On 1/16/13, David A. Wheeler <dwhee...@dwheeler.com> wrote:
> Alan Manuel Gloria:
>
>> Okay, the *semantics* is confusing to me.
>>
>> How are the following suppose to parse?
>
> The answer is, "whatever we decide it should be" :-). So now is a perfect
> time to discuss it. And if some combination seems to be nonsense, we can
> declare it an error.
>
> BTW, Don't pay serious attention to the sweet.g file's action statements for
> restart_list. I'm doing a lot of experiments with them and they're almost
> certainly "wrong" right now. So with that caveat...
>
>> library foo
>> <* begin
>>
>> define cat 'meow
>>
>> define dog 'woof
>>
>> *>
>>
>> I assume:
>>
>> (library foo
>> (begin
>> (define cat 'meow)
>> (define dog 'woof)
>> )
>
> Yes, that's what I think too.
>
> But that's if we allow same-line and later-lines simultaneously at *all*.
> My current draft BNF *does* allow this (by intent), but if the semantics are
> too complicated, we could just say either (1) it must be all on one line, or
> (2) the start has to be followed by hspace* comment_eol.
>
> But let's continue the thought...
>
>> But what happens with this?
>>
>> library foo
>> <* begin print(x)
>>
>> define cat 'meow
>> define dog 'woof
>>
>> *>
>
> To be honest, I don't know of a use case that suggests any particular
> semantic. I can image that this *might* mean:
>
> (library foo
> (begin
> (print x)
> (define cat 'meow)
> (define dog 'woof)))
>
> Though perhaps other semantics would make sense.
>
>> How about this?
>>
>> let <* x 5 *> { x + 42 }
>
> I think t that should mean:
> (let ((x 5)) (+ x 42)
>
> Basically, <*...*> wraps an extra () around an expression. Since "x 5" means
> (x 5), "<* x 5 *>" == ((x 5)). And since what follows <*...*> is just
> another parameter, that parameter should be treated normally.
>
>> Or worse, this?
>>
>> let <*x y
>> w z *>
>> 42
>
> I'm guessing that should perhaps be:
> (let (x y (w z)) 42)
>
> Perhaps we'd better off to not allow stuff to be on both the same line and
> on later lines, at least at first. The "library definition" use case and
> the "let" use case are easily distinguished that way. That might mean you'd
> have a multi-line statement with a "begin" on its own line, but if it's a
> long sequence of definitions, that may not be a big deal.
>
Okay here's the concrete semantics I propose:
1. The "head" production is the part that looks for the <*. Upon
finding a <*, it consumes any number of horizontal spaces, line
comments, and multiline/datum comments. It then enters "superlist"
production
2. "superlist" just calls the top-level "i_expr" repeatedly, creating
a list of items, and terminating upon finding a *>, returning the
yielded list.
3. When "superlist" returns, "head" just takes its returned value and
takes it as a single item, and continues on its merry way looking for
n-expressions and superlists after the *>.
The third part allows:
let <* x 5 \\ y 6 *> {x + y}
>> You know, maybe we should call it "SUPERLIST" in contrast with "SUBLIST".
>> ^^;;;
>
> You're smiling, but that's not an entirely insane name. It's hard to think
> of a good name for this.
MEGALIST
UBERLICHST
OVERLYPRETENTIOUSADJECTIVELIST
Sincerely,
AmkG
------------------------------------------------------------------------------
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612
_______________________________________________
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
