HackerTrans
トップ新着トレンドコメント過去質問紹介求人

pmcgoron

no profile record

投稿

Revised^7 Report on Scheme, Large: Procedural Fascicle Draft is now public

r7rs.org
34 ポイント·投稿者 pmcgoron·2 か月前·7 コメント

コメント

pmcgoron
·2 か月前·議論
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
pmcgoron
·2 か月前·議論
We plan to add delimited continuations in a later draft. What the actual API will look like is still in question. There is a proposal for a large API, like Racket's <https://srfi.schemers.org/srfi-226/> and a minimalistic API <https://srfi.schemers.org/srfi-248/> similar-ish to Guile's.
pmcgoron
·2 か月前·議論
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 <[email protected]> * Sending mail to the corresponding member Peter McGoron at <[email protected]>. I will forward your comment to the public issue tracker. Please indicate if you wish to be anonymous.
pmcgoron
·2 か月前·議論
> FL HOTDOG.MIAMI.FL.US. [email protected]

I'm very confused by this entry. There isn't even a miami subdomain, just a Dade subdomain.
pmcgoron
·4 か月前·議論
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.)
pmcgoron
·5 か月前·議論
Would SectorLISP (https://justine.lol/sectorlisp2/) count? It can run the LISP 1.5 metacircular evaluator.
pmcgoron
·5 か月前·議論
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.
pmcgoron
·5 か月前·議論
I guess I'll have to read more about effect handling systems, I'm very much out of my element there.

> yes, macros are hygienic!

I'm glad. Too many lisps chicken out and don't add them.

> easier to type!

Fair enough.

This seems very interesting, I will check it out.
pmcgoron
·5 か月前·議論
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.
pmcgoron
·5 か月前·議論
1. I don't know much about HM systems mathematically, but how do the effect handlers interact with type inference? I thought there was some issues with automatic inference there.

2. The macros examples on the website don't show binding situations. Are the macro hygienic like in Scheme?

3. Why the choice of [] over ()?