Advice sought for Inferno library development strategy

[clasp126...@icebubble.org]

As I mentioned in another thread, I have been working a sizeable
contribution to Inferno: specifically, a set of library modules and
applications to provide functionality which is currently missing. The
code that I've written, so far, makes use of pick ADTs in several
places. Those who have ever used pick ADTs know that they can have a
tendency to make code more complicated, more difficult to maintain, and
generally look "uglier." But, when done correctly, use of "pick"
statements can be limited to just a few functions, or to a couple of
source files.

In the process of writing these library modules, however, I stumbled
upon (quite accidentally) Limbo's support for polymorphism:
specifically, type-parameterized functions and data. So, I went back
and began switching my code to use these polymorphic features, before
continuing to write any additional library code. Unfortunately, I've
discovered that Limbo's polymorphism support is very buggy and
incomplete. (Limbo's current inability to define polymorphic functions
on type-parameterized ADTs with "self ref" arguments means that it's not
really useful for general programming.) So I am left with two (less-
than-ideal) options for continued development:

(1) I could just forget I ever knew anything about polymorphism in
Limbo, and go back to using pick ADTs, exclusively. Among the
disadvantage of this approach: (1.a) If/when Limbo's support for
polymorphism is ever completed, someone would have to go back and
re-engineer my libraries to use a polymorphic API, (1.b) such API
changes would then require updating the applications which use the
libraries, and (1.c) pick ADT interfaces generally aren't as clean
as a true polymorphic interface would be.

(2) I could continue developing polymorphic APIs by "faking" the
polymorphic functionality which would be available IF Limbo's
polymorphic support were complete. Among the advantages of this
approach: (2.a) the cleaner, polymorphic, interfaces would be
available right from the start, and (2.b) if/when Limbo's support
for polymorphism is ever completed, applications using the libraries
would not need to be updated. Among the disadvantages of this
approach: (2.Z) the library code would have to be full of
programmatically looney "fake" polymorphic code as a stand-in or
placeholder for the real API. This craziness could cause confusion
for someone trying to maintain the library code. It could also
cause confusion for application developers who try to employ the
libraries' polymorphism more generally, under the mistaken
assumption that it's complete. (2.Y) If/when Limbo's support for
polymorphism is ever completed, there would be many places, spread
across the code for a few different libraries, where the "fake"
polymorphic code would then have to be removed/replaced/updated with
the correct (complete) polymorphic code.

(3) There also is a third, "non-option:" fixing the Limbo compiler. I
do not currently have enough of a working-knowledge of the compiler
to do this, nor know anybody who does, nor have the time to learn
enough about the compiler's internals to fix it on my own. Option
(3), therefore, isn't really a viable option.

So, I'm looking for advice on which way to proceed. Which way would be
less confusing? Which way would require less work? Which way would be
easier to maintain? Any comments/suggestions/advice would be welcome.

[Go Phone]

>
> (3) There also is a third, "non-option:" fixing the Limbo compiler. I
> do not currently have enough of a working-knowledge of the compiler
> to do this, nor know anybody who does, nor have the time to learn
> enough about the compiler's internals to fix it on my own. Option
> (3), therefore, isn't really a viable option.
>
> So, I'm looking for advice on which way to proceed. Which way would be
> less confusing? Which way would require less work? Which way would be
> easier to maintain? Any comments/suggestions/advice would be welcome.

You are wasting your time investing on Limbo / Dis vm. It is a big
task to make Limbo/Dis multi threaded. It is probably time to let it
RIP.

[hiro]

educational maybe

> --
> You received this message because you are subscribed to the Google Groups
> "inferno-os" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to inferno-os+...@googlegroups.com.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/inferno-os/CABe3aPfUTTT%2BBQoco41dg_QvhmKi%3DVVi6Pm4wUjrExC%3DsFy4Dg%40mail.gmail.com.
>

[clasp126...@icebubble.org]

Go Phone <gopho...@gmail.com> writes:

> You are wasting your time investing on Limbo / Dis vm.

I find this an unexpected remark from the guy who put so much effort
into porting Inferno to Andro|d. I certainly hope you do not consider
that effort wasted. I find the Andr0id port of Inferno extremely
useful, and find myself making use of it on at least a weekly basis.

> It is a big task to make Limbo/Dis multi threaded.

I thought Dis was already multithreaded. The PDF which introduces the
Inferno Operating system describes multithreading as being a core
service provided by the OS kernel.

> It is probably time to let it RIP.

Last I heard, someone was working on creating a 64-bit version of Dis.
Was that you, or someone else on the list?

[Will Cassis]

I think "bhgv" is the person you're thinking of who got Inferno
running on Android (https://github.com/bhgv/Inferno-OS_Android).

I'm not a contributor to the Inferno list (yet!) but I'm a big fan and
am interested in improvements/modernization. I don't think your ideas
sound like wasted effort!

On 2/19/22, clasp126...@icebubble.org

> --
> You received this message because you are subscribed to the Google Groups
> "inferno-os" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to inferno-os+...@googlegroups.com.
> To view this discussion on the web, visit

> https://groups.google.com/d/msgid/inferno-os/868ru6am2z.fsf%40cmarib.ramside.
>