Clojurians Log v2
ghostwheel
Heads up: I had a chat with Alex Miller and he indicated that fspec syntax is likely to change soon as they resume work on spec. I asked him if the [int? => int?] notation was likely to be easy to still translate and he seemed to think so. I guess we’ll find out, but something to keep in mind when adding additional notation.
I’m also interested in potentially adding “type variables” to this notation for static analysis support, which I’m playing with. For example:
(>defn first [s]
[any? a, (s/coll-of a) => a]), is whitespace, so I’m certain this isn’t the exact notation, but the idea is it would be nice to know that the any? on both sides of the type equation are the same. But if we had that little bit of info added in we can do some pretty fancy static analysis.
Haskell uses lookup :: Eq a => [(a, b)] -> a -> b, so perhaps it is just a diff arrow for ours? Could get kind of crazy looking if we’re throwing in => <- ==> << and all manner of mess, but it would be cool to have a standard among projects.or at least something that doesn’t directly interfere
(>defn first [s]
^{:a any?} [(s/coll-of :a) => :a])might fit the bill better, and definitely does not interfere. It also might make sense to put gen there as well, since that eliminates the need for more potentially-confusing notation
I think George’s gspec notation is quite good as-is
@tony.kay Thanks for the heads up re possible fspec changes. Re gspec – having a standard here would definitely be fantastic, even if multiple tooling projects emerge to do different things with the information. If it becomes popular enough, I could imagine getting Cursive and CIDER on board to support some related IDE magic as well. Regarding parametric polymorphism / type variables – that's been pretty high on the list of things to think about for a while now, as it's definitely one of the bigger holes in terms of what we can do with spec vs. a proper static type system. I'll give this more thought over the coming days/weeks. Generally speaking, I'd like any changes to be backwards-compatible if possible, but not at the cost of a worse syntax. Considering the still experimental / in-flux status of Ghostwheel/gspec, I think a breaking change would be perfectly acceptable if it happens for a good reason. So far I've been pretty happy with the syntax, I feel it fits the goal of being "as simple as possible but not simpler" pretty well, but there's definitely room for extension / improvement. I'd like any changes to the notation to happen with lots of community feedback, as I believe this significantly increases the chances of a standard emerging rather than 5 slightly different and somewhat compatible forks.