"Andrew C. Greenberg" wrote:
> 
> >I'm not a compiler specialist, but couldn't the compiler recognize if
> >there are control structures like 'for' or 'while' which aren't allowed
> >in C construct like
> >       (expr) ? (commaSeparatedStmtList, expr) : (commaSeparatedStmtList,
> >expr);
> >? Then it could generate an error.
> 
> I'm sure it could, but what is the virtue, if any, of having a
> compiler with such peculiar semantics?  In particular, of compiling
> 
>         var := condition ifTrue: [expression].
> 
> but not
> 
>         var := cond1 ifTrue: [[cond2] whileTrue: [stmts]. expression]
> 
> ?  To my mind, it would be far less funky to have (as C has) either
> two separate syntactic constructs for the control structure and the
> conditional expression, or simply to forego the conditional
> expression.  No one denies that the Slang subset isn't a complete
> Smalltalk.  The question is whether any extensions are more
> beneficial than costly on all relevant fronts.  As "ugly" as having a
> separate #exprIfTrue:#exprIfFalse construct for translation to the C
> conditional expression may seem at first blush, I think to the extent
> the functionality is necessary,

It isn't necessary, it's just a convenient way to allow to write
	^ expr isTrue: [firstCaseExpr] ifFalse: [secondCaseExpr]
.. I often did it and stumbled over the C compiler errors then.

> it may be the clearest way to
> distinguish the two without confusing users.

If we'd prefer a Smalltalk programming style of plugins it would be best
to avoid C'ish ST constructs. But I have to admit that I have made - in
my current (first) plugin, therefore so much mails from me ;-) - very
C'ish code to improve the speed...(see summary below)

>  (Also, compiling "?:"
> and "," everwhere in lieu of "if()" and ";", while still providing a
> capacity to have control statements inside a conditional, when the
> conditional is not itself part of an expression will substantially
> complicate the compiler, but more important, would make cCode highly
> unreadable, IMHO.)

That's a point.

> Again, the issue is whether the benefits outweigh the costs.  One of
> the reasons that many of the more important changes you have
> requested thus far have been so quickly implemented derives in large
> part from the simplicity and elegance of the CCodeGenerator design.
> That simplicity has some costs, of course.  I just don't think the
> cost of rewriting the two expression above as
> 
>         condition ifTrue: [var := expression].
> 
>         cond1 ifTrue: [[cond2] whileTrue: [stmts]. var := expr]
> 
> is all that bad as compared to the cost of having the more
> "Smalltalk-like" expression semantics widely available.  And even if
> it was really necessary to support conditional expressions, you could
> always write the first expression above as:
> 
>         var := condition exprIfTrue: [expression].
> 
> after implementing the builtin, a substantially easier task than the
> one you suggested.  To me, however, the status quo feels just fine.

My suggestions came from the vision to be able to automatically compile
arbitrary ST classes to speed up them if they are finished... Do you
know the work of ST/X from Claus Gittinger?


> >My C compiler accepts constructs like:
> >
> >---
> >void vf( int arg) { printf("\nvf( %d)", arg); }
> >double df( int arg) { printf("\ndf( %d)", arg); return arg; }
> >
> >void main()
> >{
> >  int k;
> >  k = 0 == 0 ? vf(1), df(2) : df(3), df(4);
> >  printf("\nk: %d", k);
> >  k = 0 == 1 ? vf(1), df(2) : df(3), df(4);
> >  printf("\nk: %d", k);
> >  // interpreted as: ( k = (0 == num) ? (vf(1), df(2)) : df(3) ), df(4);
> >  // so it makes sense to use more braces...
> >}
> 
> This begs the question, of course.
> 
> >, so it is possible to use - not control - statements inside
> >expressions.
> 
> Function calls are most certainly C expressions.

That's true. ('func();' calls are also statements though, and then there
are also 'void' funcs.)

> > > The point of CCompiler is not to implement Smalltalk, but just a
> > > subset sufficient to express a hunk-o-code.
> >
> >But it is as easier to write plugins as more ST constructs are eaten by
> >the ST2C compiler...;-)
> 
> It also gets confusing when "the same" construct works sometimes but
> not others.

This is absolutely true.

Therefore I think most important - before further enhancements - are
error messages from the compiler if it something cannot compile!

And the #exprIfTrue/False: constructs would be a very nice addition to
the current capability of the compiler!

> >P.S.: To avoid misunderstandings: This is not a criticism of your work
> >(it is great!), but a suggestion for - possible and nice, but not
> >necessary - improvements!
> 
> The CCodeGenerator was not my work, but that of SqueakCentral, and
> Slang was one of the fundamental inventions that begat Squeak.  My
> work has been focused on tweaking it from time to time, and adding
> the ability to specify primitives.

A short summary:

There are two main developing lines:

- To be able to compile as much existing - _not_ C'ish like - ST code as
possible with as less changes as possible, and
- to give the programmer maximal flexibility in writing C'ish ST with
supporting as much C constructs as possible to gain maximal speed. I
know that it is already possible with
	self cCode: 'some C code' inSmalltalk: [some ST code].
, but this style isn't good for debugging purposes.


With best regards,

Stephan

P.S.: Here it is 20:41:42 now and I want to go out, so this is my last
mail for a while...

-- 
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3