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.

>> &section{News as of &(current-date)}
>
> This being, I presume, shorthand for &section{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/