On 6/24/07, Darren New <[EMAIL PROTECTED]> wrote:

Bob La Quey wrote:

> stack machines start to look very good. Why? Because using the stack
> unnamed stack variables leads to very fast function calling and nesting.

Agreed. In the interests of disclosure, I've written four FORTH
compilers from scratch in assembly, including on a 6502, which was a
task in itself considering the 6502 has no registers big enough to hold
a stack pointer.


I wrote a couple of token threaded Forths. Good clean fun.

Then I got interested in sourceless Forth, which ultimately turned out
to be a dead end.

http://www.latrobe.edu.au/philosophy/phimvt/joy/forth-joy.html

Yah, Joy is pretty cool.

> So let's get over this idea that functional languages must not use
stacks.
> Stack machines are the natural virtual machine for functional languages.
> Thus building these machines in hardware holds forth the possibilities
of
> significant performance improvement.

I also saw a description of a FORTH-based CPU/core/whatever that had
something like 32 or 64 FORTH-based cores on one chip, all independent.

> See http://www.intellasys.net/products/seaforth/index.php

Yeah, like that. I guess they productized the idea. :-)

> I suspect that it would be very easy to host parallel functional
> languages on this architecture.

That would be cool. I'll have to mention it to the other guy I know who
is really into Haskel. Thanks for the pointer.

In my experience, FORTH is far from functional, tho. I'll have to look
into Joy again.


Forth itself yes, though it pointed in that direction.

BTW, nothing about functional programming as I understand it requires
stacks. Just some kind of common I/O structure with stacks being
a good example.

This NetKernel is also very functional except now the I and O are,
as I understand it, RESTstyle resources i.e. hypermedia. The results
of REST functions, called active URIs in NetKernel, will thus be cached
which can lead to huge speed ups on repetitive computing.

As I understand it the core idea in functional programming is
very simple. A function always has the same output for the
same input. There are no hidden variables (state) that cause
the output to be different from shot to shot. This has huge upsides
for predicting what code will do. It also means one does not need to
compute anything one has computed before, just cache the
first computation.

Is this the understanding of others?

BobLQ
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg

Reply via email to