to be clear, that’s just the formalism I’m designing. Facet itself uses nominally-typed interfaces, and the closest that will approach structural interfaces is if I allow local or inline definitions of them.
Conversation
Nice, seems like this might address this concern
Quote Tweet
Replying to @brendanzab and @rob_rix
Been a bit spooked with the ‘stringy’ nature of the implementations row labels I’ve seen. Seems to pose some issues for modularity? I dunno. 
1
Yeah I’ve been wondering about this for Pikelet, where I’m hoping to use records as modules. I love the idea of smooshing together structures, but don’t like the idea that I might then run into issues with fields clashing…
1
1
Yeah! It gets a bit weird! Clojure lets you have ‘namespaced symbols’ but that requires a top level namespace thingy. Where as I would love to be able to get rid of the top level ‘command’ language (like in Dhall and Nix)
1
2
Wish I understood levitation at this point - I think it lets you bootstrap datatypes inside the system itself, which feels possibly reminiscent?
3
You’re unable to view this Tweet because this account owner limits who can view their Tweets. Learn more
Not seen this one actually! Wondering what bits of a language could be considered 'coeffectful' if anything? Records perhaps?
Still trying to get my head around this mysterious yet tantalizing thingy: ncatlab.org/nlab/show/nece
2
like, what are records, telescopes, and functions actually doing? 😳 - somehow a record field is 'stronger' than a function parameter - ie. a function can be constructed even if there is no way of providing a parameter, where as a record kind of *insists* that a field is present.
2
1
Show replies
context dependency in general. so reader/environments, for example. (and , IIRC?) have written a lot about this, and Tomas also published this v. cool site: tomasp.net/coeffects/
2