Applicative
at first was the a -> b
function 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 a
can only be chained to another Parser a
or 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 -> b
function 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.
master
branch now has separate --prod-release
and --dev-release
options 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-files
has the work we've started on a template for the Wiki pages. (Currently they display as very, very boring HTML with basically no markup.)
doc/hosting.md
on master
branch describing the new hosting configuration and listing a few things we have to change. One is "Configure new.tlug.jp
as a CNAME
to 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
and /wiki/
to the main page, as MediaWiki does.master
and you can rebase your branch on to that at your convenience.Comments from anybody else are welcome as well, of course.
Content-type
headers is a violation of the standard (because Content-type
is not a list of values).
META content-type
or whatever it is in the HTML <HEAD>
would help convince Firefox to do what we desire.