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

[Jay]

I've been trying to stay out of this...
 
If a comment at the top of the file can make the Modula-3 syntax more like C then..
 
 replace = with ==
 replace := with = 
 make assignment an expression 
 lowercase the keywords 
  try to make braces work (with some alteration for C) 
 use type name instead of name : type 
 separate function parameters with commas and require each to state its type 
  for that matter, subset C and require all declarations be separate like that?
 put back ++, --, -=, +=, etc. 
 superset C and let . be used in place of -> 
 new coding style is four space indent with opening braces on their own line :) 
 
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?
 
  Pick apart what defines Modula-3 through much discussion.
  Optional safety -- probably but that for these purposes 
  optional garbage collection  -- maybe that too 
  "object orientation" that is a subset of C++ 
    try to use C++ syntax? 
  generics (generic modules) 
  independently and relatively easily parsable interface definitions (!) 
    these are both important, but I think "independent" is more important 
    and "relatively easily" could be omitted for the goals of this exercise 
  compiles to native code 
  sizeof(integer) == sizeof(address) (minor detail) 
  built in sets and good enumerations 
  arrays; I don't like them starting at non-zero, but enums for their index are interesting 
 
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.
 
That is, this is a large exercise, but:
  if you keep optional safety, define what is safe, basically the same as in Modula-3 
  determine syntax for enums, arrays, sets 
 
Write a front end for it. Boom. Right there my patience wouldn't get far. 
Make it ABI compatible with Modula-3.
Heck, start with the existing front end MAYBE.
 
Compatibility with SOME existing code should be a goal.
Compatibility with headers is problematic but very useful.
This front end could help translation of headers to "independently parsable" form.
 
(SWIG is the name of the thing someone mentioned the other day but had the name wrong.)
 
Look into the D language.
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...
 
 - Jay



> Date: Sun, 17 Feb 2008 19:03:17 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?]> > 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> 
_________________________________________________________________
Helping your favorite cause is as easy as instant messaging. You IM, we give.
http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080218/93e11b24/attachment-0002.html>