Email list hosting service & mailing list manager

Re: Properly phased lexical syntax extension, read-time evaluation, and HashDot Scheme Jakub T. Jankiewicz (02 Apr 2021 07:19 UTC)

Re: Properly phased lexical syntax extension, read-time evaluation, and HashDot Scheme Jakub T. Jankiewicz 02 Apr 2021 07:19 UTC

> If you remember, we have two use cases: an entirely separate syntax (for
> which #lang is appropriate) and incremental extensions to existing
> syntaxes.  The #. proposal is meant for the second case only.
>
> > 1 2 #.(my-reader "3 4 5") 6 7
> >
>
> This makes editor syntax coloring, paren matching, etc. impossible, since
> everything would look like a string.

I don't think that there will be any benefits with syntax like this, is
the same as writing read function yourself and call it on string.

(my-reader "3 4 5")

Having to use string on any new syntax is not very nice. My original idea was
to add new syntax that looks the same as built-in syntax.

This is any better then #,(foo 1 2 3) if you register function my-reader you
have exactly the same #,(my-reader "3 4 5")

I don't see any benefits of extending the parser if you're required to call
it like this. You can't use it to add missing syntax that was or will be
added to the language via R^nRS or SRFI.

You can't add #u16 to the language if it don't have it already with this.

--
Jakub T. Jankiewicz, Web Developer
https://jcubic.pl/me