[Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

Eliot Miranda eliot.miranda at gmail.com
Tue Feb 15 20:58:56 CET 2011


On Tue, Feb 15, 2011 at 11:18 AM, Igor Stasenko <siguctua at gmail.com> wrote:

> On 15 February 2011 19:59, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> >
> >
> > On Mon, Feb 14, 2011 at 11:00 PM, Stéphane Ducasse
> > <stephane.ducasse at inria.fr> wrote:
> >>
> >> Eliot
> >>
> >> you use caseOf: for the generation of C in Slang and VM maker.
> >> Now this means that
> >>        - it does not need to be inlined
> >
> > No.  If it is not inlined the simulator will go *much* slower.  e.g.
> > CogVMSimulatorLSB>>byteAt: byteAddress
> > | lowBits long |
> > lowBits := byteAddress bitAnd: 3.
> > long := self longAt: byteAddress - lowBits.
> > ^(lowBits caseOf: {
> > [0] -> [ long ].
> > [1] -> [ long bitShift: -8  ].
> > [2] -> [ long bitShift: -16 ].
> > [3] -> [ long bitShift: -24 ]
> > }) bitAnd: 16rFF
> >
>
> so why not put it:
>
> ^ (long bitShift: (-8*lowBits) ) bitAnd: 16rFF
>
> ?
> Or this will be slower than caseOf: ?
>

Because that was the way the code was written.  I just copied the method.
 Further, it is only one example.  I'm not going to rewrite the VMMaker's
uses of caseOf: jyst to suit some whim of purity.  It is making unnecessary
work.  Taking it out is *much* more work (/and/ emotional energy) than just
leaving it alone.  Can't we try and be constructive?


>
>
> >>
> >>        - it could be packaged with VMMaker
> >
> > No.  It needs to be in the compiler to be inlined.  Why have you got on
> this
> > hobby-horse?  It is a non-issue.  caseOf: ios not widelty used but
> extremely
> > useful in certain circumstances.  This has the feeling of a religious
> > pogrom, not a rational approach to the system.  IIABDFI = If It Ain't
> Broke,
> > Don't Fix It.
>
> This concept kinda appeal to me.
> From other side, i am also strongly feel that house should be kept clean :)
>
> >>
> >> Are these two points correct?
> >
> > No, IMO, definitely not.
> >
> >>
> >> Stef
> >>
> >
> >
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20110215/7f68739d/attachment.htm>


More information about the Pharo-project mailing list