[9fans] native limbo

[9fans] native limbo

[kazumi iwane]

Hello 9fans,

The idea of having native limbo appeals to me, too. There seem to be
various degrees of nativeness people are talking about, though; some
see limbo as yet another language to write apps on plan9, others as
an integral part of inferno. I 'd be happy with the scenario "2" below.

1) a limbo compiler that produces plan9 native executables

Modules that access plan9 services must be written, probably taking
every advantage of native environment rather than trying to conform to
inferno's module layout. Limbo apps would speak 9p instead of styx,
too. A reincarnation of alef, really, and I fear the same fate might await.

2) a dis interpreter and plan9 native modules

Similar to 1), but modules and apps in dis binary. Thanks to Vita Nuova,
there already is a limbo-to-dis compiler on plan9 (right? don't know how
inferno/emu-dependent it is, though). You'd invoke a dis interpreter,
which would provide gc, syscall i/f and whatnot, to execute limbo apps.

3) Inferno Compatibility Environment (ICE)

Together with 2), in a manner and spirit similar to APE, it might be
possible to create a set of compatibility modules for inferno, using all
the namespace tricks and a 9p-styx gateway. But this *is* what emu
is all about, I guess...

4) a complete inferno environment *without emu*

No idea if/how this is possible, but I guess this is what some people
are after.

P.S.
No pun intented on the subject line, really.

- kazumi

Re: [9fans] native limbo

[Dan Cross]

In article <LPBBIBIIHKHEGDBPHBDOKEGFCAAA.kiwane@dream.com> you write:
>2) a dis interpreter and plan9 native modules
>
>Similar to 1), but modules and apps in dis binary. Thanks to Vita Nuova,
>there already is a limbo-to-dis compiler on plan9 (right? don't know how
>inferno/emu-dependent it is, though). You'd invoke a dis interpreter,
>which would provide gc, syscall i/f and whatnot, to execute limbo apps.

Hmm, not to be contrary, but isn't this basically what emu does
already?  It provides a dis interpreter, plus modules which map native
limbo services into native Plan 9 services (eg, a call to Sys->open()
gets mapped into open(2)).  Maybe I'm missing something.

	- Dan C.

(ps- I think that a native limbo compiler would be sweet; but I too
fear that it would go the way Alef did.)

[9fans] RE: native limbo

[kazumi iwane]

> From: Dan Cross
> In article <LPBBIBIIHKHEGDBPHBDOKEGFCAAA.kiwane@dream.com> you write:
> >2) a dis interpreter and plan9 native modules
> >
> >Similar to 1), but modules and apps in dis binary. Thanks to Vita Nuova,
> >there already is a limbo-to-dis compiler on plan9 (right? don't know how
> >inferno/emu-dependent it is, though). You'd invoke a dis interpreter,
> >which would provide gc, syscall i/f and whatnot, to execute limbo apps.
>
> Hmm, not to be contrary, but isn't this basically what emu does
> already?  It provides a dis interpreter, plus modules which map native
> limbo services into native Plan 9 services (eg, a call to Sys->open()
> gets mapped into open(2)).  Maybe I'm missing something.

In this scenario, I dreamed of having modules that closely match plan9
native system calls, device drivers interface and namespace conventions,
but not necessarily those of inferno. Significant overlap, sure. Gratuitous
incompatibilities, maybe. In areas where inferno is ahead, notably Tk, I'd
steal them and adopt them to plan9 native services :-).

Also, a dis interpreter should be a plan9 native executable, so that limbo
apps would be just like C apps but interpreted; a web browser written in
limbo would run directly in a rio window, you could write a plan9 user level
file server in limbo, etc..

I gues I'm on the "yet another language" camp.

- kazumi