Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
Should be: Goodnight, Perl 6.
Posted Feb 13, 2013 17:27 UTC (Wed) by raiph (guest, #89283)
First, Perl 6 operators compile down to function application. Folk are free to write directly in the function application style. So at some level these appear to be equivalents.
But, aiui, there are at least three big impacts:
* you need syntax to control order of evaluation;
* the pragmatics of optimization are profoundly changed;
* understanding it uses a different part of our brain.
> while being syntactically regular and expressively clearer.
Most languages allow a + b as well as add(a,b) and I'd say most folk find the a + b option expressively clearer in most situations.
To drill down in to the details of evaluation, consider the Perl 6 expression "@ X~ @b" which for our purposes I'll say means to create the array result of a crosswise combination of the elements of the array variables @a and @b, concatenating each pair.
Now consider how to express that in a function application style, in particular how the compiler, syntax and programmer deal with order of evaluation, parallelization, optimization, and laziness.
Posted Feb 13, 2013 17:59 UTC (Wed) by andrel (subscriber, #5166)
Posted Feb 13, 2013 19:21 UTC (Wed) by raiph (guest, #89283)
Aiui there have been lots of brain scan experiments demonstrating that understanding spoken natural language uses different synaptic circuits to process different syntax elements. I hope to get some time to find more useful answers to your question this weekend and post back in this thread.
Use of our natural language processing neural mechanisms for reading, writing, understanding computer languages
Posted Mar 7, 2013 21:27 UTC (Thu) by raiph (guest, #89283)
"These combined results suggest that [an area of the brain], known to be crucial for syntax processing in [natural] language, plays also a functional role in the processing of musical syntax. Hence, the present findings are consistent with the notion that Broca's area supports the processing of syntax in a rather domain-general way." (from http://www.ncbi.nlm.nih.gov/pubmed/20570253)
Posted Feb 13, 2013 19:01 UTC (Wed) by k8to (subscriber, #15413)
You don't typically need to control order of application of the function to the items, which is why it's fast. You do of course need to control order of function application, but with function syntax it's all the more clear.
Optimization meanwhile is the same, except for the most degenerate of examples such as "we hand-crafted the machine code of this operator for this one case".
But a typical implementation of combining two arrays in all permutations would be something like
permute(NIL, a, b)
so the compiler can see that there's no action required but to combine them, and it's a trivial matter to parallelize the combination across N cores or computers. Indeed there were functional compilers capable of fully optimizing this problem in the early 90s.
As for item 3 I will have to say that I doubt you are right, but I cannot claim either way since there is of course no evidence presented, and probably no research.
I do find infix to be pleasant for colloquial, familiar expressions. I find it to be personally extremely counterproductive for comprehension with unusual constructions.
Posted Feb 13, 2013 20:26 UTC (Wed) by raiph (guest, #89283)
Heh. It appears you didn't interpret the word "appear" as I intended...
> You do of course need to control order of function application, but with function syntax it's all the more clear.
So, is it concat(cross(@a,@b)) or cross(concat(@a,@b)), or something else, and what is the result?
> Optimization meanwhile is the same, except for the most degenerate of examples such as "we hand-crafted the machine code of this operator for this one case".
Are you suggesting it's degenerate to specifically atomically optimize a crosswise concatenate?
> As for [understanding a+b uses a different part of our brain than add(a,b)] I will have to say that I doubt you are right, but I cannot claim either way since there is of course no evidence presented, and probably no research.
I'd be surprised if there was no research but my own investigations have been of brain science as it relates to natural language, not computer languages. The "aiui" was partly because I've taken Larry's word (he was a linguist) that similar principles apply. I hope to dig in to this this weekend and post back here, with a focus on comparing add(a,b) and a + b.
> I do find infix to be pleasant for colloquial, familiar expressions.
I'm going to assume here you mean in computer languages. As in, you find a + b in computer code pleasant.
For me @a X @b ("array a crossed with array b") felt natural and pleasant as did @a X~ @b ("array a cross concatenated with array b").
> I find it to be personally extremely counterproductive for comprehension with unusual constructions.
So a+b works well instead of add(a,b) but a**b fails compared to power(a,b) (or something like that)?
Posted Feb 14, 2013 12:21 UTC (Thu) by fatrat (subscriber, #1518)
How does this differ from the Haskell (or Python version)
ghci> [ x+y | x <- [1,2,3], y <- [4,5,6] ]
which seems cleaner.
In Haskell, that can also deal with lazy lists etc
Posted Feb 14, 2013 17:41 UTC (Thu) by hummassa (subscriber, #307)
> 1, 2, 3 X+ 4, 5, 6
5 6 7 6 7 8 7 8 9
Posted Feb 14, 2013 18:22 UTC (Thu) by raiph (guest, #89283)
That's the same.
One issue is whether you prefer, from an expressivity point of view, x+y or something like add(x,y). I usually prefer x+y. It looks like, for the "familar" function/operator add/+, we all agree: x+y is generally preferable.
So what about "unfamiliar" functions/operators? I'm going to guess at the haskell syntax for a zipped string concat:
zipwith (++) ["foo", "bar"] ["sing", "song"].
Perl 6 uses ~ instead of ++ and supports infix notation so one can write:
["foo", "bar"] Z~ ["sing", "song"]
It seems alankila and k8to (and you?) consider the Z~ infix notation for zipped string concat to be less clear.
Let's assume for a moment that this is just a syntax sugar issue. (Regardless of whether the sugar seems sweet or not to any given writer/reader.) Given that Perl 6 is aiming at (among other things) being a metaDSL (a language for easily expressing and combining DSLs) then sugar matters and it's potentially important to make it trivial to use a wide range of expressivity, including infix notation, for user defined functions/operators (as well as builtins of course).
Posted Feb 14, 2013 19:34 UTC (Thu) by nybble41 (subscriber, #55106)
infixr 6 ++~
(++~) = zipWith (++)
["foo", "bar"] ++~ ["sing", "song"]
Posted Feb 14, 2013 21:40 UTC (Thu) by fatrat (subscriber, #1518)
I think my issues is that the [ ... ] list/monad comprehension approach is very general, and, as nybble41 points out, can be specialised as needed.
The Perl6 approach seems to lead to a proliferation of operators, and consequent maintenance issues.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds