Re: Revised syntax question

[Brian Rogoff <bpr@best.com>]

On Tue, 26 Sep 2000, Gerard Huet wrote:
[snip]
> I hate this return, and actually I do not like this dangling e4. Every 
> imperative programming language I used had a list of statements construct,
> and from LISP onwards we know how to mix imperative statements and values
> (good old progn !). Semantic ayatollahs notwithstanding, it makes perfect
> sense to interpret the sequence (s1 ; s2 ; ... ; sn) with operator ";" piping
> the state of its first argument into the second one, and returning the value
> of the second one. Furthermore it is consistent with the rest of the syntax
> to use good old parentheses as begin-end brackets. 

I think you mentioned this approach before in an e-mail. Let's discuss
it. Out of curiosity, why do you hate the return form? 

Do you still keep a "do" for loops in your syntax? One of my goals 
was to unify the syntaxes for looping and sequencing a bit. 

Daniel de Rauglaudre also mentioned the issue with "let" in the imperative 
construction. I admit that having a "do ... done e" construct makes 
translation of some of them heavier syntactically. I'm not convinced this 
is necessarily bad, but I'm open to reasoned arguments that it is too
much.

> EXTEND the revised syntax with a 5 line entry for expr at LEVEL "simple".
> 
> I usually indent my code
>     ( statement 1
>     ; statement 2
>     ...
>     ; statement n
>     )
> nicely symmetrical to 
>     match foo with   (or fun or try expr with)
>       [ case 1
>       | case 2
>       ...
>       | case n
>       ]
> and I read "begin" for "(", "then" for ";" and "end" for ")", although
> sometimes I say "returned" when I want to emphasise the returned value.
> 
> I'll be glad to communicate the 5 lines of camlp4 to whoever wants to try
> this syntax; but all flame should be sent to /dev/null

Sure I'm interested. No need for the warning, I don't think a discussion
of Revised syntax will degrade to flames as there probably aren't enough
users. Given that, we have a great opportunity to make the syntax as good 
as can be. I'm not yet wedded to any particular syntax, so I'd be happy
to try yours.

-- Brian