HN user

pmcgoron

27 karma

Graduate Student, Georgia Institute of Technology.

Mostly write Scheme in my free time. Author of some SRFIs (https://srfi.schemers.org) and member of R7RS-Large WG2.

Scheme website: https://florida.moe

Other website: https://peter.mcgoron.com

Posts1
Comments10
View on HN

What tmtvl said is correct. However, it is also a resource problem. R7RS Large is a volunteer driven effort where if people stop having the time to contribute due to personal reasons, things slow down.

If it's the latter, is there any way a random scheme dabbler can help?

Giving your comments on drafts, issues[1], and draft SRFIs is always welcome. The decisions of the Working Group are more complete when we hear more voices.

[1] https://codeberg.org/scheme/r7rs/issues

Hello everyone.

Working Group 2 is pleased to announce the first draft of the second part of the R7RS-Large Foundations, the "Procedural Fascicle". This draft encompasses the familiar block programming forms, such as lambda, let, if, or, and set!.

The draft is available here:

https://r7rs.org/large/fascicles/proc/

The biggest new feature is the ability to mix definitions and expressions in bodies, such as the body of a lambda. For example, the following is now valid:

    (define (map f lst)
      (unless (list? lst)
        (error 'map "not a list" lst))
      (define (map* lst acc)
        (if (null? lst)
            (reverse acc)
            (map* (cdr lst) (cons (f (car lst)) acc))))
      (map* lst '()))
We welcome any and all comments on the draft. Anyone can comment by

* Filing an issue on the R7RS-Large issue tracker <https://codeberg.org/scheme/r7rs> * Sending mail to the Working Group 2 mailing list <https://groups.google.com/g/scheme-reports-wg2> (you do not need a google account) * Sending mail to the Scheme Reports mailing list <https://scheme-reports.simplelists.com/> and <scheme-reports@scheme-reports.org> * Sending mail to the corresponding member Peter McGoron at <code@mcgoron.com>. I will forward your comment to the public issue tracker. Please indicate if you wish to be anonymous.

If you want to peer into an alternative reality / funhouse mirror of programming terms, you should look at ALGOL 68. For instance, types are called "modes".

https://jemarch.net/a68-jargon/

(There are also "incestuous unions", which is the actual term used in the spec.)

From John Cowan:

TAGBODY doesn't actually require continuations, delimited or undelimited, just proper tail calling. A macro can rewrite each section of the TAGBODY into a procedure nested within a `let` that tail-calls its successor, and the body of the `let` tail-calls the first procedure. (GO tag) is then equivalent to just (tag). This is a great way of doing state machines. Chicken has a tagbody egg, I think.

As someone who writes a lot of Scheme, I agree that the math syntax is not good. There have been proposals to add infix expressions (https://srfi.schemers.org/srfi-105/) but nobody seems to want them, or can agree on specifics.

However, code that is mostly function calls is fine for me, since those would have parentheses anyways in C++/Rust/whatever. In that case it makes the language more regular, which is nice for writing macros.

I'd be curious to hear your opinion on wisp (https://srfi.schemers.org/srfi-119/srfi-119.html) and the Readable project (https://srfi.schemers.org/srfi-110/srfi-110.html) which are significant indentation syntaxes for Lisp languages that are still closely related to the AST and allow for easy macro writing.