develooper Front page | perl.bootstrap | Postings from July 2000

Re: implementation strategy (was Re: Working Group Proposal)

Thread Previous | Thread Next
From:
Bennett Todd
Date:
July 20, 2000 14:35
Subject:
Re: implementation strategy (was Re: Working Group Proposal)
Message ID:
20000720173420.K494@oven.com
I realize you weren't asking me, but if I may be forgiven for
answering despite that:

2000-07-20-15:42:04 John Tobey:
> Joshua N Pritikin:
> > For what it's worth, I think it would be cool to support guile.
> 
> 1. using (explicit) refcounts or mark-and-sweep all-the-way-baby?

Surely using Scheme's own GC. When you backend onto Scheme, GC is
Somebody Else's Problem.

> 2. Why??

Well, for starters, see (1.):-).

And for another, if Guile's designers' claims are true, Scheme is
an exceptionally easy language to back-end onto. And I can easily
believe, or at least fantasize, that it would make a terrific
intermediate language for subsequent code analysis to optimize,
and I have the impression (although I can't cite references) that
it's accumulated a great track record for embedded uses where it's
providing the glue, and low-level libraries are doing the grunt,
which sounds like a match for this job.

And there are compilers available, which would give an alternate
route to executable binaries, which could be useful, and would
certainly be entertaining to some of us.

And there's QScheme, which I've not played with yet, but if it lives
up to its hype it might for the basis for a compile-and-go Perl that
runs faster than anything we could come up with trying to do the job
ourselves; certainly it claims exceedingly impressive performance
characteristics. The key would be in the quality of scheme code
generation we can pull off, of course.

-Bennett

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About