Advent of Code in GOOL

[B-rando1]

The other day I had some time on my hands, and I wanted to try doing question 1 of this year's Advent of Code in GOOL. I find the idea of hand-writing GOOL interesting, even if that's not its primary purpose, and I figured Advent of Code would be a good place to try it. It was an interesting experience, and I think it's be worth writing about here.

Background

The Advent of Code problem can be viewed here. Basically, the puzzle input is a .txt file with two columns of numbers separated by spaces. These two lists of numbers must be parsed and sorted, and then their element-wise absolute difference (i.e. Manhattan distance) is the answer to the problem. It's a simple problem, with parsing and sorting being the biggest topics.

My code is on the branch advent-of-code, with these relevant files:

• input.txt was the input file.
• HelloWorld.hs was the GOOL file I used
• stable/HelloWorld.jl is the generated Julia file. I made a small modification, marked by a comment, from the generated code because there was something I wasn't able to express in GOOL.
• HelloWorld.jl is an 'idealized' Julia file I wrote after the fact to compare with the generated code.

The code can be generated with make codegenTest_gen. Only the Python code runs without issue, but as mentioned the Julia code can be run with only one small modification.

What I found was that it took much longer (several hours instead of <30 minutes) to solve this problem in GOOL, and missing functionality impacted the code in a few ways. These included longer code because more consise options were not available, extra functions to implement what is included in the standard library but not accessible by GOOL, and one missing pattern that did not have a workaround.

Debrief

I had a few problems writing code in GOOL, which fall into three main categories. I will outline them below.

'Experiential' issues

These mostly come down to the fact that GOOL is embedded in Haskell, which of course has some downsides. While they are difficult and make writing code in GOOL feel more like writing C than Python, they aren't actually the cause of the biggest issues I faced. Plus, they would be the hardest to address.

• Since each language construct is in a separate typeclass or may even be its own function, it is difficult to import what you need without importing all of Drasil.GOOL.
• Commas are annoying in blocks. They're like semicolons, but worse since the last line can't have one.
• The syntax is a bit verbose, e.g. type annotations, scope declarations, etc.
• Poor error messages during code generation
• Lack of documentation. This is the exception in that it can be fixed without any major redesigns, and a consistent effort can improve it in the long run.

Actual bugs

• Julia's forRange includes the end value; it should not. This should be a quick fix, and indeed I made the fix on this branch so I could continue focusing on Julia. I can replicate the change in main soon.

Missing features

These ended up causing the most pain. I had to implement list sorting and parsing an integer from a string manually because they were required, and there were a number of other features that I would have used if I had the chance.

• List sort
  • This would be a very handy function to have available, since many problems require sorting.
• String split with string (i.e. multiple character) splitters
  • In this problem, the numbers were separated by three spaces, so splitting on a single space had some odd effects. I'm not sure if splitting on multiple spaces is available in every language, but it is in Julia at least.
• Casting (included in CommonRenderSym but not part of the external API)
  • One of my biggest surprises was discovering that the only way to convert a string to a different type is when reading a single line from a file. I understand the motivation to do this, as casting can have dangerous consequences, but this problem with the way its input was formatted shows that casting, or at least string conversion, is required in some cases.
  • Since we actually have parsing available internally for GOOL, it seems like a clear improvement to make parsing available in GOOL's external API.
• Many string operations that are analagous to list operations:
  • String slicing
  • Accessing characters in a string
    • I discovered that there's no way to do this in GOOL. Since my strToInt required this, I had to lie to GOOL and say that the input was not a string, but a listType char. And this had its own problems of course, requiring me to modify the generated code in all targets except Python, since their typecheckers failed.
  • String trimming
• Why is litList not allowed in C++?
  • I can't remember if I ever looked into this, but it just seems odd. I used litArray instead so that I didn't have to disable C++ from the list of outputs, but that caused issues with the generated code for Java and likely other languages.
• Lack of polymorphism
  • This didn't directly affect this problem, but I noticed that the selectionSort function I wrote is only for ints. This would be a big can of worms, but it would be nice to have polymorphism for that sort of thing.
• Functional techniques
  • We don't seem to have anything like map, filter, zip, or list comprehensions. Those would come in handy, even if they can be replaced by loops.
• Numerical functions: abs, max, min, etc.
  • abs was another function I had to do without, and there are more, of course. These are easy to implement as needed, but it's nice to have them.

Conclusion

I mainly did this to see how much more work it would be to solve an Advent of Code problem in GOOL compared to a real language like Julia. It was a little disheartening to see how wide this gap is, as well as the difference in quality between the generated code and the idealized code I wrote. I suppose that in large part that is an effect of this being a research project; my understanding is that GOOL is meant not to replace any programming languages but to inspire new languages. With that said, there are some actionable items:

• Making the cast function (or at least parsing from a string) available to the GOOL frontend is virtually required for problems like this, and shouldn't be too much work to do.
• More string functions should likewise be an easy addition and would be necessary for certain problems.
• A sort function would be very handy as well. We would need to decide if we want to provide different algorithms, but even if we only provide one it would be a good start.
• Fixing the bug with Julia's forRange. I can do this, it should be a quick fix.

We could go further on more of the points I mentioned above, but these seem to be the most essential to me. There could be a risk of going too far: e.g. adding functional techniques would be awesome, but do we really need them? The answer to this depends on what GOOL is meant to be and where we want to direct our energy.

I hope this wasn't too much of a meander 😄. I'm not exactly sure what to do with this, but I think it's worth writing it down and seeing if there's anything here that we can work on.

[JacquesCarette]

This is a fantastic experiment!

Once upon a time, we had quite a few combinators and bits of syntactic sugar so that hand-writing GOOL was not too too painful. At least, within a narrow range of "things you might want to say".

Meta-comment: it looks like you solved the problem in Julia, then you tried to reproduce that with GOOL. While that ought to work, it's not quite the best process. Better would be to look at the Julia and figure out "what is this really saying" for each logical block of code (which is sometimes a single line). Then figuring out how to say that in GOOL.

Really great debrief. We should think hard about each of those 'experiential issues'. I think some of them are not nearly as difficult to deal with as I used to think. The 'missing features' are also interesting, but for a lot, see back to the meta-comment. Certainly your list clearly points to the external API missing a variety of features, though perhaps not quite the ones your list. Your list is a great start for the requirements to adding to that API.

[B-rando1]

I'm glad you liked it!

For the record, the idealized Julia script was based on the generated code from GOOL, not vice-versa. With that said, the problem is simple enough that they both would have come pretty directly from my own mental solution to the problem. Perhaps my mental solutions are too closely tied to the languages I'm used to, and there are better ways to think about GOOL code 🤔. I am curious, what parts did you have in mind that could potentially have better formulations in GOOL than how I did them?

It's good to hear that there are things we can do to make GOOL easier to write. Even in the context of Drasil, I'm sure that more concise code would be easier to work with, and being able to show off GOOL code on its own could be helpful as well. I also agree that my list of features is only a start, and we need to think hard about which features are worth implementing and maintaining.

[JacquesCarette]

It's not really about "thinking about GOOL code" as it is about trying to think about what the right design is. We're trying to abstract out a 'language of design' where one could phrase what we want our code to be a level closer to what you'd say to a fellow programmer when describing your solution. So that's the exercise, figure out what it is you'd say -- and then we want to provide services in drasil-code and GOOL to enable that.

In the context of GOOL, going about making things "easier to say" is something that likely can only be done in an in-person meeting, where we stare at the code (both the GOOL and the generated code) to see what 'need' to say (in a better GOOL) and then make it so.

[smiths]

I'm late to the party on looking at this, but now that I've looked at the work, I really like it. Thank you for taking the initiative to do this @B-rando1. Looks like you had some fun! 😄 Did you submit the generated code to see if it passes whatever checks the advent of code people use? Even though the generated Julia code is ugly compared to the handwritten code, it is still a positive if it has the right behaviour. 😄

[B-rando1]

I'm glad you liked it! I ran it on the input they gave me, and this code gave the correct output. It is good that the code works, and getting it to work was actually how I found the bug with forRange, so that's a positive as well.