[9fans] alef compiler

[9fans] alef compiler

[Matthew Swank]

I've had an idea percolating in my head for some time now. For the past
couple of years I've been trying to figure out a way use Alef on *nix.
I had hoped that Bell Labs might open source the compiler and runtime
environment since it is obviously abandon-ware, but that doesn't seem
likely to happen. A couple of recent events has made me think more and
more about writing my own open-source Alef: the free-software license
that the current edition of Plan 9 is under, and the excellent progress
that Russ Cox et al have made in porting the plan9 libs and build
environment to *nix. My question is what resources are available about
the Alef libraries/run-time environment that don't violate the 2nd
Edition license agreement?

Thanks,

Matthew Swank
akopa@comcast.net

not an expert, just a frustrated hobbyist

[9fans] Re: alef compiler

[Russ Cox]

We could probably get the lawyers to okay releasing the Alef code,
but I don't see the good it would do.  The Alef compilers
generate Plan 9 object files, which, as discussed in the
archives, are quite different beasts from standard Unix
object files.  Further, if you really want to coexist on Unix, you
don't want to be in the business of generating your own
object files.  I suppose you could retrofit the Alef compilers
to pipe assembly into as.

Libthread provides almost all the run-time support of Alef.
It would likely not be hard to write a front end that translated
Alef code into C+libthread, but it's even easier just to write
in C to begin with, since all the Alef base has been converted.
The differences between Alef and C+libthread are almost entirely
syntactic.  I miss the syntax when I use channels, but I don't miss
it enough to make it seem worthwhile to maintain a converter.

On my list of ideal changes to my programming environment,
Alef syntax isn't very high.  I'd much rather see better support
for profiling, debugging, garbage collection, and automatically
checking correctness.

I think making Limbo run on Unix is a lot more interesting than
making Alef run on Unix.  If anyone wants to try that, I'd be
happy to provide code and moral support.

Just my opinion.

Russ

[9fans] Re: alef compiler

[Matthew Swank]

On Mon, 2004-05-24 at 01:58, Russ Cox wrote:

> On my list of ideal changes to my programming environment,
> Alef syntax isn't very high.  I'd much rather see better support
> for profiling, debugging, garbage collection, and automatically
> checking correctness.
>
> I think making Limbo run on Unix is a lot more interesting than
> making Alef run on Unix.  If anyone wants to try that, I'd be
> happy to provide code and moral support.

A Unix Limbo compiler is an interesting idea, but couldn't you get most
of what you want with an ahead-of-time compiler that turned Dis into
native machine code?

It seems like no-one is especially interested in Alef as a systems
language anymore.  Is there really more interest in Limbo divorced from
Dis?

Matt

Re: [9fans] Re: alef compiler

[Latchesar Ionkov]

On Mon, May 24, 2004 at 02:58:48AM -0400, Russ Cox said:
>
> I think making Limbo run on Unix is a lot more interesting than
> making Alef run on Unix.  If anyone wants to try that, I'd be
> happy to provide code and moral support.

Limbo running on Unix without access to the convenient Plan9/Inferno file
hierarchy doesn't sound very useful. I think that Inferno with support for
native X windows and window managers would be much more useful.

Limbo on Plan9 would be really useful though.

Thanks,
	Lucho

Re: [9fans] Re: alef compiler

[Russ Cox]

> Limbo running on Unix without access to the convenient Plan9/Inferno file
> hierarchy doesn't sound very useful.

C running on Unix without access to the convenient
Plan9/Inferno file hierarchy doesn't sound very useful
either.  But it is.

Russ

Re: [9fans] Re: alef compiler

[boyd, rounin]

> I think that Inferno with support for native X windows and window managers would be much more useful.

therein lies madness.

[9fans] Re: alef compiler

[Matthew Swank]

Well, you called my bluff.  I don't think I am up for anything as
ambitious as releasing Limbo from the Inferno, so I'll just take my
alef2c translator and go home.

Seriously, though, Alef seems to have gotten lost because no-one
(important) thought it was worth the trouble to continue to support it.
Even if it is a museum piece, if there is some interest wouldn't it be
good thing to have the code out there?  I for one would be grateful to
have the opportunity to hack on it.

Matt

Re: [9fans] Re: alef compiler

[rog]

> Even if it is a museum piece, if there is some interest wouldn't it be
> good thing to have the code out there?

i'm not sure that -code- is better than -no code-...

deleting code is a wonderful thing!

although i only used alef in passing, i did do a little bit of
exploring around the language, and the impression i got was that the
basics were there, but the vision had faltered somewhat towards the
end.

i think phil had had loads of ideas about what one might do with a
language, but not all of them were fully developed.  for instance, the
polymorphism support was substantially broken, so even if you had the
compiler, you'd still have to fix those bugs...

from my point of view, the basic problem with alef is that it tries to
be too much like C.

in a concurrent programming language, garbage collection and
language support for immutable complex types, such as you get in
limbo, make all the difference.

i'm not sure the distinction between threads and processes is a good
idea either.  it doesn't make for good modularity (no way of telling
if a function you're calling performs a communication or not; no way
of telling if your caller expects to remain in an atomic section).

Re: [9fans] Re: alef compiler

[Jeff Sickel]

> deleting code is a wonderful thing!

deleted code is debugged code

Re: [9fans] Re: alef compiler

[rog]

> deleted code is debugged code

one of the great things about the dump filesystem is the total
freedom to delete code. no need to keep it around "just in case":
it's available, but needn't clog things up.

Re: [9fans] Re: alef compiler

[boyd, rounin]

> one of the great things about the dump filesystem is the total
> freedom to delete code.

the granularity is too coarse.

Re: [9fans] Re: alef compiler

[Fco. J. Ballesteros]

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

Then it's time to write smaller files :-)

[-- Attachment #2: Type: message/rfc822, Size: 2582 bytes --]

From: "boyd, rounin" <boyd@insultant.net>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
Subject: Re: [9fans] Re: alef compiler
Date: Tue, 25 May 2004 19:51:06 +0200
Message-ID: <01c601c44280$dc4c46d0$727e7d50@SOMA>

> one of the great things about the dump filesystem is the total
> freedom to delete code.

the granularity is too coarse.