1. 19
  1.  

  2. 7

    Hey all! This is what I’ve been working on in my spare time for a while now; happy to answer any questions!

    1. 2

      <3 Looks awesome! My three personal main gripes with OCaml were no multithreading support, poor macro support and syntax, and no possibility to write source code in “top to bottom” order. The first seems now to be solvable with lwt IIUC; now I learn that you seem to have solved the second one! <3 So, on a rather tangential note to the original announcement, do you, or someone else, by any chance know of some plugin/ppx that would allow writing OCaml/Reason “main-first”, aka top-to-bottom?

      On a more on-topic angle: does Relit also work with pure (i.e. non-Reason) OCaml? It’s not fully clear to me, sorry :/

      Also does it work with the Dependent Types in OCaml (or whatever the variant of the feature is named in OCaml, I don’t recall now)? E.g. if I write a “checked size array” type, can I write a reasonable constructor for it in Relit? Now I’m starting to think that the explicit splicing syntax may still make it somewhat convoluted (?), maybe probably: $myvec.`([[elem1, elem2, elem3]])`?

      1. 3

        :D Glad to help! That bottom-to-top problem annoys me to no end. :/ Relit doesn’t work with OCaml at the moment, but I’m hoping to port it at some point in the not-so-near future. There’s nothing Reason-specific other than the changes to the reason parser and the use of the Reason parser in splices.

        1. 2

          I even wondered once if it could be possible to do some rewriter, that would reorder statements in OCaml source to get top-to-bottom — maybe even only in the “top scope”; but I don’t know the language well enough to understand if that’s feasible in any way.

          I’m sometimes tempted to learn Haskell, as it allows top-to-bottom, even though the abundance of custom operators makes it super hard to grok for me. But then I remember that it’s lazy by default, and thus hard to analyze its performance, and the temptation disappears. I do however totally love Elm on this front.

          edit: Ah, and after being corrected by Leonidas: do you know if Relit would allow writing constructors for GADTs? E.g. could one write something like the %mat and %vec in https://github.com/akabe/slap readme with Relit, and if yes, then how would the eventual `( ... )` expression for it look?

          1. 2

            That’s cool! Yeah you probably could do that in a PPX to reorder them but it wouldn’t be quite as nice as Haskell alas, which does a topological sort of everything in the same module.

            Relit at the moment lets you expand to any type, but there isn’t support at the moment for parametric types. (They can be faked with a functor, but it’d be nice to make a List notation and not have to specify what kind of list when you use it.) I don’t think this is a problem with most GADT’s (the canonical example of an AST and an eval function for example would work just fine) but since Slap seems to use parametric types, the Relit notation would be very clunky to use. (Basically Relit’s best suited to expand to types that can be stated without any parametric types: User.data, Url.t, etc, things like (’a, ‘b) Map.t are harder but again possible with functors.) We’ve put some thought into how to get it to infer the proper parametric expansion types automatically, but that’s not going to be around soon.

        2. 2

          OCaml has dependent types? That’d be new to me. OCaml has GADTs, but as far as I know no dependent types.

          Also: Lwt and Async have existed for a long time, so concurrency hasn’t been a problem in OCaml for a long time now.

          1. 2

            Right, I meant GADTs, thanks and sorry for the confusion. I’m not well versed in compsci/plt theory, so they kinda merge/blur together in my simple understanding, as features which kinda enable some vaguely similar stuff. Though I understand dependent types are something more advanced/general than GADTs and allow more, but I’m not good enough in this area to grasp the differences.

            As to Lwt, I only recently learnt about it, so it’s probably just my lack of awareness.

            1. 2

              So, not that I understand this in the least, but apparently OCaml’s first class modules can be used to prove some things and are technically dependent types? https://github.com/lpw25/girards-paradox/blob/master/girard.ml

              1. 2

                Wow, this looks like the densest module code I have ever seen. It is sort of impressive in a way.

                Though I think this is roughly as practically useful as the observation that ML modules can be translated to type classes and vice versa.

                1. 2

                  Haha yeah it’s totally ridiculous

          2. 1

            I first put it away due to how much it emphasizes Reason, but it looks well-thought-out from my initial look. Do you have examples of it being used in OCaml? Maybe adding these to the README would be nice, for all use OCamlers that don’t know how Reason syntax maps to OCaml.

            1. 3

              Yeah it doesn’t support OCaml at the moment, although we’re hoping to eventually. I’ll add that to the readme!

          Stories with similar links:

          1. relit: Hygienic typed literal macros for Reason via zem 1 year ago | 7 points | no comments