On 05/09/07, Peter William Lount <peter at smalltalk.org> wrote:
> You are still stuck on byte codes eh? That is so 1960's. I invite you
> into the innovation frame of mind, discard what you think you know about
> this topic, and open your eyes wide open and imagine a future with
> powerful blocks. We are just scratching the surface with this one new
> block feature. I've invented ten more powerful capabilities for blocks
> and integrated them so they work well.

That's for another thread. I'm not against crazy ideas on blocks, I
just say that to implement message chains, it's a smaller and easier
to understand change to make the compiler expand some new syntactic
sugar. Overloading the meaning of blocks really feels more disruptive
to me, especially if it involves potentially calling the compiler or
reflectivity at each evaluation. I like the idea to use # for
extending an otherwise unmodified syntax.

> It's important that a system be as dynamic as possible. You may need to
> recompile the block at runtime just before it's evaluated if you insist
> on remaining with the out molded notion of byte codes. But there are
> other ways. One could simply add a byte code marker for statements as
> the "add to collection byte code" above illustrated. There are many
> other ways if you are creative and innovative.

You would need to add markers for each possible evaluation strategy,
and if the system is extensible you can't know which strategy will
exist in advance. The way to deal with that is to keep the current
blocks as they are, sequential statements that will be executed
efficiently, and add a new kind of code container that has the clear
meaning of an set of statements that can be executed by different
strategies. These new code container objects are higher-level than
blocks. In fact you already have them:
     { [a]. [b]. [c] } valuesConcurrently

now we can imagine a nicer syntax than that, but besides conflicting
with current blocks, [a.b.c] would make it difficult to have complex
statements in place of a b or c.

Another nice solution would be to add a compiler hint to blocks:
[a. b. c <concurrent>] value
Here, this block would be recognized at compile-time to have special
semantics and the compiler would generate parallel code. That would be
really useful for numerical stuff like
aBigArray simdDo: [:each| a. b. c]
which would evaluate first a for each element, then b, then c (three
simd-optimized loops instead of a single big loop)

-- 
Damien Pollet
type less, do more [ | ] http://typo.cdlm.fasmz.org