Syntax extensions
Jakub T. Jankiewicz
(05 Mar 2021 20:44 UTC)
|
Re: Syntax extensions
Marc Nieper-Wißkirchen
(06 Mar 2021 09:10 UTC)
|
Re: Syntax extensions
Amirouche Boubekki
(06 Mar 2021 09:23 UTC)
|
Re: Syntax extensions
Jakub T. Jankiewicz
(06 Mar 2021 14:26 UTC)
|
Re: Syntax extensions
Marc Nieper-Wißkirchen
(06 Mar 2021 14:43 UTC)
|
Re: Syntax extensions
Jakub T. Jankiewicz
(06 Mar 2021 16:03 UTC)
|
Re: Syntax extensions
Marc Nieper-Wißkirchen
(06 Mar 2021 16:20 UTC)
|
Re: Syntax extensions
Marc Nieper-Wißkirchen
(07 Mar 2021 22:08 UTC)
|
Re: Syntax extensions
Jakub T. Jankiewicz
(08 Mar 2021 07:47 UTC)
|
Re: Syntax extensions
Marc Nieper-Wißkirchen
(08 Mar 2021 08:25 UTC)
|
Re: Syntax extensions
John Cowan
(15 Mar 2021 02:54 UTC)
|
Re: Syntax extensions
Jakub T. Jankiewicz
(15 Mar 2021 08:01 UTC)
|
Re: Syntax extensions
Marc Nieper-Wißkirchen
(15 Mar 2021 15:53 UTC)
|
Re: Syntax extensions
Adam Nelson
(16 Mar 2021 12:07 UTC)
|
Re: Syntax extensions
Marc Nieper-Wißkirchen
(16 Mar 2021 12:50 UTC)
|
Re: Syntax extensions
Jakub T. Jankiewicz
(16 Mar 2021 16:37 UTC)
|
Re: Syntax extensions
Marc Nieper-Wißkirchen
(16 Mar 2021 17:12 UTC)
|
Re: Syntax extensions
Jakub T. Jankiewicz
(16 Mar 2021 17:31 UTC)
|
Re: Syntax extensions
Marc Nieper-Wißkirchen
(16 Mar 2021 19:53 UTC)
|
Re: Syntax extensions
John Cowan
(18 Mar 2021 20:10 UTC)
|
Re: Syntax extensions
Marc Nieper-Wißkirchen
(18 Mar 2021 21:36 UTC)
|
Re: Syntax extensions
John Cowan
(19 Mar 2021 04:18 UTC)
|
Re: Syntax extensions
Marc Nieper-Wißkirchen
(19 Mar 2021 06:43 UTC)
|
Re: Syntax extensions
Jakub T. Jankiewicz
(19 Mar 2021 08:04 UTC)
|
Re: Syntax extensions
Marc Nieper-Wißkirchen
(19 Mar 2021 08:12 UTC)
|
Re: Syntax extensions
Marc Nieper-Wißkirchen
(15 Mar 2021 15:42 UTC)
|
Re: Syntax extensions
John Cowan
(18 Mar 2021 00:38 UTC)
|
Re: Syntax extensions
Marc Nieper-Wißkirchen
(18 Mar 2021 06:36 UTC)
|
Re: Syntax extensions Amirouche Boubekki (06 Mar 2021 09:47 UTC)
|
Re: Syntax extensions
Jakub T. Jankiewicz
(20 Aug 2021 21:03 UTC)
|
Re: Syntax extensions
Marc Nieper-Wißkirchen
(20 Aug 2021 21:18 UTC)
|
Hello Jakub and all :-) I think this conversation is related to yellow docket [0] [0] https://github.com/johnwcowan/r7rs-work/blob/master/ColorDockets.md#yellow-docket-syntax Le ven. 5 mars 2021 à 21:44, Jakub T. Jankiewicz <xxxxxx@onet.pl> a écrit : > > Hi, > > I plan to work on new SRFI I would know what you think about my idea. > I've already implemented first idea in my Scheme based lisp called LIPS > written in JavaScript. > > The feature I want to work on is called syntax extensions is the way to add > new syntax like build in , ' ` ,@ that work exactly the same, that would > allow users to modify the parser/reader. The feature work similar to > compiler extensions in Common Lisp. You define the mapping - string of one or > more characters and symbol for a function or macro that will be called when > parser/reader will read the token with S-Expression that immediately follow > the token. I want to chime in as a Scheme user, a newbie Scheme implementer or even more newbie language designer. A large part of my appeal to Scheme is the "no syntax" or "absence of syntax" or more commonly written as "the code is the ast". Adding more literal representations, even more so the ability to create per program ad-hoc literal representation reduces both the ease of learning scheme, and the ability to move from one code base to the other. Also, it is a second hand view, and also my understanding from reading the specification that a compliant reader is already complex. Adding reader hooks will make the implementation of Scheme more complicated, without much added value. My arguments are not tradition and not historical, it is about what are great strengths of standard Scheme in that case simple syntax, small set of literals.