perlweeklychallenge-club VS frank

Each week Mohammad S. Anwar sends out The Weekly Challenge, a chance for all of us to come up with solutions to two weekly tasks. My solutions are written in Python first, and then converted to Perl. It's a great way for us all to practice some coding.

In the previous edition Mohammad sent a call to get sponsor for his Weekly programming challenge. Several people replied to me. Those messages were forwarded to Mohammad as that is his gig. However, I noticed that the link we used to have at the top of the Perl Weekly was only showing up on the web site. I added it back. In a nutshell, if you'd like to spoonsor/financially help the work of Mohammad S Anwar then either contact him or just support him via Patreon. If you'd like to support my work then you can do so either via Patreon or via GitHub.

I run The Weekly Challenge project primarily focus on Perl and Raku but open to all programming languages. It was started on 25th March 2019. It has been going on un-interrupted ever since, thanks to the strong 350+ members of Team PWC. We were lucky enough to have solo sponsor, Perl Careers run by Peter Sergeant since July 2019 without break. Initially we had weekly prize sponsorship but later it was changed to monthly sponsorship. The best part was, I didn't have to move a finger to find the sponsor. Pete was generous enough to come forward and continued supporting the project for such a long time.

Challenge, My solutions

I am not sure, if you noticed this but Perl Mongers certificate expired few days ago. I only noticed as one of the contributor to The Weekly Challenge shared link to the site. The very next day, I saw post by Olaf Alders on Twitter talking about it and sharing the tool that can help avoid such incident in future. The certificate has now been restored.

Oh yes, Bruce Gray was a major influence for me as well a couple of years ago. He often participates in the "Raku Study Group" meetings as well - these are very broad and informal meetings every second Sunday but around the end, Bruce almost always brings up some Raku (sometimes Perl) solutions for the weekly challenges from https://theweeklychallenge.org/. In case you are interested, the repo of the meetups: https://github.com/doomvox/raku-study

Back to the topic. I picked up Raku a couple of years ago and I mostly use it as a better shell.

The pros are that you can really quickly and swiftly deliver CLI automation tools and scripts; the language has a unique but very practical regex syntax, you have very rich tools for string manipulation and you have good utilities to "drain CPU" if you are willing to spend more resources to make something faster (e.g easy multithreading for operations). Also, the language is very pleasant to use, it makes you feel very clever and powerful.

The cons cannot be neglected, however, the biggest problem probably being the performance and stability of the only actually working compiler, Rakudo, and its most functioning bytecode VM, MoarVM. The rich string-processing system and regex engine can be surprisingly slothful if you have vast amounts of text, same for precise bigint and rational computations (which are the default). Not many people understand Rakudo (and especially the VMs) enough to work on bugs or performance improvements, and there are not many low-hanging fruit remaining. Considering this, I'm sad that there has been little strategy regarding getting new maintainers, or having a release strategy besides "we will not change anything that might break code, and just release new compiler versions every couple of months".

Also, I don't know how much this is a con for you but Raku is not a language you can just "learn", you have to explore it and always be ready for a new journey. It's a horizontally huge language with a lot of corner cases you probably cannot all keep in mind. I think I'm managing pretty well but it is definitely a risk; you should probably either find a small subset you are comfortable working with and stick to it, or be okay with exploration using whatever goes, from asking others and reading the docs to investigating the core library inside Rakudo (which is not as bad as it may sound but not everybody wants to do).

Each week Mohammad S. Anwar sends out The Weekly Challenge, a chance for all of us to come up with solutions to two weekly tasks. My solutions are written in Python first, and then converted to Perl. It's a great way for us all to practice some coding.

I had almost forgot about participating The Perl and Raku Conference 2023 because of what I have gone through in the last few weeks and still going on. But the best part is, I have booked everything from air ticket to hotel reservations. Having said, I still have to get the slides ready for the my talk about The Weekly Challenge. If you are planning to attend the conference then please do come and see me. I would love to meet as many Perl enthusiasts as I can. I am mostly looking forward to meet the weekly challenge members. I got exactly 2 weeks time to get everything sorted before it is too late.

It's been a very long time that I've made a post that wasn't related to The Weekly Challenge, but it's about time I did :)

For the curious, "do be do be do" is a seminal paper in the literature on algebraic effects that introduces _frank_, quirky little language that has algebraic effects but not handlers, at least in the traditional sense.

Traditionally, an effect handler is an interpreter for a stream of commands, conforming to a specific interface. Generally, handlers surface in languages as a sort of generalized try/catch mechanism, that receive a "callback" to resume the "exception" that produced the command. In frank, not so.

Frank is based around the idea of _operators_, which generalize functions with the capability of interpreting multiple streams of commands. A plain function can be seen, in fact, as the special case of an operator that interprets no commands.

Operators are organized around ports and pegs. Pegs are the set of side effects that a computation needs. Each port is an offer to extend that set for downstream callers. Instead of building up a union of effects that each function needs, Frank propogated ambient ability inwards. Operators can then be composed based on the ports and pegs they offer.

operator: X → [peg]Y

This works partially because operators are shallow handlers and not deep handlers. Handlers interpret commands: if the handler itself is in scope when interpreting a command, then the language is said to have deep handlers. Frank has shallow handlers, meaning that commands are interpreted in an environment without the handling operator present. Shallow handlers give greater control to the programmer with respect to how commands are interpreted.

(This is a bad explanation because you already need to know what I'm talking about to understand what I'm talking about, but oh well.)

My one critism of frank is that the effect model is kinda hard for the working programmer to understand. I can explain Koka effects as "exceptions plus multiple resumption". I don't really have a categorical phrase for frank, and that's its innovation. This isn't so much a criticism but a plea for the pedagogical ramp to this research to improve.

do be do be do.

If you're still curious, check out the compiler github repo:

https://github.com/frank-lang/frank

And if anything is wrong in the above explanation, please correct me, because we all benefit from Cunningham's Law in the end. Allow me to be the fool.

How does this compare to other effect-oriented languages like Koka, Frank, and Eff?

I've been doing some work with Koka lately, but I briefly looked into the other three (including Effekt) and it mostly came down to, 'Koka seems most active in development'[1] and 'Koka had the easiest to use documentation for me'[2].

[1] E.g. https://github.com/effekt-lang/effekt had its last commit back in June; https://github.com/frank-lang/frank last commit last year; but https://github.com/koka-lang/koka last update was Oct 15. Effekt seems semi-active, at least, compared to Frank. While stability is good, I wouldn't expect it in a language actively being used for research.

[2] Comparing https://koka-lang.github.io/koka/doc/book.html and https://effekt-lang.org/docs/ and https://www.eff-lang.org/learn/

Frank's effect handling. "A strict functional programming language with a bidirectional effect type system designed from the ground up around a novel variant of Plotkin and Pretnar's effect handler abstraction. ... Frank [is different from other PLs with effect type systems in that it is based on] generalising the basic mechanism of functional abstraction itself. A function is simply the special case of a Frank operator that interprets no commands. Moreover, Frank's operators can be multihandlers which simultaneously interpret commands from several sources at once, without disturbing the direct style of functional programming with values. Effect typing in Frank employs a novel form of effect polymorphism which avoid mentioning effect variables in source code. This is achieved by propagating an ambient ability inwards, rather than accumulating unions of potential effects outwards."