[Vm-dev] HackerNews + vm-dev = a lightbulb saying "STACK!"

[H. Hirzel]

On 10/11/12, Igor Stasenko <siguctua at gmail.com> wrote:
>
> On 11 October 2012 11:42, Frank Shearar <frank.shearar at gmail.com> wrote:
>>
>> On 11 October 2012 08:45, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>>>
>>> On 10/11/12, Igor Stasenko <siguctua at gmail.com> wrote:
>>>>
>>>> On 10 October 2012 22:55, Eliot Miranda <eliot.miranda at gmail.com>
>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Oct 10, 2012 at 11:53 AM, Colin Putney <colin at wiresong.com>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> On Wed, Oct 10, 2012 at 10:22 AM, Eliot Miranda
>>>>>> <eliot.miranda at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> > Right now I'm redesigning the bytecode set to lift limits on branch
>>>>>> > distances, number of literals, and number of inst vars.  So a small
>>>>>> > increment.
>>>>>>
>>>>>> I suppose that Newspeak is different from Smalltalk in terms of the
>>>>>> size and complexity of methods that it encourages. It could be that
>>>>>> the existing limits are blocking the development of Newspeak, and
>>>>>> obviously legacy code is much less of an issue for Newspeak than
>>>>>> Squeak.
>>>>>
>>>>>
>>>>> Not newspeak.  But within Cadence we have internal customers that are
>>>>> hitting limits we must lift.
>>>>>
>>>>
>>>> <trolling>
>>>> perhaps then it would cost less to customers to attend a small course
>>>> on programming basics then?
>>>> </trolling>
>>>>
>>>> The biggest bloat of inst vars, which i ever seen in smalltalk is
>>>> Interpreter & ObjectMemory classes.
>>>> And this is mainly because this code has to be translated to C due to
>>>> limitations/design of VMMaker.
>>>> But VMMaker is special. A regular code don't requires so much state
>>>> kept per single object.
>>>>
>>>> Now, it is hard to imagine, how much more complex the software must be
>>>> that it requires even more instances in class than those two?
>>>> Especially when you saying it is not because of Newspeak.
>>>>
>>>> These news saddening me a lot.
>>>
>>> The answer is
>>>
>>> "It depends".
>>>
>>> Normally having more 255+ instance variables is a sign of bad design.
>>> But not always. There are exceptions. It depends on the problem domain
>>> and business case.
>>>
>>> I actually welcome that this limitation is lifted because of
>>> PetitParser (though Lukas has a workaround). At the moment I have not
>>> hit the limit yet.
>>
>> Is that from a large PPCompositParser? (Because each rule manifests as
>> an instvar initialised as a delegate parser. Delegates are lazily
>> resolved post initialisation.)
>>
>
> oh, man, that's lame. If/when you hit that limit, you can always
> refactor the code to use dictionary
> to hold/cache parsers instead of inst vars.

Why should I want to do this?  I want to _use_ PetitParser as is and I
do not want to temper with it's implementation.

> What PPCompositParser does is one of the things why i don't like
> PetitParser.

I perceive it as a very elegant solution. A well integrated of a DSL
into Smalltalk..

Easy to use.

And I like Lukas' PhD thesis. It's a pity that Helvetia is not
available in newer versions of Pharo.


> Sure, i don't want to discourage from using it, just my personal taste.

Yes, fine.  :-)

--Hannes

>
>> frank
>
> --
> Best regards,
> Igor Stasenko.
>