4 Replies to “OOPSLA paper”

  1. I very much hope the paper is accepted. My one point might be that the dynamics of Subtext seem much more intuitive in the screencast you did. I might suggest some kind of (necessarily static) graphic that illustrates a very basic “creation by copying” not with screenshots from Subtext but with a schematic. (e.g., this tree represents the state of the system before copying, this tree is after copying but before modification, this tree after modification… now lets walk the tree and see how we’ve got a new function.)

  2. The paper starts well, but the copying paradigm
    could be presented in a circular LIFO stack context.

    Each language (spoken and computeriezed) uses a context Stack aka Return Stack.
    The ubiquitous act of copying you’re talking about is there, embedded into the
    inner working of this fundamental protolanguage inner structure.

    Forth is truly the best protolanguage around,
    look into http://ultratechnology.com
    Marvel at the conciceness and simplicity
    of the ColorForth and AHA implementations.
    There’s much for you to learn there and apply =)

    SUGGESTIONS
    * Use this symetric hexadecimal encoding ring (clockwise from 0)
    0 1234567 8
    GFEDCBA
    * Use Black background and colors, around 4-5-6 types of colors maximum.
    * Use AHA’s trick: Blank dictionary, definitions and referenced words are the low-bits index.
    First times it sees n, the n’th zero of the Index is replaced by current position in memory,.
    Each subsequent time, a call is compiled for the referenced word.
    Hardware compiler easly doable! Would be much more like an unpacker.
    Anyway, i agree with the manifesto, working on my side for three years straight!

  3. (If I understand what I’m reading… (…which could be an issue! 😉

    If “Sum” is just a structure with three fields, arbitrarily labeled “first”, “second” and “=”, then this seems to imply that you aren’t restricted to giving it “first” and “second” values, and expecting it to give you the “=” value. You could, for example, give it the “first” and “=” values, and expect it to figure out the “second” value.

    It struck me…
    >>> This is the essence of Prolog.

    So maybe a Prolog-like approach, or some Prolog ideas would be relevant to your research. (Or not; it’s up to you. 😉

    An aside, for your most recent blog post…
    Yes, I/O will be a very interesting problem. It’s an issue for Prolog too, and functional languages, due to the side-effect nature of output. Hmmm… This could be interesting. I’ll try to stay tuned.

    [Jeff – Yes, there is some similarity with Prolog, particularly the symmetric treatment of input and output arguments. But in Subtext functions are unidirectional – changes go only from inputs to outputs – unlike the bidirectional constraints of Prolog. Further, Prolog clauses represent a whole class of facts, dynamically infered from other clauses. So Prolog is much more sophisiticated, but also much more abstract. I’m trying to keep everything as simple as possible. – Jonathan]

Comments are closed.