Re: [9fans] New language?

Re: [9fans] New language?

[Fco.J.Ballesteros]

> More seriously, I'm happy to work further on Alef, but I have long
> ago accepted Bell Labs' view that maintaing the libraries is a
> disaster.

Is there any way to generate them automatically or to permit
Alef to bind to C ones somehow? Does it use different conventions
in the object files?

Re: [9fans] New language?

[Lucio De Re]

On Wed, Jul 17, 2002 at 09:33:55AM +0200, Fco.J.Ballesteros wrote:
> 
> > More seriously, I'm happy to work further on Alef, but I have long
> > ago accepted Bell Labs' view that maintaing the libraries is a
> > disaster.
> 
> Is there any way to generate them automatically or to permit
> Alef to bind to C ones somehow? Does it use different conventions
> in the object files?
> 
I assume that Bell Labs have looked at this, although not all their
decisions have been entirely flawless.

As I read it, it's a bitch because the procedure call interface is
different from "C".  I haven't looked at the internal details, and
I'm less than confident that I would get very far.  If forsyth
chose to get involved (or rog, perhaps) we'd have a strong chance.

But if things settle down, it may well be worth it.  In addition,
Alef is still experimental, it can pick up quite a lot from Limbo,
if the interest exists (I didn't realise how many features of Alef
I had overlooked in my initial study of it - some of them are
probably obsolete, even, others may be extremely useful).

If the interest is there, I'm happy to put some effort towards
keeping Alef alive.  I am not sufficiently up to date, in an academic
sense, to drive language-based changes, though.

++L

[9fans] more extensions

[Howard Trickey]

This is tempting.  Tuples are one of my favorite things
about Limbo.

However, I'm biased, as I was the one that pushed for tuples
in Limbo, I think.

But adding them to C's already delicate grammar might
be harder than it appears.  And  there comes a point
where an extension changes the flavor of a language
a little too much, and I think this one might be over
that line.

- Howard Trickey

> Including tuples (perhaps as an instance of nameless structs) would
> simplify many interfaces, right? that's one thing I learned using
> Limbo.

[9fans] New language?

[Sam]

> be harder than it appears.  And  there comes a point
> where an extension changes the flavor of a language
> a little too much, and I think this one might be over
> that line.

Too true.  What then, a new language based on C pulling the
yummy stuff out of limbo?  One that's not interpreted, without
a garbage collector, and no atend >:), but that has tuples, array bounds
checking, etc?  At this point should we just considering loosening up
Oberon a little and making a few additions?

I'd be willing to help so long as we fix the BCPL inherited '&'
precedence.

Sam

Re: [9fans] New language?

[GBA]

Don't know much about Limbo, but have you seen this?

http://www.digitalmars.com/d/index.html


> Too true.  What then, a new language based on C pulling the
> yummy stuff out of limbo?  One that's not interpreted, without
> a garbage collector, and no atend >:), but that has tuples, array bounds
> checking, etc?  At this point should we just considering loosening up
> Oberon a little and making a few additions?
> 
> I'd be willing to help so long as we fix the BCPL inherited '&'
> precedence.
> 
> Sam
> 
> 

Re: [9fans] New language?

[Lucio De Re]

On Tue, Jul 16, 2002 at 10:45:02PM -0700, GBA wrote:
> 
> Don't know much about Limbo, but have you seen this?
> 
> http://www.digitalmars.com/d/index.html
> 
What, no tuples?!

More seriously, I'm happy to work further on Alef, but I have long
ago accepted Bell Labs' view that maintaing the libraries is a
disaster.

I see the "D" people mention "versioning".  I'm insufficiently
knowledgeable to decide whether that is something I would appreciate
or despise.  I know NetBSD is hooked on it (in the sense that meat
hangs from hooks in refrigerators, sadly) because of their use of
dynamic libraries.

I guess that makes it a useful solution, if you can't get rid of
the problem in the first place.

++L