[Omake] Should we add some sort of "syntax" parser directive?

[Aleksey Nogin]

On 30.10.2007 17:25, Jason Hickey wrote:

> The .SYNTAX seems like a reasonable choice, or maybe .LANGUAGE instead.

I like the .LANGUAGE - I think it would be more obvious what that means.

> Note that in the current implementation, the syntax doesn't change, it
> is just how it is interpreted.  This means 1) parsing will succeed as
> long as you use OMakefile syntax, but 2) errors can occur during
> semantic analysis.
> 
> A related property is that the language is scoped.
> 
>    CFILES = $(addsuffix .c, $(FILES))
>    section
>        .LANGUAGE: program
>        OFILES = addsuffix(.o, FILES)
>    # Back to old syntax

Yes, I figured that out.

BTW, I was thinking along the lines that ".LANGUAGE: make: 0" is for
language without "=>" (_with_ support for old-style foreach), while
".LANGUAGE: make: 1" is language with "=>" ... and files that do not use
foreach can then be annotated ".LANGUAGE: make: 0-1". Not that it
matters much, as, hopefully all the foreach'es will get quickly converted...

>> If we settle on this approach, it would probably be a good idea to add
>> it to 0.9.8.x now to ensure that an attempt to use program syntax in a
>> any future pre-syntax version of OMake would result in a meaningful
>> error message.
> 
> I've been thinking it might be better to include syntax on the trunk
> also.  It seems like it is in the general topic of language
> improvements, like keyword arguments.  Another very nice thing about
> syntax is that whitespace is handled at parse time.  Say goodbye to
> character-by-character whitespace analysis.  There is minor performance
> improvement, but large improvement in designer satisfaction.

I agree that we should land the syntax branch soon. I was hoping we'd
make a quick 0.9.8.7 with the syntax branch landing and fixes for
whatever bugs that would inevitably get reported right after the release
of 0.9.8.6. While we could delay 0.9.8.6 a bit and do it all at once, I
think that the "release early, release often" strategy is the right one
here.

Aleksey