(f value: n) <=> f{n}
Marcel Weiher
marcel at metaobject.com
Mon Jul 10 08:30:01 UTC 2000
> From: Mats Nygren <nygren at sics.se>
> I meant in particular the new possibilities that arises. That will make
> it possible to write in entirely different ways even within the same
> syntax. In that sense it is a new game to play.
Yes definitely! However, this is where Alan's warnings come into
play: you don't want to do have gratuitously non-obvious semantics
happening. I am fairly optimistic that this can be controlled,
especially since you can already have unexpected things happening
today.
> >> Can you give me some pointers to the trampoline stuff? I know
there are
> >> postings on this but I never found them in the archives.
> >
> >There are some details below, do you want to see code?
>
> I would like to see code, and also if you have some explanation of the
> general ideas, probably others will have an interest in that. Perhaps
> you have some old Squeak-list thread?
I just re-posted it in another reply.
[just a symbol]
> Then
> myCollection do: [ :each | each doSomething ].
> can be written
> myCollection do: #doSomething.
Ah, I was a little sloppy there myself: what can follow is a
complete message expression. The message will be caught along with
all its arguments, provided with a receiver and then used in normal
#collect: iteration messages. At least this is how it works in the
code I've given.
The original Objective-C code actually uses iterators. All the
iterators are stepped through simultaneously, while non-iterators are
kept constant during evaluation. The assumption here is that you
never want to use an iterator in an iterating context without
iterating over it. With a collection, this is not always a valid
assumption, which is why iterators are important in that context. A
Smalltalk solution would need to use Streams, but that also has the
'discrimination' problem: you couldn't assume that having a stream
in there always means that you want to stream its contents
automagically.
> which is ok to my standards. But it seems you can handle nested
loops in
> elegant ways, I havn't really understood your framework yet.
Well, nesting *could* be handled, but isn't. All the 'framework'
really does is extend the concept of 'message send' a little:
instead of being able to send a message to just a single receiver,
you can send it to lots of receivers.
Because the operations are really very similar, the syntax is also
very similar, sort of like writing many receivers on a mail message.
This contrasts with the current way, where the change from a single
receiver to many receivers means you suddenly leave messaging
altogether and have to resort to anonymous functions. Wowzers!
There is actually an interesting scripting language, FScript, which
extends this entire iteration concept and takes it off in the
direction of APL (see www.fscript.org). However, I am not sure
wether APL is a good generalization to make.
> To me it seems like you are currying functions, in particular the
> Collection-traversals. If you are familiar with the
> "lambda-calculus/combinatory logic"-terminology it would be
interesting to
> read
> a description of this in such terms.
It does have some aspects of currying (see the code-comments), but
traditional currying is a little difficult with Smalltalk as it is:
how to drop keywords? Of course, one way would be to view a
multi-keyword message as a sequence of single keyword messages slowly
constructing a message-objects with key/value arguments. However, I
think that direction has been explored quite a bit already.
> Is it possible to have your way of doing things alongside the
established way
> controlled by metaobjects, as in CLOS? (By making a specical
generic function
> class
> with its own way of application)
I actually use the standard way (at least now). However, I am still
lookin at how to extend these ideas. One important requirement for
me is that the result should 'fit' in with the concept of
communicating objects, or at least something similarily concrete.
What I don't want to do is a plain 'import' of concepts from FP,
although I do want the capabilities.
> Anyhow my guess is you are doing things similar to ideas I have been
> experimenting with outside of Squeak. After my vacation it should
be fun
> to get into this.
Great!
Marcel
More information about the Squeak-dev
mailing list
|