Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    sssjjjnnn
    @sssjjjnnn
    The thing that threw me off about 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
    So an applicative parser can only parse a fixed sequence of things, compared to a monad that basically lets you code up any sequence you want
    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:

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