RE: [capnproto] Cap'n Proto for Elm

; prasanth somasundar Subject: Re: [capnproto] Cap'n Proto for Elm Did this ever go anywhere? I'm working on some elm <-> haskell interaction for a sandstorm app and this would be nice to have. Quoting prasanth somasundar (2019-05-29 05:00:46) >Hey Everyone, > >I'm thinking abo

Re: [capnproto] Cap'n Proto for Elm

Did this ever go anywhere? I'm working on some elm <-> haskell interaction for a sandstorm app and this would be nice to have. 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.

Re: [capnproto] Cap'n Proto for Elm

Quoting Kenton Varda (2019-06-07 09:45:37) >On Thu, Jun 6, 2019 at 7:41 PM Prasanth Somasundar ><[1]mezu...@live.com> wrote: > >Hey guys, >I've updated [2]the doc with a new write API suggestion. The gist is >that writes never happen to the byte array. Instead, we build a

Re: [capnproto] Cap'n Proto for Elm

On Thu, Jun 6, 2019 at 7:41 PM Prasanth Somasundar wrote: > Hey guys, > I've updated the doc > > with a new write API suggestion. The gist is that writes never happen to > the byte array. Instead,

Re: [capnproto] Cap'n Proto for Elm

f Prasanth Somasundar Sent: Saturday, June 1, 2019 11:48 PM To: Ian Denhardt; 'Kenton Varda' via Cap'n Proto; David Renshaw; Kenton Varda Subject: RE: [capnproto] Cap'n Proto for Elm > I like this Cool > I toyed at one point with the idea of having the code generator automatically &g

RE: [capnproto] Cap'n Proto for Elm

Original Message- From: Ian Denhardt Sent: Saturday, June 1, 2019 8:25 PM To: 'Kenton Varda' via Cap'n Proto ; David Renshaw ; Kenton Varda ; Prasanth Somasundar ; Prasanth Somasundar Subject: RE: [capnproto] Cap'n Proto for Elm Quoting Prasanth Somasundar (2019-06-01 23:12:20) >

RE: [capnproto] Cap'n Proto for Elm

Quoting Prasanth Somasundar (2019-06-01 23:12:20) > What about just dumping everything into the same module, but without > the prefixed namespace for every value/type/type constructor. The > reason that we're prefixing everything with underscores is to avoid > name collisions, but we can simply

RE: [capnproto] Cap'n Proto for Elm

:09 PM To: Ian Denhardt ; 'Kenton Varda' via Cap'n Proto ; David Renshaw ; Kenton Varda ; Prasanth Somasundar Subject: RE: [capnproto] Cap'n Proto for Elm Yea, I'm not going to put a ton of time into that particular problem. Maybe just a few hours. --Prasanth -Original Message- From

Re: [capnproto] Cap'n Proto for Elm

Quoting Prasanth Somasundar (2019-06-01 04:21:18) >Except for module names. Like I said, I'll try to fix this as best I >can and see if it makes sense to pursue. My current plan is to >topologically sort the graph, break any cycles with extra generics, and >then hide the generics

Re: [capnproto] Cap'n Proto for Elm

From: Ian Denhardt Sent: Friday, May 31, 2019 7:43 PM To: 'Kenton Varda' via Cap'n Proto; David Renshaw; Kenton Varda Cc: Prasanth Somasundar; 'Kenton Varda' via Cap'n Proto Subject: Re: [capnproto] Cap'n Proto for Elm And in fact you can't even do: type JSON

Re: [capnproto] Cap'n Proto for Elm

On Fri, May 31, 2019 at 2:54 PM David Renshaw wrote: > Note that Prasanth's example aliases a module that's at an intermediate > point in the nested hierarchy. I doubt that Haskell would let you do > something like: > > type Global = Pipeline'Stage'Worker'Global; > ... > case

Re: [capnproto] Cap'n Proto for Elm

On Fri, May 31, 2019 at 3:07 PM Kenton Varda wrote: > >> With Elm and Haskell, I believe the only layer of namespacing that's >> provided is the module name which is why both Ian and I gravitated to it >> initially. >> > > Are you saying Elm and Haskell don't provide any way to declare aliases?

Re: [capnproto] Cap'n Proto for Elm

On Thu, May 30, 2019 at 3:40 PM Ian Denhardt wrote: > Oof, point taken. Slightly off topic for this list, but how would you > feel about accepting (wire compatible) patches to the sandstorm schema > to flatten the namespace? Here's another doozy (from the output of the > go code generator): > >

Re: [capnproto] Cap'n Proto for Elm

roups. Seems that I actually had this account in Google since 2010 and forgot about it. We can just use my real name. --Prasanth From: Ian Denhardt Sent: Thursday, May 30, 2019 6:36 PM To: 'Kenton Varda' via Cap'n Proto; Kenton Varda Cc: David Renshaw; prasanth somasu

Re: [capnproto] Cap'n Proto for Elm

Quoting 'Kenton Varda' via Cap'n Proto (2019-05-30 14:22:59) >Actual line of code from Cloudflare Workers: >case PipelineDef::Stage::Worker::Global::Value::JSON: >So again, I'm not sure this is a problem specific to certain languages. >:) Oof, point taken. Slightly off topic for

Re: [capnproto] Cap'n Proto for Elm

On Thu, May 30, 2019 at 10:50 AM prasanth somasundar wrote: > Pointer field defaults: Field defaults in general are not features I feel > super great about. Not that I’ve thought about this in horribly great > depth, but they seem to be very problematic if they are ever updated – your > binaries

RE: [capnproto] Cap'n Proto for Elm

Quoting prasanth somasundar (2019-05-30 13:50:26) > I'm hoping that I can use `elm-bytes` in a better way than being > forced to decode it into a full Elm data type - though as I say this, > it seems that I'd need some buy-in that I can't be guaranteed. I may > end up with that solution in the

Re: [capnproto] Cap'n Proto for Elm

On Wed, May 29, 2019 at 11:27 PM Ian Denhardt wrote: > One bit of food for thought: you can't exactly mmap() in elm, That's not as true that you might think. I'm not familiar with Elm specifically, but as I understand it, it transpiles to JavaScript for execution in the browser. JavaScript

Re: [capnproto] Cap'n Proto for Elm

On Wed, May 29, 2019 at 8:38 PM Ian Denhardt wrote: > The biggest one is nested namespaces, per discussion. If it's any consolation, even though C++ has nested namespaces, the code doesn't end up any less verbose. When you're using the declarations from a capnp file in C++ code, you either

RE: [capnproto] Cap'n Proto for Elm

- Data traversed so far. Assume that we've only traversed 30 bytes for -- w/e reason. -- currentTraversalDistance = 30 --, traversalLimit = 67108864 --} From: David Renshaw Sent: Thursday, May 30, 2019 5:30 AM To: Ian Denhardt Cc: prasanth somasundar ; capnproto Subject: Re: [c

Re: [capnproto] Cap'n Proto for Elm

Thanks! I wrote some comments inline below. On Wed, May 29, 2019 at 11:38 PM Ian Denhardt wrote: > Quoting David Renshaw (2019-05-29 21:33:03) > > >This has piqued my interest. Which parts of the schema language don't > >map well to Haskell/Elm? > > The biggest one is nested namespaces,

RE: [capnproto] Cap'n Proto for Elm

Quoting prasanth somasundar (2019-05-29 22:08:27) > Thanks for the feedback. This is really helpful. You're welcome. > * Not supporting every feature/Optimize for well written schema > Very interesting point. I'm not generally good at making those sorts of > concessions, but I probably should

Re: [capnproto] Cap'n Proto for Elm

Quoting David Renshaw (2019-05-29 21:33:03) >This has piqued my interest. Which parts of the schema language don't >map well to Haskell/Elm? The biggest one is nested namespaces, per discussion. Neither language has intra-module namespaces, so you either end up doing a bunch of complex

RE: [capnproto] Cap'n Proto for Elm

rdt Sent: Wednesday, May 29, 2019 1:14 PM To: prasanth somasundar Subject: Re: [capnproto] Cap'n Proto for Elm 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 o

Re: [capnproto] Cap'n Proto for Elm

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

[capnproto] Cap'n Proto for Elm

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 the initial design