Fork me on GitHub

Just watched the hickey keynote. First bit def felt a bit straw manish but the second half was super interesting... from the point of view of having built a schema-typed system in python this year and the issues we had with optional data etc and how that affected composition of our business logic


Not sure I can express it succinctly but I think he's on to something with composing selects to suit the use case of what you're trying to achieve at that point of your control flow


Going to go for a cycle and have a think


My immediate idea was "woah, if I specify I need a ::user-id and ::zip and you give me a ::user, something can auto-extract!".


I saw his slide with :req and :opt and thought, "pretty sure we've done this... I sense a refactor coming" 😂


Yeah it makes sense - if you're specyfing what bits you need you might as well pull out the data too while you're there!


(probably on to nothing) - as what I usually do is turn a series of bytes into some sort of RDF typed thing, I'm wondering how to model things like "this should be a postcode, but sometimes is junk"


wear the scarf tho Jade


Thing is I was planning too Broce….. not going to now.


partly b/c I want to communicate the intended type to whatever human might have to come in and correct it


thinking about it a bit more, I suppose it is one of those places where you do want to wrap a type. ingest-postcode which could have a postcode or an error. idk


while I haven’t watched the presentation yet, when I’ve had to deal with modelling imperfect matches while not losing data, I’d do this


1) the main entity is a PostcodeMatch 2) then PostcodeMatch is guaranteed to be either a Postcode or a MalformedPostcode 3) MalformedPostcode contains the raw data (if possible) plus postcode-relevant fields that contain any hints that I were able to extract from the raw data

👍 4

(not using any language-specific terms here as to what the “entities” are in order to avoid confusion)


@dominicm: are you alluding to the duplication between destructuring and “select”? And hinting that a macro could do both? This stuff could certainly be inferred through static analysis of the declarations, but when you do that you really want them to flow from the leaves up to the roots - like hindly milner - but for specifications not types?


IIRC ambrose has been working on flowing/infering specs in core.typed next


@rickmoynihan accidentally perhaps, yes 😊


thinking about it a bit more, I suppose it is one of those places where you do want to wrap a type. ingest-postcode which could have a postcode or an error. idk


what i didnt quite grok from the talk is how to get rid of spec/or though. I get why it's bad just now how you can get rid of it from all use cases. in the talk he brings up the example of a user, with ::first-name ::last-name and an ::addr and uses something like a method call (movie-tickets user). but what if you have a method where you want to deliver movie tickets either to a users' home address, or if not provided, digitally to their e-mail address. How would you express that without or? ::user [::email] or ::user [::addr] are both valid selects here.


I think some kind of spec/or will still be valid in the select - is totally ok to say I require this thing or this other set of things in the context of a function. I think you just can't say what things are optional or required at a top level aggregation


@cfeckardt: I may have missed something but IIRC Rich never mentioned any problems with s/or at all… Infact I seem to remember him praising or saying that Maybe et al essentially attempted to model or but missed all the important properties of it (commutativity etc) Rich’s mistake which was the same as with Maybe was with s/keys and :opt/`:opt-un`


yeah exactly. but how do we get around that problem with s/select? That's what I do not understand! (For those who are wondering what we're talking about it's this talk: from 11m to 33m or so)


@cfeckardt What problem do you think we need to get around?


You think we need to "get rid of s/or"? Why? That wasn't what Rich talked about...


@cfeckardt: So the problem is that you have a set of functions that operate on something, say a ::person. What typically happens is that few of those functions require all of a ::person, so spec users face a problem… either you 1. Define ::person as having lots of :opt/`:opt-un` fields… or you 2. define lots of different variations of ::person. The general concept as I recall it is to put in a schema all of the possible properties of the ::person, but say nothing of what is required. s/select then states which parts of the ::person schema are required for a specific function/context. This is thought to be better because you can reuse the schemas and not end up with either a proliferation of schemas or almost every field being marked as optional. Does that help?

👍 4