Folks working on the Smalltalk to C Translator:

I agree with what Andrew says below. But as the guy who designed
and implemented Slang in the first place, I can't resist throwing in
a few additional words about its history and design philosophy. :->

First, one can always add features. But it takes a great
deal of restraint and good taste to NOT add every feature you can
think of. One the secrets to the portability of Squeak is that
the Smalltalk to C translator started off nearly as minimal as it
could possibly be (only about 3 dozen rules). In many cases, it
seemed better to modify the Smalltalk code to be translated rather
than adding additional features to the translator. Although we are
now using the translator to build primitives in addition to building
the VM itself, I still think it is reasonable to balance the
cost of modifying the code to be translated against the cost of
adding (and maintaining) translator features. I'm not arguing against
progress, here, just pointining out that there are several paths
to the desired goal. 

We were very conservative about the dialect of C that the translator
generates. We stuck entirely to the ANSI C standard and in at least one
case (right shifts) tried to do the least ambiguous thing even though
the spec itself does not fully define the operation. This conservative
approach has been a huge success and we should be careful not to
introduce any new feature which is not 100% ANSI C. The question
is what your compiler or my compiler does, but what the ANSI C spec
says *ALL* C compilers should do. Some C compilers have an ANSI
compatible switch; if so, that can be used to verify that we aren't
generating non-conforming code. But the safest thing is to follow
the spec. I use the Kernighan and Ritchie C manual, Second Edition.

Thanks for the recent work on the Smalltalk-to-C translator,
expecially the combined efforts of Stephan Rudlof and Andrew
Greenberg.

Happy Holidays!

	-- John



At 12:29 PM -0500 12/25/99, 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 may be the clearest way to 
>distinguish the two without confusing users.  (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.)
>
>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 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.
>
>> > 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.
>
>>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.