tlug/tlug

Tokyo Linux Users Group general conversation

Curt J. Sampson

@0cjs

Good to hear. So there's some hope others might be able to deal with our code.
Yes, what you say about applicative makes sense. I've gotten through only the intro of the paper, which is the part that provides the patterns motivating the Applicative typeclass, but it seems to me that a key difference is that, whereas with a Functor you give a "regular" function to 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.
But wait, how did we do this with our Parser monad? By type the structure has embedded in it a function, rather than just a value, so every 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

Ah, <*> 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.
I'll just go learn Applicative and then it will probably make sense.

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:

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.
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

Hm. https://lists.tlug.jp is not small. 605 MB and 72K files and still downloading....

Edward Middleton

@E14n_twitter

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

Change the capital-C to a small-c in our [headers.values] section.
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

@E14n_twitter

@0cjs I changed the T for type to upper case and that fixed the issue.

Curt J. Sampson

@0cjs

Wow! Well, cool!

It would be a good idea to squash those two test commits and make sure the commit message documents exactly what's going on there.

Did the all-lower-case version still have the issue?

Edward Middleton

@E14n_twitter

I don't know, I was looking at the wrong site when I checked ;)

Where communities thrive

People

Repo info

Activity