public inbox for cgen@sourceware.org
 help / color / mirror / Atom feed
From: Jim Blandy <jimb@redhat.com>
To: cgen@sources.redhat.com
Subject: Porting CGEN to other Scheme implementations
Date: Thu, 27 Jan 2005 18:30:00 -0000	[thread overview]
Message-ID: <vt2u0p2spes.fsf@zenia.home> (raw)


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?

             reply	other threads:[~2005-01-27 18:30 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-27 18:30 Jim Blandy [this message]
2005-01-27 18:40 ` Doug Evans
2005-01-27 19:31   ` Jim Blandy
2005-01-27 19:33 ` Frank Ch. Eigler

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=vt2u0p2spes.fsf@zenia.home \
    --to=jimb@redhat.com \
    --cc=cgen@sources.redhat.com \
    /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).