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
    (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.

> 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.

--- David A. Wheeler

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: 
Readable-discuss mailing list

Reply via email to