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

[Frank Shearar]

On 11 October 2012 11:54, 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.
> What PPCompositParser does is one of the things why i don't like PetitParser.
> Sure, i don't want to discourage from using it, just my personal taste.

You can't do that refactoring, at least if you want to keep the
PPCompositeParser: it has a very strong opinion. Which is your point,
of course. I agree: if you don't like the taste of the
PPCompositeParser, don't use it at all. (And hope that the grammars
you wish to compose aren't PPCompositeParsers.)

For limited grammars it's very handy, because Smalltalk doesn't have
implicit sends, and this way you still get to avoid writing "self"
everywhere.

frank

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