09:37 pm, 17 Mar 04
monads for functional programming
I'm glad I've spent so much time with the Haskell manuals because so many papers are written using Haskell.
In the Haskell tutorial's monads section they mention a paper by Wadler called "Monads for functional programming", and I finally looked it up the other day.
This paper uses some simple examples as motivation and builds in a straightforward way. I can see why they recommend it.
I understand the idea and goals of monads, but not the deep understanding I would need to explain the idea to someone unfamiliar with it. It requires more thought.
Writing that made me also want to look up effects systems: they've come up a few times in class and I understand why Cyclone uses one for modelling memory accesses, but I can't quite explain it. (The Cyclone stuff is black magic, though: they're not really mentioned in the manual because they've manage to make the compiler infer most of the effects of functions; so when you're reading about the language you don't even think about it. They go into it here.)
PS. There's a bit where their CVS bit their TeX: they wanted to talk about a type called "Id", so for TeX-speak they wrapped it like $Id$, and then CVS happily expanded that to include the filename and revision time. Nobody appears to have noticed, because it's in the postscript file I've been reading...
In the Haskell tutorial's monads section they mention a paper by Wadler called "Monads for functional programming", and I finally looked it up the other day.
This paper uses some simple examples as motivation and builds in a straightforward way. I can see why they recommend it.
I understand the idea and goals of monads, but not the deep understanding I would need to explain the idea to someone unfamiliar with it. It requires more thought.
Writing that made me also want to look up effects systems: they've come up a few times in class and I understand why Cyclone uses one for modelling memory accesses, but I can't quite explain it. (The Cyclone stuff is black magic, though: they're not really mentioned in the manual because they've manage to make the compiler infer most of the effects of functions; so when you're reading about the language you don't even think about it. They go into it here.)
PS. There's a bit where their CVS bit their TeX: they wanted to talk about a type called "Id", so for TeX-speak they wrapped it like $Id$, and then CVS happily expanded that to include the filename and revision time. Nobody appears to have noticed, because it's in the postscript file I've been reading...
I've started dabbling in arch, but i prefer to spend the little time i have for code coding, instead of learning a new (bizarre-feeling) version management tool. Maybe i'm just starting to get stodgy. And with my luck, arch will still do the same (annoying) thing.
this, from the darcs manual, is especially cool:
Although most filepatches will be hunks, darcs is clever enough to support other types of changes as well. A ``token replace'' patch replaces all instances of a given token with some other version. A token, here, is defined by a regular expression, which must be of the simple [a-z...] type, indicating which characters are allowed in a token, with all other characters acting as delimiters. For example, a C identifier would be a token with the flag [A-Za-z_0-9].
What makes the token replace patch special is the fact that a token replace can be merged with almost any ordinary hunk, giving exactly what you would want. For example, you might want to change the patch type TokReplace to TokenReplace (if you decided that saving two characters of space was stupid). If you did this using hunks, it would modify every line where TokReplace occurred, and quite likely provoke a conflict with another patch modifying those lines. On the other hand, if you did is using a token replace patch, the only change that it could conflict with would be if someone else had used the token ``TokenReplace'' in their patch rather than TokReplace--and that actually would be a real conflict!