Re: [stack] function/object ambiguity + quotation alternative

John Nowak wrote:
> Ideally, a language  
> should make writing long definitions possible (which I often find  
> useful in Scheme when prototyping and experimenting) and short  
> definitions elegant (which concatenative languages do well).

That's certainly true. A long definition that's in a considerable state
of flux _can_ be rather hard to juggle around in a concatenative
language. That's one time when I'd personally forgive the use of local
variables :-), although I'd rather see the programmer spend some time
back at the drawing board (or experimenting with primitives) first.

Let's face it: if you don't know what you're doing yet, you're picking a
poor time to commit to code. The overhead of stack manipulations is only
a part of the problem you're going to face.

I admit that I've done a decent amount of exploratory programming in
concatenative languages; and I don't think they're any more unpleasant
in practice (although clearly in theory they're worse). You WILL wind up
with some nasty stack shuffles, but I think that's part of the penalty
of exploratory programming (leftover and/or misnamed temporary variables
are essentially the same thing). If you're careful to think at every
step you'll minimize the shuffling, and often by the end you'll
understand the problem well enough to do a complete rewrite _correctly_.

> > I do agree that Forth is a system language, with poor facilities for  
> > any
> > higher-level work. I don't concede anything :-) about "Forth and
> > friends", since I don't know what languages you're refering to.

> I was referring to stack-based languages in general; the average  
> length of a function definition needs to be shorter than in a language  
> like Scheme to achieve the same level of readability.

If your only measurement is how a syntax helps you see arities, then
applicative languages win by acclamation. But there's more to reading a
program than knowing the arities of the functions. Concatenative
languages can reveal or conceal a lot more about dataflow, and that can
help (or hinder) the reading as well. Depends on what tools the language
has, and which ones the programmer uses.

> The nesting in  
> Scheme helps visually and things remain mostly understandable even if  
> you don't know the arities of all the functions involved. That's only  
> my opinion of course; I've not launched a study to determine if this  
> goes for most people, although I suspect it does.

Forth is the only concatenative language we've discussed that lacks
nesting. Why would you list "nesting" as an advantage of associative
languages?

> > Factor's EMACS mode, "Fuel", supports automated refactoring.
> Aye, something like this likely helps by reducing the incentive to  
> write large definitions in the first place. It's a shame I've never  
> managed to convince myself to learn Emacs.

Heh. I'm a vim guy myself. But after so much time waiting for a C
refactorer, it's amusing to see one pop up for Factor so quickly. It's
actually becoming reasonably competent.

> - John

-Wm