[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LFM + LFSP = LFE?
On Fri, 13 Jun 2003, Avi Bryant wrote:
> On Fri, 13 Jun 2003, Michael Vanier wrote:
> > Consider the gauntlet thrown ;-) BTW GNU Smalltalk gets around some of
> > these problems, although you can't start the file with
> > #! /usr/bin/env gst
> > to make it executable like you can with python. Also, there's the syntax
> > issue.
> Which syntax issue do you mean? I certainly don't intend to use chunk
> format the way gst does - I don't like to write ! everywhere any more than
> you do.
> Do you have any syntax suggestions?
I have a suggestion.
I have been working on this issue with adapting Smalltalk usage to the
command line, or at least to presenting it outside a browser. In my Slate
language, I lay out method code as an annotated block expression, as such:
d@(Dictionary traits) keysAndValuesDo: block
"Applies a two-argument block to each key and value."
d isEmpty ifTrue: [^ d].
d array doWithIndex:
[| :each :index | each ifNotNil:
[block value: each value: (d values at: index)]]
The "@" symbol is appropriated for dispatching, and we use that to
distinguish a method definition signature from other things. We simply
treat the outer or top-level lexical area as a sequence of expressions,
using Smalltalk's separator for that, the period. There's no dependency on
the textual layout of the code, except that the method definition has to
be distinct as an expression: either being the top-level expression in a
statement, or using parentheses to set it apart in a surrounding
Now, we are absolutely interested in image-based development, but this was
our solution for files that we will probably keep, and resort to
expression-based utilities to make it more comprehensible as the system
becomes more complex, rather than additional special syntax.
It's also true that we can define methods with an expression, but this is
not something that is useful for interchange.
Brian T. Rice
LOGOS Research and Development