Subscribe: York Haskell Compiler
Added By: Feedage Forager Feedage Grade B rated
Language: English
bit  bugs  checker  code  compiler  core  error  file  good  haskell org  haskell  much  prelude  work  yhc core  yhc 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: York Haskell Compiler

York Haskell Compiler

Last Build Date: Wed, 03 Aug 2016 23:41:42 +0000


Yhc is dead

Sun, 03 Apr 2011 18:20:00 +0000

Someone recently asked on the Yhc mailing list if Yhc was dead. The answer is yes, noone has been working on the compiler for several years. The nhc98 compiler, from which Yhc originally forked, is still maintained. Since this is the end of Yhc, I thought I'd share a few random thoughts about Yhc:

  • Writing a Haskell compiler is a big undertaking, and the work required to compile a moderate number of programs from Hackage is immense. Too many libraries rely on something GHC specific - either language or runtime features. The GHC team have gone out of their way to ensure that their compiler is by default a standard Haskell compiler, which has kept Haskell as a viable language separate from GHC. But without widely-used competing implementations, programs tend to end up depending on GHC.

  • There are still other non-GHC Haskell compilers, and I wish them all well. Many offer features missing in GHC (compile to Javascript, tiny runtime system, extreme portability, code mobility etc.) - there are lots of interesting ideas floating around.

  • Yhc started in a fairly haphazard way, and became a fork of nhc long before anyone had noticed. Had Yhc's contributions been rolled back into nhc they'd probably have had more lasting impact.

  • One of the big draws for Yhc was it's ability to take a Haskell program, and produce a Core complete program. Despite all of Yhc's other weaknesses, Yhc Core drew several people to the project - I hope something equivalent appears for other Haskell compilers.

  • If you don't understand monads, you aren't yet ready to write a Haskell compiler.

  • If you have a group of Haskell programmers in the same place, you should try a group project. It's fun.

  • The biggest challenge for Yhc was the build system - we ended up with 10,000 lines of Python Scons scripts. Without a robust build system nothing else matters. When our sole Python hacker left the team that was the beginning of the end.

Working on Yhc was fun, and I learned a lot. Thanks to everyone who was involved.

Haskell on BEAMs

Sun, 18 May 2008 19:11:00 +0000

Recent developments showed that Haskell, via conversion from Yhc Core, can run on:
Ability to run Haskell on some runtime gives Haskell programmers access to some or all features provided by that runtime, while keeping the features provided by the language unchanged. So it may be worth trying more runtimes to run Haskell programs on.

BEAM is a virtual machine Erlang runs on. Erlang provides a distributed fault-tolerant concurrency-oriented computing platform, and its use keeps widening for various kinds of applications. BEAM is in plural in this blog post's title because a distributed Erlang program is running on multiple instances of BEAM, and so would a Haskell program in the same environment.

There are projects aimed at compilation of some programming languages to Erlang or Core Erlang:
So, why not add a compiler from Yhc Core to both collections?

For about a month I have been experimenting with a converter of Yhc Core to Core Erlang. The converter was in part based on the Javascript backend converter, and in part on Haskerl. The goal was set to run a Haskell program that utilizes some commonly used subset of Haskell Prelude, and is also able to deal with creation of Erlang processes, sending, and receiving messages. This program served as an example.

The goal was reached, so I would like to publish the results for everybody to see and criticize. Any feedback is appreciated.

Read on.


Yhc/Javascript backend: personal/historical notes

Fri, 28 Mar 2008 18:23:00 +0000

It looks like this blog has been silent for more than a year ;) In the light of the first milestone reached recently by one of Yhc subprojects, the Javascript backend, I am happy to break the silence and put some personal historical notes as well as notes about the current status of the project I have been working on for more than 1.5 years.1. The "crazy idea"I was not definitely the first to have a thought to convert Haskell to Javascript. One that I can now recall was a piece of text on this page (by Jared Updike, dated March 2006):------------------...In addition I was thinking it would be cool to compile Haskell toJavaScript so then you could actually write arbitrary things inHaskell and run them in browsers...------------------There was a number of others that I lost track of. Anyway, the idea was in the air, and seeing other people expressing it prompted me that it was worth trying.2. First experimentsI started my experiments with Nhc98 in June 2006. The intermediate form of Haskell program before it was turned to bytecodes was called PosLambda. It was not very easy to understand it, but some primitive things worked out. Later I noticed that theHajax page appeared on Haskellwiki (the link points to its earliest version) which referred to some of my developments. I started my own Wiki page, STG in Javascript, sort of response to the Hajax page. The "STG in Javascript" page is still there, showing the progress during that time (Summer 2006). Later, another developer (nickname Vir) picked up the topic, however his work is completely independent from mine.3. Yhc coreSome time in September 2006 I learned (thanks Neil) about Yhc Core: an intermediate format that Yhc produces during compilation, similar by its idea to GHC Core, but much simpler and with more stable format. Plus, it has an externalized form, so in order to process it there was no need to alter the code of the Haskell compiler itself. These benefits were very attractive, and Yhc Core had much in common with PosLambda, so transition of my converter was relatively painless. In October 2006, the sources of the Javascript converter were checked into the Yhc darcs repo, so the Javasscript backend "officially" became a subproject of Yhc.4. The Roman echoOn November 16, 2006, the first runnable example was published. It was a web page with an input field. When a decimal or Roman number was typed in, it responded with the same number converted to Roman or decimal (conversion code by Malcolm Wallace), plus approximate time that the conversion took. First results were perhaps terribly slow: time shown might be seconds, yet it worked.5. DOM interfaceIt was absolutely necessary to find a way how to call DOM functions from Haskell. In the first Roman echo example, these calls were manually coded, but for more than one hundred of them defined by the Web Consortium, that did not seem acceptable. In addition, accurate representation of DOM methods' argument type information was critical, as one of Haskell's benefits in Web application design is strong static typing (as opposed to Javascript with no static typing at all).Happily, the Web consortium provides DOM interface specifications in OMG IDL syntax. And there is an utility that is capable of understanding DOM IDL: H/Direct (by Sigbjorn Finne). The way H/Direct reflected IDL interface inheritance was simple, but not very open-ended: all sub-interfaces of an interface were presented as constructors of an algebraic data type, which meant that in order to add an instance of an interface, the whole thing needed to be recompiled as Haskell does not have extensible algebraic types.So, the the Haskell code generator was stripped off from original H/Direct code while the IDL parser remained in place. The new Haskell code generator transformed the hierarchy of IDL interfaces into hierarchy of Haskell type classes. This is a more open-ended solution, as instances to classes may be defined elsewhere without changes to class definition itself.Finally, DOM IDL interface definiti[...]

100 bugs!

Mon, 05 Feb 2007 16:38:00 +0000

Three days ago Thorkil Naur filed bug #100 for Yhc. Using a bug tracker was a good step for Yhc - and has helped us remember, track down and fix loads of bugs. We currently have 101 bugs, 62 of which remain open. Some bug statistics:
  • 7 beginner bugs - these are bugs which don't require much Haskell knowledge, or in depth compiler knowledge. If you are just getting started, all of these should be within reach.
  • 15 defects which are either High or Medium importance - at least one of which got fixed this morning!
  • 30 enhancement requests - often relating to cleaning up the internals of Yhc.
  • 17 bugs owned by me (2 by Andrew, 4 by Dimitry, 2 by Tom, 2 by Mike) - 25 waiting for you to own them :)
Well done to everyone who has contributed to Yhc - and hopefully we'll be able to reduce the bug count to 0 at some point!

1000 patches!

Thu, 21 Dec 2006 00:19:00 +0000

The Yhc project hit 1000 patches sometime today. Congratulations on Dimitry for being the 1000th patcher, and for everyone who's made a commit.

This does of course mean that doing a non --partial darcs get is going to take forever...


Thu, 14 Dec 2006 00:36:00 +0000

The Yhc Core stuff has been coming on loads recently, being used in more and more projects, and gaining lots of cool features - even a strictness analyser! Check out the Yhc documentation here: . A lot of this work is focused towards performance enhancements, so I'll give more details on that once we have a headline number to brag about :)

One cool thing I've been working is Yhc.Core.Html (not yet in the documentation index, but it should be tomorrow). If you load up Hugs and take your Yhc.Core file:

> loadCore "Roman.ycr" >>= writeFile "Roman.html" . coreHtml

That will generate a file called Roman.html, which is a hyperlinked, colour-coded viewer for your code. A sample is here. The links which are internal to this file are hyperlinked, and it also hilights the uses as well. Click on an identifier to see what it does.

Hopefully this should be of use to people who spend most of their day pouring over the details in a Yhc.Core document - i.e. me!

Yhc.Core documentation!

Sun, 15 Oct 2006 23:02:00 +0000

Since a few people now have an interest in Yhc.Core I thought I'd actually document it with a little tutorial style introduction.

There are also some little examples, including one to count the number of times you use the literal 42 in your code.

We've also been busy getting installing set up, you can now do "scons install" on Linux, download nice snapshots on Windows, and there is progress towards Gentoo eBuilds and Debian .deb's.

Beginner Bugs

Sun, 08 Oct 2006 16:12:00 +0000

Want to start helping out on a big Haskell project, but frustrated that there is no easy way into a project? The Yhc team has the answer, help with Yhc :)

There are basically 3 steps to get into full swing as a proper Yhc developer, and everyone is welcome!

1) Download Yhc from darcs, and compile.
  • If it goes wrong, email us (yhc -at-
  • If the documentation is unclear, fix it or email us
  • If something takes some hard work, tell us what, so we can fix it
2) Either pick your own task you feel like, or pick one of our beginner bugs from the bug tracker. All the beginner bugs are designed to be able to be done incrementally, i.e. even a small amount of progress can be used. They shouldn't require much deep knowledge of the code base, some require a bit of Haskell, some require a bit more, some require none. There should be something suitable for everyone on that list.

3) Either pick your own task, or pick one of our normal bugs - they vary greatly in difficulty, scope etc. By this time you are a fully fledged Yhc developer :)

We are friendly people, so if at any point you need a bit of advice or help, or something seems to be a bit harder than it could be, just drop us an email - yhc -at-

Yhc.Core API available

Wed, 20 Sep 2006 18:23:00 +0000

Yhc.Core is now a publically available and somewhat supported API! There are no docs on it, but check out the Yhc repo and see src/compiler98/Yhc/Core. Just add "import Yhc.Core" at the top and you can do all cool sorts of things.

Step 1 is to generate Core files, with the .ycr extension. If you are compiling Yhc adding scons core=1 to the command line, and all the libraries will have .ycr files generated along with the .hi and .hbc files. If you are compiling an individual file, then add the yhc -corep flag, and it will generate a .ycr file.

The .ycr files are stored in Binary, but thats OK, because if you want to view one, its literally as simple as:

import Yhc.Core
showFile x :: FilePath -> String
showFile x = loadCore x >>= return . show

(There will be a flag/program/command to view a .ycr file at some point - its not hard to do, but it is hard to figure out where the flag should go and what it should be called!)

Now once you've got Core, what can you do? Take a look at the data structure in the Yhc.Core.Type file, to see what it contains. There are already two programs that depend on Yhc.Core, Catch and Dr Haskell. In particular if you take a look at the main file of Dr Haskell, you can see some trivial ways to play with Core.

Hopefully Yhc.Core will be useful for many projects - if it interests you please drop an email to yhc -AT-, saying what you want to do etc. (Of course, you don't have to, but we're curious folk!)

Nofib suite getting there!

Sun, 17 Sep 2006 02:25:00 +0000

Some good news to report, slowly but surely more of the nofib benchmark suite is running successfully - we now have 24 tests in the nofib benchmark going through nicely, and added to the buildbot.

The issue tracker is starting to see more use, getting more of the thoughts that were marked down as "oh, we should do that" and converting them into concrete bugs that one day someone might solve. Its also useful for tracking down where things are going.

We can now output core for all the libraries Yhc builds with - simply pass core=1 to Scons and it will do the hard work for you. Not massively helpful, unless you're me, but might be of general use one day!

We also have a few more features merged in - no need to give the -unlit flag for .lhs files, and the OPTIONS_YHC pragma is supported in a similar manner to the OPTIONS_GHC pragma.

Yhc is slowly getting more useful, once the base libraries are useable with Yhc, it will be good enough to start eating our own dogfood!


Sun, 13 Aug 2006 15:18:00 +0000

GHC has nightly builds, now Yhc has something even better, buildbot! - and for instructions (email yhc -AT- to register)

Every time a change it checked into the Yhc repo, builds are triggered, and the test results are calculated. This should ensure that breaking the build is a 10 minute affair, and it also means we can remotely debug compile/runtime errors on other people's machines by trail and error without their intevention - which has already meant that we got Mac PPC up and running without access to the machine. Something that would have taken much longer if we had to wait for email exchanges between every change.

So who has a wacky architecture, and wants to be a buildbot? Its entirely automated, you can nice is as much as you want, your machine doesn't have to be on all the time, and it means that you'll always have a working Yhc available for you :)

Yhc Core (v2)

Mon, 24 Jul 2006 12:59:00 +0000

I have tweaked the Yhc -core output so its much more like normal Haskell, still not 100% there, but getting closer all the time :)

I want it to be possible to do:
yhc -core Sample.hs 2> Sample2.hs
hugs Sample2.hs

At the moment, that sometimes works. The only problem I know about is dictionaries for typeclasses - and thats all to do with their names. I'm still figuring out what the answer to that should be.

Anyway, taking the pam daeh example thats been used before:

daeh v220 =
case v220 of
(:) v221 v222 ->
_ ->
Prelude.error Sample._LAMBDA228

_LAMBDA228 =
"Sample: Pattern match failure in function at 9:1-9:15."

pam v223 v224 =
case v224 of
[] ->
(:) v225 v226 ->
(:) (v223 v225) (Sample.pam v223 v226)

test v227 =
Sample.pam Sample.daeh v227

And now the cool bit:

hugs Sample2.hs

And it works!

Hopefully this will be of use to people who want to work with reduced Haskell, since they can use existing Haskell parsers and type checkers to do their work. If you are interested in this, drop an email to the yhc mailing list (yhc -AT-

Summer of Code (2)

Wed, 31 May 2006 16:10:00 +0000

Implement a better type checker for yhc
by Leon P Smith, mentored by Malcolm Wallace

We have a change in the student, so good luck to Leon on the type checker!

Summer of Code

Fri, 26 May 2006 16:38:00 +0000

Implement a better type checker for Yhc
by Mathieu Boespflug, mentored by Malcolm Wallace

Here's hoping for a better type checker!

Patch Statistics

Mon, 13 Mar 2006 15:18:00 +0000

Ever wondered how often people commit patches to Yhc?

Now, a nice graphical chart can show you:

Note that this page won't be around for ever, but I hope that once we have haddock documentation and regression tests running every night, slipping this in as well won't be too hard, or perhaps it might get into darcs-web.

The graph goes from Nov 2005 to present, and the current number of patches is about 340.

The tool for generating this graph is in the repo, under misc/DarcsGraph.hs - just run "darcs changes" to a file, and give that file to DarcsGraph.

Pyhi: A python interpreter

Thu, 02 Mar 2006 17:32:00 +0000

Andrew says:

I've just committed an entirely new Yhc interpreter, written in Python. Pyhi
(as it is known) currently only supports a limited set of the bytecodes
(enough to run Hello World) and is approximately 100 times slower than the C

It uses many of the built in Python features, such as garbage collection, to
attempt to gain some speed and yet is still hopefully written in a fairly
understandable, Pythonic fashion.

Bytecodes are represented as functions which are called using a 'trampoline'
function in order to decouple the Haskell and Python call stacks.

This most definitely a work in progress so don't expect many programs will run
just yet :-)


Mon, 27 Feb 2006 14:27:00 +0000

Yhc now has full and nice support for C Preprocessor directives. If you would like to compile with them simply include the flag -cpp, and it will run an internal preprocessor (no extra runtime dependancies).

The cpp support is provided by Cpphs in its use as a library. For the moment, the flag defined is __YHC__. The makefile on both Windows and Unix has changed substantially - both automatically detect if you are missing cpphs, and darcs get it for you if required.

Hopefully this should make stage 2 easier - compiling the heirarchical libaries!

Yhc vs YHC

Fri, 20 Jan 2006 19:13:00 +0000

We have now named most things, which is a good step forward (Yhc, Yhi, Yhe, Gyhe, Yho ...)

One final thing we need to name is Yhc itself. If you look at the previous posts you'll see I tend to name it Yhc, and Bob tends to name it YHC. I personally prefer Yhc, because it looks quite a lot nicer, all the demo logos that have been done have had "hc" in lower case, and YHC seems a lot more violent, while Yhc is more friendly.

Thoughts and opinions?

Wiki v2

Sun, 15 Jan 2006 00:29:00 +0000

I have started moving some bits of the old wiki to the new wiki, there is quite a lot of content, so if anyone wants to help :) I'm also thinking the Yhc website should just be the wiki, no static pages at all - so all the static content probably needs moving as well.

Hopefully once all this is done we'll have the best documented compiler.

Update: all done, there should be nothing on the old wiki which isn't on the new one - I also reorganised quite a bit at the same time.

Lines of code

Wed, 11 Jan 2006 00:32:00 +0000

For anyone who's interested, currently the Yhc compiler is 23578 lines of Haskell code. This is just the compiler, not the runtime etc.

More on Type Checking

Thu, 05 Jan 2006 12:48:00 +0000

Christmas was spent mostly researching methods of type checking, and trying to get a good handle on what I'm going to do. After much looking, I now have apparently three options:
  • Write a standard type checker based on the W algorithm.
  • Write one based on Olaf's compositional method.
  • Attempt to refine Neil's idea for coming up with simple rules to be fed to a solver.

I don't like the first option - it's been done before, it'll give us no advantage over any other compiler, and it's boring. Olaf's method seems to have two major advantages - clear code with an easy to understand algorithm, excellent error messages/debugging. Meanwhile Neil's method seems to be the black horse - we don't know what we'll get out of it. From the first attempt at it, it appears that clear code will be one of the advantages, but speed may be lacking.

I think I'm probably going to go with Olaf's method first - that way we get excellent error messages guaranteed (one of my primary aims). However, I do think there's genuine scope in Neil's solver method, and I think a second experimental type checker may be written later, as I think it has much greater scope for being able to deal with really really complex type extensions.

So that's my thoughts for the moment. I need to speak to Olaf about a few details of his checker, and then I'll get writing.


User Interface

Tue, 03 Jan 2006 12:54:00 +0000

The Yhc compiler takes most of its Haskell-compiling code from nhc98, and most of its backend/interpretter has been rewritten by Tom. The one bit that I think needs most attention is the user interface. Specifically, I see the following problems in the user interface (where user is a programmer, and interface is how they use yhc):
  • YHC_BASE_PATH - this trips pretty much everyone up
  • Path handling, where .hbc files go etc
  • Doesn't list which file its compiling.
  • Error messages are usually pretty bad, compiling many files at a time has made this worse, since now you don't even know the file the errors in
YHC_BASE_PATH is scheduled for elimination. Listing compiled files is trivial. Error messages are being slowly replaced, but the lack of global state in Haskell is making this quite a bit harder.

The one thing where there is less concensus as to what the desired behaviour should be is path handling - i.e. deciding where to put a file, and where to get it from. I have started a wiki page with my thoughts on this, which is here. Please add your thoughts, hopefully we'll come to a nice concensus, and have a nicely implemented user interface before long.

HsNub - update

Mon, 02 Jan 2006 01:59:00 +0000

I just finished HsNub, and while it works basically, its not all that I was hoping for. The basic problem is that lots of functions which are entirely different have the same bytecode! For example, selecting the first element out of a data structure is given as lots of different names, often field selectors. To be useful, it would need to incorporate some knowledge of the types as well.

Just to show an example of it running, when trying it on my regular expression library, tweaked to add two functions func1 and func2 that are just like id, I get the result:

{Data.Char-cont, YHC.Internal-_id, Prelude-id, Prelude-Prelude.Enum.Prelude.Char.fromEnum, Prelude-Prelude.Enum.Prelude.Char.toEnum, Prelude-Prelude.Integral.Prelude.Integer.toInteger, Prelude-Prelude.Num.Prelude.Integer.fromInteger, RegExpData-func2, RegExpData-func1}
(plus plenty of other equal functions)

So it works, but its just a bit too verbose, and your program must type, whereas the bytecode doesn't. Its also really slow, but I'm sure that could be fixed with a bit of effort.

One thing I did find is that a massive amount of the standard libraries are the same. Some statistics about the functions in the prelude:

1826 functions
701 distinct bytecode sequences (38%)
45025 bytecodes, 27584 of which are required (61%)
1363 distinct constant tables (75%)
4732 constant entires, 4512 of which are required (95%)

Maybe a better bytecode format would store each function as a pointer to a bytecode chunk, and a pointer to a constant table - that way different ones could be mixed and matched. I don't expect the standard compiler to do this (way too expensive, harms debugging), but its useful to be able to do as a standalone optimiser, and nicely cuts away at the memory required.

Crazy Ideas

Mon, 26 Dec 2005 14:46:00 +0000

Having a small, clean, simple, production strength Haskell compiler lets a lot of people come up with Crazy ideas that just weren't feasible before. (alright, so Yhc certainly isn't production strength yet, but it could be without too much work...)

Some of the crazy ideas are listed at on the wiki, some others have been sent out in emails. Quite a lot aren't crazy at all, but would be really useful! Just a quick summary of some side projects/tools that are being developed, or have been thought of:
  • Haskell HBC -> Java bytecode
  • Javascript runtime for HBC files
  • Python runtime for HBC files
  • Playstation port (entirely speculation so far)
I also came up with a new crazy idea for Yhc, HsNub. Have you ever written a function, and later found out that it did the same as a function in the prelude? Take the Yhc code base, I recently eliminated the function second, which is equivalent to the Prelude function const. It would have been nice if something spotted this and gave out a warning. With a portable bytecode, this isn't that much work - two functions can be seen as equivalent if they are identical at the bytecode level. I intend to write this tool once I have a working bytecode library - I don't expect it to take more than an hour at most - thats the nice thing about having a relatively simple Haskell implementation!

YHC and types

Sat, 17 Dec 2005 13:22:00 +0000

So it appears by some weird twist of fate that I'm going to be writing YHC's type checker, and it appears that over christmas is when I'm going to be starting on this task.Yhc of course currently uses the nhc98 type checker. This, while it works well, could do with some improvement. My two personal bugbears with it are:Type ErrorsLack of any extensionsIf we use this program as an example:main = print $ "a" == 5yhc currently produces this type error:yhcc: The class Prelude.Num has no instance for the type Prelude.[].Possible sources for the problem are: 1:23When type checking declarations at: 1:1-1:23Okay, so from this we can get two pieces of information:First, the type system thinks that lists are not numbers, quite reasonably.Second, where the error came from.Ghc produces this error:jam.hs:1:22: No instance for (Num [Char]) arising from the literal `5' at jam.hs:1:22 Probable fix: add an instance declaration for (Num [Char]) In the second argument of `(==)', namely `5' In the second argument of `($)', namely `"a" == 5' In the definition of `main': main = print $ ("a" == 5)This also tells us where the error is, and that it doesn't think lists are numbers. However it also provides quite a lot more information that is very useful for finding and fixing the bug:It tells us the error in our own language - Haskell. If we were to write an instance for (Num [Char]), that's exactly what we would start by typing!It tells us more information than is necessary - in order for there to be a type error all that mattered was we tried to match a number against a list, but the additional information that it was a list of characters gives added context, and makes it much easier for us to work out where the problem is.It suggests a fix. Okay, in this case it's suggested what's probably a bad fix - we probably don't want strings to be numbers, but in many cases, this is exactly what would be neededIt tells us in more human terms where the error is. A human is not good at counting line and column numbers, they are good at looking for patterns like "it's in the comparison"Okay, so type errors fall a long way short of ghcs, but even ghc's error messages are not yet good enough, as Olaf Chitil points out [1].Secondly, you may have noted in all the posts we have made, that we intend to implement at least a few extensions to Haskell 98/06 (currently on the list are Multi parameter type classes, and all the jazz that goes with that). This means I need to understand how the type checker works in every detail, and know exactly where it needs extending in order to make things work. To get to this state, would take almost as long as it would for me to write a type checker that I understood in much more detail, and as such, my proposal is that I'm going to completely rip out the type checker, and replace it with something new and shiny.My plan is to write a very compositional type checker as described by Olaf in his paper, and hopefully get the following benefits:Good error messages!Modularity - if the type checker is compositional, it should be easy to add new rules and extensions, and to enable and disable themUnderstandability - Simple Haskell that just plugs together is good Haskell!Having had a quick chat with Olaf about it - Speed. Hopefully, this should be a pretty quick type checkerSo, I'm off to visit the pain monster for a bit to make sure I fully understand what I'm do[...]