From: Tom Lord <lord@regexps.com>
Cc: guile-devel@gnu.org
Subject: trump C#, C++, and Java
Date: Wed, 12 Jun 2002 13:37:27 -0700 (PDT) [thread overview]
Message-ID: <200206122037.NAA13611@morrowfield.home> (raw)
In-Reply-To: Pine.GSO.4.05.10206121809210.12624-100000@cicero.ida.ing.tu-bs.de
> 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
prev parent reply other threads:[~2002-06-12 20:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-30 7:28 guile/workbook/extension/dynamic-root.text Tom Lord
2002-05-30 12:28 ` guile/workbook/extension/dynamic-root.text Han-Wen Nienhuys
2002-05-30 15:31 ` guile/workbook/extension/dynamic-root.text Rob Browning
2002-05-30 17:28 ` guile/workbook/extension/dynamic-root.text Tom Lord
2002-05-30 20:31 ` guile/workbook/extension/dynamic-root.text Gary Houston
2002-06-12 16:35 ` guile/workbook/extension/dynamic-root.text Dirk Herrmann
2002-06-12 20:37 ` Tom Lord [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200206122037.NAA13611@morrowfield.home \
--to=lord@regexps.com \
--cc=guile-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).