## Where communities thrive

• Join over 1.5M+ people
• Join over 100K+ communities
• Free without limits
##### Activity
Curt J. Sampson
@0cjs

Your intuition seems right. From the paper:

pure f <*> u1 <*> … <*> un
This canonical form captures the essence of Applicative programming: computations have a fixed structure, given by the pure function, and a sequence of subcomputations, given by the effectful arguments.

sssjjjnnn
@sssjjjnnn
I think the key difference between Applicative and Monad is that Monad lets you look at the result of the previous step to determine what kind Parser to use for the next step (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
Curt J. Sampson
@0cjs
Yeah, that looks like it.
sssjjjnnn
@sssjjjnnn
I was taking another look at MonadicParserDemo, and it looks like you duplicated the the fmap in parserApply. You can call it from there like this:
(Parser parse_f) parserApply parse_x =
Parser \$ \state ->
let (f, state')  = parse_f state
in parse (fmap f parse_x) state'
Curt J. Sampson
@0cjs
Yup, that works too, though I don't think it's quite as clear for a beginner. What do you think?
sssjjjnnn
@sssjjjnnn
As far as I can tell the main reason to have the Functor interface is for that fmap function, so it seems weird not to use it
Just pushed some code to my branch. It's doing the basic parsing using Applicatives
Curt J. Sampson
@0cjs
Actually, the main reason for having both Functor and Applicative is just to get us to Monad.
sssjjjnnn
@sssjjjnnn
Right, but I think the reason (or one reason) they require Functor is for fmap. Is there any case where fmap would ever be different from the code in Applicative
?
Curt J. Sampson
@0cjs
And I'm pretty sure there must be a clever way to do it without having to bind (f, state'), but it's been too long a day (I worked from 8 a.m. to 10 pm.) and I can't work it out right now.
No, I think it would never be different because it would break the rules, right?
sssjjjnnn
@sssjjjnnn
That's my understanding. I think that is literally an fmap operation and things would be very weird or broken if it was different
Curt J. Sampson
@0cjs
So the awkwardness here seems to be because the state is going the opposite direction of the application of the function to the argument.
sssjjjnnn
@sssjjjnnn
Yeah, it's weird. In a sense they are going opposite directions, because the state gets passed down from the outer wrapper to the inner parsers and then the results get passed back up
Curt J. Sampson
@0cjs
So, I've been taking a break from this for a week, but I guess I should get back to it. Anybody up for some hacking at Lodge on Saturday afternoon or any time on Sunday?
sssjjjnnn
@sssjjjnnn
I'm out of town for a week, so I can't make it this weekend
Curt J. Sampson
@0cjs
Ah well. I'll have a look at your applicative parser anyway, and try to finish the monadic parser explanation.
Commit messages on your branch look good, at least. :-)
sssjjjnnn
@sssjjjnnn
Your commit message standards are pretty high but I'm trying :)
Curt J. Sampson
@0cjs
I just keep in mind the audience for the message, and what they really need from it. That would be me, six months later. :-)
Curt J. Sampson
@0cjs

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.

Curt J. Sampson
@0cjs
So, maybe we'd better get back to hacking on the website this weekend, or this coming week?
sssjjjnnn
@sssjjjnnn
I just got back in town. How about tomorrow afternoon?
Curt J. Sampson
@0cjs
Works for me. How does around 15:00 sound?
Curt J. Sampson
@0cjs
I also notice that [TGIFreeCodeCamp[ https://www.meetup.com/Thank-God-Its-FreeCodeCamp-Friday/] is opening their room in Akihabara 10:00-18:00 Mon-Thu this week for free "self-study." I guess what we do pretty nearly qualifies, so this might make it more convenient (or less inconvenient :-)) for @yaseppochi to come in, if he wanted to....
sssjjjnnn
@sssjjjnnn
That works for me
Curt J. Sampson
@0cjs
Right-o. See you at Lodge tomorrow at 15:00.
Curt J. Sampson
@0cjs
Hey dude. Hate to break our appointment, but I've come down with something and am feeling pretty ill and have to bail on today. Maybe later this week?
sssjjjnnn
@sssjjjnnn
Ok, no problem. BTW,
Lodge is closed for golden week
Curt J. Sampson
@0cjs
Oh! Well, that would have gone badly anyway.
Curt J. Sampson
@0cjs
Oh my! Seems I'm the only one here at Co-edo?
Curt J. Sampson
@0cjs
Ok, the new branch with what's approaching the final version of the wiki content generation code is dev/cjs/190511/wiki.
Curt J. Sampson
@0cjs
For those keeping up remotely, the 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.)
Curt J. Sampson
@0cjs
Ok, I've just pushed up 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?
Curt J. Sampson
@0cjs

@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:

1. Fix the broken links to namespaced pages. You don't need to worry about the actual Haskell code itself (unless you want to), just check that you think the solution I picked (prefix things we know are namespace URLs with /wiki/) is correct.
2. Redirect /wiki and /wiki/ to the main page, as MediaWiki does.
If this looks good to you, I'll put these commits on master and you can rebase your branch on to that at your convenience.

Comments from anybody else are welcome as well, of course.

Curt J. Sampson
@0cjs
Edward Middleton
@0cjs I have found the issues with pages showing up as code when loaded from cache. netlify is sending two content type headers, one with the original content type and one with the html type. It appears the cache is only storing the text type.
Curt J. Sampson
@0cjs
Ooof! That's not good.
Feel like putting in a support request and asking them about this? Sounds like a bug in their system; I'm pretty sure sending two Content-type headers is a violation of the standard (because Content-type is not a list of values).
Curt J. Sampson
@0cjs
Two other things that might be worth trying, just in case it's silly code bugs:
1. Change the capital-C to a small-c in our [headers.values] section.
2. Try moving that config to a _headers file.
And, probably a pretty hacky workaround, but I wonder if setting a META content-type or whatever it is in the HTML <HEAD> would help convince Firefox to do what we desire.
Edward Middleton
Ah. Oh! I know what we should do: update our netlify-test site to have subdirs that do all three versions, so that we can demo it.