Re: [fonc] why are true,false,nil pseudovariables
On Sun, Jun 12, 2011 at 1:43 AM, David Barbour dmbarb...@gmail.com wrote: Anyhow, I agree that there are plenty of optimizations available. But I don't believe we can replace a true/false/nil method invocation with a specialized bytecode in a typical open system. SELF did not have specialized bytecodes for these. See http://selflanguage.org/documentation/published/implementation.html --scott -- ( http://cscott.net ) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] why are true,false,nil pseudovariables
On Sun, Jun 12, 2011 at 1:07 AM, C. Scott Ananian csc...@laptop.org wrote: SELF did not have specialized bytecodes for these. See http://selflanguage.org/documentation/published/implementation.html --scott Why is this relevant? The opening question was about Squeak. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] why are true,false,nil pseudovariables
On Sun, Jun 12, 2011 at 2:20 PM, David Barbour dmbarb...@gmail.com wrote: On Sun, Jun 12, 2011 at 1:07 AM, C. Scott Ananian csc...@laptop.org wrote: SELF did not have specialized bytecodes for these. See http://selflanguage.org/documentation/published/implementation.html --scott Why is this relevant? The opening question was about Squeak. The self system included a full implementation of Smalltalk. Look, this isn't really a big deal. Squeak makes some architectural choices. We're discussing alternatives. It's certainly possible for Squeak to have used a different compilation strategy for constants. You could start with the architecture of SELF, for example, and make the tradeoff that you have a lot of native methods but gain the advantage of very few specialized bytecodes. You may prefer to have more specialized bytecodes and fewer native methods, or some other point in the design space. There's no right or wrong here. I'm just puzzled why you seem to be insisting that no other alternative to Squeak's design is possible, when there are multiple existing systems which demonstrate the opposite. I've been continuing the discussion because it's been a nice opportunity to tip my hat to a lot of other people's excellent and interesting systems work, but I think it's time this thread ended now. --scott -- ( http://cscott.net ) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] why are true,false,nil pseudovariables
On Mon, Jun 6, 2011 at 11:48 AM, Ondrej Bilka nel...@seznam.cz wrote: My point is that you could just Object have methods true,false and nil Any reasonably optimalizing compiler would replace them with bytecode. As methods, you could override them. And since you don't know which subclasses override these methods, you couldn't optimize. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] why are true,false,nil pseudovariables
On Sat, Jun 11, 2011 at 2:05 AM, David Barbour dmbarb...@gmail.com wrote: On Mon, Jun 6, 2011 at 11:48 AM, Ondrej Bilka nel...@seznam.cz wrote: My point is that you could just Object have methods true,false and nil Any reasonably optimalizing compiler would replace them with bytecode. As methods, you could override them. And since you don't know which subclasses override these methods, you couldn't optimize. This is a very limited way of thinking about your compiler. It hasn't been mainstream thinking since the advent of Java, which turned conventional compiler technology on its head. (Obviously, the ideas quite predate Java, but I'm just speaking of point at which the majority of papers in academic compiler conferences (say, PLDI) suddenly shifted away from purely static compilation.) --scott -- ( http://cscott.net ) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] why are true,false,nil pseudovariables
On Sat, Jun 11, 2011 at 11:19 PM, David Barbour dmbarb...@gmail.com wrote: On Sat, Jun 11, 2011 at 6:33 PM, C. Scott Ananian csc...@laptop.org wrote: the majority of papers in academic compiler conferences (say, PLDI) suddenly shifted away from purely static compilation. True, if you use a dynamic compiler you can do quite a few more optimizations. I guess I'm used to the embedded world, where static compilation is still king. Even if you're doing pure static analysis, you should be doing open/closed class analysis and specializing/inlining any class which has no subclasses in the compilation. --scott -- ( http://cscott.net ) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] why are true,false,nil pseudovariables
On Sat, Jun 11, 2011 at 8:34 PM, C. Scott Ananian csc...@laptop.org wrote: Even if you're doing pure static analysis, you should be doing open/closed class analysis and specializing/inlining any class which has no subclasses in the compilation. Doesn't work with pluggable components. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] why are true,false,nil pseudovariables
On Sun, Jun 12, 2011 at 12:13 AM, David Barbour dmbarb...@gmail.com wrote: On Sat, Jun 11, 2011 at 8:34 PM, C. Scott Ananian csc...@laptop.org wrote: Even if you're doing pure static analysis, you should be doing open/closed class analysis and specializing/inlining any class which has no subclasses in the compilation. Doesn't work with pluggable components. This is discussed in the paper(s). Closed/open types can be considered part of the type system, in which case they are perfectly compatible with plugins. They can also be considered a type of runtime optimization or method cache, in which case you just need to do a bit of extra bookkeeping when you load your component. No inherent problem. If you actually *do* redefine 'true' in your pluggable component, of course, you get the poor performance which you apparently wanted. But there's no magical reason why you can't do proper interprocedural analysis. (Call it 'link time optimization' and stick it in the dynamic loader if you want to keep it under the radar.) --scott -- ( http://cscott.net ) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] why are true,false,nil pseudovariables
On Sat, Jun 11, 2011 at 9:36 PM, C. Scott Ananian csc...@laptop.org wrote: This is discussed in the paper(s). Closed/open types can be considered part of the type system, in which case they are perfectly compatible with plugins. If you make it an explicit part of the type system, I could see that working, but it's also an extra concept for developers to struggle with. I've tried a few language designs with open functions and data types, but ended up rejecting the technique to improve composition. Open/closed *analysis* is not such an easy task in an open system. Anyhow, I agree that there are plenty of optimizations available. But I don't believe we can replace a true/false/nil method invocation with a specialized bytecode in a typical open system. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] why are true,false,nil pseudovariables
They are parsed just like variables. Rather than finding their declaration in the method itself they are known to the compiler. Hence pseudovariables. It also has the advantage that you don't have to pollute your literal frame since there are special bytecodes that handle them. Cheers, Toon On Jun 6, 2011 5:51 PM, Ondrej Bilka nel...@seznam.cz wrote: Hello As I started looking at squeak I am puzzled why true,false and nil are pseudovariables. Why they cannot be just constants like 0,1. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] why are true,false,nil pseudovariables
My point is that you could just Object have methods true,false and nil Any reasonably optimalizing compiler would replace them with bytecode. On Mon, Jun 06, 2011 at 08:05:13PM +0200, Toon Verwaest wrote: They are parsed just like variables. Rather than finding their declaration in the method itself they are known to the compiler. Hence pseudovariables. It also has the advantage that you don't have to pollute your literal frame since there are special bytecodes that handle them. Cheers, Toon On Jun 6, 2011 5:51 PM, Ondrej Bilka nel...@seznam.cz wrote: Hello As I started looking at squeak I am puzzled why true,false and nil are pseudovariables. Why they cannot be just constants like 0,1. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
