> I suggest optimizing for "well-written" schema, and making peace > with the fact that certain constructs may generate unpleasant APIs.
This has piqued my interest. Which parts of the schema language don't map well to Haskell/Elm? - David On Wed, May 29, 2019 at 4:19 PM Ian Denhardt <[email protected]> wrote: > Oops, forgot to cc the list. > > Quoting Ian Denhardt (2019-05-29 16:13:32) > > Neat. Some feedback: > > > > * Re: why not the Haskell implementation, it's definitely stable enough > > and complete enough to write a compiler plugin. At the serialization > > layer there are only a couple things missing, and they shouldn't be a > > problem for this use case. I would say don't like the stability > > disclaimers in the README scare you away (note: I am the author of the > > Haskell implementation). > > > > You may even be able to cannibalize parts of the Haskell code > > generator itself; especially the first bits of the translation process > > would look very similar if I were writing an elm backend. Feel free to > > pick my brain about it if you try to do this. > > > > * Re: Single module vs. Splitting things up for namespacing, note that > > Elm does not allow cyclic dependencies between modules, so this > > probably just won't work, since you can have cycles within a single > > capnp schema. > > > > Also, from having had the same initial instinct with the Haskell > > implementation (where it is possible to break cycles with .hs-boot > > files), I will say that I found the massive pile of imports wasn't any > > better than Long_Names_With_Underscores -- especially since you still > > have to distinguish identifiers at call sites, so you don't even save > > much typing outside of the imports. From an implementer's perspective > > it was also much simpler to do it in one file. > > > > I ultimately ended up going with the one-module-per-capnp-file > > approach, and my usual advice re: long names is to tell people to just > > not use nested namespaces in their schema file. It's always possible > > to change a schema to avoid these in a wire-compatible way. > > > > * More generally, if you try to make *every* feature of the schema > > language map to Elm in an ergonomic way, you will be in for a rough > > time. I suggest optimizing for "well-written" schema, and making peace > > with the fact that certain constructs may generate unpleasant APIs. > > This applies especially if the user can easily just avoid those > > features. > > > > * Re: built-in types, note that in addition to run-time checks, you will > > also have to do some special logic for 64-bit arithmetic, since Elm > > uses JavaScript's numbers internally, which are double-precision > > floating point, and thus can only faithfully represent integers up to > > 53 bits. > > > > * Re: interfaces, producing a warning strikes me probably unnecessary; > > if the library clearly marked serialization-only, users will not > > expect it to pay attention to interfaces. > > > > * It's not entirely clear to me how you plan to implement the traversal > > limit with the API you've described. > > > > * Note that as of 0.19 Elm no longer allows single quotes in > > identifiers, so you'll need to do something else for union names. > > Fortunately, underscores are also illegal in capnp names, but legal in > > Elm. > > > > Hope this is helpful. I'll keep an eye on this; interested to see where > > it goes. > > > > -Ian > > > > Quoting prasanth somasundar (2019-05-29 05:00:46) > > > Hey Everyone, > > > > > > I'm thinking about building out a Cap'n Proto implementation in Elm > for > > > the fun of it. Thought I'd send an email to this list as suggested > and > > > get some feedback on [1]the initial design which I've also linked > > > below. Any thoughts, comments, or concerns are appreciated. > > > > > > > > > --Prasanth > > > > > > > > > Another link to the doc in case you missed it: > > > > https://docs.google.com/document/d/12qMVyQPOWTXviFKIpjKLXgusKZ95miuRmu9 > > > AxacyGOA/edit?usp=sharing > > > > > > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "Cap'n Proto" group. > > > To unsubscribe from this group and stop receiving emails from it, > send > > > an email to [2][email protected]. > > > Visit this group at [3]https://groups.google.com/group/capnproto. > > > To view this discussion on the web visit > > > [4] > https://groups.google.com/d/msgid/capnproto/BYAPR11MB259933537902814 > > > B8C0041F4C51F0%40BYAPR11MB2599.namprd11.prod.outlook.com. > > > > > > Verweise > > > > > > 1. > https://docs.google.com/document/d/12qMVyQPOWTXviFKIpjKLXgusKZ95miuRmu9AxacyGOA/edit?usp=sharing > > > 2. mailto:[email protected] > > > 3. https://groups.google.com/group/capnproto > > > 4. > https://groups.google.com/d/msgid/capnproto/BYAPR11MB259933537902814B8C0041F4C51F0%40BYAPR11MB2599.namprd11.prod.outlook.com?utm_medium=email&utm_source=footer > > -- > You received this message because you are subscribed to the Google Groups > "Cap'n Proto" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > Visit this group at https://groups.google.com/group/capnproto. > To view this discussion on the web visit > https://groups.google.com/d/msgid/capnproto/155916089026.23375.1007569258138270396%40localhost.localdomain > . > -- You received this message because you are subscribed to the Google Groups "Cap'n Proto" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/capnproto. To view this discussion on the web visit https://groups.google.com/d/msgid/capnproto/CABR6rW9Y%3DrO3%3DD0YOC2OpeFaSKTq7_UL8MdX%2BuyxSmfuxPr2eg%40mail.gmail.com.
