I saw an interesting post on HackerNews [1] about a book called "Stack Computers: The New Wave" (1989)[2]. I thought, that's pretty interesting. Stack computers. Stack languages. Forth. Hmmm, Forth. I wonder if it would be worth spending some time on Forth? Then there's a post on GreenArrays, Inc. [3] and Chuck Moore and ColorForth [4] and such. And I think, Yea. That's cool. But I shouldn't really go down this road. How are stack languages related to Smalltalk? And then I realized the StackVM is called a StackVM because it uses a ... STACK. Oh, right. Stack. Maybe the informing principle of the StackVM is that it uses a stack. Like Forth. Sometimes a brick has to fall on my head before I see what's going on.
Chris
[1] http://news.ycombinator.com/ [2] http://www.ece.cmu.edu/~koopman/stack_computers/index.html [3] http://www.greenarraychips.com/ [4] http://www.colorforth.com/
One of most modern ones, i think: http://factorcode.org/
On 7 October 2012 01:13, Chris Cunnington smalltalktelevision@gmail.com wrote:
I saw an interesting post on HackerNews [1] about a book called "Stack Computers: The New Wave" (1989)[2]. I thought, that's pretty interesting. Stack computers. Stack languages. Forth. Hmmm, Forth. I wonder if it would be worth spending some time on Forth? Then there's a post on GreenArrays, Inc. [3] and Chuck Moore and ColorForth [4] and such. And I think, Yea. That's cool. But I shouldn't really go down this road. How are stack languages related to Smalltalk? And then I realized the StackVM is called a StackVM because it uses a ... STACK. Oh, right. Stack. Maybe the informing principle of the StackVM is that it uses a stack. Like Forth. Sometimes a brick has to fall on my head before I see what's going on.
Chris
[1] http://news.ycombinator.com/ [2] http://www.ece.cmu.edu/~koopman/stack_computers/index.html [3] http://www.greenarraychips.com/ [4] http://www.colorforth.com/
And of course don't forget to read (or re-read) Eliot's excellent explanations:
http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the-...
Dave
On Sat, Oct 06, 2012 at 07:13:12PM -0400, Chris Cunnington wrote:
I saw an interesting post on HackerNews [1] about a book called "Stack Computers: The New Wave" (1989)[2]. I thought, that's pretty interesting. Stack computers. Stack languages. Forth. Hmmm, Forth. I wonder if it would be worth spending some time on Forth? Then there's a post on GreenArrays, Inc. [3] and Chuck Moore and ColorForth [4] and such. And I think, Yea. That's cool. But I shouldn't really go down this road. How are stack languages related to Smalltalk? And then I realized the StackVM is called a StackVM because it uses a ... STACK. Oh, right. Stack. Maybe the informing principle of the StackVM is that it uses a stack. Like Forth. Sometimes a brick has to fall on my head before I see what's going on.
Chris
[1] http://news.ycombinator.com/ [2] http://www.ece.cmu.edu/~koopman/stack_computers/index.html [3] http://www.greenarraychips.com/ [4] http://www.colorforth.com/
What is cool in those stack-manipulation languages family, that they allow you to directly manipulate stack (tautology ;)
It is easy to express function call(s) in those languages, unlike procedural ones. In procedural languages, we have to go to great lengths implementing semantics, which directly manipulates stack, like in compilers or FFI. In stack manipulation languages, however, this is directly available as basic,core functionality, on which you build everything else.
On 06.10.2012, at 16:13, Chris Cunnington smalltalktelevision@gmail.com wrote:
How are stack languages related to Smalltalk?
The Squeak VM *is* a stack machine. For passing arguments to a method it uses a stack exclusively (in contrast to most microprocessors, which use registers, and only use the stack for larger function calls). E.g., you can switch a Squeak browser to show byte codes. That demonstrates how the stack is used:
plus ^ 3 + 4
switch to byte codes:
21 <20> pushConstant: 3 22 <21> pushConstant: 4 23 <B0> send: + 24 <7C> returnTop
And then I realized the StackVM is called a StackVM because it uses a ... STACK.
No, every Squeak VM (interpreter, Cog, etc) with the current byte code set uses a stack. The Stack VM is so called because it maps the Smalltalk stack to the native C code stack for speed.
- Bert -
On Tue, Oct 9, 2012 at 11:24 AM, Bert Freudenberg bert@freudenbergs.dewrote:
On 06.10.2012, at 16:13, Chris Cunnington smalltalktelevision@gmail.com wrote:
How are stack languages related to Smalltalk?
The Squeak VM *is* a stack machine. For passing arguments to a method it uses a stack exclusively (in contrast to most microprocessors, which use registers, and only use the stack for larger function calls). E.g., you can switch a Squeak browser to show byte codes. That demonstrates how the stack is used:
plus ^ 3 + 4
switch to byte codes:
21 <20> pushConstant: 3 22 <21> pushConstant: 4 23 <B0> send: + 24 <7C> returnTop
And then I realized the StackVM is called a StackVM because it uses a
... STACK.
No, every Squeak VM (interpreter, Cog, etc) with the current byte code set uses a stack. The Stack VM is so called because it maps the Smalltalk stack to the native C code stack for speed.
<pedantry alert> Not quite. The virtual Smalltalk-80 machine is a spaghetti stack, composed of a chain of MethodContext objects, each contaning its own stack for evaluation. The interpreter operates on these context objects directly, maintaining an activeContext and using its stack for evaluation. The stack VM maps contexts to a machine stack, so that arguments don't have to be copied from sender context to new context, and so that context objects do not have to be allocated on every send, both of which are crucial for performance. But this machine stack is distinct from the C stack, organized as a set of pages of fixed size, so as to make the stack effectively infinite (overflowing onto the heap in the form of contexts). The interpreter's implementation (the C functions making up the interpreter), and in Cog, the JIT's compiler implementation, run on the C stack, but Smalltalk is not executed on the C stack in any of the Squeak VMs. </pedantry alert>
- Bert -
On Wed, Oct 10, 2012 at 1:20 AM, Göran Krampe goran@krampe.se wrote:
On 10/10/2012 12:35 AM, Eliot Miranda wrote:
<pedantry alert>
[SNIP of really nice and compact description of the Stack VM]
Eliot, I love it when you write about these things. You... technical freak! :)
...so what's next in Cog land? GC revamp? More NB interplay?
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 hope to get the green light for the GC revamp because that's important for performance, but he who pays the piper picks the tune.
regards, Göran
On Wed, Oct 10, 2012 at 10:22 AM, Eliot Miranda eliot.miranda@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.
But… isn't that an odd cost/benefit mismatch? It would seem that switching instruction sets isn't easy, even given VM support. Are there no other changes that could/should be made at the same time? Is this something we could imagine doing more than once in the near future?
Colin
On Wed, Oct 10, 2012 at 11:53 AM, Colin Putney colin@wiresong.com wrote:
On Wed, Oct 10, 2012 at 10:22 AM, Eliot Miranda eliot.miranda@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.
But… isn't that an odd cost/benefit mismatch? It would seem that switching instruction sets isn't easy, even given VM support. Are there no other changes that could/should be made at the same time? Is this something we could imagine doing more than once in the near future?
I had reason to add support for two bytecode sets to the VM recently so all the support at the VM level is there to do incremental development of the new bytecode set. i'm writing the image-level support (you'll perhaps have noticed the fag to select the bytecode set added to trunk recently). I can imagine having multiple bytecode sets being very useful and something one does quite often. Claus Gittinger's Smalltalk/X has support for four bytecode sets and can execute Java bytecode natively. With the current header format I've only been able to shoe-horn in a single one.
Making lots of changes at one time is a way of increasing the risk of failure.
Colin
On 10 October 2012 22:55, Eliot Miranda eliot.miranda@gmail.com wrote:
On Wed, Oct 10, 2012 at 11:53 AM, Colin Putney colin@wiresong.com wrote:
On Wed, Oct 10, 2012 at 10:22 AM, Eliot Miranda eliot.miranda@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.
But… isn't that an odd cost/benefit mismatch? It would seem that switching instruction sets isn't easy, even given VM support. Are there no other changes that could/should be made at the same time? Is this something we could imagine doing more than once in the near future?
I had reason to add support for two bytecode sets to the VM recently so all the support at the VM level is there to do incremental development of the new bytecode set. i'm writing the image-level support (you'll perhaps have noticed the fag to select the bytecode set added to trunk recently). I can imagine having multiple bytecode sets being very useful and something one does quite often. Claus Gittinger's Smalltalk/X has support for four bytecode sets and can execute Java bytecode natively. With the current header format I've only been able to shoe-horn in a single one.
Making lots of changes at one time is a way of increasing the risk of failure.
Colin
-- best, Eliot
On Wed, Oct 10, 2012 at 3:23 PM, Igor Stasenko siguctua@gmail.com wrote:
On 10 October 2012 22:55, Eliot Miranda eliot.miranda@gmail.com wrote:
On Wed, Oct 10, 2012 at 11:53 AM, Colin Putney colin@wiresong.com
wrote:
On Wed, Oct 10, 2012 at 10:22 AM, Eliot Miranda <
eliot.miranda@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>
hint, our internal customers are not using either Smalltalk or Newspeak; we are compiling a third language down to the bytecode.
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.
But… isn't that an odd cost/benefit mismatch? It would seem that switching instruction sets isn't easy, even given VM support. Are there no other changes that could/should be made at the same time? Is this something we could imagine doing more than once in the near future?
I had reason to add support for two bytecode sets to the VM recently so
all the support at the VM level is there to do incremental development of the new bytecode set. i'm writing the image-level support (you'll perhaps have noticed the fag to select the bytecode set added to trunk recently). I can imagine having multiple bytecode sets being very useful and something one does quite often. Claus Gittinger's Smalltalk/X has support for four bytecode sets and can execute Java bytecode natively. With the current header format I've only been able to shoe-horn in a single one.
Making lots of changes at one time is a way of increasing the risk of
failure.
Colin
-- best, Eliot
-- Best regards, Igor Stasenko.
On 10/11/12, Igor Stasenko siguctua@gmail.com wrote:
On 10 October 2012 22:55, Eliot Miranda eliot.miranda@gmail.com wrote:
On Wed, Oct 10, 2012 at 11:53 AM, Colin Putney colin@wiresong.com wrote:
On Wed, Oct 10, 2012 at 10:22 AM, Eliot Miranda eliot.miranda@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.
--Hannes
But… isn't that an odd cost/benefit mismatch? It would seem that switching instruction sets isn't easy, even given VM support. Are there no other changes that could/should be made at the same time? Is this something we could imagine doing more than once in the near future?
I had reason to add support for two bytecode sets to the VM recently so all the support at the VM level is there to do incremental development of the new bytecode set. i'm writing the image-level support (you'll perhaps have noticed the fag to select the bytecode set added to trunk recently). I can imagine having multiple bytecode sets being very useful and something one does quite often. Claus Gittinger's Smalltalk/X has support for four bytecode sets and can execute Java bytecode natively. With the current header format I've only been able to shoe-horn in a single one.
Making lots of changes at one time is a way of increasing the risk of failure.
Colin
-- best, Eliot
-- Best regards, Igor Stasenko.
On 11 October 2012 08:45, H. Hirzel hannes.hirzel@gmail.com wrote:
On 10/11/12, Igor Stasenko siguctua@gmail.com wrote:
On 10 October 2012 22:55, Eliot Miranda eliot.miranda@gmail.com wrote:
On Wed, Oct 10, 2012 at 11:53 AM, Colin Putney colin@wiresong.com wrote:
On Wed, Oct 10, 2012 at 10:22 AM, Eliot Miranda eliot.miranda@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.)
frank
--Hannes
But… isn't that an odd cost/benefit mismatch? It would seem that switching instruction sets isn't easy, even given VM support. Are there no other changes that could/should be made at the same time? Is this something we could imagine doing more than once in the near future?
I had reason to add support for two bytecode sets to the VM recently so all the support at the VM level is there to do incremental development of the new bytecode set. i'm writing the image-level support (you'll perhaps have noticed the fag to select the bytecode set added to trunk recently). I can imagine having multiple bytecode sets being very useful and something one does quite often. Claus Gittinger's Smalltalk/X has support for four bytecode sets and can execute Java bytecode natively. With the current header format I've only been able to shoe-horn in a single one.
Making lots of changes at one time is a way of increasing the risk of failure.
Colin
-- best, Eliot
-- Best regards, Igor Stasenko.
On 11 October 2012 11:42, Frank Shearar frank.shearar@gmail.com wrote:
On 11 October 2012 08:45, H. Hirzel hannes.hirzel@gmail.com wrote:
On 10/11/12, Igor Stasenko siguctua@gmail.com wrote:
On 10 October 2012 22:55, Eliot Miranda eliot.miranda@gmail.com wrote:
On Wed, Oct 10, 2012 at 11:53 AM, Colin Putney colin@wiresong.com wrote:
On Wed, Oct 10, 2012 at 10:22 AM, Eliot Miranda eliot.miranda@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.
frank
On 11 October 2012 11:54, Igor Stasenko siguctua@gmail.com wrote:
On 11 October 2012 11:42, Frank Shearar frank.shearar@gmail.com wrote:
On 11 October 2012 08:45, H. Hirzel hannes.hirzel@gmail.com wrote:
On 10/11/12, Igor Stasenko siguctua@gmail.com wrote:
On 10 October 2012 22:55, Eliot Miranda eliot.miranda@gmail.com wrote:
On Wed, Oct 10, 2012 at 11:53 AM, Colin Putney colin@wiresong.com wrote:
On Wed, Oct 10, 2012 at 10:22 AM, Eliot Miranda eliot.miranda@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.
On 10/11/12, Frank Shearar frank.shearar@gmail.com wrote:
On 11 October 2012 11:54, Igor Stasenko siguctua@gmail.com wrote:
On 11 October 2012 11:42, Frank Shearar frank.shearar@gmail.com wrote:
On 11 October 2012 08:45, H. Hirzel hannes.hirzel@gmail.com wrote:
On 10/11/12, Igor Stasenko siguctua@gmail.com wrote:
On 10 October 2012 22:55, Eliot Miranda eliot.miranda@gmail.com wrote:
On Wed, Oct 10, 2012 at 11:53 AM, Colin Putney colin@wiresong.com wrote: > > > On Wed, Oct 10, 2012 at 10:22 AM, Eliot Miranda > eliot.miranda@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.
On 11 October 2012 14:59, H. Hirzel hannes.hirzel@gmail.com wrote:
On 10/11/12, Frank Shearar frank.shearar@gmail.com wrote:
On 11 October 2012 11:54, Igor Stasenko siguctua@gmail.com wrote:
On 11 October 2012 11:42, Frank Shearar frank.shearar@gmail.com wrote:
On 11 October 2012 08:45, H. Hirzel hannes.hirzel@gmail.com wrote:
On 10/11/12, Igor Stasenko siguctua@gmail.com wrote:
On 10 October 2012 22:55, Eliot Miranda eliot.miranda@gmail.com wrote: > > > > On Wed, Oct 10, 2012 at 11:53 AM, Colin Putney colin@wiresong.com > wrote: >> >> >> On Wed, Oct 10, 2012 at 10:22 AM, Eliot Miranda >> eliot.miranda@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.
On 10/11/12, Igor Stasenko siguctua@gmail.com wrote:
On 11 October 2012 11:42, Frank Shearar frank.shearar@gmail.com wrote:
On 11 October 2012 08:45, H. Hirzel hannes.hirzel@gmail.com wrote:
On 10/11/12, Igor Stasenko siguctua@gmail.com wrote:
On 10 October 2012 22:55, Eliot Miranda eliot.miranda@gmail.com wrote:
On Wed, Oct 10, 2012 at 11:53 AM, Colin Putney colin@wiresong.com wrote:
On Wed, Oct 10, 2012 at 10:22 AM, Eliot Miranda eliot.miranda@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.
On 11.10.2012, at 03:54, Igor Stasenko siguctua@gmail.com wrote:
If/when you hit that limit, you can always refactor the code to use dictionary to hold/cache parsers instead of inst vars.
It's a pain in the neck having to deal with this. Also, you lose an order of magnitude in efficiency, unless you support both styles and only flow over into dictionaries when needed. Makes the code way more complicated. Also, debugging is not as nice as with real variables. Etc.
The code limits are something that not many people run into, but hitting the limit hurts, hard. Kudos to Eliot for taking this on.
- Bert -
On 11 October 2012 19:26, Bert Freudenberg bert@freudenbergs.de wrote:
On 11.10.2012, at 03:54, Igor Stasenko siguctua@gmail.com wrote:
If/when you hit that limit, you can always refactor the code to use dictionary to hold/cache parsers instead of inst vars.
It's a pain in the neck having to deal with this. Also, you lose an order of magnitude in efficiency, unless you support both styles and only flow over into dictionaries when needed. Makes the code way more complicated. Also, debugging is not as nice as with real variables. Etc.
I disagree. You have problems in a first place because of bloat. When you have over 255 variables to track, it makes little difference for humans how are they stored. Please do not mix cause and effect together. Human brains is simply do not fit for accounting that much information, and there is no way how humans can make sense out of so much various state grouped into a single entity. Not saying about unbearable complexity of code which needs to manage that amount of state meaningfully inside a single entity.
If language allows you to do something, it doesn't means you should do it and exploit it up to the point of total absurd. (STL and especially Boost C++ libraries is a good example of such abuses :)
And yes, for a simple demonstration, can you compare following two snippets of code and say, which one is more bearable/readable and easier to work with:
Object subclass: #Point instanceVariableNames: 'x y' classVariableNames: '' poolDictionaries: '' category: 'Kernel-BasicObjects'
----- ObjectMemory subclass: #Interpreter instanceVariableNames: 'activeContext theHomeContext method receiver instructionPointer stackPointer localIP localSP localHomeContext localReturnContext localReturnValue messageSelector argumentCount newMethod currentBytecode successFlag primitiveIndex primitiveFunctionPointer methodCache atCache lkupClass reclaimableContextCount nextPollTick nextWakeupTick lastTick interruptKeycode interruptPending semaphoresToSignalA semaphoresUseBufferA semaphoresToSignalCountA semaphoresToSignalB semaphoresToSignalCountB savedWindowSize fullScreenFlag deferDisplayUpdates pendingFinalizationSignals compilerInitialized extraVMMemory receiverClass interpreterProxy showSurfaceFn interruptCheckCounterFeedBackReset interruptChecksEveryNms externalPrimitiveTable primitiveTable globalSessionID jmpBuf jmpDepth jmpMax suspendedCallbacks suspendedMethods profileProcess profileMethod profileSemaphore nextProfileTick metaclassSizeBytes statIOProcessEvents statCheckForEvents statQuickCheckForEvents statProcessSwitch statPendingFinalizationSignals gcSemaphoreIndex' classVariableNames: 'AtCacheEntries AtCacheFixedFields AtCacheFmt AtCacheMask AtCacheOop AtCacheSize AtCacheTotalSize AtPutBase BlockArgumentCountIndex BlockMethodIndex BytecodeTable CacheProbeMax CallerIndex ClosureMethodIndex CompilerHooksSize CrossedX DirBadPath DirEntryFound DirNoMoreEntries DoBalanceChecks EndOfRun HomeIndex InitialIPIndex JitterTable MaxExternalPrimitiveTableSize MaxJumpBuf MaxPrimitiveIndex MillisecondClockMask PrimitiveExternalCallIndex PrimitiveTable SemaphoresToSignalSize TempFrameStart' poolDictionaries: 'VMBasicConstants VMMethodCacheConstants VMObjectIndices' category: 'VMMaker-Interpreter'
-------- you know, sometimes for me it even hard to tell whether i need to add a new state variable or there's already some variable what i can reuse.. neither i can clearly tell, what the purpose of each and every of variables in that bloated class without spending a considerable amount of time groking the code.
And do you really think that debugging its code would be significantly easier comparing if that state would be held in dictionary?
The code limits are something that not many people run into, but hitting the limit hurts, hard. Kudos to Eliot for taking this on.
Again, it hurts hard not because you reached those limits, the fact that you reached them is indication that your design contain severe problems which you should deal with first, instead of patching the language to allow you continue exploiting and building even more bloat.
- Bert -
Just to make it clear: i am not against such features. I just sad that Eliot wasting his precious time on something which having so little impact. And sure thing i know that often a software engineers are not in a position to decide what should be top priority task.
And needless to say that i wish Eliot best and all his efforts to succeed.
vm-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Chris Cunnington -
Colin Putney -
David T. Lewis -
Eliot Miranda -
Frank Shearar -
Göran Krampe -
H. Hirzel -
Igor Stasenko