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]