User: Password:
|
|
Subscribe / Log in / New account

Should be: Goodnight, Perl 6.

Should be: Goodnight, Perl 6.

Posted Feb 12, 2013 11:14 UTC (Tue) by niner (subscriber, #26151)
In reply to: Should be: Goodnight, Perl 6. by alankila
Parent article: Chromatic: Goodnight, Parrot

The nice thing about hyper operatiors is that they allow automatic parallelization and they work with all operators even ones you define yourself. The compiler simply has much better optimization possibilities this way. That the code becomes very compact is a nice side effect.


(Log in to post comments)

Should be: Goodnight, Perl 6.

Posted Feb 13, 2013 9:44 UTC (Wed) by k8to (subscriber, #15413) [Link]

But a generic method of applying functions to data can achieve the same thing while being syntactically regular and expressively clearer.

Should be: Goodnight, Perl 6.

Posted Feb 13, 2013 17:27 UTC (Wed) by raiph (guest, #89283) [Link]

> But a generic method of applying functions to data can achieve the same thing

Can it?

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.

Should be: Goodnight, Perl 6.

Posted Feb 13, 2013 17:59 UTC (Wed) by andrel (guest, #5166) [Link]

Have there been psychology experiments proving that understanding the different syntax uses a different part of the brain, or is that still informed conjecture?

Should be: Goodnight, Perl 6.

Posted Feb 13, 2013 19:21 UTC (Wed) by raiph (guest, #89283) [Link]

> Have there been psychology experiments proving that understanding the different syntax uses a different part of the brain, or is that still informed conjecture?

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) [Link]

I've just hunted around starting from a google for "understanding syntax" "brain scans". I've not yet found stuff specifically discussing how natural language syntax processing neural mechanisms impact our processing of computer language, but here's one that A) confirms use of some such mechanism in processing of music notation and B) suggests that such mechanisms would/can also be used used in reading, writing, understanding computer languages.

"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)

Should be: Goodnight, Perl 6.

Posted Feb 13, 2013 19:01 UTC (Wed) by k8to (subscriber, #15413) [Link]

Claims 1 and 2 are false on their face, because (as you point out yourself) the execution is equivalent.

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.

Should be: Goodnight, Perl 6.

Posted Feb 13, 2013 20:26 UTC (Wed) by raiph (guest, #89283) [Link]

> Claims 1 and 2 are false on their face, because (as you point out yourself) the execution is equivalent.

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)?

Should be: Goodnight, Perl 6.

Posted Feb 14, 2013 12:21 UTC (Thu) by fatrat (subscriber, #1518) [Link]

How does this differ from the Haskell (or Python version)

ghci> [ x+y | x <- [1,2,3], y <- [4,5,6] ]
[5,6,7,6,7,8,7,8,9]

which seems cleaner.

In Haskell, that can also deal with lazy lists etc

Should be: Goodnight, Perl 6.

Posted Feb 14, 2013 17:41 UTC (Thu) by hummassa (subscriber, #307) [Link]

Cleaner than

> 1, 2, 3 X+ 4, 5, 6
5 6 7 6 7 8 7 8 9

? ok then.

Should be: Goodnight, Perl 6.

Posted Feb 14, 2013 18:22 UTC (Thu) by raiph (guest, #89283) [Link]

> How does this differ from the Haskell (or Python version)
> ghci> [ x+y | x <- [1,2,3], y <- [4,5,6] ]
> [5,6,7,6,7,8,7,8,9]

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).

Should be: Goodnight, Perl 6.

Posted Feb 14, 2013 19:34 UTC (Thu) by nybble41 (subscriber, #55106) [Link]

Haskell doesn't let you mix letters and symbols in operator names, but apart from that it's simple to define an operator similar to Z~ which works on any nested list type, including lists of strings ([[Char]]):

infixr 6 ++~
(++~) = zipWith (++)

["foo", "bar"] ++~ ["sing", "song"]

Should be: Goodnight, Perl 6.

Posted Feb 14, 2013 21:40 UTC (Thu) by fatrat (subscriber, #1518) [Link]

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 © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds