syntax changes (srfi-107/108/109)
Per Bothner
(29 Dec 2012 21:43 UTC)
|
Re: syntax changes (srfi-107/108/109)
John Cowan
(30 Dec 2012 03:22 UTC)
|
Re: syntax changes (srfi-107/108/109)
John Cowan
(30 Dec 2012 03:37 UTC)
|
Re: syntax changes (srfi-107/108/109) Per Bothner (30 Dec 2012 04:45 UTC)
|
Re: syntax changes (srfi-107/108/109)
John Cowan
(31 Dec 2012 07:37 UTC)
|
Re: syntax changes (srfi-107/108/109)
Per Bothner
(31 Dec 2012 08:42 UTC)
|
Re: syntax changes (srfi-107/108/109) Per Bothner 30 Dec 2012 04:45 UTC
On 12/29/2012 07:22 PM, John Cowan wrote: > Per Bothner scripsit: >> There is a seeming ambiguity, since in Scheme the character '&' >> is a valid symbol character. However, a symbol followed >> immediately by either '{' or '[' is not defined by standard >> Scheme, so this is a conflict-free extension. > > Unfortunately, &condition[car '(a b c)] is perfectly well-defined > R6RS lexical syntax, where [] means the same as () and symbols > beginning with ampersands are actually standard for names of > condition types. I don't say it should be that way, but it is. Technically, it's well-defined R6RS lexical syntax, but it would be horrible style. First, people would normally put a space before the '['. Secondly, I don't see '[...]' used much except for "clauses" (rather than expressions), and if '[...]' is used only for such clauses (as I see in the Racket documentation) that doesn't seem like it would conflict. >> §ion{News as of &(current-date)} > > This being, I presume, shorthand for §ion{News as of &[(current-date)]}. Correct. >> + Kawa has this syntax for a vector constructor: >> [e1 e2 ... en] >> This is the same as `#(,e1 ,e2 ... ,en), which is the same as >> (vector e1 e2 .. en) except producing an immutable vector. > > More to the point, the last is code, whereas the first two are > lexical syntax and therefore work in data. I think it's important > to always keep the data applications firmly in mind. > [LATER] > Hmm, it seems I was wrong. [a b c] complains of undefined variables, > so it really is (vector a b c), whereas #(a b c) is indeed lexical syntax. Right - the e1 ... en are (in Kawa) expressions that are evaluated. And `#(,e1 ,e2 ... ,en) is *not* lexical syntax that works in data. At least not in any meaningful sense. (The reader does return a form, just like it does for [e1 e2 ... en], but it doesn't seem useful except in expression context.) -- --Per Bothner xxxxxx@bothner.com http://per.bothner.com/