On the bus ride out to Charleroi I caught a stray brainwave about how to properly notate at least some of Haskell's Lens library, so I wrote up some notes on it. This is going to be slightly spooky, but not much more than the previously-existing ability to bind one data structure to another. I don't know if this is in the spirit of the Haskell library, as it relies heavily on types and type transformations, but I gather that types don't perform quite the role they do in Perl 6. We could conceivably make the lens type-aware so that a lot of mechanism could go away, but the code below has the general idea. The 'lens' library is essentially a metaphor for focussing in on your data, in roughly the following sense:
my $lens = Optical::Bench::BeamSplitter.new; $a =< $lens >= $b; # Think of $a "passing through" $lens into $b. $a = 'foo bar'; is-deeply $b, [ 'foo', 'bar' ]; $b.[1] = 'moo'; is $a, 'foo moo';
Lenses can be chained:
my $lens2 = Optical::Bench::BeamSplitter.new('-'); $a =< $lens >=< $lens2 >= $b; $a = 'foo-bar baz-qux'; is-deeply $b, [ [ 'foo', 'bar' ], [ 'baz', 'qux' ] ];
If that behavior is a little too magical, use the '<<' and/or '>>', and then the changes only go in one direction, or none at all (but they'll still happen on binding.)
$a << $lens >= $b; $a = 'foo bar'; is-deeply $b, [ 'foo', 'bar' ]; # ok 1 $b.[0] = 'moo'; is-deeply $b, [ 'moo', 'bar' ]; is $a, 'foo bar'; # ok + 2, ok 3
If you're having trouble coming up with a use for this, envision database work, where you have a transform (like, say, converting timestamps) you need to do on the way in and out of the database:
my $lens = O::B::mySQL.new('Mmm dd, yyy'); $created-date =< $lens >= $created-date-mySQL; is $created-date, 'Feb 3, 2016'; is $created-date-mySQL, '2016-02-03T09:50+02:00';
Put this anywhere in your method, and you can rest assured that the mySQL date will be formatted correctly when it gets saved. With sufficient black magic, it might even work like:
$post.<created-date> =< O::B::mySQL::Date.new >= $params.<created>;
so you could drop that into your Dancer'ish Controller, or maybe even directly in your database Model, once there's an ORM thing for Perl 6.

Replies are listed 'Best First'.
Re: Focussing Haskell into Perl 6
by DrForr (Beadle) on Feb 04, 2016 at 13:24 UTC

    Apparently dashes in variable names in Perl 6 are terribly controversial, "extra work" for programmers. I can see how forcing your shift-fingers not to press down is a bit of extra work, but believe it or not, you get used to it.

    They've been the standard in functional languages for decades, so there is a great deal of prior art. And surely Perl programmers are among the elite few that can actually change the regular expression their chosen tool uses to highlight and select identifiers, we've already added $@%&* to the front.

    Yes, this could have been done with simple method calls, but the original Haskell docs created their own syntax, and in Perl 6 we're free to create our own syntax as well. If as a programmer you want to stick to the same set of operators that's been in use since what, 1989 or even earlier, if you count the inheritance from all the way back in FORTRAM, feel free.

    And yes, there are modules on CPAN that handle date formatting, and date conversion. This is not CPAN code, as the distinct lack of '->' and the use of custom operators such as '=<' should make clear. With this posting I'm merely experimenting with how to transform data reversibly from one format into the other, and in the process of reading the original Haskell document I came up with what I thought was a neat way to describe the bonding.

    If it wasn't abundantly clear earlier, this isn't even so much as a proof of concept. I have a test suite that fails because I haven't created the operators, and a lib/Optical/Bench.pm that is a hollow shell consisting of nothing but documentation. I know there's a lot of ill will toward Perl 6 out there in the community, and people use it as a scapegoat for Perl's decline over the last 10 years rather than pointing to the fact that PHP took over the Apache market because it was easier to install or any number of reasons.

    I happen to like what I've played with of the language as it addresses many of the concerns I've had with Perl5 over the years, and am willing to embrace its flaws. Those of you that aren't willing to approach perl 6 with an open mind are more than welcome to your opinion, but please don't criticize language features that you're not willing to take the time to understand. Not that it'll stop you, mere words won't do that.

      I know there's a lot of ill will toward Perl 6 out there in the community...
      There was a lot of ill will toward Perl 6 out there in the community, and there may still be some ill will today, but much less than, say, two years ago, because the Perl 6 team has finally delivered something more or less up to the expectations, something that is great anyway.

      I am personally enthusiastic about Perl 6 (and I have written several tutorials and articles about it in French over the past two years or so -- all together about 300 pages of material), but I must say that there were some moments in the past where I was starting to have some serious doubts about Perl 6 going to go anywhere at the time, because it took so long to get out.

      As for the rest of your post, I guess that I would need to take the time to look at the Haskell lens module you're referring to in order to really understand what your posts are about. I haven't done that yet.