"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...
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)
Slang is neither C nor Smalltalk. Necessarily, its a bit of each.
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?
That would be well beyond the scope of the present system. Perhaps in time we can consider building a full native Smalltalk with threaded access to the VM routines. It isn't likely that the present code will ever directly evolve to such a system. (On the other hand, there is no reason the parser front-end can't evolve to such a thing.)
The promise of SqC is that Jitter will in time give us a sufficient performance boost as to obviate any need to do that sort of thing.
Therefore I think most important - before further enhancements - are error messages from the compiler if it something cannot compile!
Perhaps. Some documentation would be a good thing too. Perhaps you can help us out on that front?
Merry Christmas everyone.
"Andrew C. Greenberg" wrote:
Perhaps. Some documentation would be a good thing too. Perhaps you can help us out on that front?
At the moment I'm working at a first release of a LargeIntegers (arithmetics) plugin; I want to take it out before Y2K! But after that I can write some docs. I'm freshly in the perspective of a plugin newby, so this could be the best time to write these docs.
Merry Christmas,
Stephan
Just a completely unimportant note, albeit interesting IMO, and also remembering Alan Kay's previous comments about Smalltalk and simplified English.
Andrew C. Greenberg wrote:
Slang is neither C nor Smalltalk. Necessarily, its a bit of each.
As I read this, it struck me that the linguistically accurate name for Slang would be Pidgin.
This name would also be self-documenting: If I remember correctly from linguistics class, pidgins are mixtures of two languages that emerge especially where to cultures meet, as small subsets of a full language, and often focusing on/limited to a certain domain where the need from translation/communication arose, eg. for trade.
Ah, my online dictionary bore me out:
pidgÄin (pæj2n) n. 1. A simplified form of speech that is usually a mixture of two or more languages, has a rudimentary grammar and vocabulary, is used for communication between groups speaking different languages, and is not spoken as a first or native language.
PidÄgin English [ Alteration of pigeon English from Pidgin English pigeon business perhaps from the Chinese pronunciation of English business ]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^!!!!!!!!
Talk about reflexive language semantics!
Special-purpose, for certain needs, simplified, subset, mixture of two, rudimentary grammar and vocabulary, comm. betw. different language groups, not first language, etc.: It is striking how thison point by point describes the nature and origins of Squeak Slang; hereby proposed to be named Pidgin Squeak (or Pidgin for short).
ok, back to work now Henrik
squeak-dev@lists.squeakfoundation.org