3 ms·

Thanks for answering my earlier question. Here's hoping you catch another one! In a lot of my clojure scripts, I forget the shape of the data, and so to help f

Thanks for answering my earlier question. Here's hoping you catch another one! In a lot of my clojure scripts, I forget the shape of the data, and so to help future me, I've use tricks like pre/post constraints, defstructs, schemas, etc. In my experience, TypeScript has the best typing ergonomics (block-local, partial interfaces!). But since I prefer lisp language and interaction ergonomics, I'm always on the lookout for new developments, like https://github.com/coalton-lang/coalton https://github.com/coalton-lang/coalton, which has pushed me to start playing with sbcl. Maybe CCL has already solved this, but I'm not versed in CL, so what methods do you find most effective for passing down knowledge of constraints and data shape to your future selves?

lisper 4y ago
That's a really good question. No, CCL has not solved this. CCL is just a CL implementation with a really fast compiler and a nice IDE, but it doesn't really extend the language. Ergolib, which has nothing to do with CCL (it works on most CL implementations) extends the language, but it doesn't really deal with the "shape" of data. I haven't actually heard that term before, but I presume it's referring to data type constraints. If that assumption is correct, then the answer to your question is that this is a very hard problem. The solution that is currently in ergolib is not even half-baked. I had a vision of evolving ergolib into a fully-fledged new programming language which would be called Ergo and include a state-of-the-art type inferencer, but I have yet to get around to implementing it. It turns out that dealing with the vaguaries of external data sources is MUCH harder than dealing with inconsistencies within my own code. I hardly ever get type errors in my code, despite the fact that I have minimal support for typing, and even what little there is I hardly ever use. The closest I get is to be fairly anal about creating classes for everything and avoiding punning cons cells like the plague. Punning cons cells is a vert common practice in idiomatic Lisp code, but I think it's a Really Bad Idea (tm). So, for example, I really hate association lists. Ergolib has support for abstract associative maps, which allow you to use an alist as the underlying implementation if you really want to, but the default is a hash table, and I find I hardly ever need to change that. The hard stuff for me is dealing with external interfaces, which almost always comes down to parsing. This is one reason I love Lisp -- once you get your data into the form of an S-expression, a lot of the heavy lifting has been done and everything just becomes much easier. So any time I have to deal with json, or xml, or csv, or whatever, the first thing I do is parse it to turn into a sexpr, and that almost always turns out to be the hard part of whatever I'm doing. Did that answer your question?
- whacked_new 4y ago
  Yea, for the most part. The problems you describe with external data are supposed to be clojure's forte, but clojure also makes cheap footguns because maps fill most of the use cases for alists / hash tables, and implicit nil punning is everywhere. Once data comes through the wire and is turned into a map, if there isn't an enforceable structure in code, I have to run the program to check the data's shape. Hardly new in dynamic languages, and there are many solutions (e.g. spec, malli, schema, just to name 3 for clojure), but I haven't seen one matching the ergonomics that TypeScript 3+ offers today. Thanks again! Always enjoy insight from experienced lispers.

lisper 4y ago

That's a really good question. No, CCL has not solved this. CCL is just a CL implementation with a really fast compiler and a nice IDE, but it doesn't really extend the language. Ergolib, which has nothing to do with CCL (it works on most CL implementations) extends the language, but it doesn't really deal with the "shape" of data. I haven't actually heard that term before, but I presume it's referring to data type constraints. If that assumption is correct, then the answer to your question is that this is a very hard problem. The solution that is currently in ergolib is not even half-baked. I had a vision of evolving ergolib into a fully-fledged new programming language which would be called Ergo and include a state-of-the-art type inferencer, but I have yet to get around to implementing it. It turns out that dealing with the vaguaries of external data sources is MUCH harder than dealing with inconsistencies within my own code. I hardly ever get type errors in my code, despite the fact that I have minimal support for typing, and even what little there is I hardly ever use. The closest I get is to be fairly anal about creating classes for everything and avoiding punning cons cells like the plague. Punning cons cells is a vert common practice in idiomatic Lisp code, but I think it's a Really Bad Idea (tm). So, for example, I really hate association lists. Ergolib has support for abstract associative maps, which allow you to use an alist as the underlying implementation if you really want to, but the default is a hash table, and I find I hardly ever need to change that. The hard stuff for me is dealing with external interfaces, which almost always comes down to parsing. This is one reason I love Lisp -- once you get your data into the form of an S-expression, a lot of the heavy lifting has been done and everything just becomes much easier. So any time I have to deal with json, or xml, or csv, or whatever, the first thing I do is parse it to turn into a sexpr, and that almost always turns out to be the hard part of whatever I'm doing. Did that answer your question?

whacked_new 4y ago
Yea, for the most part. The problems you describe with external data are supposed to be clojure's forte, but clojure also makes cheap footguns because maps fill most of the use cases for alists / hash tables, and implicit nil punning is everywhere. Once data comes through the wire and is turned into a map, if there isn't an enforceable structure in code, I have to run the program to check the data's shape. Hardly new in dynamic languages, and there are many solutions (e.g. spec, malli, schema, just to name 3 for clojure), but I haven't seen one matching the ergonomics that TypeScript 3+ offers today. Thanks again! Always enjoy insight from experienced lispers.