Inline

On Sun, Jan 18, 2009 at 6:52 PM, erik quanstrom <quanstro@quanstro.net>wrote:

> > Well, actually, I was thinking of something along the lines of Lisaac:
> > "dynamic" modules are statically compiled ala object files, & the run
> time
> > handles issues between Plan9 & Inferno. Sys->load & the like would not be
> > dynamic, but would work as expected. Hell, it could even just be a
> > .Net/perl2exe clone: every binary is just an ultra-cut down Dis +
> compiled
> > modules. I like the Lisaac model better, and that's where I was hedging
> my
> > bets; I have a bunch of notes on my local Inferno install, but nothing to
> > show due to more pressing issues. C'est la vie.
> > & debugging this would require a 9Limbo-aware debugger; the .Net-style
> > approach could serve a /lproc or the like though (not that the native one
> > couldn't, but the VMish approach could have hooks for stopping
> execution).
> > $0.02
>
> perhaps i wasn't clear.  so please forgive me for repeating
> myself and charles.
>

No, I understand actually, but we're talking past each other. Despite being
an ass, I'm not nearly as stupid as you
may think.


>
> this is exactly the type approach that i was pointing out
> would not work.  it won't work because inferno provides an
> environment.  the inferno vm will not be able to replicate
> the environment without also dragging large parts of the
> inferno kernel along.  but the consequence of doing this
> will make inferno procs fundamentally different from
> plan 9 procs.
>

Understood; you'll note I never say port Inferno's everything to run atop
Plan9 (Dis does this fine enough).
I meant an static collection of Limbo modules could be shoe-horned into a
binary. I'm talking about Limbo the language;
there would be numerous differences between a 'native' limbo & the hosted
one. For one, dynamic loading wouldn't work.
Another is the thought experiment you provide below. Certain things could be
abstracted, other things would have to go.
I don't want an libinferno.


>
> if you're not convinced of this, try this thought experiment.
> suppose an inferno proc accesses a # device.  and suppose
> further that this device is different in plan 9 and inferno.
> how do you bridge the cap in both directions so that neither
> inferno nor plan 9 is aware of the joke?
>

Again, a native limbo might be different; a programmer might have to handle
such things, much like the way C programmers
have to handle the differences between Plan9 & everything else. I like Limbo
the *language*, most of which could be abstracted to run atop Plan9 fine
methinks. I don't think I'll be running wm/wm anytime soon, nor did I ever
say that. Given that Limbo is modular, reads of # devices could be handled
by a plan9_limbo & an inferno_limbo module, with the same "interface". I
don't see this as a major issue stopping Limbo *the language* from being
brought into native use. *shrug*


> - erik
>
>


--
And in the "Only Prolog programmers will find this funny" department:

Q: How many Prolog programmers does it take to change a lightbulb?

A: No.
 -- Ovid

   "By cosmic rule, as day yields night, so winter summer, war peace, plenty
famine. All things change. Air penetrates the lump of myrrh, until the
joining bodies die and rise again in smoke called incense."

   "Men do not know how that which is drawn in different directions
harmonises with itself. The harmonious structure of the world depends upon
opposite tension like that of the bow and the lyre."

   "This universe, which is the same for all, has not been made by any god
or man, but it always has been, is, and will be an ever-living fire,
kindling itself by regular measures and going out by regular measures"
-- Heraclitus