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])

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.