Re: [fonc] why are true,false,nil pseudovariables
On Sat, Jun 11, 2011 at 9:36 PM, C. Scott Ananian 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
On Sun, Jun 12, 2011 at 12:13 AM, David Barbour wrote: > On Sat, Jun 11, 2011 at 8:34 PM, C. Scott Ananian 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 8:34 PM, C. Scott Ananian 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 Sat, Jun 11, 2011 at 11:19 PM, David Barbour wrote: > On Sat, Jun 11, 2011 at 6:33 PM, C. Scott Ananian 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 6:33 PM, C. Scott Ananian 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. ___ 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, BGB 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] Alternative Web programming models?
On 6/11/2011 6:59 PM, Julian Leviston wrote: On 11/06/2011, at 3:40 PM, BGB wrote: 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. Yes, but this method of programming sucks, severely. This is why I am wholeheartedly happy that FoNC are on the case. Unfortunately I don't know of any other group of people who have both the insight and capability to do this research. yes, but reloading as the app runs, is still better convenience-wise than its main alternative: go over to Bash or CMD; hit up-arrow, which re-summons a command like, say, "make -f Makefile.msvc"; wait for several minutes (as the C or C++ compiler rebuilds everything, doing a big recursive makefile walk), maybe go and use bathroom or get coffee; start up app, and test whatever changes were made; edit source files some more; repeat... the main advantage is that, often, the in-program "load" command may only take maybe a matter of milliseconds, or a few seconds for a large mess of scripts, and so is a good deal faster, and doesn't require exiting/restarting the app, but as a drawback, does not cover statically-built parts of the app. the analogy would be doing a page-load in FireFox, vs going and exiting and rebuilding FireFox, to update the page... also, one can type commands interactively into the console, but the downside of this is that it is not nearly as effective (the console isn't very good for entering large/complex fragments), as well as generally anything entered into the console is forgotten when the app exits/reloads. "auto-reload on save" could also make sense... for example, in my 3D engine, it is possible to dynamically alter the map geometry as the program is being run (this is how my mapper works), however, the "trick" is that the world representation is not itself nearly so dynamic, and in-fact, most of the "dynamic" aspects can be attributed to me using a very "quick and dirty" strategy to rebuilt the BSP tree (some years back, I had observed that QuickSort could be used as the basis of an O(n log2 n) BSP-rebuild algorithm, vs a more traditional O(n^3) or so BSP algorithm...). a sufficiently fast dynamic compiler could recompile and relink the code whenever the user makes changes, and then saves them... I actually originally intended something like this with my "dynamic C compiler" project, but discovered that my C compiler was far too slow and buggy with this, and often attempting something like this was more liable to blow up in ones' face than work correctly (there are many ugly issues with hot-patching running C code). I later concluded that C was not really the ideal sort of language for this sort of thing. a partial compromise could be a "fast reload" key, where one hits a key to cause the VM to automatically reload any loaded scripts (without having to re-enter a console command). the downside is that one would have to keep track of any loaded modules as to force-reload them. hmm... either way, it is better than a full rebuild with "make", since this generally requires fully exiting and restarting the program as well, in addition to any delays related to rebuilding. Decades later and the Smalltalk and Self systems are STILL some of the easiest environments to discover the intention of programmers, and to create new models and expressions in code. Almost needless to say is that even though this is the case, these systems are severely lacking. Who am I to judge, that I have produced nothing that "doesn't suck"? I'm at present simply someone who is calling it how I see it. All development begins with the awareness of a "lack". ;-) A real need in the beholder. image-based systems have their own sets of drawbacks though... dynamic reload could be a "good enough" compromise IMO, if done well... or such... ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alternative Web programming models?
On 11/06/2011, at 3:40 PM, BGB wrote: > 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. Yes, but this method of programming sucks, severely. This is why I am wholeheartedly happy that FoNC are on the case. Unfortunately I don't know of any other group of people who have both the insight and capability to do this research. Decades later and the Smalltalk and Self systems are STILL some of the easiest environments to discover the intention of programmers, and to create new models and expressions in code. Almost needless to say is that even though this is the case, these systems are severely lacking. Who am I to judge, that I have produced nothing that "doesn't suck"? I'm at present simply someone who is calling it how I see it. All development begins with the awareness of a "lack". ;-) A real need in the beholder. ___ 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 wrote: > On Mon, Jun 6, 2011 at 11:48 AM, Ondrej Bilka 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 Sat, Jun 11, 2011 at 1:40 AM, BGB 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] Logo and Silicon
Jecel, thanks for your reply. Inline. On Jun 11, 2011, at 4:38 PM, "Jecel Assumpcao Jr." 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
Re: [fonc] Logo and Silicon
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. I personally find it > easier > to fathom designing circuits in a way that's both visual and programmatic, > just > because I'm a very visual/verbal person, and it fits my learning style well. But did you actually understand the Visual6502 and not just the idea of it? 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). 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. I really hate to deal with structural designs in Verilog or VHDL (as opposed to behavioral designs) which is why I use TkGate. 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. 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. > 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": 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 the late 1990s and today, when it become a kind of programming language (the last page above, for example, describes the earlier version though it was updated in 2009). -- Jecel ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Logo and Silicon
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. I personally find it easier to fathom designing circuits in a way that's both visual and programmatic, just because I'm a very visual/verbal person, and it fits my learning style well. 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? -- Casey Ransberger ___ 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 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 //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc