Re: guile/workbook/extension/dynamic-root.text

Re: guile/workbook/extension/dynamic-root.text

[Tom Lord]

What do you think of moving to a _stackless_ execution model?  In 
a stackless model, eval would never call itself recursively
and a single scheme computation could be resumed from multiple
C stacks or multiple frames in a given C stack.  In a stackless model,
the conservative part of `gc' could be removed.  In a stackless model,
it would be possible to implement a symbolic debugger with _no_
run-time overhead cost.

In a stackless implementation, call/cc would be very fast.

In a stackless implementation, since you can easily have precise GC,
you can easily have _incremental gc_.

With a stackless implementation, you can easily make the interpreter 
single threaded (simplifying programming) but able to multiplex
several real threads by rapidly context switching at virtual
instruction boundaries.  Since it's stackless, those context switches
can be very cheap.

There is a smooth migration path:  if you start by making `eval' and
`apply' stackless, you can still provide "backwards compatible"
interfaces for built-ins that expect a stack-full, conservative-GC
system.  You can gradually fix such built-ins in the core, and perhaps
eventually deprecate the compatability interface.

The big catch: In a stackless implementation, built-ins would no
longer be allowed to call `eval' or `apply' -- they would instead have
to be split up into multiple C functions.  Believe I know that
sometimes the C friendly calling conventions inherited from SCM are
the big win of Guile -- but personally I'm skeptical: I think a
stackless implementation can also be easy to use and will have much
nicer performance and robustness characteristics.

All of this is roughly my plan for systas, which I still sometimes
think about unforking with guile.  I think that guile hackers might
enjoy exploring the wiki running on systas at:

      http://www.regexps.com/labnotes/devo-meta-x/view-topic/---cgi---/---index---

-t

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

Re: guile/workbook/extension/dynamic-root.text

[Han-Wen Nienhuys]

lord@regexps.com writes:
> In a stackless implementation, since you can easily have precise GC,
> you can easily have _incremental gc_.
 
> There is a smooth migration path:  if you start by making `eval' and
> `apply' stackless, you can still provide "backwards compatible"
> interfaces for built-ins that expect a stack-full, conservative-GC
> system.  You can gradually fix such built-ins in the core, and perhaps
> eventually deprecate the compatability interface.

Yes, it also destroys GUILE's biggest asset, and the very purpose of
why GUILE came to be: easy integration with external packages (written
in C)

	 SCM
	 foo (SCM x)
	 {
		x = scm_acons (gh_symbol2scm("bar"), gh_int2scm(1),
	 x);
		/*
			non conservative GC at this point will munge the head of x.
		*/
		x = scm_acons (gh_symbol2scm("baz"), gh_int2scm(2), x);
                return l;
	 }


I think this has been discussed before, and I still think that it is a
Bad Idea.

ObGuile:

What's keeping the 1.6 release? Lurking around, I only see lots of
discussion on tiny details that could just as well be fixed in a 1.6.1
`bugfix' release.  I would really like to require GUILE 1.6 for
Lilypond 1.6 (which is to be released in a few months)


--
Han-Wen Nienhuys   |   hanwen@cs.uu.nl    | http://www.cs.uu.nl/~hanwen/


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

Re: guile/workbook/extension/dynamic-root.text

[Rob Browning]

Han-Wen Nienhuys <hanwen@cs.uu.nl> writes:

> What's keeping the 1.6 release? Lurking around, I only see lots of
> discussion on tiny details that could just as well be fixed in a
> 1.6.1 `bugfix' release.  I would really like to require GUILE 1.6
> for Lilypond 1.6 (which is to be released in a few months)

At this point, the only issues are the relatively minor bits mentioned
in my last release status msg.  I should be able to clean those up
sufficiently in a day or two, but if not, then due to Real Life
factors, I'll suddenly have quite a bit more time for Guile for a
while, starting next Wed.

Either way, once those minor bits are cleaned up, I'll release the new
beta, and under the new release policy, if no serious problems crop up
within 2 weeks, I'll release the first stable 1.6 version.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

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

Re: guile/workbook/extension/dynamic-root.text

[Tom Lord]

        lord:

	[stackless]

	hanwen:

	destroys GUILE's biggest asset, and the very purpose of
	why GUILE came to be: easy integration with external packages (written
	in C)

	[example given that uses conservative gc]


But there are at least several different ways to accomplish the same
goals as that example code, all of which use "easy integration with
... C" yet are stackless-compatible.  So, if it was discussed before,
and what you're saying was the conclusion, that conclusion was
mistaken.

-t


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

Re: guile/workbook/extension/dynamic-root.text

[Gary Houston]

> From: Tom Lord <lord@regexps.com>
> Date: Thu, 30 May 2002 10:28:04 -0700 (PDT)
> 
>         lord:
> 
> 	[stackless]
> 
> 	hanwen:
> 
> 	destroys GUILE's biggest asset, and the very purpose of
> 	why GUILE came to be: easy integration with external packages (written
> 	in C)
> 
> 	[example given that uses conservative gc]
> 
> 
> But there are at least several different ways to accomplish the same
> goals as that example code, all of which use "easy integration with
> ... C" yet are stackless-compatible.  So, if it was discussed before,
> and what you're saying was the conclusion, that conclusion was
> mistaken.

Weren't the previous discussions mainly about conservative vs
precise gc?  Would it be possible to use stackless Scheme
execution and still conservatively scan the C stack?

Stackless execution seems worth investigating just for the speed-up to
call/cc: it's one of the main features of Scheme and it should be
possible to use it without worrying about performance.


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

Re: guile/workbook/extension/dynamic-root.text

[Dirk Herrmann]

On Thu, 30 May 2002, Tom Lord wrote:

> The big catch: In a stackless implementation, built-ins would no
> longer be allowed to call `eval' or `apply' -- they would instead have
> to be split up into multiple C functions.  Believe I know that
> sometimes the C friendly calling conventions inherited from SCM are
> the big win of Guile -- but personally I'm skeptical: I think a
> stackless implementation can also be easy to use and will have much
> nicer performance and robustness characteristics.

One could even have a 'stackless' implementation that allows recursive
calls.  IIRC Marius once told me about a publication that dealt with the
problem of intermingled C and scheme stacks.  I can't currently find the
link, though, sorry.

Best regards,
Dirk Herrmann


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

trump C#, C++, and Java

[Tom Lord]

   > Dirk Herrmann

   > One could even have a 'stackless' implementation that allows recursive
   > calls.  IIRC Marius once told me about a publication that dealt with the
   > problem of intermingled C and scheme stacks.  I can't currently find the
   > link, though, sorry.


You probably mean the paper indicated by keywords "MTA" and
"Cheney"(sp?) and author "Henry Baker".

Another relevant one might be keywords "phantom stacks" and
author "Richard Stallman".

More obscure is kws "UUO handler" and author "Guy Steele" -- or
perhaps that's just a section within the rabbit thesis (I forget).

The general pattern of turning cheap calls to expensive calls
ex-post-facto, at run-time, only on demand, is illustrated (not for
stackless but for generational collection of environments) by recent
SCM for generational GC of environments.

Making it tractable to write C code that honors such complex calling
conventions yet has good performance isn't easy at all.  You might
want to write a custom pre-processor or even a whole new language.

This is just one more in a very long list of little details that one
can't quite do portably in (tractable) C or C++ but that are trivial
if done in a translator _to_ C or C++.  A translator can take a simple
function call syntax and translate it into a quite complex calling
convention automatically.

If one is going to go the trouble of building language support for
this sort of thing, one might as well at the same time address a host
of closely related problems such as: safe execution; portable VM;
modern object model; etc.  If one has bad taste, one will invent C#
:-) If one has better taste, one might build a Java, C# and C++ killer
like the (specification stage project) Pico C:

    http://www.regexps.com/devo-meta-x/view-topic/PicoC/IntroTopic


-t


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