Re: [fonc] why are true,false,nil pseudovariables

2011-06-11 Thread David Barbour
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

2011-06-11 Thread C. Scott Ananian
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

2011-06-11 Thread David Barbour
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

2011-06-11 Thread C. Scott Ananian
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

2011-06-11 Thread David Barbour
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?

2011-06-11 Thread BGB

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?

2011-06-11 Thread BGB

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?

2011-06-11 Thread Julian Leviston

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

2011-06-11 Thread C. Scott Ananian
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?

2011-06-11 Thread C. Scott Ananian
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

2011-06-11 Thread Casey Ransberger
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

2011-06-11 Thread Jecel Assumpcao Jr.
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

2011-06-11 Thread Casey Ransberger
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

2011-06-11 Thread Michael FIG
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