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.

Reply via email to