Fork me on GitHub
#malli
<
2021-12-09
>
Eddie14:12:24

Thanks! I’m surprised you found this so quickly without me doing any advertising. :) I am currently using this prototype in a research project to give a more concrete example of how something like this could be valuable. After I make that work public, I plan to make a wider pitch to the community. That said, if people have any feedback and ideas now, I would love to hear it!

Ben Sless14:12:21

First of all, you get cool-points 😎

Ben Sless14:12:14

Second, can you share some of your design decisions? Why did you choose a bespoke representation rather than use tools.analyzer output?

Ben Sless14:12:38

Another thing I thought of while reading the code was some impedance mismatch between the type information and the expression encoding which could be unified

Ben Sless14:12:09

You could create "big lambda"

;; Type Abstraction
'[:FN [:cat T] U]
Then the abstraction and environment representations could be shared

Ben Sless14:12:56

Although => is pretty much that, already In its context, why do you need to tag s-vars at all? You know it's a function of type to type

Ben Sless15:12:07

You can blame someone I follow for starring your project 🙂

Eddie16:12:22

This is all great. I appreciate you taking the time to take a closer look. > Why did you choose a bespoke representation rather than use tools.analyzer output? This is the first I’m hearing of tools.analyzer :) It seems ideal for this kind of thing. I stuck to a representation that was as close to lambda calculus and Hindley–Milner as possible to make the papers easier to translate into code. The thought of expanding the bespoke representation to cover all of Clojure gave me nightmares. Tools.analyzer might save the day. > Another thing I thought of while reading the code was some impedance mismatch between the type information and the expression encoding which could be unified … > Although => is pretty much that, already Yea, figured it would be nice if everyone’s function schemas “just worked” as function types during inference without any changes, so I used :=>. I’m sure you noticed that only positional args are supported right now (via :cat). At some point I would like to try to add support for varargs. Also maybe destructuring, but that might be challenging. Still, you raise a good point about the unnecessary separation between expressions trees and type/schema trees. As you mentioned, the tagging of :var and :s-var could be eliminated. Also the logically equivalent functions like substitute-vars and substitute-types could be made into 1 generic function. I went back and forth on this design decision a couple times. In the end, my decision to separate into 2 kinds of trees was motivated by wanting more explicit information about what went wrong when debugging these algorithms. I was brand new to type theory when I started. With hindsight, I wouldn’t choose the same design. Based off of 1 mornings worth of googling, I think a change to tools.analyzer and a unified encoding is a good direction!

Ben Sless16:12:23

The only problem with tools analyzer is it has a lot of output which can get unwieldy, there are about 15 node types to parse there instead of 4

Ben Sless16:12:37

Then you might end up needing to use another method to walk the tree, either the analyzer's walk mechanism with multi methods or something like meander

Ben Sless16:12:38

If you lift the type representation to ast nodes as well you could then write your own emitter which translates it back down to a schema

Nechemya Ungar07:12:18

Hi all, I am new to clojure (using clojurescript) and I come form a static-typing background (typescript), I looked into bringing some order into the code base I got into, and malli was recommended to me over spec. I wanted to say that for newcomers like me it would have been helpful if the readme actually started with introduction of the malli provider - it really helps to create a quick scaffolding for data structures. thanks2

👍 1
amithgeorge12:12:59

In the readme, it mentions decimal? as built-in schema. Checking the relevant https://github.com/metosin/malli/blob/0.7.0/src/malli/core.cljc#L2234, decimal? is not registered as a schema. decimal? was removed in this https://github.com/metosin/malli/commit/5deae59357b2eb3fb9890282e679bb2d7fa557e3. Is it possible to add it back? At the moment I am using decimal? in a :fn schema and that works.

ikitommi15:12:23

PR welcome to add it back

👍 1
amithgeorge16:12:11

I maybe missing something here. I added decimal? to predicate-schemas. My expectation was after that evaling the file with this change, the following code should work

(validate :decimal 10.9M)
But that errors out with this message
; Execution error (ExceptionInfo) at malli.core/-fail! (core.cljc:137).
; :malli.core/invalid-schema {:schema :decimal}
For context,
(validate decimal? 10.9M)
works fine with the change. What else needs to change to support :decimal . Also, do you think this is needed?

amithgeorge16:12:35

Found it. If :decimal support is to be added, then I need to add :decimal to type-schemas . I will exclude this change for now and raise a PR for only the inclusion of decimal? .

ikitommi17:12:44

Merged, thanks!

👍 1