Pluggable Morphs

Wouldn't the pluggable Morphs be more flexible/powerful if they took blocks instead of selectors?

Sean

> Wouldn't the pluggable Morphs be more flexible/powerful if they took blocks
> instead of selectors?

Note that blocks do not serialize correctly: a Morph referencing a block
can not be saved as a .morph file.

Try it:
        m _ Morph new.
        m setProperty: #dummy toValue: [:x | x + 1].
        m saveOnFile

For this reason in muO I use LambdaMessageSends instead of blocks.

I would love to see this fixed though.

Stef

On 04.01.2011, at 00:45, Stéphane Rollandin wrote:

>> Wouldn't the pluggable Morphs be more flexible/powerful if they took blocks
>> instead of selectors?
>
> Note that blocks do not serialize correctly: a Morph referencing a block can not be saved as a .morph file.

Not only that, blocks are much harder to debug. They're basically useless black boxes in inspectors or debuggers, whereas receiver+selector can be easily examined, changed, etc. Late binding wins, again ...

- Bert -

Bert Freudenberg wrote

blocks are much harder to debug. They're basically useless black boxes in inspectors or debuggers, whereas receiver+selector can be easily examined, changed, etc. Late binding wins, again ...

I understand that that's the case at present.  But ideally, can't the tools be improved to be more useful with blocks (e.g. show the decompiled version), given that they are a useful part of the system.  It seems backward to me to not use something powerful because the tools are weak.

Sean

>> blocks are much harder to debug. They're basically useless black boxes in
>> inspectors or debuggers, whereas receiver+selector can be easily examined,
>> changed, etc. Late binding wins, again ...

> I understand that that's the case at present.  But ideally, can't the tools
> be improved to be more useful with blocks (e.g. show the decompiled
> version), given that they are a useful part of the system.  It seems
> backward to me to not use something powerful because the tools are weak.

Did you have a look to LambdaMessageSend ? Basically it's an AST in the
form of nested message sends wrapping a block which is its compiled
form. So it has the speed of a block and the apparent structure and ease
of manipulation of a MessageSend.

Stef

Stéphane Rollandin wrote

Did you have a look to LambdaMessageSend?

I took a quick look in FunSqueak, I'll have to take a deeper look when I get a minute.  Two questions:
* does it address the debuggability issue Bert mentioned for blocks?
* can it have state?

Thanks.
Sean

> I took a quick look in FunSqueak, I'll have to take a deeper look when I get
> a minute.  Two questions:
> * does it address the debuggability issue Bert mentioned for blocks?

If you're caught in the debugger while the LMS block fails, no. But
since the structure of that block is exposed via the LMS, it is possible
to debug by erasing all compiled forms in the suspected code and see the
same error that was in the block appear within the evaluation of the
original LMS. Don't know if I'm being clear here.

> * can it have state?

Yes, via default values stored in LambdaSlots. Look in the class-side of
NFunction for examples, like:

-----------------
hyperbolicDamping

  | decayRate |

  decayRate _ Lambda scale default: 1; description: 'x scaling'; type:
NumericSlot.

  ^ (Lx abs /// decayRate + 1) reciprocal
-----------------


In that code, decayRate is a lambda slot whose default gives the
returned LMS state:


NFunction hyperbolicDamping
  -->
  Lx.Lscale.{((<x> abs /// <scale>) + 1) reciprocal}


NFunction hyperbolicDamping defaultForm
  -->
  Lx.{((<x> abs /// 1) + 1) reciprocal}


(NFunction hyperbolicDamping parametrize: #scale default: 42) defaultForm
  -->
  Lx.{((<x> abs /// 42) + 1) reciprocal}


This is a step away from pure functional programming but it is very
useful in practice.

muO has lots of examples of LMS usage; if you want to explore them get
the ready-to-go image at
http://www.zogotounga.net/comp/squeak/muo/muO%20257%20image.zip


best,

Stef

On 1/4/11 5:43 PM, "Sean P. DeNigris" <[hidden email]> wrote:

>
>
> Stéphane Rollandin wrote:
>>
>> Did you have a look to LambdaMessageSend?
>>
>
> I took a quick look in FunSqueak

But the last FunSqueak do not have muO and his several packages into, next
build I add again.

Edgar

FunSqueakCog4.2-10549-alpha.8 has the LambdaMessageSend class (FunctionalTalk category).

Sean

On 1/6/11 2:26 PM, "Sean P. DeNigris" <[hidden email]> wrote:

> FunSqueakCog4.2-10549-alpha.8 has the LambdaMessageSend class (FunctionalTalk
> category).
>
> Sean
And FunSqueakCog4.2-10577-alpha.9 , which was the most populated by packages
(have Magma).
But as can't be updated, i need start again.

The last was FunSqueakCog4.2-10813-alpha.zip and when Chris publish the
"official" version i update and add new packages, muO is on my list and with
muO some more packages (as pre requisites).
If any in previous images is not in the new and you wish be on, ask and I
put into.

Edgar

Edgar J. De Cleene-3 wrote

If any in previous images is not in the new and you wish be on, ask and I
put into.

Thanks!  This is great service :)

Sean