Re:Bard (a new Lisp from Mikel Evins)
by raganwald on Saturday February 27, 2010 @06:51AM
(#1155202)
There is a cadre of programming moralists who will wail and gnash their teeth that the world doesn't need Yet Another Object System, Yet Another Lisp, or Yet Another Language. All I can say in reply is, "So what? I couldn't care less what The World needs. Designing and implementing Bard is entirely about what I need." If you aren't interested in another Lisp, you are quite free to move right along. There's nothing to C here.
Re:Bard (a new Lisp from Mikel Evins)
by raganwald on Saturday February 27, 2010 @08:04AM
(#1155240)
in fairness, "void" strikes me as a type while "nil" strikes me as a representation. When I see "nil" in a language I expect it to have all the hideous C-like baggage of applying to any type and being a valid value for any variable. With "void," I would stop and read the documentation to see how it works.
If void behaves like nil in other languages, that's bad. But if it behaves like None in Haskell, that's good.
Re:Bard (a new Lisp from Mikel Evins)
by jrockway on Saturday February 27, 2010 @03:20PM
(#1155764)
Seeing as how there is no not-Nothing ("Just") data constructor, it seems that it is more like ⊥ ("undefined").
But like most specifications for unimplemented software, he could have just forgotten to add this, and will realize he needs the other half when he starts implementing.
Slow clap.
If void behaves like nil in other languages, that's bad. But if it behaves like None in Haskell, that's good.
But like most specifications for unimplemented software, he could have just forgotten to add this, and will realize he needs the other half when he starts implementing.