From: ···@sef-pmax.slisp.cs.cmu.edu
Subject: Re: Eval (Was: What's a treeshaker?)
Date: 
Message-ID: <31n64u$ohp@cantaloupe.srv.cs.cmu.edu>
    From: ········@mindspring.com (Robert Sanders)
    
    This brings me to one point: what is Gwydion going to use as the
    architecture-specific back end?  I beg you to consider at least
    allowing the gcc back end as an option; even if it offers lower
    performance, it will give you dozens of architectures for free.

We're quite aware that the portability problem was our biggest failing last
time, and we're considering various ways of making the Gwydion compiler as
portable as possible.  A C back-end is one thing we're looking at, but
there are some problems with that.

    I'm also worried about Gwydion's portability between Unixes.  Even in
    porting something as small as Mindy to Linux I had to tweak a few old
    BSD constants to POSIX versions and change sigvec to sigaction.
    Little things like aren't even worth mentioning, but in a product the
    size of Gwydion they could add up to quite a royal pain.
    
Well, you probably have to mess with the same set of Unix hassles,
regardless of how big your application is.  Everyone keeps hoping that the
Unix people will get their house (or various vaguely similar houses) in
order, but it keeps not happening.  There's not much we can do about it,
since we need to use those services.  All we can do is to keep the Unix
interface code quarantined in a separate module.  GUI and OODB facilities
could also present portability problems unless stronger standards emerge.

    I'm quite enthusiastic about Gwydion.  Both my roommates want to
    transfer to CMU for their grad studies so they can help get it out the
    door ASAP :-)
    
If they can get in to CMU, we can probably use them.  There are several
hard problems, each worthy of a Ph.D. thesis, in and around Gwydion.
If they're not ready to make such a big move, there will still be the
opportunity to help populate our someday-to-be-humongous library of neat
stuff written in Dylan.  (I guess it's not creeping featurism if you call
it a library.)

-- Scott

===========================================================================
Scott E. Fahlman			Internet:  ····@cs.cmu.edu
Principal Research Scientist		Phone:     412 268-2575
School of Computer Science              Fax:       412 681-5739
Carnegie Mellon University		Latitude:  40:26:46 N
5000 Forbes Avenue			Longitude: 79:56:55 W
Pittsburgh, PA 15213
===========================================================================
From: Robert Sanders
Subject: Re: Eval (Was: What's a treeshaker?)
Date: 
Message-ID: <RSANDERS.94Aug3022710@hrothgar.mindspring.com>
>     This brings me to one point: what is Gwydion going to use as the
>     architecture-specific back end?  I beg you to consider at least
>     allowing the gcc back end as an option; even if it offers lower
>     performance, it will give you dozens of architectures for free.
> 
> We're quite aware that the portability problem was our biggest failing last
> time, and we're considering various ways of making the Gwydion compiler as
> portable as possible.  A C back-end is one thing we're looking at, but
> there are some problems with that.

I wasn't necessarily suggesting that Gwydion compile to C, although
that does give you an easy C FFI; the bigloo Scheme compiler is a good
example.  When you compile to C, calling an arbitrary C function given
the function name and argument description is rather trivial.

What I was suggesting was that Gwydion be able to compile to RTL
(register transfer language), the back-end for GCC, G++, GNU Pascal,
GNU Fortran, and GNU ADA.  I don't know how flexible it is, but RTL
backends have been written for just about every processor there is.

> Well, you probably have to mess with the same set of Unix hassles,
> regardless of how big your application is.  Everyone keeps hoping that the
> Unix people will get their house (or various vaguely similar houses) in
> order, but it keeps not happening.  There's not much we can do about
> since we need to use those services.  All we can do is to keep the

Well, POSIX is at least a messy house with standards for trash
placement.  I don't think there are too many platforms nowadays which
have sigvec but not sigaction; if so, I think the burden of the port
should be on their shoulders.

Non-POSIX things like mmap(), mprotect(), can have quite dramatic
effects on the efficiency of, say, GC, and shouldn't be avoided just
because they're not universally available.  I was mostly expressing
surprise that Mindy used an obsolete signal interface that is
functionally equivalent to the POSIX one.

  -- Robert