expecting literal blocks

Hello all,
I'm a smalltalker but relatively newbie working with Dolphin.  I found
some things that in Smalltalks that I come (VS and VW) do not occur.
I need pass a block as an argument in traditional messages like
#ifTrue:ifFalse: , #and: and the compiler do not allow me to pass a
non-literal block. For example:

test
       
        | block |
        block := [3 + 4].
        3 > 4
                ifTrue: [3 - 4]
                ifFalse: block

not compile (Error: expecting literal block)!

I have to implement the avobe method as follow:

test
       
        | block |
        block := [3 + 4].
        3 > 4
                ifTrue: [3 - 4]
                ifFalse: [block value]

The same situation with another messages.
I know that this occur by optimization razons.
I know that the compiler inlines those messages if the argument is a
literal block. But I think that (as in others Smalltalks) it should
allow to pass non-literal blocks too.
What do you think?

Regards,
Guillermo Sapaya

Guillermo Sapaya wrote:

> I know that this occur by optimization razons.
> I know that the compiler inlines those messages if the argument is a
> literal block. But I think that (as in others Smalltalks) it should
> allow to pass non-literal blocks too.

I think that'd be better too, but I suspect it might be harder to implement
than it looks.

As far as I can see, the Dolphin compiler doesn't parse #ifTrue:#ifFalse: (etc)
as normal message sends, and then later recognise the special selector and emit
optimised bytecode.  I think it must parse #ifTrue:#ifFalse: as a special case
of the grammar (like if() in C) which -- if true -- would make it more
difficult to allow arbitrary identifiers as the parameters of the "send".

The reason I think the compiler works that way is that it gives error messages
for "erroneous" constructions like:

    1 > 0
         ifTrue: [1]
         ifTrue: [0].

    -- chris