[M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?]

[Tony Hosking]

Not to rain on this parade, but I hate the idea of Swiss-Army-knife  
programs that do a multitude of tasks.  Better to have a program do  
one thing well (and correctly) than many things badly (incorrectly).   
So the notion of one compiler handling two syntaxes does not sit well  
with me.  Why not just a preprocessor from C-like syntax, which  
observes Modula-3 typing and semantics, into regular Modula-3?  But,  
I echo Olaf's point -- there are way more important things to be  
worrying about than the color of the ceiling tiles, or in this case  
syntactic sugar.

On Feb 17, 2008, at 1:03 PM, Olaf Wagner wrote:

> I'd rather not go this way and change the complete syntax and
> convert to and fro between the two. If we really want to do that,
> I'd rather have it as something like a compatible extension (as far
> as possible).
>
> What about changing only the keywords from uppercase to lowercase
> and using {} instead of BEGIN END? I'm not sure if that would
> satisfy the C-adherents, and I'm also not sure if it would
> introduce syntactic ambiguities, as {} are also used for sets.
> I'd like to keep the changes to the syntactical structure minimal
> (upper- and lowercase is only lexical matter after all). The abstract
> syntax should be kept as it is.
>
> If something like this would be possible, I'd vote for supporting
> both syntaxes in one compiler and turn on the C-style by a comment
> or automatically by recognizing the first word of a module. I'd not
> support mixing of styles within one module.
>
> Olaf
>
> PS: I'm not really suggesting we do this now, I just wanted to comment
>     on the possibility of doing something like this. Anyway it will
>     depend on somebody who provides appropriate patches and updates
>     the language specification etc.
>
> Quoting Mika Nystrom <mika at async.caltech.edu>:
>
>> Well I used to be mostly a C programmer but I long since weaned
>> myself off that syntax :)
>>
>> Your point of the post- and pre-increment might be a bit difficult
>> for C programmers to stomach, but... well it is probably hard to
>> tell what programmers will hate and what they will love.
>>
>> Wouldn't a way to go about it be to take the Modula-3 BNF and modify
>> the rules as needed?  Would you like to be able to convert back and
>> forth (why not), e.g., using m3tk (m3pp?)?  You have to lower-case
>> all the keywords, convert the braces appropriately (a bit tricky
>> since Modula-3 has abandoned the Pascal/Algol FOR i := 0 TO 10 DO
>> BEGIN END, so braces map only to the ENDs, not BEGINs (for the most
>> part)).
>>
>> Type "attributes"(is that the right word?) are also an area where
>> Modula-3 is significantly different from the C family.  In C, you
>> write
>>
>> int *a, *b, c;
>>
>> we have
>>
>> REF INTEGER a, b;
>> INTEGER c;
>>
>> And arrays?
>>
>> VAR arr : REF ARRAY OF ARRAY [FIRST(SomeEnum)..LAST(SomeEnum)] OF  
>> ARecord;
>>
>> ARecord *arr[][first(SomeEnum)..last(SomeEnum)];
>>
>> I prefer Algol syntax myself but I could definitely see that there
>> might be people who would prefer a syntax mapped to C.  One might
>> be able to sneak Modula-3 into places where it wouldn't otherwise
>> be used...
>>
>> Would it be possible to make "m3c" close enough in syntax that some
>> simple C header files could be processed?  Am I just being ridiculous
>> now?  A compiler that can process both C and Modula-3 in the same
>> file?
>>
>> Python, by the way, provides some interesting hooks for C programs
>> to interact with the Python garbage collector.  Something similar
>> could be done here.  (But there is far less reason to write C code
>> to plug into M3 than there is to write it to plug into Python.)
>>
>>     Mika
>>
>>
>> Darko writes:
>>> If you like the idea, maybe you'd like join me in working out what
>>> such a syntax would look like? Note that I want to keep the  
>>> structure
>>> the same, so no assignments in expressions, for example. Also,  
>>> would C
>>> programmers revolt at not having post and pre increment, also inside
>>> expressions (as statements would be ok)? Requiring some sort of EVAL
>>> statement? I guess the big question is whether removing these things
>>> would make the whole idea unacceptable to the target audience. Does
>>> the Algol syntax serve a purpose in making it clear that it isn't C?
>>>
>>>
>>> On 16/02/2008, at 8:42 PM, Mika Nystrom wrote:
>>>
>>>>
>>>> "If Steve Bourne could turn C into Algol using cpp, I'm sure you
>>>> can figure out how to turn Algol[Modula] back into C using  
>>>> <...>"...
>>>>
>>>> If you think it would help acceptance of Modula-3, I don't see why
>>>> not?
>>>>
>>>> I copied the code exactly the way it came off the old half-inch
>>>> tape from Berkeley.
>>>>
>>>> Darko writes:
>>>>> I'm not sure what you're getting at or if I'm missing something
>>>>> witty.
>>>>> I've said the form of the keywords makes little or no  
>>>>> difference in
>>>>> my
>>>>> opinion. In my mail you quote I say there should be a C like  
>>>>> syntax
>>>>> for M3 as well as the existing one. I wasn't being sarcastic.  
>>>>> It's a
>>>>> matter of taste. I write in both all the time and it doesn't  
>>>>> have any
>>>>> impact on me, I go almost entirely by indentation, which I  
>>>>> think is
>>>>> very important. The indentation is pretty awful in code you posted
>>>>> but
>>>>> it could me my mailer.
>>>>>
>>>>> On 16/02/2008, at 10:51 AM, Mika Nystrom wrote:
>>>> ...
>>
>
>
>
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>                Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin,  
> Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23  
> 45 86 95
>    http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz:  
> Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:  
> DE163214194
>