Three toads and the spit of a badger
Published October 13, 2014
So Epoch has a couple of warts that I'm looking at smoothing out. One of them has to do with overloads that do type decomposition of algebraic sum types:
//// How things look today//type Optional : T | nothingTest : integer x{ print(cast(string, x))}Test : nothing{ print("Nothing")}entrypoint :{ Optional exists = 42 Optional doesntexist = nothing Test(exists) Test(doesntexist)}
I'm thinking about modifying the parser so that overloads of a function can be chained together without repeating the function name, by just specifying the signature of an overload immediately after the body of the function, and following with the body of the overload:
//// How things look with implicit overloads//type Optional : T | nothingTest : integer x { print(cast(string, x)) } : nothing { print("Nothing") }entrypoint :{ Optional exists = 42 Optional doesntexist = nothing Test(exists) Test(doesntexist)}
The last question I want to ask is what lambdas look like, and whether or not they can help compact this code even further. Here's one thought experiment:
//// Experiment with lambda syntax//type Optional : T | nothingentrypoint :{ Optional exists = 42 Optional doesntexist = nothing var f = lambda :(integer x) { print(cast(string, x)) } :(nothing) { print("Nothing") } f(exists) f(doesntexist)}
I'm not totally sold on the lambda syntax yet. I do like the idea of allowing overloads of lambdas, specifically for the type decomposition thing. Or maybe type decomposition just really needs a first-class structure, like case:
//// Experimental case statement//type Optional : T | nothingTest : Optional in{ case(in) : integer x { print(cast(string, x)) } : nothing { print("Nothing") }}entrypoint :{ Optional exists = 42 Optional doesntexist = nothing Test(exists) Test(doesntexist)}