Fwd: [stack] Concatenative Research

On Mon, Jan 31, 2011 at 1:20 PM, Justin <[email protected]> wrote:

> Hello. Is this forum still alive? I haven't shown my head here for a couple
> of years. I'm a MA/CS major with an ongoing interest in giving concatenative
> languages a firmer mathematical foundation. I have a few partial results:
> (i) an operational semantics, (ii) a concept of & application for
> homomorphisms, (iii) a type system. Is anyone else around here interested in
> this sort of research? Here's a link to my (ongoing) work,
>
> http://dl.dropbox.com/u/17328602/concat/index.html
>
>
Some small comments...

> There are no variables. I have the impression that variables are a
> difficult concept to grasp. We spend years teaching students about variables
> in math class, and even in college many students have difficulty
> understanding that (lambda x. x) and (lambda y. y) are identical. This is
> certainly a double-edged sword - variables are a powerful reasoning aid -
> but I am nonetheless interested in glimpsing a world free of variables.
>

One major problem with variables is not variables themselves, but the
existence of two entirely different concepts overloaded with the same name.

   - Half the time we mean "named storage location" and the other half the
   time we mean "named value". The "named storage location" notion of variables
   implies a stateful system and all the attendant difficulties in analysis.
   - The "named value" notion of variables is a convenience that allows us
   to remove the irrelevant computational fluff of stack manipulations from our
   expressions.

"Concatenative" refers to the syntactic sugar (glucose?, alcohol?) of
choosing a syntax in which function composition is represented by string
concatenation.

I invite you to contemplate what these languages are in the absence of a
string representation. (For example, at one higher level of abstraction a
concatenative language is one where functional composition is represented by
the concatenation of two lists of tokens. But I'm sure we can abstract it
well away from the representation.)

The neatness of concatenative program fragments often arises from a
carefully pre-chosen alignment of the output values of the previous function
with the input requirements of the next.

Where it doesn't align neatly, we need a bunch of stack manipulating "fluff"
that adds nothing to computation.

What may be interesting and useful would be to return to typed variables
(named values variety) and something like a SQL "natural join".

99% of the time which function result variable, needs to be bound which
input variable, is obvious and can be automatically inferred from their type
and name.

By making the rules for doing this explicit, you should be able to create a
concatenative language that doesn't involve the notion of a stack, nor are
the program fragments cluttered with irrelavent variable name references or
stack manipulation "fluff".

I would argue that any language where the function definitions are cluttered
with stack manipulations OR variable references has NOT yet met the full
promise of concatenative languages.



-- 
John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : [email protected]
New Zealand

=======================================================================
This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
=======================================================================


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