Re: [stack] Concatenative Research
John Nowak <[email protected]> Wed, 2 Feb 2011 05:02:57 -0500
| Newsgroups | gmane.comp.lang.concatenative |
|---|---|
| Message-ID | <[email protected]> |
On Feb 1, 2011, at 4:02 PM, John Carter wrote:
> The truely irritating thing about both stack languages, and the more
> traditional languages with named parameters, is that the order of the
> parameters and the names don't really matter.
>
> ...
>
> ie. In a very strong sense, parameter names and parameter order is fluff and
> irrelevant to the actual computation being performed!
You could have functions of multiple arguments take records instead. That does away with your parameter names (as you can use field accessors internally) and therefore all substitution, renaming, and the usual lambda dance. It also does away with your argument ordering.
Programming in such a way would work fairly well in a language like Backus's FP. To echo Tanksley, it's lovely. If you've not read Backus's Turing Award lecture, you must: http://www.stanford.edu/class/cs242/readings/backus.pdf
That said, I take issue with the charge that these names are all just fluff. Pointfree languages are generally bad at using a single value at multiple places within a computation. Variables make this much easier.
Pointfree languages are also generally *very* bad at refactoring. This may seem like a strange charge when you have languages with names like "Factor", but it's true. Take, for example, the following function (in pseudo-Joy) that sums a list:
sum = [0] dip [null?] [drop] [uncons [+] dip sum] ifte
Now take that and refactor it to a generic fold function that abstracts over the initializer (in this case '0') and the function to fold with (in this case '+'). In a language with variables, this is trivial. For example, I might do something like this:
Z F fold = [Z] dip [null?] [drop] [uncons F dip sum] ifte
Without variables, this isn't pretty. I'll leave it as a fun exercise.
- jn