Let us return to our first enum-style Color type declaration and the problem of printing out values of that type:
#!/usr/bin/mythryl
Color = RED | GREEN | BLUE;
fun print_color color = {
case color
RED => print "RED\n";
GREEN => print "GREEN\n";
BLUE => print "BLUE\n";
esac;
};
print_color RED;
print_color GREEN;
print_color BLUE;
When run this of course produces
linux$ ./my-script
RED
GREEN
BLUE
First off, note that we wrote print_color RED; above, not print_color( RED );.
Now that we know that Mythryl functions are not C functions, and can take any type of argument, we need no longer keep up the pretense that parentheses are associated with function invocation. In Mythryl, parentheses are used for constructing tuples and for grouping; they have nothing whatever to do with function invocation. Putting useless parentheses in function calls in Mythryl just makes you look like a beginner who is still writing C in Mythryl.
Now look at the above function definition. It works just fine, but an experienced Mythryl programmer would rarely if ever write it that way. Mythryl function syntax supports implicit case statements to allow writing such functions without an explicit case, and an experienced Mythryl programmer would almost always automatically take advantage of that fact:
#!/usr/bin/mythryl
Color = RED | GREEN | BLUE;
fun print_color RED => print "RED\n";
print_color GREEN => print "GREEN\n";
print_color BLUE => print "BLUE\n";
end;
print_color RED;
print_color GREEN;
print_color BLUE;
When run, the above script will produce exactly the same output as the previous version, and in fact will probably compile into exactly the same binary code — the first thing the Mythryl compiler does with such function syntax is to expand it into an explicit case internally.
But what a difference in readability! Seven lines of function definition have shrunk to four, and assymetric clutter has given way to pleasing symmetry. The first version was rather ugly; the second version is actually quite pretty! (Always listen to your esthetic sense. It is the voice of experience. Beautiful code is better code.)
Now we are not only writing Mythryl code that works — we are starting to write Mythryl code that looks like Mythryl code, code that an experienced Mythryl programmer might read without wincing.