Re: [Gnu-arch-users] arch roadmap 1 (and "what's tom up to")

[Tom Lord]

    > From: "Tobias C. Rittweiler" <address@hidden>

    > On Thursday, July 1, 2004 at 8:21:58 PM, 
    >     Tom Lord <address@hidden> wrote:

    >>     > Tom, this aspect certainly looks *interesting* and useful, but I 
yet
    >>     > have to mediate about the *practical* usefulness, because I can 
imagine
    >>     > a loss when it comes down to actual /integration/ (note: this is 
clearly
    >>     > not the same as combination). Did you already collect insights wrt 
this?

    >> I don't quite understand what issue you mean by "/integration/" so I'm
    >> not sure how to answer.

    > The integration between different language features and facilities in
    > either ways: technical as well as social.

    > An example for the technical integration is memory management. Another
    > one is flow of control, especially languages with heavy use of exception
    > vs. those without any kind of stack-unwinding exception handling.

Ah, ok.   Another example of that is the type system: mapping the data
types in one language into or onto or bijectively with those of the
next language.

Yes, I have thought about that and have many little tricks up my
sleeve but I don't have any big grand unified theory in most areas.

The single, abstract datatype in furth (an
array-like/dictionary-like/atom-like thing with single inheritence)
_is_ I think a universal and for deep reasons (it's a good abstract
model of what you can do given a CPU holding an address in some
register and connected to a hierarchical store).  Many historic
languages can't map type-for-type cleanly onto one another (e.g.,
Emacs lisp thinks that the null-pointerlike-value and the false-value
are the same;  Scheme thinks they are different;  there is no
unproblematic way to put these together).   Yet for every mismatch
like that there's an easy fix that _does_ fit into the universal type
albeit while breaking strict compatability with the historic language
(e.g., an Emacs lisp-prime, with nil and false distinct, while not
able to run the emacs lisp library, would still have the other
interesting attributes of emacs lisp).

Memory mgt:  well, I actually intend it to be practical to run _some_
applications on Furth using only reference counting but, afaik, graph
tracing GC plus finalizers plus explicit deletion of values plus weak
reference support is a sufficiently general model into which to
subsume everything else.

Flow control:  when the matches between languages break down (as
between Scheme and almost anything else), there's always the
"coroutine" model in which languages don't directly call out to one
another but do a kind of in-process RPC-like communication, each side
doing whatever the heck it wants with flow control.   The FFI, that
is, the C interface, works that way:  C programs communicate with
Furth programs by alternately giving cycles to the VM and reading and
writing virtual machine registers between virtual instructions.  This
is such a simple yet only slightly awkward approach that solves so
many common problems in inter-language bindings that I'm surprised it
didn't take off years ago.   I guess it's partly because, for a long
time, only Sun and then Microsoft were taken seriously proposing VM
APIs and Sun's was inherited from a completely different world
(i.e., not meant to be a definitive word in VMs) and MSFTs, despite
the history of some of the people who worked on it, is too.



    > Social integration is how well a certain facility of one language is
    > perceived to fit into another. I can recall a usenet post from you to
    > CLL, in which you asked what would be if there was a way to have all
    > the python library available for lisp/scheme (I think that may even
    > be a historical reason for furth now?) at the cost of a lousy
    > integration of this foreign library into the lisp programming model.

Social integration is just a freaky black art and, based on much
experience, I have a few rules of thumb (which are fairly banal):

    ~ need it _right_away_?  That's what quick and dirty hacks
      are for (like making Python callable from CL or Tcl callable
      from Guile)

    ~ otherwise: start from scratch and do it right (like Arch).
      You'll catch _way_ more sh*t up front, much of it (even and
      most disappointingly from geeks) sounding like echos of what
      the mythical pointy-haired-boss would say (can you say
      "internalized abuse"?).   In the medium and longer term, though,
      the clarity of what you create will (slowly) win hearts and
      minds.

In that context, I caution schemers that while Scheme has many
virtues, like optional bignum support, Scheme is great when you need
it and a heavyweight burden when you don't: there is more than one way
to crack the egg from which Scheme has given us a taste of the yolk.


    > My problem is that, assumed that the technical obstacles aren't
    > too hairy, I'm not convinced that in praxis the usefulness will
    > be as great as one might thought a priori for the reason of
    > social integration above. On the other hand, it's worth a
    > try. :-)

Yeah.  I'm encouraged by Parrot and Python both slowly converging on
unholy "Scheme underneath with a standard library on top".  I'm also
encouraged by the palpable, substantial, and recent upswing of renewed
(or anew) interest in lisp-family languages.

My take is that the lisps are very close to fundamental expressions of
deep truths, the same way that Einstein's Special Relatively squarely
nails the truth that Lorentz and friends recognized but couldn't quite
grasp.  _Something_ (maybe Furth, maybe not) in a lispish direction
wins unless we are just collectively too damn stoopid. ("Space aliens
program in Scheme.")

-t

p.s.: I don't have another thread to put this in so I'll just toss out
that all of the parts of C++ that didn't make it into C, except for
the syntactic extensions, would have been better provided by exactly
three new constructs:

        ~ inline functions
        ~ named, parameterized blocks (like functions except
          you can't call them.  Instead you have to use...)
        ~ global goto -- for leaving the current function call
          almost as during a return but, instead of returning, jumping
          to named parameterized block.   The caller of the function
          that jumps to a block becomes the caller of the block so
          that if the block returns, rather than jumps to another
          block, it returns to that caller

The "C as intermediate language" crowd would go nuts over those
features.

For direct use, as in C++, you _might_ want a fancier means of syntax
extension than CPP (though inline functions would let you get pretty
far all by themselves).

That'd turn a furth inner-interpreter from something like this:

        while (cycles--)
        {
          $inx_reg->fn ();
        }

into something like this:

        if (cycles)
          jump $inx_reg->block (--cycles);