More fun hackin' on my language lately. It's gonna be C-level with a more ML/Haskell-ish syntax and with a fancier type system.
One of my main thoughts recently is that one use of a type system is to enforce conventions. With conventions built into the type system, I can make the associated syntax overhead lighter. For example, good C libraries conventionally namespace their code by using prefixes, so I can provide a "namespace { ... }" construct that does this automatically. A more involved convention is Glib's error reporting, which as you can think of as the natural way to do exceptions in C without using setjmp hacks. Rather than the convention of having every exception-raising function take in an extra GError**, I can provide an "exception" tag on function declarations and provide the corresponding raise, try, catch (rescue? with?) functionality myself.
Recent gotcha: if you allow type constructors, than code like
char foo(int x, int y)
(which looks like a function declaration and requires an opening curly to its right) is ambiguous. Just changing the names of the identifiers, to make it more clear:
option hash(list string, list int)
which looks like a complicated type (in OCaml syntax: (string list, int list) Hashtable.t option¹). The parser doesn't expect a opening curly to follow it.
Recently working on / thinking about: any type that's of pointer kind can have a "maybe" attribute, which corresponds to the possibility of being NULL in C. A string (which is a char*, so that's a pointer kind) is a subtype of {maybe}string, so you can pass variables of the former form to functions expecting the latter, but not the reverse—you have to test for NULL first.
1 Again, it's the backwards problem: I write ref int in OCaml to get something of type int ref.
OCaml:
# Some 3;;
- : int option = Some 3
Haskell (who got it right, I think):
Prelude> :type Just 3
Just 3 :: Num a => Maybe a
One of my main thoughts recently is that one use of a type system is to enforce conventions. With conventions built into the type system, I can make the associated syntax overhead lighter. For example, good C libraries conventionally namespace their code by using prefixes, so I can provide a "namespace { ... }" construct that does this automatically. A more involved convention is Glib's error reporting, which as you can think of as the natural way to do exceptions in C without using setjmp hacks. Rather than the convention of having every exception-raising function take in an extra GError**, I can provide an "exception" tag on function declarations and provide the corresponding raise, try, catch (rescue? with?) functionality myself.
Recent gotcha: if you allow type constructors, than code like
char foo(int x, int y)
(which looks like a function declaration and requires an opening curly to its right) is ambiguous. Just changing the names of the identifiers, to make it more clear:
option hash(list string, list int)
which looks like a complicated type (in OCaml syntax: (string list, int list) Hashtable.t option¹). The parser doesn't expect a opening curly to follow it.
Recently working on / thinking about: any type that's of pointer kind can have a "maybe" attribute, which corresponds to the possibility of being NULL in C. A string (which is a char*, so that's a pointer kind) is a subtype of {maybe}string, so you can pass variables of the former form to functions expecting the latter, but not the reverse—you have to test for NULL first.
1 Again, it's the backwards problem: I write ref int in OCaml to get something of type int ref.
OCaml:
# Some 3;;
- : int option = Some 3
Haskell (who got it right, I think):
Prelude> :type Just 3
Just 3 :: Num a => Maybe a
"spatula." C'mon, you know you like it as a keyword ;^)