<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>Some corrections..<BR><BR><BR>
try to make braces work (with some alteration for C) <BR>
>> for SETS<BR><BR>
Optional safety -- probably but that for <EM>these purposes</EM> <BR> optional garbage collection -- maybe that too <BR><BR>
"but" should say "punt"<BR>
That is, this dialect of C that has some Modula-3 features, might have optional safety, or even garbage collection.<BR>
<BR>
- Jay<BR><BR><BR><BR>
<BLOCKQUOTE>
<HR id=EC_stopSpelling>
From: jayk123@hotmail.com<BR>To: wagner@elegosoft.com; m3devel@elegosoft.com<BR>Subject: RE: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?]<BR>Date: Mon, 18 Feb 2008 04:26:17 +0000<BR><BR>
<META content="Microsoft SafeHTML" name=Generator>
<STYLE>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass EC_body.hmmessage
{font-size:10pt;font-family:Tahoma;}
</STYLE>
I've been trying to stay out of this...<BR> <BR>If a comment at the top of the file can make the Modula-3 syntax more like C then..<BR> <BR> replace = with ==<BR> replace := with = <BR> make assignment an expression <BR> lowercase the keywords <BR> try to make braces work (with some alteration for C) <BR> use type name instead of name : type <BR> separate function parameters with commas and require each to state its type <BR> for that matter, subset C and require all declarations be separate like that?<BR> put back ++, --, -=, +=, etc. <BR> superset C and let . be used in place of -> <BR> new coding style is four space indent with opening braces on their own line :) <BR> <BR>Hm. I think if anyone really wants to do this, instead of nit picking about Modula-3 syntax here and there, go about it in a slightly different way?<BR> <BR> Pick apart what defines Modula-3 through much discussion.<BR> Optional safety -- probably but that for <EM>these purposes</EM> <BR> optional garbage collection -- maybe that too <BR> "object orientation" that is a subset of C++ <BR> try to use C++ syntax? <BR> generics (generic modules) <BR> independently and relatively easily parsable interface definitions (!) <BR> these are both important, but I think "independent" is more important <BR> and "relatively easily" could be omitted for the goals of this exercise <BR> compiles to native code <BR> sizeof(integer) == sizeof(address) (minor detail) <BR> built in sets and good enumerations <BR> arrays; I don't like them starting at non-zero, but enums for their index are interesting <BR> <BR>Take the existing definition of C and alter it to have these characteristics very very much like Modula-3 but with very very very much Modula-3 syntax.<BR> <BR>That is, this is a large exercise, but:<BR> if you keep optional safety, define what is safe, basically the same as in Modula-3 <BR> determine syntax for enums, arrays, sets <BR> <BR>Write a front end for it. Boom. Right there my patience wouldn't get far. <BR>Make it ABI compatible with Modula-3.<BR>Heck, start with the existing front end MAYBE.<BR> <BR>Compatibility with SOME existing code should be a goal.<BR>Compatibility with headers is problematic but very useful.<BR>This front end could help translation of headers to "independently parsable" form.<BR> <BR>(SWIG is the name of the thing someone mentioned the other day but had the name wrong.)<BR> <BR>Look into the D language.<BR>It might be just the ticket... you MIGHT find that it has all the aspects of Modula-3 that any of you desire, and more...<BR> <BR> - Jay<BR><BR><BR>
<HR id=EC_stopSpelling>
<BR>> Date: Sun, 17 Feb 2008 19:03:17 +0100<BR>> From: wagner@elegosoft.com<BR>> To: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?]<BR>> <BR>> I'd rather not go this way and change the complete syntax and<BR>> convert to and fro between the two. If we really want to do that,<BR>> I'd rather have it as something like a compatible extension (as far<BR>> as possible).<BR>> <BR>> What about changing only the keywords from uppercase to lowercase<BR>> and using {} instead of BEGIN END? I'm not sure if that would<BR>> satisfy the C-adherents, and I'm also not sure if it would<BR>> introduce syntactic ambiguities, as {} are also used for sets.<BR>> I'd like to keep the changes to the syntactical structure minimal<BR>> (upper- and lowercase is only lexical matter after all). The abstract<BR>> syntax should be kept as it is.<BR>> <BR>> If something like this would be possible, I'd vote for supporting<BR>> both syntaxes in one compiler and turn on the C-style by a comment<BR>> or automatically by recognizing the first word of a module. I'd not<BR>> support mixing of styles within one module.<BR>> <BR>> Olaf<BR>> <BR>> PS: I'm not really suggesting we do this now, I just wanted to comment<BR>> on the possibility of doing something like this. Anyway it will<BR>> depend on somebody who provides appropriate patches and updates<BR>> the language specification etc.<BR>> <BR>> Quoting Mika Nystrom <mika@async.caltech.edu>:<BR>> <BR>> > Well I used to be mostly a C programmer but I long since weaned<BR>> > myself off that syntax :)<BR>> ><BR>> > Your point of the post- and pre-increment might be a bit difficult<BR>> > for C programmers to stomach, but... well it is probably hard to<BR>> > tell what programmers will hate and what they will love.<BR>> ><BR>> > Wouldn't a way to go about it be to take the Modula-3 BNF and modify<BR>> > the rules as needed? Would you like to be able to convert back and<BR>> > forth (why not), e.g., using m3tk (m3pp?)? You have to lower-case<BR>> > all the keywords, convert the braces appropriately (a bit tricky<BR>> > since Modula-3 has abandoned the Pascal/Algol FOR i := 0 TO 10 DO<BR>> > BEGIN END, so braces map only to the ENDs, not BEGINs (for the most<BR>> > part)).<BR>> ><BR>> > Type "attributes"(is that the right word?) are also an area where<BR>> > Modula-3 is significantly different from the C family. In C, you<BR>> > write<BR>> ><BR>> > int *a, *b, c;<BR>> ><BR>> > we have<BR>> ><BR>> > REF INTEGER a, b;<BR>> > INTEGER c;<BR>> ><BR>> > And arrays?<BR>> ><BR>> > VAR arr : REF ARRAY OF ARRAY [FIRST(SomeEnum)..LAST(SomeEnum)] OF ARecord;<BR>> ><BR>> > ARecord *arr[][first(SomeEnum)..last(SomeEnum)];<BR>> ><BR>> > I prefer Algol syntax myself but I could definitely see that there<BR>> > might be people who would prefer a syntax mapped to C. One might<BR>> > be able to sneak Modula-3 into places where it wouldn't otherwise<BR>> > be used...<BR>> ><BR>> > Would it be possible to make "m3c" close enough in syntax that some<BR>> > simple C header files could be processed? Am I just being ridiculous<BR>> > now? A compiler that can process both C and Modula-3 in the same<BR>> > file?<BR>> ><BR>> > Python, by the way, provides some interesting hooks for C programs<BR>> > to interact with the Python garbage collector. Something similar<BR>> > could be done here. (But there is far less reason to write C code<BR>> > to plug into M3 than there is to write it to plug into Python.)<BR>> ><BR>> > Mika<BR>> ><BR>> ><BR>> > Darko writes:<BR>> >> If you like the idea, maybe you'd like join me in working out what<BR>> >> such a syntax would look like? Note that I want to keep the structure<BR>> >> the same, so no assignments in expressions, for example. Also, would C<BR>> >> programmers revolt at not having post and pre increment, also inside<BR>> >> expressions (as statements would be ok)? Requiring some sort of EVAL<BR>> >> statement? I guess the big question is whether removing these things<BR>> >> would make the whole idea unacceptable to the target audience. Does<BR>> >> the Algol syntax serve a purpose in making it clear that it isn't C?<BR>> >><BR>> >><BR>> >> On 16/02/2008, at 8:42 PM, Mika Nystrom wrote:<BR>> >><BR>> >>><BR>> >>> "If Steve Bourne could turn C into Algol using cpp, I'm sure you<BR>> >>> can figure out how to turn Algol[Modula] back into C using <...>"...<BR>> >>><BR>> >>> If you think it would help acceptance of Modula-3, I don't see why<BR>> >>> not?<BR>> >>><BR>> >>> I copied the code exactly the way it came off the old half-inch<BR>> >>> tape from Berkeley.<BR>> >>><BR>> >>> Darko writes:<BR>> >>>> I'm not sure what you're getting at or if I'm missing something<BR>> >>>> witty.<BR>> >>>> I've said the form of the keywords makes little or no difference in<BR>> >>>> my<BR>> >>>> opinion. In my mail you quote I say there should be a C like syntax<BR>> >>>> for M3 as well as the existing one. I wasn't being sarcastic. It's a<BR>> >>>> matter of taste. I write in both all the time and it doesn't have any<BR>> >>>> impact on me, I go almost entirely by indentation, which I think is<BR>> >>>> very important. The indentation is pretty awful in code you posted<BR>> >>>> but<BR>> >>>> it could me my mailer.<BR>> >>>><BR>> >>>> On 16/02/2008, at 10:51 AM, Mika Nystrom wrote:<BR>> >>> ...<BR>> ><BR>> <BR>> <BR>> <BR>> -- <BR>> Olaf Wagner -- elego Software Solutions GmbH<BR>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<BR>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<BR>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin<BR>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<BR>> <BR><BR><BR>
<HR>
Helping your favorite cause is as easy as instant messaging. You IM, we give. <A href="http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join" target=_blank>Learn more.</A> </BLOCKQUOTE><br /><hr />Connect and share in new ways with Windows Live. <a href='http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008' target='_new'>Get it now!</a></body>
</html>