Ok, so I spent almost exactly one hour on modules per struct and have concluded that this is impossible. I did have one other idea that I thought I might float by you guys:
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 error on those while still giving users `$Elm.overrideName` to allow a user to manually resolve collisions. This works in Elm particularly because record fields do not have name collisions (or more accurately, record fields are encoded in the type, so the same field can access different types in different records). Fields, which are the things that are most likely to overlap, can overlap, but Structs/Unions/Enums cannot. This might be a bit opaque to the user, but I'm hoping through documentation, good error messages, and an easy escape hatch via annotations, this can be alleviated. I suspect that 90% of schemas files will not have name collisions internally and this way we get to keep shorter names and easier to use but transfer some complexity to the schema file. There is one exception to field names overlapping: A struct with a union uses its field names as Type constructors. For this I basically have no option other than to prefix the union's name. --Prasanth -----Original Message----- From: Prasanth Somasundar Sent: Saturday, June 1, 2019 12:09 PM To: Ian Denhardt <[email protected]>; 'Kenton Varda' via Cap'n Proto <[email protected]>; David Renshaw <[email protected]>; Kenton Varda <[email protected]>; Prasanth Somasundar <[email protected]> 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: [email protected] <[email protected]> On Behalf Of Ian Denhardt Sent: Saturday, June 1, 2019 10:02 AM To: 'Kenton Varda' via Cap'n Proto <[email protected]>; David Renshaw <[email protected]>; Kenton Varda <[email protected]>; Prasanth Somasundar <[email protected]> Subject: 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 in `Internal` modules. Not 100% it'll work, but > we'll see. It's fairly complex, but I would feel better about that than > presenting long names with no escape. You may run into some trouble with this due to the fact that Elm doesn't let you re-export values imported from another module. So, there's no way to import a data constructor from anywhere other than the module in which it was defined, iirc. If you decide to go this route make sure you write some proof of concept modules early on to verify that the code you intend to generate will actually build. It's your project, but my advice would still be to keep it simple. I spent far longer than I care to think about banging my head against this kind of thing. As has been discussed, deeply nested namespaces generate painful APIs even if the target language has the needed namespace support, So I really think well-written schema should avoid them anyhow. And it is always possible to modify a schema to change the names and namespace structure without breaking wire compatibility, so one is never *really* stuck with what upstream has given them (e.g. I see why Kenton doesn't want to change the sandstorm stuff, but there's no reason I couldn't use my own forked versions to write apps). Best of luck, whatever route you decide to go. -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/155940854142.15918.7713439203705816260%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/BYAPR11MB259998A6DB148B191D0A6CF3C51B0%40BYAPR11MB2599.namprd11.prod.outlook.com.
