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

[H. Hirzel]

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"?  :-)

--Hannes

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