Re: [stack] function "adjoinment"?

eas lab <[email protected]> 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]