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] Re: t-shirt attempt
Hi Chris... I finally had some time to address the points you made in you reply. Chris Warburton chriswa...@googlemail.com writes: If I understand correctly then there's the potential for ambiguities to arise if we differentiate WRT 2 different objects, and we're calling the same method on both. Actually, there isn't. The 'bind' operator takes a closure as its first argument, and generates a new closure where the specified formal parameter (named by the second argument) is bound to the value in the third argument: NewMethod = bind(OldMethod, 'OldMethodArgN', Value); The 'explicit' operator is also unambiguous. It takes a binding from the closure's lexical environment and turns it into an explicit argument: NewClosure = explicit(OldClosure, 'OldClosureLexVar'); I'm changing my mind on things here: the NewClosure should always take the old lexical variable as the first argument (not as the explicitly named N in Nth argument). If a different ordering is needed, the caller can construct a wrapper method for it. As for the other direction, I've personally been thinking about a similar method of automatically abstracting functions. Rather than injecting new arguments, we generate a separate, more generic function from which we can reconstruct the original function by specifying the arguments. I think this would be a lot harder to use in practice without a lot of reflective capabilities. How would we anticipate the number or types of the arguments? I think the parallels with your notion of more-implied = derivative and more- explicit = antiderivative is interesting, and would value people's thoughts. Me too! Thanks a lot for writing back, this is indeed interesting to me, -- Michael FIG mich...@fig.org //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Logo and Silicon
Jecel, thanks for your reply. Inline. On Jun 11, 2011, at 4:38 PM, Jecel Assumpcao Jr. je...@merlintec.com wrote: Casey, Here's a fun thought: while staring at the Visual6502 visualization, it occurred to me that the likes of Verilog and VHDL probably represent a rather tall order to new folks (like, hey, me,) and the idea popped in there. (snip) But did you actually understand the Visual6502 and not just the idea of it? Nope. But it struck me to be able to see it compute. I do think I took something of value from the experience: I just don't know what it is yet. I didn't, and I am reasonably familiar with that processor at the schematic level and also an integrated circuit designer (I have created a few chips at the rectangle level). Even simple microprocessors are hard to grok, yes, because they're vast. The next watershed, though, might be finding a relatively simple architecture which is also fast. Field programmability gives me a touch of hope that systems will be able to optimize adaptively to the behavior of the user(s) driving, and evolution itself is a pretty straightforward idea, but this is just a thought-example. Most likely the shape it would take would end up surprising me. Biology is a great place to look for working concurrent systems, at least I think so, so hopefully that's a worthwhile thought experiment. The problem is quantitative - there are just too many rectangles changing color at once and there are too many to fit in the screen at a reasonable size. You have to blow them waay up, slow them wy down, and then focus on units of things, I think. Have you looked at the ALUs that kids have been making in Minecraft? You can _walk around_ in there. Inside the simulated microprocessor, and actually watch the electrons walk down the Redstone wire. And when you want the birds-eye, a simple server mod lets you fly way up and look down. It was the thing that jumped out at me and said: it's time, mortals can make processors now, which means you can do anything. Quit your job and go, Case. I probably won't have time to finish a design, but I'll have learned a lot in failing, at least. I really hate to deal with structural designs in Verilog or VHDL (as opposed to behavioral designs) which is why I use TkGate. I'm going to have to look up TkGate, because I don't know the difference. Unfortunately, we get into quantitative problems again with screen sizes. My hand drawn schematics in the 1980s were always one to three pages of very large paper. You needed a big desk to be able to fully open them up and you could see both the big picture and details at the same time. It was easy to quickly trace some signal from one side of the design to the other. Imagine walking alongside the wire as the electron travels. While your view is very limited to your specific locus of attention, you can zoom out. A heads up display would probably help. Now people do schematics on letter sized paper. The project is broken down into some 20 or so pages. Each page has just one or two integrated circuits (or subblocks) in them and wires running to the edge of the page to connectors that indicate other pages. In other words, this is a netlist and not a schematic and there is no advantage compared to the same thing in VHDL. It has the disadvantage of taking up 20 pages to do what VHDL would do in just 3. Sure. So in this hypothetical Logo, which I'm calling WeeHDL like a right parody, you should be able to do macroscopic things like what you do in Verilog. We seem to have learned that different sets of metaphors help explain different sets of problems. The problem I have with Verilog seems to be that it's used to avoid thinking about the very details that I hope to understand. I obviously want a lot of abstraction, but I also want to able to understand the mapping between these representations, which got me thinking OMeta, etc. It dawned on me that I could probably make a little Logo where the turtles draw with metal ink. Has anyone tried anything like this before? Does it seem like a good idea to try it now? You might like Chuck Moore OKAD system which is used to create the GreenArray chips. The software is not available, but there are videos of him giving demos of it. Mostly in his fireside chats: Oh, I looked at their site the first day that I became aware that I wanted to actually build a computer instead of keeping the blinders on about my hardware. I didn't know that he was involved in that. The TinyComputer jumped out at me as a system that I actually wouldn't mind writing assembly on, and it's been a long time since I've said that. Going to look at GreenArrays again. http://www.ultratechnology.com/rmvideo.htm http://www.ultratechnology.com/okad.htm http://www.colorforth.com/vlsi.html Note that the software evolved quite a bit from the early 1990s (when it was a paint the rectangles style) to
Re: [fonc] Alternative Web programming models?
On Sat, Jun 11, 2011 at 1:40 AM, BGB cr88...@gmail.com wrote: The responsiveness of exploratory programming environments (such as the Smalltalk programming environment) allows the programmer to concentrate on the task at hand rather than being distracted by long pauses caused by compilation or linking. this is also partly where dynamic script loading and eval can be nifty... say, one is using an app, and then in the console they type in a command, say: ;load(scripts/myscript.bs); and can quickly edit the file, hit the uparrow in the console to re-enter the prior command, and observe the results. or, the ability to directly type script commands into the console to observe results, ... You should spend some time playing around with the Web Inspector in Chrome or other Webkit browser. Console, live code editing, lots of other good stuff. The only big drawback is the complexity of the system: HTML+CSS+JS is quite a hairy beast. but, I was also left recently thinking some about the possible strangeness of me basically creating a vaguely Lisp-like programming environment within C. http://en.wikipedia.org/wiki/Greenspun's_Tenth_Rule --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 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] Alternative Web programming models?
On 6/11/2011 6:30 PM, C. Scott Ananian wrote: On Sat, Jun 11, 2011 at 1:40 AM, BGBcr88...@gmail.com wrote: The responsiveness of exploratory programming environments (such as the Smalltalk programming environment) allows the programmer to concentrate on the task at hand rather than being distracted by long pauses caused by compilation or linking. this is also partly where dynamic script loading and eval can be nifty... say, one is using an app, and then in the console they type in a command, say: ;load(scripts/myscript.bs); and can quickly edit the file, hit the uparrow in the console to re-enter the prior command, and observe the results. or, the ability to directly type script commands into the console to observe results, ... You should spend some time playing around with the Web Inspector in Chrome or other Webkit browser. Console, live code editing, lots of other good stuff. The only big drawback is the complexity of the system: HTML+CSS+JS is quite a hairy beast. yeah... my current strategy already involves some amount of typing commands into the console... as noted in the other post, the main role that load(...) serves, is that I am limited to about 100 characters at a time I can type into the console, which is a limitation. edit/reload/go is more of a compromise... but, I was also left recently thinking some about the possible strangeness of me basically creating a vaguely Lisp-like programming environment within C. http://en.wikipedia.org/wiki/Greenspun's_Tenth_Rule --scott except, in my case, there is a more direct reason: long ago, I had messed around with Scheme, and implemented a Scheme VM; many Scheme-like facilities and practices have managed to somewhat outlive the original VM, but were just sort of kludged back onto C, and became a part of the baseline coding practice. or such... ___ 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
