Syntaxes & Block Closures

Mats Nygren nygren at
Fri Sep 15 15:46:47 UTC 2000

Henrik Gedenryd <Henrik.Gedenryd at> wrote:
> Mats Nygren wrote:
> >> I think there has got to be a better solution for embedding code than
> >> comments (given the potential quote problem), but I'm not sure exactly
> >> what. 
> > 
> > It is important to try to avoid that. This can be done by making
> > the involved syntaxes a little more flexible, or inventing new ways of
> > interpreting existing syntactic constructs. I have in this way
> > eliminated the need to write C-code directly in strings as is done now.
> > (The quote problem doesn't exist, see above)
> The straight forward solution, which is already used in Slang, is to define
> messages that do nothing in Squeak but have a meaning in the other
> language., like #inline:, #cCoerce:into:.


has nothing to do with syntaxes. One could ask for inlining of Smalltalk
just as well. (With the restrictions that comes with it). Then of course
letting inline masquerade as a message send isn't particularly good.
Since it isn't a message send, not to the expressed receiver at least.
Compare the not in every respect completely ill designed language C.

  inline int f(int x)  { return x+1; }

this makes sense

  f: x  self inline: true. ^x+1

does not. I will show a version of Slang, later when I have rewritten the
parser, where it is written

  ":inline" f: x ^x+1

instead. This results in a normal method when parsed by an ordinary parser,
but when parsed for making C code, typing information (in comments with
a ':' in the begining) is parsed too, in a somewhat extended syntax.


is a major complication and for no use at all. The problem is that Slang
is a typed language without expressions for types. It lacks all nice
properties. Have a look at my version of this when it appears, and let's
continue this then.

I can see no justification whatever for quoted code, as it is currently used.
Note also that when the C parser is working it will be fairly easy the change
C code to Slang. Some adjustments have to be made, but thats all.

> E.g.
>     Python import: 'moduleName'
> where Python would be eg. a subclass of OtherLanguage.

In this particular example I still recommend that this is handled in a
special way, treating modules and their dependencies should not be done
behind the back of the code generation system, that would make it
impossible to get a grip of things. I will have more to say later.
But possibly there is a misunderstanding going on. Let's get back to
the matter when actual Python-code should be produced.

For the general case however, leave the possibility to have quoted code,
that shows the white spots in the map. A much better solution, as I have
already expressed, is to have it in the same syntax, avoiding its
execution when run in Squeak is easy. Having it in the same syntax makes
everything work smothly. And besides

  "Back to the Future: The Story of Squeak, A Practical Smalltalk *Written in Itself*"

will get a little closer to truth. At present there is a substantial amount of code
written in C, bash, make, m4, etc. Being able to handle the C code from within
Squeak will not make things less flexible.

Note for example that the current "Slang->C" cannot inline code that
contain quoted C code.


More information about the Squeak-dev mailing list