Bob La Quey wrote: > 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? >
I know very little about functional programming, but I keep getting stuck on claims that assume the absence of side effects. Is code that has side effects (eg, any i/o) not allowed IN a function by some kind of formality? Is side-effects stuff forced into some special code artifact that is outside the meaning of _function_ -- or what? Regards, ..jim -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
