Why Concatenative Programming Matters (2012) • Hacker News Board

Re: Why Concatenative Programming Matters (2012)

#31

Post by eurleif » Sat, Apr 13, 2013, 8:57 PM UTC

GhotiFish wrote: post #30

Scaevolus wrote: post #2

The elegant minimalism of Forth is inspiring-- how many other languages can fit their REPL and development environment into a few kilobytes? However, I find implicit arity to be the largest barrier in reading concatenative programs. To understand what a line of Forth code does, you need to understand both what each function does, and how it manipulates the stack to accomplish it. That's more memory pressure than an i…

>To understand what a line of Forth code does, you need to understand both what each function does, and how it manipulates the stack to accomplish it. I don't understand this. I don't need to know how add works to know it pops two bytes off the stack and pushes them added together. Likewise for my own functions. I don't need to know how they do it, just what they do.

I think the point was that you can't tell if `foo bar` is equivalent to `bar(foo())` or `bar(foo(value_from_stack))` or `bar(foo(val1, val2))` or `foo(); bar()` or what unless you know the stack effect of the words.

Re: Why Concatenative Programming Matters (2012)

#32

Post by michaelfeathers » Sat, Apr 13, 2013, 9:19 PM UTC

The only thing that bothers me about the concatenative languages I've seen is the stack. It is a global variable. You don't have the bounding (this is your part of the stack) that you have in languages that have an enforced frame for procedure/method calls.

Sometimes I wonder what a concatenative language would look like if operations could only access things given them by the immediately previous operation and if those things were read-only.

Re: Why Concatenative Programming Matters (2012)

#33

Post by mwotton » Sat, Apr 13, 2013, 9:29 PM UTC

michaelfeathers wrote: post #32

The only thing that bothers me about the concatenative languages I've seen is the stack. It is a global variable. You don't have the bounding (this is your part of the stack) that you have in languages that have an enforced frame for procedure/method calls. Sometimes I wonder what a concatenative language would look like if operations could only access things given them by the immediately previous operation and if th…

Row polymorphism has something to say about this, doesn't it? Coming from Haskell, I'm still finding concatenative programming hard to handle.

Re: Why Concatenative Programming Matters (2012)

#34

Post by [deleted] » Sat, Apr 13, 2013, 9:29 PM UTC

michaelfeathers wrote: post #32

The only thing that bothers me about the concatenative languages I've seen is the stack. It is a global variable. You don't have the bounding (this is your part of the stack) that you have in languages that have an enforced frame for procedure/method calls. Sometimes I wonder what a concatenative language would look like if operations could only access things given them by the immediately previous operation and if th…

[deleted]

Re: Why Concatenative Programming Matters (2012)

#35

Post by kenko » Sat, Apr 13, 2013, 10:09 PM UTC

bun-neh wrote: post #12

Scaevolus wrote: post #2

The elegant minimalism of Forth is inspiring-- how many other languages can fit their REPL and development environment into a few kilobytes? However, I find implicit arity to be the largest barrier in reading concatenative programs. To understand what a line of Forth code does, you need to understand both what each function does, and how it manipulates the stack to accomplish it. That's more memory pressure than an i…

You should look in to Factor, a higher level concatenative language.. http://factorcode.org/ There is a package for lexical variables for those instances where stack shuffling is absolutely not the way to implement your algorithm. This page http://docs.factorcode.org/content/article-locals-examples.h... compares the stack shuffling vs lexical variable approaches. Oh, and those lexical variable have essentially no com…

This snippet reads to me as if it says:

(1) move the player unconditionally (2) do something involve fire, or perhaps involving firing, unconditionally (3) maybe the player waves? maybe there are waves? (4) ??? (5) ??? (6) update the score (7) create a new crab unconditionally (8) storm the fortress? there is a storm?

Nothing is self-describing absent context. (I have sufficient context for "draw-score" and "spawn-crab" that I don't think they mean, say, "check scores to see if there's a draw" and "create a crab of the 'spawn' type".)

Re: Why Concatenative Programming Matters (2012)

#36

Post by abecedarius » Sat, Apr 13, 2013, 11:24 PM UTC

michaelfeathers wrote: post #32

The only thing that bothers me about the concatenative languages I've seen is the stack. It is a global variable. You don't have the bounding (this is your part of the stack) that you have in languages that have an enforced frame for procedure/method calls. Sometimes I wonder what a concatenative language would look like if operations could only access things given them by the immediately previous operation and if th…

One thing it could look like is Backus's FP. I made a concatenative variant of it back in the 80s, and just rewrote the essentials this afternoon: https://github.com/darius/peglet/blob/master/examples/fp.py

In my earlier dialect I added a form of local variables, just enough for better readability without really changing the semantics.

Re: Why Concatenative Programming Matters (2012)

#37

Post by beatgammit » Sun, Apr 14, 2013, 12:55 AM UTC

AlexanderDhoore wrote: post #15

I especially liked the comparison with unix pipes. Whereas Powershell is kind of an attempt to make command line scripting OOP. This could be applied to create the next generation of unix shells... I'll have to think about this.

Hmm, interesting. I've been thinking about a Haskell-based shell, but the flow of concatenative programming might be a better fit. Maybe I'll have to play with this idea this summer as well...

Re: Why Concatenative Programming Matters (2012)

#38

Post by chongli » Sun, Apr 14, 2013, 2:42 AM UTC

raganwald wrote: post #14

Scaevolus wrote: post #2

The elegant minimalism of Forth is inspiring-- how many other languages can fit their REPL and development environment into a few kilobytes? However, I find implicit arity to be the largest barrier in reading concatenative programs. To understand what a line of Forth code does, you need to understand both what each function does, and how it manipulates the stack to accomplish it. That's more memory pressure than an i…

It's exacerbated by the tendency to factor a single function into many simpler ones. That's an interesting comment. I often wonder about where the "sweet spot" of expression lies. If you break things up into too many small things, it's confusing. But a huge monolithic entity is also confusing. What's the "right level of decomposition?"

>If you break things up into too many small things, it's confusing.

Not if you're disciplined about it.

>What's the "right level of decomposition?"

The key is not to decompose your whole problem into a network of tightly coupled parts. It's far better to build up your language with layers of abstraction until you have a new language which makes your problem trivial to express.