Re: [stack] impure concatenativity: let without translation

John Nowak <[email protected]> wrote:
>  William Tanksley, Jr wrote:
>  > second, <ironic>solving once and for
>  > all</ironic> the pesky problem of finding the roots of a quadratic
>  > equation in a concatenative language. I'll do the latter in a distinct
>  > post.

>  I look forward to it. I assume it's nicely doable even if I've not
>  seen it done yet.

Given all the time I've had, one would think I'd be finished already.
I'm not. (Of course, I haven't really put much time into it.)

Don't expect too much -- I don't make the quadratic equation's
*formula* obvious in a concatenative syntax. Instead, I make
completing the square's *process* obvious. From what I can see,
formulas learned in infix will only be recognizable when expressed
using infix. But because computers perform processes better than they
"evaluate formulas", I can always express the quadratic formula as its
equivalent process -- and even if you've never learned how to complete
the square, you'll be able to confirm or deny that the process will
find the roots of the polynomial.

>  > <define>(quad a b c)
>  >    <let>
>  >        ...
>  >   </let>
>  >      p n
>  > </define>
>  > Such a syntax would be unbearable over short ranges (like in the 'let'
>  > above), but I suspect it would be convenient over large syntatic
>  > blocks -- and would make counting parentheses a thing of the past.

>  In all honesty, I've not ever counted parentheses since I began using
>  DrScheme for all my Scheme editing needs years ago. I really do think

I'll check it out -- I do have some recently acquired Scheme editing needs.

>  this is a tool problem. For example, to give the benefits of what you
>  show here, the editor could flash the name of the first element of
>  each list as you close them. Mousing over a closing paren could do the
>  same. I do think the current state of things though in DrScheme (and
>  presumably emacs) is quite sufficient.

The nice thing about such an editor is that it's essentially a static
debugger. I've often thought of doing something like that for a
concatenative language -- flashing thin little arrows to and from the
sources and sinks of the data each word is consuming.

But... I've never found flashing parens sufficient for reading complex
structures, neither in SQL nor in Lisp. I want to be able to *look* at
any part of the code and have some hope of seeing what it's connected
to. I suppose I don't have an actual complaint with Scheme's syntax,
really, and I've never had a problem figuring out Scheme's parens
(after I learned it).

>  >> What are the negative practical implications of being impure?

>  > The problem is that we don't know. I'd like to understand the negative
>  > practical implications of being purely concatenative. I know they
>  > exist.

>  After working more on this recently, I've become convinced that having
>  a concatenative language that is not *purely* concatenative is simply
>  a horrible idea (macros and so on are fine). It complicates not only
>  the implementation, but also how you can fundamentally reason about
>  the language. Additionally, as you say, we simply don't know
>  everything we'd be losing yet.

Good arguments. I'll have to remember them.

>  I've mentioned this before, but I believe such an argument possibly
>  extends to recursive definitions as well (e.g. fact = [zero?] [succ]
>  [pred dup pred fact *] if). To make a completely and wholly
>  unconvincing argument, such definitions destroy the soundness of my
>  termination checker. A special form like 'letrec' would do similarly.

Now this is fascinating -- and I find your termination checker
argument to be profoundly convincing. I've long been interested in
establishing a more useful lower bound for termination proofs.
(Charity always succeeds,
http://pll.cpsc.ucalgary.ca/charity1/www/home.html, but the language
seems to have passed away.)

In general, limiting the capabilities of a language in order to make
reasoning about the language has much precedent; that was (as we've
discussed) the original purpose of the FP language.

>  At the moment, I'm going forward with a purely concatenative language
>  that also does away with recursive definitions and is hence
>  "nameless". In other words, there's no difference between a function
>  definition and a (simple expanding) macro definition except in terms
>  of implementation details (provided that quotations are opaque). I've
>  posted a bit about this previously, and I'm now beginning to
>  understand some of the implications with respect to the type system
>  and optimization possibilities.

Very nice.

>  - John

-Wm