# function "adjoinment"?

## John Nowak — 2010-01-31 23:22:17

    We're familiar with the notion of function composition:

        (a -> b) -> (b -> c) -> (a -> c)

    However, is anyone familiar with a notion of function "adjoinment"?

    Given a function F that takes a tuple A to a tuple B, and a function G

    that takes a tuple C to a tuple D, the adjoinment of F and G would be

    a function that takes the concatenation of A and B to the

    concatenation of C and D. In other words:

        (a -> b) -> (c -> d) -> (a++b -> c++d)

        where ++ is concatenation and a,b,c,d are tuples/stacks

    Such an operation would be equivalent to a smart variant of the

    "spread" combinator in Factor where each function provided would be

    automatically "aligned" with its input. For example, if curly braces

    are the adjoinment operation, the following equality holds:

        {sq, +}  ==  + [sq] dip  == [sq] 2dip +

    In order for this to work, each function would have to have an arity

    of the form N -> M where N and M are natural numbers; it's not clear

    how this could be extended to functions of variable arities (e.g.

    "clear" or "dip"), but that's not an issue for my purposes.

    This is not a proposal. I'm mainly curious if anyone is familiar with

    a formal treatment of such an operation.

    - jn

## Matt Hellige — 2010-02-01 02:40:53

    On Sun, Jan 31, 2010 at 5:22 PM, John Nowak <john@...> wrote:

     >

    >

    >

    > We're familiar with the notion of function composition:

    >

    > (a -> b) -> (b -> c) -> (a -> c)

    >

    > However, is anyone familiar with a notion of function "adjoinment"?

    > Given a function F that takes a tuple A to a tuple B, and a function G

    > that takes a tuple C to a tuple D, the adjoinment of F and G would be

    > a function that takes the concatenation of A and B to the

    > concatenation of C and D. In other words:

    >

    > (a -> b) -> (c -> d) -> (a++b -> c++d)

    > where ++ is concatenation and a,b,c,d are tuples/stacks

    >

     This reminds me of the *** operator in Haskell's Arrow library, which,

    when specialized to the (->) arrow, has type (a->c) -> (b->c) ->

    (a,a') -> (b,b'). You can use this to do something similar, and with

    isomorphisms (a,(b,c)) <=> ((a,b),c), you can treat it like a more

    general concatenation version.  The special syntactic sugar for arrows

    hides the tuple plumbing and makes this reasonably pleasant, but of

    course Haskell's type system doesn't actually allow us to abstract

    over tuples of arbitrary length.

    I wonder if it would be possible to type this operator in a system of

    extensible records like Daan Leijen's Morrow? That would be a neat

    trick.

    Finally, it also reminds me of operads. I've speculated a bit about a

    general syntax for operadic composition, but don't really have

    anything useful to say.

    Matt

## William Tanksley, Jr — 2010-02-01 14:33:49

    Matt Hellige <matt@...> wrote:

     > John Nowak <john@...> wrote:

    > > We're familiar with the notion of function composition:

    > > However, is anyone familiar with a notion of function "adjoinment"?

    > > Given a function F that takes a tuple A to a tuple B, and a function G

    > > that takes a tuple C to a tuple D, the adjoinment of F and G would be

    > > a function that takes the concatenation of A and B to the

    > > concatenation of C and D. In other words:

    > > (a -> b) -> (c -> d) -> (a++b -> c++d)

    > > where ++ is concatenation and a,b,c,d are tuples/stacks

    >

     I'm so bad at reading this kind of notation. But I think I see what you're

    describing.

    I wonder if it would be possible to type this operator in a system of

     > extensible records like Daan Leijen's Morrow? That would be a neat

    > trick.

     Hmm... That's very interesting. I'd not noticed that one "fly by" on

    lambda-the-ultimate. And this is a particularly interesting twisting of

    Leijen: if I read you correctly, you're suggesting making all stack

    functions take the same number of arguments, and then special-casing each

    one by extending its record.

    Given that practical concatenative languages tend to have style guidelines

    that say "no more than 7 arguments per function", it's actually vaguely

    conceivable that this would work (actually, I've never seen a style

    guideline that says 7; they tend to say 3, as 7 is the utter limit of human

    memory). Whatever limit you choose, you'd have to provide means for

    overriding that limit.

    Finally, it also reminds me of operads. I've speculated a bit about a

     > general syntax for operadic composition, but don't really have

    > anything useful to say.

     It does indeed look like operad theory might be useful here. I've never seen

    that before, so I'll leave it up to you -- the intros I found are _very_

    mathematical.

    Matt

    -Wm

    [Non-text portions of this message have been removed]

## john@johnnowak.com — 2010-02-01 15:04:16

    "William Tanksley, Jr" <wtanksleyjr@...> wrote:

     > John Nowak <john@...> wrote:

    >> (a -> b) -> (c -> d) -> (a++b -> c++d)

    >> where ++ is concatenation and a,b,c,d are tuples/stacks

    >

    > I'm so bad at reading this kind of notation. But I think I see what

     you're

     > describing.

     Might've helped if I described it correctly. I meant:

       (a -> b) -> (c -> d) -> (a++c -> b++d)

    Or, to put it another way, if composition is this:

     ____

    |____|

    |____|

    Then adjoinment is this:

     ____ ____

    |____|____|

    Really "concatenation" is a much better term for this than adjoinment

    considering the input tuples are necessarily concatenated to be passed to

    such a function... but using that term here is likely a bad idea.

    I have a *very* tentative sketch of some ideas here; it wasn't written to

    be made public, but if anyone wants to look at my notes, go for it:

    http://johnnowak.com/heap/vis.txt

    - jn

## Matt Hellige — 2010-02-01 19:39:26

    On Mon, Feb 1, 2010 at 8:33 AM, William Tanksley, Jr

    <wtanksleyjr@...> wrote:

     >

    > Matt Hellige <matt@...> wrote:

    >

    > I wonder if it would be possible to type this operator in a system of

    > > extensible records like Daan Leijen's Morrow? That would be a neat

    > > trick.

    >

    > Hmm... That's very interesting. I'd not noticed that one "fly by" on

    > lambda-the-ultimate. And this is a particularly interesting twisting of

    > Leijen: if I read you correctly, you're suggesting making all stack

    > functions take the same number of arguments, and then special-casing each

    > one by extending its record.

     Yes, this is what I'm suggesting. But I only just thought of it as I

    was reading the original email in this thread, so I'm not really sure

    whether it would be possible and haven't really thought it through,

    let alone tried it. The stack effect system of languages like Cat,

    though, always reminded me of a kind of row polymorphism, so I've had

    the inkling before.

    Matt

## john@johnnowak.com — 2010-02-01 20:04:10

    On Mon, 1 Feb 2010 13:39:26 -0600, Matt Hellige <matt@...> wrote:

     > Yes, this is what I'm suggesting. But I only just thought of it as I

    > was reading the original email in this thread, so I'm not really sure

    > whether it would be possible and haven't really thought it through,

    > let alone tried it. The stack effect system of languages like Cat,

    > though, always reminded me of a kind of row polymorphism, so I've had

    > the inkling before.

     If you make use of the fact that almost all first-order functions have

    a fixed arity (e.g. 3 -> 2) except for bizarre functions like 'clear',

    you can type things similar to Factor's smart combinators that handle

    things like stack concatenation. You just need a tiered approach where

    your combinators are not themselves first-class values and only have

    first-order functions provided to them. This lets you have types like

    the following for function "concatenation":

       fn-cat : (A -> B, C -> D) -> A C -> B D

    The only requirement for this to work is that rows are introduced before

    (i.e. "to the left of") the point they are used in a concatenation. For

    example, instantiating the above function with a function of type

    'R int -> R int' and a function of type 'R string int -> R char' would

    yield a function of type 'R int string int -> R int char'.

    Another example is concatenating first-class stacks; the only requirement

    is that two first-order functions need to be supplied -- once for each

    stack -- and then you can assemble the appropriate function "magically":

       stack-cat : (A -> B, C -> D) -> R {A} {C} -> R {B++D}

    This is all a bit cleaner if first order functions are not lifted to

    operate on stacks of >= N size (where N is their input arity), but rather

    on stacks of *exactly* N size, aka N-tuples. Doing this eliminates the

    need to magically "unlift" functions and make them no longer row

    polymorphic. This is the system I briefly describe in that "vis.txt"

    document I linked to: http://johnnowak.com/heap/vis.txt

    I should note that the flatness of concatenating inputs and outputs, as

    opposed to the pairing done in the Arrow for -> in Haskell, lends itself

    much better to a visual representation.

    - jn

    P.S. Emailing very quickly from work. Apologies if the above is unclear

    (or worse).

## John Nowak — 2010-02-03 06:14:22

    On Jan 31, 2010, at 6:22 PM, John Nowak wrote:

     > We're familiar with the notion of function composition:

    >

    >    (a -> b) -> (b -> c) -> (a -> c)

    >

    > However, is anyone familiar with a notion of function "adjoinment"?

     For what it's worth, I've asked a similar question on LtU to cast a

    wider net:

    http://lambda-the-ultimate.org/node/3803

    - jn

## chris glur — 2010-02-06 08:19:26

    Perhaps because of 3rd [going 4th] world connectivety, I couldn't get

    the ltu - yet.

    But since I've 'got you on the line' I'll slip in MY topic "cat-like

    for productivety".

    There's no problem with people playing cross-word puzzles, but

    when I queried cat-like's contribution to productivity, W. Tanksley changed the

    subject and pointed out that 'greatest productivity increases are from

    team-building,

    hence the increased use of java'. I don't dispute this, nor the claim that any

    productivity increase is bad, because it creates unemployment.

    However, altho' the joy-author doesn't seem to directly say so, as

    Prof. Herzberg

    does in his reference to 'conquering complexity', my reference to PRODUCTIVITY

    is the same as theirs: the individual algorithm-designer/coder; and not some

    higher 'what is the purpose of life' consideration.

    Admittedly the topic of productivity increase is related to psychology and fuzzy

    stuff which we technologists don't formally know about.

    While re-reading my files related to 'this' I find repeated implications towards

    that "structuring helps human cognition and hence productivity"; but

    like Victorian

    sex it's never spelled out. Eg. is point-free good because it avoids the need to

    remember names ? Or is the replacement of names by "it" really better,

    when you might

    NEED to know/remember whether the data is in the soak, wash, spin or

    dry function?

    Consider how many billions of people CAN ride-a-bicycle, but few KNOW how to.

    Analogously, IMO computing productivity [in my above defined context] must start

    from human-cognition/psychology. Knowing the goal is more important

    that discussing

    cute steps which allow you to move - perhaps towards some undefined goal.

    Here's a paste  which is relevant to individual

    productivity:--------------------

    I had great productivity increase results with mc > cedit > User-menu/F11

    for scheme-code.

    My previous notes, stated that I didn't like the 'structured editor' facility,

    because I had to lose sight of the text while the process inserted

    the new text. Yes the annoyance of 'loss of sight of the subject' for half a

    second, is related to the annoyance against top-posting ?

    Once I'd accepted this small annoyance, and I'd patched cedits 'lisp' facilty

    towards scheme, I found that the syntax-colouring and "just enter a

    full structure

    at a time instead of single-characters" was a MASSIVE productivity booster.

    It's especially good for scheme, which has only a few syntax elements.

    The beauty of such a system, is that when you work with a new language, or

    a "haven't used for years" one, you re/familiarise yourself with the syntax

    while building the cedit-templates. And 'capture' the knowledge of the syntax

    -- that's how 'expert systems' work.  Then you don't have to waste your creative

    mental resources on syntax trivialities. After all, an IfThenElse construct has

    only 4 elements: its name, the predicate, the consequent, the alternate.

    Why enter 6 keys for 'banana' when it's just a SINGLE-concept !?

    I want to extend cedit's user-menu to be able to enter IDs once only, and then

    just pick-them-off-a-menu for later insertion.  Scoping won't be possible.

    So: avoid complexity and adding too many features to mc/cedit, but I

    found cedit's

    syntax hi-lighting and template-inserting editor a big productivity booster.

    The hi-lighting/colouring and predefined layout/pretty-printing makes eg. the 4

    components of the IfThenElse construct evident/identifiable from amongst the

    mess of brackets.

    I can't understand why they haven't eliminated char-by-char code writing, and

    replaced it by menu-driven -- a bit like spreadsheets. The only things

    you need to

    originate, besides the 'sequence', are ID names.

    When you want to instruct an elevator to go to floor 9, you select ONE button,

    instead of writing a syntactically valid message!?

    == Chris Glur.

     On 2/3/10, John Nowak <john@...> wrote:

    >

    > On Jan 31, 2010, at 6:22 PM, John Nowak wrote:

    >

    >> We're familiar with the notion of function composition:

    >>

    >>    (a -> b) -> (b -> c) -> (a -> c)

    >>

    >> However, is anyone familiar with a notion of function "adjoinment"?

    >

    > For what it's worth, I've asked a similar question on LtU to cast a

    > wider net:

    >

    > http://lambda-the-ultimate.org/node/3803

    >

    > - jn

    >

    >

## William Tanksley, Jr — 2010-02-06 16:05:19

    chris glur <crglur@...> wrote:

     > There's no problem with people playing cross-word puzzles, but

    > when I queried cat-like's contribution to productivity, W. Tanksley changed

    > the

    > subject and pointed out that 'greatest productivity increases are from

    > team-building,

    > hence the increased use of java'. I don't dispute this, nor the claim that

    > any

    > productivity increase is bad, because it creates unemployment.

    >

     That's not even a vague approximation to what I said; it certainly doesn't

    belong in quotes. You picked up _nothing_ about what I meant, although you

    did spell all the words correctly (except "team-building", which I never

    said). The succeeding economic claim is entirely incorrect, and isn't

    related to anything I said.

    I can't understand why they haven't eliminated char-by-char code writing,

     > and

    > replaced it by menu-driven -- a bit like spreadsheets. The only things

    > you need to originate, besides the 'sequence', are ID names.

    >

     But they have done this. It's called "visual programming". (Don't be

    deceived -- "Visual C++" isn't a visual programming environment in THIS

    sense.) Look it up. Actually, Nowak's messages in this thread have been

    about his ideas in that area, so you've been standing right next to a

    pioneer and didn't even know it :-).

    Go ahead, look up "visual programming". A good place to start might be

    http://www.alice.org -- it's for beginners and only works for programming 3D

    animations/scenes/games, but it's very well written and has been ported to

    many systems. I don't think Alice is specifically your _goal_, but it might

    point you in the right direction. Wikipedia will tell you the rest.

    == Chris Glur.

    -Wm

    [Non-text portions of this message have been removed]

## stevan apter — 2010-02-06 16:24:02

    On Feb 6, 2010, at 11:05 AM, William Tanksley, Jr wrote:

     > chris glur <crglur@...> wrote:

    >

    > > There's no problem with people playing cross-word puzzles, but

    > > when I queried cat-like's contribution to productivity, W. Tanksley changed

    > > the

    > > subject and pointed out that 'greatest productivity increases are from

    > > team-building,

    > > hence the increased use of java'. I don't dispute this, nor the claim that

    > > any

    > > productivity increase is bad, because it creates unemployment.

    > >

    >

     not to worry.  as productivity approaches 1 all the displaced

    programmers can become managers.

    company hierarchy of the future:

    	CTO

    	 |

    	mgr

    	 |

    	 :

    	 |

    	mgr

    	 |

    	programmer (1)

    hey, replace the management chain with "federal govt" and "programmer"

    with "private sector (1)" and you're on to something.

    [Non-text portions of this message have been removed]

## pml060912 — 2010-02-07 11:43:45

    --- In concatenative@yahoogroups.com, "William Tanksley, Jr" <wtanksleyjr@...> wrote:

     >

    > chris glur <crglur@...> wrote:

    >

    > > There's no problem with people playing cross-word puzzles, but

    > > when I queried cat-like's contribution to productivity, W. Tanksley changed

    > > the

    > > subject and pointed out that 'greatest productivity increases are from

    > > team-building,

    > > hence the increased use of java'. I don't dispute this, nor the claim that

    > > any

    > > productivity increase is bad, because it creates unemployment.

    > >

    >

    > That's not even a vague approximation to what I said; it certainly doesn't

    > belong in quotes. You picked up _nothing_ about what I meant, although you

    > did spell all the words correctly (except "team-building", which I never

    > said). The succeeding economic claim is entirely incorrect, and isn't

    > related to anything I said.

     Don't let him get to you. You're getting angry enough that you're overstating your rebuttals (for instance, that economic claim isn't ENTIRELY incorrect, although it takes special circumstances like very low elasticity of demand for it to happen - but those DO occur). Sooner or later he's going to pick up on an overstatement and make out that it undercuts your entire position. P.M.Lawrence.

## eas lab — 2010-02-09 11:13:31

    Re. economics/employment, you've followed my 'wrong-question'.

    Like the cat-like-discussion being 'wrong' because it doesn't look to the

    higher, more appropriate question: how to make the programmer more productive;

    "reducing unemployment is an absurd concept", since the amount of leisure is

    the measure of progress.  That US citizens work longer hours than their

    parents did, shows how thing have gone wrong.

     > Sooner or later he's going to pick up on an overstatement and make out that

    > it undercuts your entire position.

     Correct, except that I'm buying, not selling.  I hope to pick up some usefull

    ideas, from amongst the name dropping: "that's called visual programming";

    since I came here seeking:

    1. methods of formal proof of algorithms [following Mc Carthy's notes] and

     find none yet;

    2. more productive parogramming paradigm/s;  this looks hopefull.

    The algol view of repeatedly:

    * collect the args,

    * call the procedure,

    * process the returned value/s;

    can [by moving away from the low level implementation view] be better

    understood [human cognition is more important the machine efficiency]

    by lisp-like: (proc3 (a, (proc2 (proc1 b c) d) ))

      which is a visual mess, as is algol's

    proc3( proc2( proc1 (b,c), d))

      and is more managable if it can be written as eg.

    proc1? -> proc2? -> proc3? -> result.

    I've been [perhaps falsely] encouraged by this data-flow view point,

    from noting how unix-piping can conceptually simplify some tasks, by

    effective information-hiding.

    The point which I'm apparently failing to make is that although forth

    and other cat-like are too low-level, stack-shuffling to construct the

    individual functions, they could perhaps be profitably used at the

    higher level.

    <forgotten name> apparently told that joy-author [sorry I'm not a

    name-dropper] was merely showing some low-level implementation of

    factorial, and that evokeing XY gives a better hi-level implementation.

    Well I've got an even better unary-function, which is called "factorial".

    Is he really trying to dispute that a joy implementation of factorial

    is less cognitively clear than the lisp or algol direct translation of

    the pseudo code which the author directly GAVE?

    A related meta-programming idea:

      when I look at nightmare Oberon-code [C would be the same] with

    3,4,5 nested IfThenElse, I'm reminded how a remarkable forth implemenation

    could perhaps solve it.  I'm ad-libbing this, but think decision-table.

    Using 3 varables: Dog, Cat, Man; each with 1 of 3 conditions

       Fat,Red,New.  [3 x 3 matrix to be viewed by constant width font]

    Dog x   s   e

    Cat k   s   t

    Man a   r   t

    The PROCedudres are: exchange, sell, error, kill, train, advise, rest;

     where the decision-table shows that a fat-dog gets exchange and

     a new-man gets train;..rather than factoring the pairs to eg:

    IF red THEN

       IF (dog OR cat) THEN sell;

    ...etc.

    The [need to be stated] productivety/maintenance benefits from such a

    notation are, amomgst others, information hiding and "all possible

    cases are layed out, in the 3 x 3 matrix for consideration, without the

    additional mental translation of nested IfThenElse".

    What blew my mind when the forth implementation was shown me, was that

    the column & row headers are easy syntactic-sugar, and since forth

    natively...[the details escape me now, as they should, if we free our

    mind from trivialities]. IIRC the rows are unwrapped, so that (Red,Cat)

    becomes the 5th element of the vector of jump-table-elements; and

    fat-man is the 7th - which jumps-to/calls PROC: 'advise'.

    IMO there's a wide acceptance that increased productivety comes from

    meta programming.  The disasterous mental bond that we oldies have to

    stack-shuffling and assembly language direct mapping of the hardware,

    is apparently freed in those who start with scheme as their first

    language.

    IMO approaching computer science from mathematics, rather from

    engineering and hardware, has massive advantages.

    OTOH perhaps its because they didn't get to play with registers

    and shifting bits, that the modern-boys are unduly fascinated with

    stack-shuffling..etc. --  which I want to free my mind of?

    I've just realised that the decision-table-notation can't be easily

    implemented in algol-family languages, since they don't 'read and

    interpret' the source-code like forth does?

    == Chris Glur.

     On 2/7/10, pml060912 <pml540114@...> wrote:

    > --- In concatenative@yahoogroups.com, "William Tanksley, Jr"

    > <wtanksleyjr@...> wrote:

    >>

    >> chris glur <crglur@...> wrote:

    >>

    >> > There's no problem with people playing cross-word puzzles, but

    >> > when I queried cat-like's contribution to productivity, W. Tanksley

    >> > changed

    >> > the

    >> > subject and pointed out that 'greatest productivity increases are from

    >> > team-building,

    >> > hence the increased use of java'. I don't dispute this, nor the claim

    >> > that

    >> > any

    >> > productivity increase is bad, because it creates unemployment.

    >> >

    >>

    >> That's not even a vague approximation to what I said; it certainly doesn't

    >> belong in quotes. You picked up _nothing_ about what I meant, although you

    >> did spell all the words correctly (except "team-building", which I never

    >> said). The succeeding economic claim is entirely incorrect, and isn't

    >> related to anything I said.

    >

    > Don't let him get to you. You're getting angry enough that you're

    > overstating your rebuttals (for instance, that economic claim isn't ENTIRELY

    > incorrect, although it takes special circumstances like very low elasticity

    > of demand for it to happen - but those DO occur). Sooner or later he's going

    > to pick up on an overstatement and make out that it undercuts your entire

    > position. P.M.Lawrence.

    >

    >

## John Nowak — 2010-02-09 13:28:02

    On Feb 9, 2010, at 6:13 AM, eas lab wrote:

     > Is he really trying to dispute that a joy implementation of factorial

    > is less cognitively clear than the lisp or algol direct translation of

    > the pseudo code which the author directly GAVE?

     No. Your reading comprehension is just very poor (in all honesty).

    - jn

## William Tanksley, Jr — 2010-02-09 22:59:00

    eas lab <lab.eas@...> wrote:

     > Re. economics/employment, you've followed my 'wrong-question'.

    >

     I've denied that your question is meaningful.

    Like the cat-like-discussion being 'wrong' because it doesn't look to the

     > higher, more appropriate question: how to make the programmer more

    > productive;

    > "reducing unemployment is an absurd concept", since the amount of leisure

    > is

    > the measure of progress.  That US citizens work longer hours than their

    > parents did, shows how thing have gone wrong.

     My response is the same as it was to the productivity question: there is no

    single "measure of progress", because the problem is multidimensional; it's

    not a matter of measuring how far we are on a line. As for "unemployment":

    there will always be more work to do than there are people to do it -- some

    say The Singularity will eliminate that, but I say nobody knows enough about

    (any kind of) Intelligence to know what Artificial Intelligence will do.

    That's not to say there's no such thing as unemployment; obviously there IS.

    It's to say that productivity increase isn't what creates it.

     > Sooner or later he's going to pick up on an overstatement and make out

    > that

    > > it undercuts your entire position.

    > Correct,

    >

     'twas no overstatement, really; I can hold my own in economics. PML, the

    situations in which the dislocation caused by a productivity increase

    remains semi-permanent aren't themselves caused by the productivity

    increase; any change in relative economic situation under those

    circumstances would cause the same duration of dislocation. The fact that

    productivity increase is a change, and any change under those circumstances

    would cause unemployment, doesn't mean that we can say that "productivity

    increase" causes unemployment. It's better to say that those circumstances

    prolong the unemployment caused by unpredicted change. (I know YOU know

    that, PML, but I need to show why I said what I said.)

    except that I'm buying, not selling.

     >

     Then start selling! You need some currency before you can start buying. And

    you need to be a customer before you can be always right :-).

    I hope to pick up some usefull

     > ideas, from amongst the name dropping: "that's called visual programming";

    >

     Look it up. That IS what it's called. It does what you want. I even gave you

    a starting point URL. What wouldn't you call name-dropping?

    since I came here seeking:

     > 1. methods of formal proof of algorithms [following Mc Carthy's notes] and

    >  find none yet;

    >

     My work is in this field, along the lines of

    http://tunes.org/~iepos/joy.html, reduced to bitstrings of two flat

    pseudo-combinators in order to give me an easily manipulated and completely

    precise semantics. Can you understand Kerby's work? Formal proofs aren't

    easy. And I'm only working on the very first step: the formal semantics.

    Once that's done I'll try to build a real (useful) language based on those

    semantics.

    Hey, have you checked out SPARK Ada? That's a brilliant system. The

    Wikipedia article is helpful. It's amazing that it runs identically on any

    Ada compiler; that was an amazing job of language specification.

    2. more productive parogramming paradigm/s;  this looks hopefull.

     >

     Glad to hear that. (Seriously.)

    I've been [perhaps falsely] encouraged by this data-flow view point,

     > from noting how unix-piping can conceptually simplify some tasks, by

    > effective information-hiding.

    >

     I still think you should check out the classic FP/FL approach of Backus. In

    open source, I think QNIAL comes closest. I know it's not what this group

    DOES, but if that's what you want, that's the closest to doing it.

    The point which I'm apparently failing to make is that although forth

     > and other cat-like are too low-level, stack-shuffling to construct the

    > individual functions, they could perhaps be profitably used at the

    > higher level.

    >

     I've commented that I'm intrigued by your inversion of levels -- "because

    concatenative is too low-level, let's use it only for high-level tasks". I'm

    honestly not sure whether you're onto something really interesting, or you

    just haven't noticed the contradiction.

    <forgotten name> apparently told that joy-author [sorry I'm not a

     > name-dropper] was merely showing some low-level implementation of

    > factorial, and that evokeing XY gives a better hi-level implementation.

    > Well I've got an even better unary-function, which is called "factorial".

    >

     Are you suggesting that paying someone else to write programs for you is

    easier than writing them yourself (i.e. you're saying that you'd rather just

    call someone else's program "factorial" rather than write your own in Joy)?

    I'm not sure that's true. For anything more complex than a factorial

    function, the specs are going to be harder to communicate than the program

    is to write.

    Is he really trying to dispute that a joy implementation of factorial

     > is less cognitively clear than the lisp or algol direct translation of

    > the pseudo code which the author directly GAVE?

    >

     You're quoting Manfred showing a really unreadable implementation whose only

    purpose is to demonstrate how it works on a low level. A few paragraphs

    later in the same essay he gives a much better implementation.

    A related meta-programming idea:

     >  when I look at nightmare Oberon-code [C would be the same] with

    > 3,4,5 nested IfThenElse, I'm reminded how a remarkable forth implemenation

    > could perhaps solve it.  I'm ad-libbing this, but think decision-table.

    >

     1-D jump tables are standard practice in Forth; 2D are less used, but still

    present (and an obvious elaboration). They are indeed useful, though; you're

    absolutely right. You definitely did some research here.

    In CLOS and Factor, this is done slightly differently, using their

    multiple-dispatch OO mechanism. Factor even has predicate classes, where the

    dispatch algorithm calls another method to determine what type a given type

    of parameter is -- so you could have a Single and Married predicate class of

    the Human abstract class (with Man and Woman concrete subclasses), for

    example, and a method (lookup table) that depended on them. (Random example,

    I'm not proposing.)

    The [need to be stated] productivety/maintenance benefits from such a

     > notation are, amomgst others, information hiding and "all possible

    > cases are layed out, in the 3 x 3 matrix for consideration, without the

    > additional mental translation of nested IfThenElse".

    >

     Yup.

    I'm reminded of Julian V Noble's state machine DSL for Forth. It's not the

    exact thing you're describing; the rows are input tokens and the columns are

    states; but the benefits are what you're describing, for its own different

    domain.

    What blew my mind when the forth implementation was shown me, was that

     > the column & row headers are easy syntactic-sugar, and since forth

    > natively...[the details escape me now, as they should, if we free our

    > mind from trivialities]. IIRC the rows are unwrapped, so that (Red,Cat)

    > becomes the 5th element of the vector of jump-table-elements; and

    > fat-man is the 7th - which jumps-to/calls PROC: 'advise'.

    >

     Yup.

     > IMO there's a wide acceptance that increased productivety comes from

    > meta programming.  The disasterous mental bond that we oldies have to

    > stack-shuffling and assembly language direct mapping of the hardware,

    > is apparently freed in those who start with scheme as their first

    > language.

    >

     Yup. That's something that Scheme and Forth have special... Concatenative

    languages in general don't have it quite so much, unless you're willing to

    borrow from Forth's ideas, which kind of hurts the mathematical cleanness of

    the language (and makes it harder to reason about). Interestingly, the

    inventor of Forth recommends avoiding almost all of the fancy syntactic

    things you can do, and sticking to the basic concatenative nature of the

    language (that's not how he says it, of course).

    I've just realised that the decision-table-notation can't be easily

     > implemented in algol-family languages, since they don't 'read and

    > interpret' the source-code like forth does?

    >

     Dead-on right. The problem is that their parsers have to see a lot of the

    source in order to understand any of it. Forth parsers only have to see one

    word at a time; so if a word "consumes" some source, the parser will simply

    never see it, and not become confused.

     > == Chris Glur.

     -Wm

    [Non-text portions of this message have been removed]

## chris glur — 2010-02-10 02:23:27

    ]> Is he really trying to dispute that a joy implementation of factorial

    ]> is less cognitively clear than the lisp or algol direct translation of

    ]> the pseudo code which the author directly GAVE?

    ]No. Your reading comprehension is just very poor (in all honesty).

    So should I comprehend that joy-syntax is less comprehendable

    [with the normal back ground of reading plain text] than lisp/algol ?

    Can you make any contibution to my several TECHNICAL questions,

    starting with opinons of the viability of cat-like 'meta-langauge-ing'

    functions which have been already built in a language which doesn't

    require manual shuffling. ?

    NB. I say 'cat-like' since:

    * there seems to still be discussions about names;

    * I mean the data-flow paradigm, and especially where there are no globals;

        so that at stage N the programmer doesn't need to know/see what happened

      in the previous N-1 functions  i.e. effective information hiding.

    == Chris Glur.

    PS. as an engineer, I like your graphical representation,

    [we prefer diagrams to words..words] but :

    -------------------------------

       then their composition would be this:

         IN

          |

       .--o--------.

       |     F     |

       |--o-----o--|

          |     |

       .--o-----o--.

       |     G     |

       |--o--------|

          |

         OUT

       and their concatenation would be this:

         IN          IN    IN

          |           |     |

       .--o--------.--o-----o--.

       |     F     |     G     |

       |--o-----o--|--o--------|

          |     |     |

         OUT   OUT   OUT

       Composition indicates a dependence (e.g. G is dependent on the

    output of F) that

       requires sequential evaluation whereas concatenation indicates an

    independence (e.g. F

       and G do not share inputs) that allows for parallel evaluation.

    Both operations are

       associative.

    ---------------------

     how should I comprehend "share inputs" ?

## John Nowak — 2010-02-10 03:50:56

    On Feb 9, 2010, at 9:23 PM, chris glur wrote:

     > So should I comprehend that joy-syntax is less comprehendable

    > [with the normal back ground of reading plain text] than lisp/algol ?

     Maybe, but not for the reasons you're presenting (e.g. some

    illustrative Joy example when many far clearer and more obvious

    versions exist). I do see how people could find it harder to

    understand though. Hence the visualization.

    The only goal of a programming language, despite popular opinion

    nowadays, is not to convey ideas to other programmers. It is an

    important goal, but other requirements exist. The benefits that

    concatenative languages may have in terms of reasoning or the

    opportunities they open up for alternative forms of memory

    management are worth looking at even if they can be a bit more

    challenging to use. Who said writing good programs was easy?

     > Can you make any contibution to my several TECHNICAL questions,

    > starting with opinons of the viability of cat-like 'meta-langauge-ing'

    > functions which have been already built in a language which doesn't

    > require manual shuffling. ?

     I've no interest in such a language so I have no contributions.

    I'm trying to solve different problems. I'm not sure why you

    seem to be presuming that you deserve an answer.

     > PS. as an engineer, I like your graphical representation,

    > [we prefer diagrams to words..words] but :

    > how should I comprehend "share inputs" ?

     This was explained in the link I posted:

    http://johnnowak.com/heap/vis.txt

    Again, very provisional stuff. Just thought someone might be

    interested or have seen something similar. You'd be wasting

    your time to critique it at this point.

    - jn

## chris glur — 2010-02-10 14:24:14

    jn wrote:-

     > The only goal of a programming language, despite popular

    > opinion nowadays, is not to convey ideas to other programmers.

     This is a confirmation of my claim that english is a crappy language.

    A main goal of mine/us IS to convey ideas to other programmers;

    usually ourselves - later. Power from parallel processing is of

    little interest to me these days.

    ]> how should I comprehend "share inputs" ?

    ]   This was explained in the link I posted:

    ] http://johnnowak.com/heap/vis.txt

    No I don't think it needs explaining. IMO our words are wrong.

    Ad-libbing it now [for practice] since you've omitted the diagram:

    if the stages are 'in-series' so that output(N) connects to

    input(N+1) [as is conventional] then "output(N) and input(N+1)"

    could be said to be "common".

    If input(N+1) is independent of output(N) then parallel processing

    is possible. In fact (N), (N+1) ordering does NOT exist.

    The concepts are very simple and clear  -- also from your diagrams.

    Once you start using words, you've got to define eg. "share inputs",

    which is more of an electrical-engineering idea ?

    == Chris Glur.

## William Tanksley, Jr — 2010-02-10 14:43:01

    chris glur <crglur@...> wrote:

     >  ]No. Your reading comprehension is just very poor (in all honesty).

    > So should I comprehend that joy-syntax is less comprehendable

    > [with the normal back ground of reading plain text] than lisp/algol ?

    >

     Nowak gave a good answer to this. Mine is a little different: No. If all you

    know how to read is plain English text, don't expect to be able to read

    Lisp, Algol, or Joy at all. In fact, if that's all you know, you can't

    reasonably expect to be able to read the specification of the factorial

    function, since that uses not only algebraic notation, but also the concept

    of recursion.

    People need a basic platform of training. Of all the notations mentioned

    above, Joy definitely requires the least training; of course, that's not to

    say that it's the easiest to use, although I think that the basic notation

    is an excellent framework for an easy-to-use language (as Factor's rapid

    success demonstrates). I include "algebraic notation" as one of the

    notations against which Joy has to compete, and I include it as a notation

    that's harder to teach; in fact, it's much harder, because it's not a

    consistent system (note: I've taught algebra up to "Intermediate" level at a

    community college (that's about good high school level, which is more than

    most people get); I know the problems people normally have learning it).

    In fact, in advanced math, people tend to invent their own notations.

    Herstein writes several of the most-used texts in abstract algebra

    (including the one I learned the majority of my abstract algebra from), and

    his invented notation for function composition used in the context of group

    theory is actually deliberately concatenative (although, of course, he

    doesn't use the term).

    Can you make any contibution to my several TECHNICAL questions,

     > starting with opinons of the viability of cat-like 'meta-langauge-ing'

    > functions which have been already built in a language which doesn't

    > require manual shuffling. ?

    >

     A technical question requires technical context in order to support a

    discussion that reaches resolution; you haven't done any work to provide

    that context. Why don't you build -- or find -- a little compositional

    language (the term I've seen for what you're talking about), and tell us how

    awesome it is, rather than asking us how awesome it'd be? After all, you're

    the one who thinks it'd be awesome.

    You already know that bash, csh, and scsh are made to be mainly

    compositional (the first two are pretty bad programming languages aside from

    their ability to compose other languages' work). You probably know that

    Plan9 is an entire OS designed to enable compositional programming; its pipe

    model includes routing and mailbox support. A while ago you heard (but to

    all evidence did not listen to) me pointing out the Piccola language, which

    is a formal language for software composition. If compositional programming

    is so awesome, why isn't every program written using one of these languages

    to stitch its other languages together?

    NB. I say 'cat-like' since:

     > * there seems to still be discussions about names;

    >

     There have never been any discussion of names in the sense you're using.

    Your language isn't at all like the 'Cat' language. It's concatenative only

    in an odd, crippled way (since you don't want to allow dataflow reshaping).

    It wouldn't really be appropriate to call it 'concatenative', so I respect

    that decision; but it's bizarre to call it 'cat-like'.

    * I mean the data-flow paradigm, and especially where there are no globals;

     >

     I think of concatenative and FP-derived languages when you (and others)

    speak of that.

       so that at stage N the programmer doesn't need to know/see what happened

     >  in the previous N-1 functions  i.e. effective information hiding.

    >

     ...but this is actually a thought-provoking definition. I suspect that it's

    impossible and I'm not sure that it's at all practical; it seems to imply

    that each word in the definition of a program would have to be operationally

    independent of all the previous words; but such a language would be

    incredibly verbose, since you'd have to have distinct words for any possible

    operation, with no possibility of overloading due to context (since the

    definition excludes the possibility of using context).

    The reason I suspect it's impossible is that programming is (to be informal)

    all about making things happen and reacting to things that happen. If you

    can't know or see that happened in the previous N-1 functions, how can you

    program by that definition? This is only an informal suspicion, and I'd be

    glad to discuss what's wrong with it :-).

    And, of course, the deep mathematical meaning I see in your definition MAY

    actually be a creature of my own fevered imagination. If I've read too much

    into your text, let me know.

     == Chris Glur.

     >

     -Wm

    [Non-text portions of this message have been removed]

## chris glur — 2010-02-11 01:29:45

    > Nowak gave a good answer to this. Mine is a little different:

    > No. If all you know how to read is plain English text, don't

    > expect to be able to read Lisp, Algol, or Joy at all.

     I've arrived here via: semi-conductor junctions > transistors > registers

    ->CPUs -> binary coding -> hex coding -> asm -> various HLL.

    If I was A kiddie who'd entered via C, I might be fascinated to look

    *down* to see [and grovell with] the underlying details.

    At this stage of life I want to move *UP*.

    I want the computer to do the grovelling.

    OTOH notions like voice input are absurd, and even colloquial english is crap.

    I favour a method that builds on what we've got: decades of schooling and

    practice in reading.  IIRC a note here previously led to a mention of

    'limited syntax' ideas for speech eg. as used in aviation-speak.

    So, remove art/creativety from what can be formalised and automated.

     > You already know that bash, csh, and scsh are made to be

    > mainly compositional (the first two are pretty bad programming

    > languages aside from their ability to compose other languages'

    > work).

     IMO these [full featured, with control structures ..etc] are botched [l

    ike C] nightmares, where the 'template writer' which I mentioned is

    good to handle -- I want to make a template to translate cannonical

    english into Chinese too.

    The only good thing about 'shell programming' is the ability to pipe.

    Eg. I threw together something to convert:

       Nowak  gave  a good answer to this. Mine is a little different: No. If

       all you

       know  how  to  read  is plain English text, don't expect to be able to

       read

     to:

     > Nowak gave a good answer to this. Mine is a little different:

    > No. If all you know how to read is plain English text, don't

    > expect to be able to read Lisp, Algol, or Joy at all.

     Taking existing functions, it does something like:

     RemoveMultipleSpaces | ReplaceLineEndWithSpace | CutLinesAtWordBoundryForLen<80

     ...etc.

     > If compositional programming is so awesome, why isn't every

    > program written using one of these languages to stitch its

    > other languages together?

     I only accept inductive inferences in fuzzy field like anthropology and

    sociology. We are discussing science. Even IF the soft/fuzzy aspect of

    psychology/cognition is applicable, it is scientifically analyzable

     >> I mean the data-flow paradigm, and especially where there

    >> are no globals; so that at stage N the programmer doesn't

    >> need to know/see what happened in the previous N-1 functions

    >> i.e. effective information hiding.

    > ...but this is actually a thought-provoking definition. I

    > suspect that it's impossible and I'm not sure that it's at all

    > practical; it seems to imply that each word in the definition

    > of a program would have to be operationally independent of all

    > the previous words; but such a language would be incredibly

    > verbose, since you'd have to have distinct words for any

    > possible operation, with no possibility of overloading due

    > to context (since the definition excludes the possibility of

    > using context).

     In the extreme, my example above has ONE word "|" : pipe;

     and access to an infinite library of functions, one of which

     might be named "factorial".

    What I'm interested in, is extending this model with some

    control structures, ability to 'feed input to the data flow

    at stage I and to "branch/Tee" output at stage J ...etc.

    I've just realised that what I'm considering is old-hat and already

    repeatedly proven: the layer-structure where each layer-worker

    only needs to know about his 2 immediate neighbouring levels;

    which via information-hiding greatly increases productivety.

    == Chris Glur.

## William Tanksley, Jr — 2010-02-11 17:17:19

    chris glur <crglur@...> wrote:

     > > Nowak gave a good answer to this. Mine is a little different:

    > > No. If all you know how to read is plain English text, don't

    > > expect to be able to read Lisp, Algol, or Joy at all.

    > I've arrived here via: semi-conductor junctions > transistors > registers

    > ->CPUs -> binary coding -> hex coding -> asm -> various HLL.

    > If I was A kiddie who'd entered via C, I might be fascinated to look

    > *down* to see [and grovell with] the underlying details.

    > At this stage of life I want to move *UP*.

    > I want the computer to do the grovelling.

    >

     I like how you express that; it's amusing. (And informative -- it helps

    explain your perspective a bit. You tend to give too little context for your

    questions.)

     > OTOH notions like voice input are absurd, and even colloquial english is

    > crap.

    >

     Not only do I have no problem with voice input, I'd actually like to study

    it; a concatenative language would be an easy candidate for voice input,

    since it's inherently less tree-structured than an applicative one;

    concatenative text is read and understood completely left to right, without

    special out-of-order punctuation. I wouldn't ever expect to do SERIOUS

    programming by voice, but your type of programming (I called it

    compositional, you're welcome to your own term, although I won't use

    'cat-like') could be a serious candidate for voice -- do the hard stuff in

    another language, then just toss off commands that activate those more

    complex routines.

    I favour a method that builds on what we've got: decades of schooling and

     > practice in reading.

     To be fair, it's plausible that this native ability to understand human

    language requires something structured like the actual human languages we

    observe; it may be that concatenative languages are inherently unsuited due

    to their dependence on non-human mathematical and data-structure

    capabilities, such as maintaining a deep data and/or return stack. But if

    so, that condemnation applies doubly to applicative languages, which require

    all the same return stack capabilities, plus a lot of rapidly changing named

    variables, plus delimiters and out-of-order parsing.

    IIRC a note here previously led to a mention of

     > 'limited syntax' ideas for speech eg. as used in aviation-speak.

    > So, remove art/creativety from what can be formalised and automated.

    >

     I just learned about Gellish (wikipedia it); it even includes the concept of

    contexts and (kind of) the concept of types. I've always wanted to build a

    computer language based on a human-understandable language. Kind of like

    how Heinlein fictionalized that the computer MYCROFT (well, the HOLMES IV)

    was programmable in Loglan (no doubt a subset) even when he was non-sentient

    (sadly, I don't think loglan/lojban is actually apt for that). (Was that a

    spoiler? Naw, too early in the book.)

    ...My friend's been studying relational theory from Darwen's (free) text at

    http://dbappbuilder.sourceforge.net/Rel.php, and based on that he's started

    using a coding convention in his Forth that's new to me: the things he used

    to express as verbs are now typically expressed as 3-tuple relations. So,

    for example, he used to say msg mqueue SEND; now he'd say msg mqueue

    IS-SENDABLE-ON. (I chose an example where the name is the only obvious

    difference.) This consistent use of triples makes his code interestingly

    consistent and understandable, and also makes it amenable to treatment with

    things like Gellish or other RDP-type manipulation. It also allows his code

    to look less like it's doing complex things, and more like it's _talking_

    about those things.

    I wonder whether hooking up a custom Gellish dictionary to a type

    inferencer, and wrapping that into a concatenative language, would result in

    a reasonably pleasant programming experience?

    Meanwhile, APL is one now-computer language that actually started out itself

    life as a communication language between humans. One of its successors might

    be worthy of your study.

      > You already know that bash, csh, and scsh are made to be

    > > mainly compositional (the first two are pretty bad programming

    > > languages aside from their ability to compose other languages'

    > > work).

    > IMO these [full featured, with control structures ..etc] are botched [l

    > ike C] nightmares,

     scsh isn't botched like C (it's botched like Scheme :-) -- but the other two

    _definitely_ are. One should add that they're botched WORSE than C.

     where the 'template writer' which I mentioned is

     > good to handle -- I want to make a template to translate cannonical

    > english into Chinese too.

    >

     Gellish does that.

    The only good thing about 'shell programming' is the ability to pipe.

    I understand, yes. At the same time, those DO have something to teach.

      > If compositional programming is so awesome, why isn't every

    > > program written using one of these languages to stitch its

    > > other languages together?

    >

     I grant that my analogy was sloppy and not to be accepted. In fact, inasmuch

    as there ARE programs written in those languages (for example, the early

    versions of 'git') my argument undermines itself.

    I only accept inductive inferences in fuzzy field like anthropology and

     > sociology. We are discussing science. Even IF the soft/fuzzy aspect of

    > psychology/cognition is applicable, it is scientifically analyzable

    >

     Perhaps in theory. But not at the current state of the science. Those are

    all still soft sciences, and they will remain so for a LONG time (at least

    until their practitioners start attempting to reproduce experimental

    results). You're right to be wary of arguments by analogy, but you need to

    reject them for the right reasons.

     >> I mean the data-flow paradigm, and especially where there

    > >> are no globals; so that at stage N the programmer doesn't

    > >> need to know/see what happened in the previous N-1 functions

    > >> i.e. effective information hiding.

    > > ...but this is actually a thought-provoking definition. I

    > > suspect that it's impossible and I'm not sure that it's at all

    > > practical; it seems to imply that each word in the definition

    > > of a program would have to be operationally independent of all

    > > the previous words; but such a language would be incredibly

    > > verbose, since you'd have to have distinct words for any

    > > possible operation, with no possibility of overloading due

    > > to context (since the definition excludes the possibility of

    > > using context).

    > In the extreme, my example above has ONE word "|" : pipe;

    >  and access to an infinite library of functions, one of which

    >  might be named "factorial".

    >

     How is that 'one extreme' useful in understanding a program? Don't you have

    to understand what the functions actually _do_? Furthermore, this isn't even

    an approach to responding to my response, since you have to answer whether

    the 'functions' interact with each other.

    What I'm interested in, is extending this model with some

     > control structures, ability to 'feed input to the data flow

    > at stage I and to "branch/Tee" output at stage J ...etc.

    >

     I continue to recommend that you check out FP/FL, APL/A+/K, or QNIAL. Those

    languages were build from the ground up for dataflow. Interestingly, most

    definitions in them are readable when spoken left to right (even though

    they're executed right to left).

    APL has the interesting distinction that it was designed and productively

    used as a communication language before it was ever used as a computer

    language. One of the first compilers was a classroom full of graduate

    students :-) who knew assembly language but no APL -- they were given APL

    text, had the symbols briefly explained, and were told to implement the

    result. The number of bugs in the result were compared to a similar setup in

    which the specifications for the program were delivered in pseudocode with

    math notation. APL won solidly. (Sorry, I don't have a citation for that --

    I believe Iverson spoke on it during his acceptance speech for one of his

    awards.)

    I've just realised that what I'm considering is old-hat and already

     > repeatedly proven: the layer-structure where each layer-worker

    > only needs to know about his 2 immediate neighbouring levels;

    > which via information-hiding greatly increases productivety.

    >

     I'm not sure what you mean by "levels". Usually information hiding refers to

    hiding information from the higher levels of abstraction, and ideally you're

    only supposed to know anything about the _one_ layer beneath you (never the

    layer above you). But you appear to mean something more than that -- not

    only that the levels hide information, but that the very words you use to

    address the lower levels don't change each other's meanings.

    In practice, of course, Spolsky's maxim holds: "all abstractions are

    leaky". http://www.joelonsoftware.com/articles/LeakyAbstractions.html

    == Chris Glur.

    -Wm

    [Non-text portions of this message have been removed]

## stevan apter — 2010-02-11 17:31:07

    On Feb 11, 2010, at 12:17 PM, William Tanksley, Jr wrote:

     >

    > Meanwhile, APL is one now-computer language that actually started out itself

    > life as a communication language between humans. One of its successors might

    > be worthy of your study.

    >

     true.

    and don't overlook http://en.wikipedia.org/wiki/Lincos_(language).

    [Non-text portions of this message have been removed]

## William Tanksley, Jr — 2010-02-11 18:22:55

    stevan apter <sa@...> wrote:

     > William Tanksley, Jr wrote:

    > > Meanwhile, APL is one now-computer language that actually started out

    > itself

    > > life as a communication language between humans. One of its successors

    > might

    > > be worthy of your study.

    > true.

    >

     I think you meant, "Ver". (A Lincos word.)  :-)

    I should add that Apter's http://www.nsl.com is a good place to gather info

    about the APL descendants (if you're willing to do some thinking). Although,

    stevan, I note that you haven't written about Ripple; that has some loose

    connections to Enchilada, so it might be interesting to you.

    and don't overlook http://en.wikipedia.org/wiki/Lincos_(language).

    Interesting indeed (thank you!), although I don't think this fits what I

    want. I don't want a language that instructs its hearer from scratch; I want

    one that I can start with a reasonable amount of common ground. Building a

    computer language requires common ground -- no computer is going to learn

    from the language user, they have to start with what the compiler writer

    tells them. (And that's pretty much all they have.)

    -Wm

    [Non-text portions of this message have been removed]