dev/cjs/190407/monadic-parser, with a new
src/TLUG/MonadicParserDemo.hsthat is intended to have fairly detailed (and I hope enlightening) explanations of the various pieces of a Monadic parser done in the simplest possible way (e.g., no proper error handling). Let me know if you think it's useful. (It's definitely been useful for me to write out the explanations.)
Applicativeat first was the
a -> bfunction call. But then I realized what it was doing--basically running the operation and passing the result as an argument to that function which then applies some custom logic. And then chaining it is just like passing more arguments to the function
fmap, which handles running it "in" the structure, with an "applicative functor" you lift the function into the structure before using
<*>to apply the function-containing structure to the data-containing structure(s). Given that, that you'd need a function of specify arity followed by the right number of structured values to match that arity becomes clearer.
Parser acan only be chained to another
Parser aor something that will run the function inside and deconstruct the output (
runParser). So one would think you could do the same thing with Applicative. I need to look closely at what's different between the two. The clue is surely in the type signatures:
(<*>) :: f (a -> b) -> f a -> f b (>>=) :: m a -> (a -> m b) -> m b
<*>is basically an "apply a function to arguments" function as opposed to
>>=which is chainable because it produces an output that can be used as input for another
>>=. No, wait. There's something else.
a -> Parser b) vs. Applicative which is always a fixed chain independent of any values that were parsed. The
a -> bfunction just lets you combine multiple results into one and can't determine the type of the next Parser
Also, I often find that, when cleaing up a series of WIP ("Work In Progress," for any others who are listening in) commits to ready them for integration to the
master branch, the work of writing up a commit message that actually explains things well often finds problems and prompts me to go back and fix them. I guess it's along the same lines as the Readme Driven Development idea. I notice it particularly now because I keep meeting up with situations where someone's done a commit to make some tests pass, with no real explanation.* and when I ask them they don't really know what they did.
*My favourite commit message from today: "What the heck?" When I asked the guy, he said the tool he was using to comit wouldn't let him use "WTF?" as a commit message because it was too short.
masterbranch now has separate
--dev-releaseoptions so you can test your branch on your Netlify account, and we now have four sample wiki pages being served properly under the exact same
/wiki/...URLs as the current site uses, though we don't have links to pages with
:in the working (probably a fairly easy fix) or transcludes working (a more difficult fix, but in progress). The
dev/ejdm/wiki-fileshas the work we've started on a template for the Wiki pages. (Currently they display as very, very boring HTML with basically no markup.)
masterbranch describing the new hosting configuration and listing a few things we have to change. One is "Configure
tlug-jp.netlify.com." @E14n_twitter, can we get that done in the near future? Or can anybody else do it?
@E14n_twitter Can you have a look at my changes on
dev/cjs/190512/wiki-ns-link-fix? (These can currently be seen on https://cjs-tlug.netlify.com/.) There are two changes:
/wiki/) is correct.
/wiki/to the main page, as MediaWiki does.
masterand you can rebase your branch on to that at your convenience.
Comments from anybody else are welcome as well, of course.