Hi Adam,

in another thread, you give the following example

(nest
  (let ((foo bar)) _)
  (parameterize ((baz qux)) _)
  (call/cc _)
  (lambda (fhqwhgads) _)
  (when (move zig) _)
  (do the thing))

as a use case for "nest". In the above example, "(let ((foo bar)) _)" is not an application with some placeholder inside but a special form. In the syntax you give below, you say, however, <step> is a list (an application).

So, is each <step> supposed to be of the form (<datum> ...), where exactly one <datum> has to be the identifier _ (in the sense of free-identifier=?)?

But then you don't need custom placeholders for nested uses of nest.

Marc

Am Fr., 28. Aug. 2020 um 04:29 Uhr schrieb Adam Nelson <xxxxxx@nels.onl>:

By formal specification, you mean something that looks like the definitions in section 4 (Expressions) of the R7RS document, right?

Here are some signatures of nest and nest-reverse, in the meantime:

(nest <step> ... <initial-value>)

(nest <placeholder> <step> ... <initial-value>)

(nest-reverse <initial-value> <step> ...)

(nest-reverse <initial-value> <placeholder> <step> ...)

Where each <step> is a list (an application) containing exactly one placeholder. A placeholder is the symbol _, but, if <placeholder> is provided, it replaces _ as the placeholder symbol.

On 8/24/20 6:15 AM, Marc Nieper-Wißkirchen wrote:

Adam, thank you very much for all the hard work. 

Before I can finally evaluate the nest forms, though, I'd like to ask you to add a formal specification as it is done for the special forms in R7RS. The current description is rather vague and it is not at all clear (at least to me) what the arguments of nest (and nest-reverse) are allowed to be.

Please update the description so that we have a full specification and so that I still have a few days to review.

Thanks a lot!

Marc

Arthur A. Gleckler <xxxxxx@speechcode.com> schrieb am So., 23. Aug. 2020, 20:13:

I've just published draft #3 of SRFI 197. It was submitted by Adam Nelson, author of the SRFI.

Adam has asked me to announce last call for this SRFI. He believes that it is ready for finalization, but would like to give reviewers one last chance to submit corrections and feedback before we finalize it.

In particular, I appeal to anyone reading this to try the sample implementation, run the tests, and send feedback about your results.

If you're interested in this SRFI, please give your feedback via the SRFI 197 mailing list before 2020-08-31. After that, assuming that no major revisions are required, we will declare it final. It is important that we get your feedback before 2020-08-31. If that deadline is too soon for you, but you would like to contribute, please let me know so that I can extend the last-call period.

Here are Adam's comments on the draft:

I have a third and hopefully final draft of SFRI 197 ready. This should be marked as a last call for comments, too.

Notable changes:

• Name has been changed again, to "Pipeline operators".
• Placeholder syntax has been changed from `<>` and `<…>` to `_` and `_ …`.
• There is no longer an implicit final argument in `chain` steps with no argument placeholders. A step with no `_` will now ignore the result of the last step.
• Clarified that `chain` produces a `let*` form and does not literally nest expressions.
• Added `nest` and `nest-reverse` operators that do literally nest expressions.
• Enabled syntax highlighting in code blocks.
• Removed nonfunctional Copy buttons from code blocks. (I don't know why Notable includes these but doesn't include a script for them…)

Here is the commit summary:

• Update sample implementation.
• new draft
• Fix errors reported by W3C HTML Validator.
• Update sample implementation to Draft 3
• Update name in README
• Update implementation link to point to repository root
• Remove unused Material Icons font
• Use standard format.

Here's the diff:

https://github.com/scheme-requests-for-implementation/srfi-197/compare/draft-2..draft-3

Regards,


SRFI Editor