Re: [stack] Barebone implementation of concatenative language in c or c++

John Nowak scripsit:

> Sure, it's simple, but what's beautiful about it? It's a bit like having 
> Scheme without lambda really. 

Scheme (and other applicative languages) need lambda or something like
it because they need to bind names locally.  Joy has only global names,
so it doesn't need any such abstraction: non-primitive functions are
literally nothing but lists of objects, where every object in Joy has
both a datum interpretation ('3' means 3) and a function interpretation
('3' means "accept a sequence, return an equivalent sequence but with
3 pushed on it").

> If given the choice between a language with the ability to 
> construct abstractions and one without, all other things being equal, 
> I'm certainly opting for the former. I can't think of an instance where 
> I wouldn't.

Well, given the choice I'd rather have a language that binds local names,
which is why I'm a Joy implementer but not a Joy user.  Although, as Henry
Baker showed, a lambda-based language without assignment and with single-use
names is equivalent to a concatenative language.

> Look at my example again:
> 
>    Haskell:  bi f g x = (f x, g x)
>    Joy:      x [F] [G] bi = x F x G
> 
> The issue is that the 'bi' in Haskell always permits arbitrary order 
> reduction whereas determining if it is possible in the Joy version is 
> undecidable. This is true regardless of concerns related to strictness.

But Haskell only permits arbitrary-order reduction *because* it is
pure and lazy.  If you define bi in ML, you'll get a function which
must be evaluated left to right, because it returns bottom if f does.
That's why I say concatenation is not directly relevant.

> Similar issues hold for other functions like fold. The source of the 
> problem is the fact that all functions in Joy are lifted to operate on 
> products (i.e. the stack). This makes it difficult or impossible to 
> write higher order functions that have the usual laws because it is 
> difficult or impossible to prevent functions from accessing arbitrary 
> amounts of the program's state. For example, the above law for map does 
> hold with the side condition that 'F' has a stack effect of ( x -- y ).

That's true.  Note, however, that the "map law" doesn't hold for Scheme
either, except with the side condition that F returns just once and with
just one value.

> Manfred's "The Algebra of Joy" talks about Joy's suitability for 
> equational reasoning and algebraic manipulation, but I'm of the opinion 
> that it's not actually very good in this regard. I'd actually say that 
> languages like Clean or Haskell -- or better yet, something like 
> Charity, Squiggol, or Hagino's CPL -- are far better in this regard. 

Or Pure, which directly does equational reasoning.

-- 
Schlingt dreifach einen Kreis vom dies!    John Cowan <[email protected]>
Schliesst euer Aug vor heiliger Schau,     http://www.ccil.org/~cowan
Denn er genoss vom Honig-Tau,
Und trank die Milch vom Paradies.            --Coleridge (tr. Politzer)