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

[Frank Shearar]

On 11 October 2012 14:59, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>
> On 10/11/12, Frank Shearar <frank.shearar at gmail.com> wrote:
>>
>> 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.)
>
> +1
>
>> 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.
> +1
>
> What do you use for grammars which are not "limited"?  :-)

A few years ago I started writing a parser for Delphi (not in
PetitParser): that was upwards of 250 rules, and I hadn't nailed down
everything I wanted to. I'd probably just hold my nose and say "self
foo" everywhere, with PetitParser.

frank

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