Re: [stack] function "adjoinment"?

chris glur <[email protected]> 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]