Re: Threads and asyncs

[Tom Lord <lord@regexps.com>]

       > so that A really contains only frames generated by eval.


Why do you need more than one such frame (on a C stack) per Scheme
thread (without calls out to "non-primitive foreign functions")?

With only one C frame, call/cc can be _really_ fast and I think you
can go in this direction without trashing eval's performance.

But, loosely speaking -- the idea of mixing special stacks for
classical C with stacks just for Scheme seems to me to be a useful
one, and, if the interfaces in Guile are suitably cleaned up, a way to
evolve forward.

It's a drag that the work on Guile debugger support has thwarted
simply dropping in the faster eval from recent SCMs -- but you could
leapfrog over that with a stackless eval.


	 > and current C programs can be grandfathered

One language implementor I met made a big fuss over amdhal's law --
which has the implication for Guile that cleaning up various apis
(internal and external) should be a big priority.

I sort of agree, except that there's a trap there: which is to build
up abstractions for abstraction sake in areas where, really, there are
right and wrong answers, with the right answers requiring less than
fully general abstractions (and, in fact, being somewhat incompatible
with fully general abstractions).  

Sort of.  (Isn't there a better way to map out design spaces than
email threads?  That'd be wikid cool.)


     > Did that make sense?  Anyone see a hole in it?

IM*H*O: nothing major.  Keep going in that direction.   But you're
nearing the frontier between my experience and my speculation, so I'll
shut up now.



bibop,
-t


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel