public inbox for cgen@sourceware.org
 help / color / mirror / Atom feed
* Porting CGEN to other Scheme implementations
@ 2005-01-27 18:30 Jim Blandy
  2005-01-27 18:40 ` Doug Evans
  2005-01-27 19:33 ` Frank Ch. Eigler
  0 siblings, 2 replies; 4+ messages in thread
From: Jim Blandy @ 2005-01-27 18:30 UTC (permalink / raw)
  To: cgen


I'm interested in porting CGEN to MzScheme.  MzScheme has an active
development community, and (of particular interest to Red Hat) an
actively maintained Scheme-to-C compiler.  I'd like to talk about how
I'm thinking of approaching it, and see what folks think.

I'd like to convert CGEN to use standard R5RS scheme where possible,
and have a per-implementation file --- guile.scm or mzscheme.scm ---
that is loaded before anything else that can define or fix things as
necessary.

The only big issue here is CGEN's use of Guile keywords.  Standard
Scheme doesn't have keywords at all.  Common Lisp allows one to
customize the reader pretty heavily, and I assume that has been
imitated in some Scheme systems, but R5RS Scheme does not, and
MzScheme only allows you to replace the reader entirely.

The "R5RS wherever possible" approach suggests that CGEN simply stop
using Guile keywords, and use symbols whose names begin with :, or
something like that, instead.  Older Guiles used to recognize :foo as
a keyword object, but that was made optional and disabled by default,
since there is Scheme code out there that uses symbols whose names
start with : as symbols.

I've gotten this working for cgen-sid.scm, and it wasn't too bad.
It entailed:
- defining a 'cgen-keyword?' function
- replacing #:foo with either :foo or ':foo
- looking for cases where we check (symbol? foo) before we check
  (keyword? foo)

We'll need some way to produce a helpful warning when people read old
.cpu files with a new CGEN.


At the moment, to build SID files, for example, we invoke Guile like
this:

    guile -s cgen-sid.scm <cgen flags>

The '-s SCRIPT' terminates Guile's argument parsing and passes the
remaining arguments to the script itself.  I'd like to change the
cgen-FOO.scm scripts to expect to be invoked like this:

    guile -l ${cgensrc}/guile.scm -s cgen-sid.scm <cgen flags>

or

    mzscheme -f ${cgensrc}/mzscheme.scm -r cgen-sid.scm <cgen flags>

which have the effect you'd guess.  guile.scm and mzscheme.scm are new
files that would get loaded first, and could do whatever compatibility
trickery was needed.

Most of the stuff in fixup.scm, and some stuff from read.scm, would
move to the new guile.scm.

Thoughts?  Objections to the whole enterprise?  Doughnuts?

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Porting CGEN to other Scheme implementations
  2005-01-27 18:30 Porting CGEN to other Scheme implementations Jim Blandy
@ 2005-01-27 18:40 ` Doug Evans
  2005-01-27 19:31   ` Jim Blandy
  2005-01-27 19:33 ` Frank Ch. Eigler
  1 sibling, 1 reply; 4+ messages in thread
From: Doug Evans @ 2005-01-27 18:40 UTC (permalink / raw)
  To: Jim Blandy; +Cc: cgen

Jim Blandy writes:
 > 
 > I'm interested in porting CGEN to MzScheme.  MzScheme has an active
 > development community, and (of particular interest to Red Hat) an
 > actively maintained Scheme-to-C compiler.  I'd like to talk about how
 > I'm thinking of approaching it, and see what folks think.

How good is the debugging capabilities of MzScheme?
Compared to Guile?  1/2 :-)

OOC, how come Redhat has a particular interest in a Scheme-to-C compiler?

btw, one day I want to port CGEN to Rscheme, for fun's sake.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Porting CGEN to other Scheme implementations
  2005-01-27 18:40 ` Doug Evans
@ 2005-01-27 19:31   ` Jim Blandy
  0 siblings, 0 replies; 4+ messages in thread
From: Jim Blandy @ 2005-01-27 19:31 UTC (permalink / raw)
  To: Doug Evans; +Cc: cgen

[-- Attachment #1: Type: text/plain, Size: 631 bytes --]


Doug Evans <dje@transmeta.com> writes:
> Jim Blandy writes:
>  > 
>  > I'm interested in porting CGEN to MzScheme.  MzScheme has an active
>  > development community, and (of particular interest to Red Hat) an
>  > actively maintained Scheme-to-C compiler.  I'd like to talk about how
>  > I'm thinking of approaching it, and see what folks think.
> 
> How good is the debugging capabilities of MzScheme?
> Compared to Guile?  1/2 :-)

MzScheme has much better debugging capabilities, I think.  They have
an IDE called DrScheme which does all kinds of great stuff.  Here's a
screen shot of DrScheme giving me an error backtrace:


[-- Attachment #2: DrScheme error backtrace screenshot --]
[-- Type: image/png, Size: 41879 bytes --]

[-- Attachment #3: Type: text/plain, Size: 201 bytes --]


> OOC, how come Redhat has a particular interest in a Scheme-to-C
> compiler?

Well, just speed.

> btw, one day I want to port CGEN to Rscheme, for fun's sake.

Absolutely!  May the most useful win.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Porting CGEN to other Scheme implementations
  2005-01-27 18:30 Porting CGEN to other Scheme implementations Jim Blandy
  2005-01-27 18:40 ` Doug Evans
@ 2005-01-27 19:33 ` Frank Ch. Eigler
  1 sibling, 0 replies; 4+ messages in thread
From: Frank Ch. Eigler @ 2005-01-27 19:33 UTC (permalink / raw)
  To: Jim Blandy; +Cc: cgen

[-- Attachment #1: Type: text/plain, Size: 323 bytes --]

Hi -

> I'm interested in porting CGEN to MzScheme.  MzScheme has an active
> development community, and (of particular interest to Red Hat) an
> actively maintained Scheme-to-C compiler.  [...]

You may wish to dig around the CVS history to pull out the old Hobbit
cgen port, just in case it's useful.  Good luck.

- FChE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2005-01-27 19:33 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-01-27 18:30 Porting CGEN to other Scheme implementations Jim Blandy
2005-01-27 18:40 ` Doug Evans
2005-01-27 19:31   ` Jim Blandy
2005-01-27 19:33 ` Frank Ch. Eigler

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).