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 logic to split stuff across multiple modules and still break dependency cycles (in Haskell; per my earlier message, in Elm you're just SOL, since mutually recursive modules are just not supported, full stop), or you deal with long_names_with_underscores (Haskell actually uses the single quote as a namespace separator). This is a problem for the Go implementation as well; some of the stuff from sandstorm's web-session.capnp spits out identifiers that are pushing 100 characters. (I actually bumped into @glycerine at a meetup just the other day; we talked about this among other things). The fact that union field names are scoped to the struct is a bit awkward, since union tag names are scoped at the module level in most ML-family languages. More makeshift namespacing. The lack of a clean separation between unions and structs introduces a bit of an impedance mismatch as well; if you do things naively you end up with an awkward situation where *every* sum type is wrapped in a struct, which is a bit odd since they are used so liberally (and are normally so lightweight) in these languages. The Haskell implementation specifically looks for structs which are one big anonymous union so it can omit the wrapper. If you have an anonymous union you also need to invent a name for the field, since you can't actually have "anonymous" fields in records. For Haskell, there's no way to talk about a record type without giving it a name, so every group needs an auxiliary type defined. There's not really anything clearly nicer to do than just name it <Type>'<field> or such, which makes the long name problem worse. Along similar lines, in Haskell you end up having to define auxiliary types for parameter and return types, and without more of a hint the end up being things like <Type>'<method>'params and <Type>'<method>'results -- a mouthful even for short type names. I've taken to just always manually giving my parameter and return arguments names to avoid this kind of compiler output; the schema is much more verbose, but the call site is much nicer. None of this section applies to Elm since you can just have anonymous record types. I intentionally decided to just not support custom default values for pointer fields; it gets really awkward because messages can be mutable or immutable, and you end up needing different implementation strategies for each type; for immutable messages you can't do what most implementations do (copy the value in place on first access), but you could "follow" the pointer into some constant defined in the generated code without a copy. But that gets weird because there are functions to access the underlying message/segment, so you could run into situations where you've jumped to a whole other message silently. With mutable messages you can do the normal thing, but writing code that's generic over both of these gets really weird. At some point I ended up checking the schema that ship with capnproto, and with sandstorm, and discovered that, in >9000 lines of schema source, the feature was used exactly twice, both to set the default value of a text parameter to the empty string. So I just said "screw it, this is a waste of time." The plugin just prints a warning to stderr and ignores the custom default. I actually have a much longer critique that I think would be worth writing, including some things that aren't a problem for Haskell specifically, but cause problems for other languages -- and I am being bothered to go help with dinner, so I'll leave it at this for now. -Ian -- 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/155918727572.10312.15632533580192568031%40localhost.localdomain.
