7 ms·

Why we're supporting Typed Clojure

212 points by pbiggar 13y ago

brudgers 13y ago
The paper behind Racket's new contract system which allows optional typing to be determined at runtime or compile time or both and across modules: http://www.eecs.northwestern.edu/~robby/pubs/papers/oopsla2012-stff.pdf http://www.eecs.northwestern.edu/~robby/pubs/papers/oopsla20...
- ambrosebs 13y ago
  That's insane.
  - bionerd 13y ago
    For a very long time I've regarded Racket as a purely educational Scheme dialect not particularly useful for real work. It was only a few months ago that I actually bothered to look at it's (amazing!) documentation [1] and realized how wrong I've been. It's incredible what are the Racket guys doing and what they've already achieved. The Typed Racket [2, 3] is "only" a cherry on top. [1] http://docs.racket-lang.org/ http://docs.racket-lang.org/ [2] The Type Racket Guide: http://docs.racket-lang.org/ts-guide/ http://docs.racket-lang.org/ts-guide/ [3] The Type Racket Reference: http://docs.racket-lang.org/ts-reference/ http://docs.racket-lang.org/ts-reference/
    - brudgers 13y ago
      What I see is that in part the transition from MZscheme to Racket has meant that a new generation of Lisp oriented academics are in PLT leadership roles - this is something Felleisen has long promoted in his own work (e.g. listing junior authors first on joint papers since everyone already knows who he is). In other words, Racket is now being driven by research into computation and the earlier generation's area of emphasis - the pedagogy of computation - is being treated as a largely solved problem. This is not to say that PLT is no longer pursuing pedagogical projects or that in the past there wasn't significant discovery and invention within computation, only that the How to Design Programs project offers a mature and battle tested framework for teaching introductory programming and there is not a lot of reason to revisit it. One of the things that attracts me to Racket - beyond the fact that it is a Lisp - is that the documentation is full stack. I was aware of the paper because there is a link within the Racket documentation of the contract system. The payoff from reading a paper that is specifically organized around the language at hand is intellectual continuity and when the language is a Lisp that continuity extends all the way from implementation to the lambda calculus.
  - brudgers 13y ago
    I suspect it is done with higher order functions in a manner analogous to what Rich Hickey has done with map and reduce here: http://www.infoq.com/presentations/Clojure-Reducers http://www.infoq.com/presentations/Clojure-Reducers
breckinloggins 13y ago
One of the best ways to get people to support optional typing in dynamic languages is to make sure their tools can read those types and provide metadata. Program verification is cool, but enabling "intellisense" on a hash is even cooler.
- pbiggar 13y ago
  Indeed. I'm hoping the IDE support will include emacs - it can already do loads of cool things connected to nrepl, but completion on a hash would be amazing.
  - seanmcdirmid 13y ago
    Does emacs support language aware intelliense (auto complete) for any language? I thought the common case was support through CTAGs.
    - rayiner 13y ago
      It does for several languages (Dylan, Common Lisp, Java, etc). If you've got a compiler with an API, like say Clang, you can talk to it from Emacs Lisp.
      - seanmcdirmid 13y ago
        How does Emacs plug into a statically typed language like Java? Does a compiler like Clang have an interactive/heuristic based mode suitable for use in a language-aware editor? Or do they just assume the code is in a good state and run the compiler when feedback is desired?
        barrkel 13y ago
        A compiler designed to support things like code completion can have an explicit API. For example, it may be asked to parse the code until the cursor location, the do a longjmp back out (or throw an exception, or whatever) with symbolic information about that location in the code. If the parser error recovery is decent (and there is some effort put into this in most substantial front ends, since it's key to good error messages in large projects with long compile times, where recompile on every error fix isn't a great experience), the code doesn't need to be in a good state.
jafaku 13y ago
> Typed Clojure is one of the biggest advancements to dynamic programming languages in the last few decades. It shows that you can have the amazing flexibility of a dynamic language, while providing lightweight, optional typing. I'm sure there have been great advances. But you are showcasing this as if it was a completely new idea, even though PHP has been using it for a long time. Correct me if I'm wrong.
- ambrosebs 13y ago
  You're correct. Sam Tobin-Hochstadt is the star of the show, and is given a mention in the article, along with his fantastic Typed Racket.
- TylerE 13y ago
  You're totally wrong. For one thing, PHP coerces WAY too much for any type system to be effective. That's just plain duck typing.
  - jafaku 13y ago
    What do you mean?
    - TylerE 13y ago
      I'd like to see your defintion of structural typing in PHP. (Hint: Not casts, not lots of manual gettype)
      - jafaku 13y ago
        I don't have a definition, I just use the thing. That's why I'm asking, I'm not a computer scientist. Eg: $f = function helloAction(Http\Request $request) { $response = new Http\Response("Hello " . $request->query->get('name'), 200); $response->setMa // at this point the IDE will show a list of methods like 'setMaxAge($time)', because it knows its type }; Now I can pass $f somewhere else, like this: $someObject->someMethod($f); And the method can accept it like this: protected method someMethod($f) {} // no checks! Or like this: protected method someMethod(\Closure $f) {} // only an argument of type Closure will be accepted. So those are types for me. If you are asking for something like this: Response $r = new Response(...); Then yeah, PHP doesn't have that. Though I don't know why we would want that, it's kind of redundant.
anaphor 13y ago
I still don't think this is worth supporting if you don't use Clojure. As far as dynamic languages go, I already use Racket quite a bit and as mentioned I can just use Typed Racket if I want, or I can use Racket's excellent contract system for some things (sparingly if I need good performance). Also I doubt it will catch on in the Python community, which is hostile to this sort of thing. JavaScript is perhaps a good use for it but there are already typed languages that run in the browser.
- ambrosebs 13y ago
  FWIW I've been pushing Typed Clojure in interesting directions that can be directly applied back to Typed Racket. The implementations are so similar that there is good potential for cross pollination.
  - anaphor 13y ago
    Fair enough, it does sound like an interesting research project, I'm just not sure what will come of it. Can you make any speculations about what those directions might be? Or is it too early? Edit: global type inference? I thought that was infeasible for TR and Clojure at the moment?
    - ambrosebs 13y ago
      Speaking speculatively, improving type inference is a great place for collaboration. Concretely, I've extended several minor ideas. Typed Clojure uses occurrence typing in sequential forms, as well as conditionals: http://frenchy64.github.io/2013/09/08/simple-reasoning-assertions-core-typed.html http://frenchy64.github.io/2013/09/08/simple-reasoning-asser... We can type check (filter identity coll) a little more accurately (which is actually quite hard to do): https://github.com/clojure/core.typed/blob/master/src/main/clojure/clojure/core/typed/base_env.clj#L729 https://github.com/clojure/core.typed/blob/master/src/main/c... The type system's interaction with Java's type system is interesting, which is something I've fleshed out. I have heterogeneous maps as well as heterogeneous vectors, and support complex operations like merge. Unsure if relevant to Racket. There are lots of other ideas which I need to implement to type check Clojure, but aren't necessarily crucial to type checking Racket, but would be nice to have.
zcrar70 13y ago
Typescript also uses 'gradual' typing. See http://siek.blogspot.co.uk/2012/10/is-typescript-gradually-typed-part-1.html http://siek.blogspot.co.uk/2012/10/is-typescript-gradually-t... - Siek is referenced in the original post, too. Clojure's type system sounds more powerful than Typescript's though.
- ambrosebs 13y ago
  AFAIK Typescript is level 1 gradual typing. Typed Clojure is also level 1, but I'm aiming for level 3. I guess Typed Clojure is more powerful than Typescript in a few ways, but it's more about how well the type system fits the language. I've never used Typescript, but it seems to fit nicely, with interesting tradeoffs.
dribnet 13y ago
Pleased to see Rich Hickey also supporting this. http://www.indiegogo.com/individuals/222990/activities http://www.indiegogo.com/individuals/222990/activities
memracom 13y ago
There is already typing in Clojure (and Python and Ruby). It`s called "100% unit test coverage". If you want it, you can have it now.
- pbiggar 13y ago
  Unit test coverage (as much as I enjoy it, since that's how CircleCI makes all its money) is good, but it can't provide the guarantees static type checking can. Each has its place, and neither replaces the other.
- steveklabnik 13y ago
  I write lots of Ruby, and I downvoted you because this isn't very constructive.
- acjohnson55 13y ago
  Can 100% unit test coverage give you intellisense, real-time warnings, and refactoring capabilities? Nope. Unit testing is great for verifying that a piece of code works conforms to specification, but typing verifies that you're using a piece of code as expected. Two different things.
- tel 13y ago
  Coverage isn't the same as enumeration of all possible modes. 100% test coverage might mean that all of your "wiring" fits together, but with dynamic languages it may not as runtime information may affect your types and break things. 100% enumeration of runtime behaviors is another property, far stronger than any non-dependent static types today, but also exponentially more difficult than 100% test coverage. Good static types are a cheap way to get probably halfway between those two on a log scale.
- mcguire 13y ago
  100% of what? The parameter value space?
heyadayo 13y ago
Check out cobra, python inspired -- it already helped developers "realize how great optional typing can be in everyday code": http://cobra-language.com/docs/why/ http://cobra-language.com/docs/why/ Great language too if you're down with .NET.
leefrank 13y ago
my friend's mother-in-law makes $76/hr on the internet. She has been fired for 9 months but last month her payment was $14190 just working on the internet for a few hours. this big57.com
pjmlp 13y ago
This is great news for Clojure. Based on my experience, dynamic languages without optional typing make large scale enterprise development unbearable. Sure, one should be writing unit tests, but in the enterprise context those tests rarely do exist, or if they do, either don't test what they should or are so complex that invalidate any re-factoring taking place.
- quatrevingts 13y ago
  Do you have any experience with the inverse statement? That is, have you had a good experience with optional types in an enterprise context? I'm curious how many runtime errors persist due to the optionality of the type system. Perhaps code standards requiring all "library" code to be typed would be a good balance.
  - pjmlp 13y ago
    Just kind of. Most enterprise customers I have worked with, favour dynamic languages just for scripting tasks, while using static typed ones for the large scale projects. By large scale, I mean, projects with at least three development sites, at least 30 developers, all the different set of skills. With lots of attrition. The only time I saw it working, was in a project done with TCL, which lacks optional types, but everyone on team was a top developer, the team was small, and located on the same open space. So startup world, not enterprise.
cabalamat 13y ago
People interested in optional types for Python may be interested in my @typ decorator that implements them: https://github.com/cabalamat/ulib/blob/master/debugdec.md https://github.com/cabalamat/ulib/blob/master/debugdec.md Sample: @typ((int,float), ret=(int,float)) def square(x): return x*x Here the parameter x is an int or float, and so is the return type. It doesn't currently let you compose types, but that wouldn't be too difficult to add, e.g. {str:int} could mean a dictionary whose keys are strings and values are integers.
- acjohnson55 13y ago
  That's okay, but that doesn't seem to help much to verify your type correctness before runtime, which seems to me to be a big part of the benefit of type checking. Also, what you'd really want is something that implements type variables like: @typ[A implements *](A, ret=A) def square(x): return x * x But I don't know how you'd do that in Python. BTW, your printargs looks pretty cool! I might just makes something like that for JS...
  - cabalamat 13y ago
    > that doesn't seem to help much to verify your type correctness before runtime I don't think that's possible in Python. > Also, what you'd really want is something that implements type variables That is possible, you could check what the type of the incoming parameter is and then check that the return value is the same type. I'm not sure that there's an obvious syntax for saying this, but one could always send a string to @typ and have it parse some made-up syntax. I suspect this would be a lot of effort and it would probably make sens to use a typed language, instead of trying to shoehorn it into Python. I invented @typ so I could quickly document the types in my functions, & with the added advantage that it catches some errors. > your printargs looks pretty cool! I might just makes something like that for JS... I look forward to seeing it.
LindaWell 13y ago
my Aunty Paige just got an awesome yellow Nissan Rogue SUV by working part time from a home computer... find more information................http://redir.ec/buzz55 http://redir.ec/buzz55
dep_b 13y ago
There one thing that really stirred my interest: nil isn’t allowed If this really is what I think it is (a certain reference to a class can never be nil) then I am really excited. It never made sense to me that someone was able to call a function I wrote that really needed instances with nils instead, so I was forced to check and throw in case they did. It's just not clear and it leads to a lot of unnecessary checking or nil pointer exceptions.
- ambrosebs 13y ago
  nil is explicit in Typed Clojure, and it's a goal to statically avoid misuses of nil. This rough screencast describes on aspect to the approach http://vimeo.com/55280915 http://vimeo.com/55280915
mseebach 13y ago
An introduction to typed clojure (strangely missing from both the blog post and the IndieGoGo campaign): http://www.clojure.net/2013/03/14/Typed-Clojure/ http://www.clojure.net/2013/03/14/Typed-Clojure/
draegtun 13y ago
Perl6 & Rebol are some other examples of dynamic languages which come with optional typing. NB. And I believe Perl6 in certain cases will/can raise compile-time type errors.
wcummings 13y ago
This guy is a little too souped on optional type-checking. This has existed in erlang for years, in the form of dialyzer (which allows for compile time validation of complex nested data structures), and in any dynamic language a good developer is using pre-checks & post-checks (in the case of js) or a combination of tagged values and pattern matching to ensure type-checking at runtime. It's a nice feature, but calling it "one of the biggest advancements to dynamic programming languages in the last few decades" is ignorant.
- pbiggar 13y ago
  OP here. I do actually believe what I said. Pre- and post-checks are of course possible, but I've rarely seen them used in practice. More importantly, they can't be used to provide any sort of correctness guarantee, which static typing can. I'm not sure what you mean by tagged values and pattern matching - I know what those concepts are, but I think you're saying they're widely used by good developers? I have not seen evidence for this. The reason I call it one of the biggest advancements is that it is actually being used in production, has low overhead (both in cognitive load and performance-wise), and actually handles the complexities of duck-typing. It shows that it is practical. (By contrast, Erlang is sufficiently different to most other dynamic languages, both in use case and semantics, that it is difficult to generalize from Erlang to say Python).
  - wcummings 13y ago
    >Pre- and post-checks are of course possible, but I've rarely seen them used in practice. I agree, I wish more people (especially Javascript developers) saw the value of pre (and post!) checking. >The reason I call it one of the biggest advancements is that it is actually being used in production, has low overhead (both in cognitive load and performance-wise), and actually handles the complexities of duck-typing. It shows that it is practical. (By contrast, Erlang is sufficiently different to most other dynamic languages, both in use case and semantics, that it is difficult to generalize from Erlang to say Python). This is fair, I just meant to point out that conceptually this isn't new, it's just a new implementation. Can you expand a bit on what you said about duck-typing?

212 points by pbiggar 13y ago

The paper behind Racket's new contract system which allows optional typing to be determined at runtime or compile time or both and across modules: http://www.eecs.northwestern.edu/~robby/pubs/papers/oopsla2012-stff.pdf http://www.eecs.northwestern.edu/~robby/pubs/papers/oopsla20...

ambrosebs 13y ago
That's insane.
- bionerd 13y ago
  For a very long time I've regarded Racket as a purely educational Scheme dialect not particularly useful for real work. It was only a few months ago that I actually bothered to look at it's (amazing!) documentation [1] and realized how wrong I've been. It's incredible what are the Racket guys doing and what they've already achieved. The Typed Racket [2, 3] is "only" a cherry on top. [1] http://docs.racket-lang.org/ http://docs.racket-lang.org/ [2] The Type Racket Guide: http://docs.racket-lang.org/ts-guide/ http://docs.racket-lang.org/ts-guide/ [3] The Type Racket Reference: http://docs.racket-lang.org/ts-reference/ http://docs.racket-lang.org/ts-reference/
  - brudgers 13y ago
    What I see is that in part the transition from MZscheme to Racket has meant that a new generation of Lisp oriented academics are in PLT leadership roles - this is something Felleisen has long promoted in his own work (e.g. listing junior authors first on joint papers since everyone already knows who he is). In other words, Racket is now being driven by research into computation and the earlier generation's area of emphasis - the pedagogy of computation - is being treated as a largely solved problem. This is not to say that PLT is no longer pursuing pedagogical projects or that in the past there wasn't significant discovery and invention within computation, only that the How to Design Programs project offers a mature and battle tested framework for teaching introductory programming and there is not a lot of reason to revisit it. One of the things that attracts me to Racket - beyond the fact that it is a Lisp - is that the documentation is full stack. I was aware of the paper because there is a link within the Racket documentation of the contract system. The payoff from reading a paper that is specifically organized around the language at hand is intellectual continuity and when the language is a Lisp that continuity extends all the way from implementation to the lambda calculus.
- brudgers 13y ago
  I suspect it is done with higher order functions in a manner analogous to what Rich Hickey has done with map and reduce here: http://www.infoq.com/presentations/Clojure-Reducers http://www.infoq.com/presentations/Clojure-Reducers

breckinloggins 13y ago

One of the best ways to get people to support optional typing in dynamic languages is to make sure their tools can read those types and provide metadata. Program verification is cool, but enabling "intellisense" on a hash is even cooler.

pbiggar 13y ago
Indeed. I'm hoping the IDE support will include emacs - it can already do loads of cool things connected to nrepl, but completion on a hash would be amazing.
- seanmcdirmid 13y ago
  Does emacs support language aware intelliense (auto complete) for any language? I thought the common case was support through CTAGs.
  - rayiner 13y ago
    It does for several languages (Dylan, Common Lisp, Java, etc). If you've got a compiler with an API, like say Clang, you can talk to it from Emacs Lisp.
    - seanmcdirmid 13y ago
      How does Emacs plug into a statically typed language like Java? Does a compiler like Clang have an interactive/heuristic based mode suitable for use in a language-aware editor? Or do they just assume the code is in a good state and run the compiler when feedback is desired?
      - barrkel 13y ago
        A compiler designed to support things like code completion can have an explicit API. For example, it may be asked to parse the code until the cursor location, the do a longjmp back out (or throw an exception, or whatever) with symbolic information about that location in the code. If the parser error recovery is decent (and there is some effort put into this in most substantial front ends, since it's key to good error messages in large projects with long compile times, where recompile on every error fix isn't a great experience), the code doesn't need to be in a good state.

jafaku 13y ago

> Typed Clojure is one of the biggest advancements to dynamic programming languages in the last few decades. It shows that you can have the amazing flexibility of a dynamic language, while providing lightweight, optional typing. I'm sure there have been great advances. But you are showcasing this as if it was a completely new idea, even though PHP has been using it for a long time. Correct me if I'm wrong.

ambrosebs 13y ago
You're correct. Sam Tobin-Hochstadt is the star of the show, and is given a mention in the article, along with his fantastic Typed Racket.
TylerE 13y ago
You're totally wrong. For one thing, PHP coerces WAY too much for any type system to be effective. That's just plain duck typing.
- jafaku 13y ago
  What do you mean?
  - TylerE 13y ago
    I'd like to see your defintion of structural typing in PHP. (Hint: Not casts, not lots of manual gettype)
    - jafaku 13y ago
      I don't have a definition, I just use the thing. That's why I'm asking, I'm not a computer scientist. Eg: $f = function helloAction(Http\Request $request) { $response = new Http\Response("Hello " . $request->query->get('name'), 200); $response->setMa // at this point the IDE will show a list of methods like 'setMaxAge($time)', because it knows its type }; Now I can pass $f somewhere else, like this: $someObject->someMethod($f); And the method can accept it like this: protected method someMethod($f) {} // no checks! Or like this: protected method someMethod(\Closure $f) {} // only an argument of type Closure will be accepted. So those are types for me. If you are asking for something like this: Response $r = new Response(...); Then yeah, PHP doesn't have that. Though I don't know why we would want that, it's kind of redundant.

anaphor 13y ago

I still don't think this is worth supporting if you don't use Clojure. As far as dynamic languages go, I already use Racket quite a bit and as mentioned I can just use Typed Racket if I want, or I can use Racket's excellent contract system for some things (sparingly if I need good performance). Also I doubt it will catch on in the Python community, which is hostile to this sort of thing. JavaScript is perhaps a good use for it but there are already typed languages that run in the browser.

ambrosebs 13y ago
FWIW I've been pushing Typed Clojure in interesting directions that can be directly applied back to Typed Racket. The implementations are so similar that there is good potential for cross pollination.
- anaphor 13y ago
  Fair enough, it does sound like an interesting research project, I'm just not sure what will come of it. Can you make any speculations about what those directions might be? Or is it too early? Edit: global type inference? I thought that was infeasible for TR and Clojure at the moment?
  - ambrosebs 13y ago
    Speaking speculatively, improving type inference is a great place for collaboration. Concretely, I've extended several minor ideas. Typed Clojure uses occurrence typing in sequential forms, as well as conditionals: http://frenchy64.github.io/2013/09/08/simple-reasoning-assertions-core-typed.html http://frenchy64.github.io/2013/09/08/simple-reasoning-asser... We can type check (filter identity coll) a little more accurately (which is actually quite hard to do): https://github.com/clojure/core.typed/blob/master/src/main/clojure/clojure/core/typed/base_env.clj#L729 https://github.com/clojure/core.typed/blob/master/src/main/c... The type system's interaction with Java's type system is interesting, which is something I've fleshed out. I have heterogeneous maps as well as heterogeneous vectors, and support complex operations like merge. Unsure if relevant to Racket. There are lots of other ideas which I need to implement to type check Clojure, but aren't necessarily crucial to type checking Racket, but would be nice to have.

zcrar70 13y ago

Typescript also uses 'gradual' typing. See http://siek.blogspot.co.uk/2012/10/is-typescript-gradually-typed-part-1.html http://siek.blogspot.co.uk/2012/10/is-typescript-gradually-t... - Siek is referenced in the original post, too. Clojure's type system sounds more powerful than Typescript's though.

ambrosebs 13y ago
AFAIK Typescript is level 1 gradual typing. Typed Clojure is also level 1, but I'm aiming for level 3. I guess Typed Clojure is more powerful than Typescript in a few ways, but it's more about how well the type system fits the language. I've never used Typescript, but it seems to fit nicely, with interesting tradeoffs.

dribnet 13y ago

Pleased to see Rich Hickey also supporting this. http://www.indiegogo.com/individuals/222990/activities http://www.indiegogo.com/individuals/222990/activities

memracom 13y ago

There is already typing in Clojure (and Python and Ruby). It`s called "100% unit test coverage". If you want it, you can have it now.

pbiggar 13y ago
Unit test coverage (as much as I enjoy it, since that's how CircleCI makes all its money) is good, but it can't provide the guarantees static type checking can. Each has its place, and neither replaces the other.
steveklabnik 13y ago
I write lots of Ruby, and I downvoted you because this isn't very constructive.
acjohnson55 13y ago
Can 100% unit test coverage give you intellisense, real-time warnings, and refactoring capabilities? Nope. Unit testing is great for verifying that a piece of code works conforms to specification, but typing verifies that you're using a piece of code as expected. Two different things.
tel 13y ago
Coverage isn't the same as enumeration of all possible modes. 100% test coverage might mean that all of your "wiring" fits together, but with dynamic languages it may not as runtime information may affect your types and break things. 100% enumeration of runtime behaviors is another property, far stronger than any non-dependent static types today, but also exponentially more difficult than 100% test coverage. Good static types are a cheap way to get probably halfway between those two on a log scale.
mcguire 13y ago
100% of what? The parameter value space?

heyadayo 13y ago

Check out cobra, python inspired -- it already helped developers "realize how great optional typing can be in everyday code": http://cobra-language.com/docs/why/ http://cobra-language.com/docs/why/ Great language too if you're down with .NET.

leefrank 13y ago

my friend's mother-in-law makes $76/hr on the internet. She has been fired for 9 months but last month her payment was $14190 just working on the internet for a few hours. this big57.com

pjmlp 13y ago

This is great news for Clojure. Based on my experience, dynamic languages without optional typing make large scale enterprise development unbearable. Sure, one should be writing unit tests, but in the enterprise context those tests rarely do exist, or if they do, either don't test what they should or are so complex that invalidate any re-factoring taking place.

quatrevingts 13y ago
Do you have any experience with the inverse statement? That is, have you had a good experience with optional types in an enterprise context? I'm curious how many runtime errors persist due to the optionality of the type system. Perhaps code standards requiring all "library" code to be typed would be a good balance.
- pjmlp 13y ago
  Just kind of. Most enterprise customers I have worked with, favour dynamic languages just for scripting tasks, while using static typed ones for the large scale projects. By large scale, I mean, projects with at least three development sites, at least 30 developers, all the different set of skills. With lots of attrition. The only time I saw it working, was in a project done with TCL, which lacks optional types, but everyone on team was a top developer, the team was small, and located on the same open space. So startup world, not enterprise.

cabalamat 13y ago

People interested in optional types for Python may be interested in my @typ decorator that implements them: https://github.com/cabalamat/ulib/blob/master/debugdec.md https://github.com/cabalamat/ulib/blob/master/debugdec.md Sample: @typ((int,float), ret=(int,float)) def square(x): return x*x Here the parameter x is an int or float, and so is the return type. It doesn't currently let you compose types, but that wouldn't be too difficult to add, e.g. {str:int} could mean a dictionary whose keys are strings and values are integers.

acjohnson55 13y ago
That's okay, but that doesn't seem to help much to verify your type correctness before runtime, which seems to me to be a big part of the benefit of type checking. Also, what you'd really want is something that implements type variables like: @typ[A implements *](A, ret=A) def square(x): return x * x But I don't know how you'd do that in Python. BTW, your printargs looks pretty cool! I might just makes something like that for JS...
- cabalamat 13y ago
  > that doesn't seem to help much to verify your type correctness before runtime I don't think that's possible in Python. > Also, what you'd really want is something that implements type variables That is possible, you could check what the type of the incoming parameter is and then check that the return value is the same type. I'm not sure that there's an obvious syntax for saying this, but one could always send a string to @typ and have it parse some made-up syntax. I suspect this would be a lot of effort and it would probably make sens to use a typed language, instead of trying to shoehorn it into Python. I invented @typ so I could quickly document the types in my functions, & with the added advantage that it catches some errors. > your printargs looks pretty cool! I might just makes something like that for JS... I look forward to seeing it.

LindaWell 13y ago

my Aunty Paige just got an awesome yellow Nissan Rogue SUV by working part time from a home computer... find more information................http://redir.ec/buzz55 http://redir.ec/buzz55

dep_b 13y ago

There one thing that really stirred my interest: nil isn’t allowed If this really is what I think it is (a certain reference to a class can never be nil) then I am really excited. It never made sense to me that someone was able to call a function I wrote that really needed instances with nils instead, so I was forced to check and throw in case they did. It's just not clear and it leads to a lot of unnecessary checking or nil pointer exceptions.

ambrosebs 13y ago
nil is explicit in Typed Clojure, and it's a goal to statically avoid misuses of nil. This rough screencast describes on aspect to the approach http://vimeo.com/55280915 http://vimeo.com/55280915

mseebach 13y ago

An introduction to typed clojure (strangely missing from both the blog post and the IndieGoGo campaign): http://www.clojure.net/2013/03/14/Typed-Clojure/ http://www.clojure.net/2013/03/14/Typed-Clojure/

draegtun 13y ago

Perl6 & Rebol are some other examples of dynamic languages which come with optional typing. NB. And I believe Perl6 in certain cases will/can raise compile-time type errors.

wcummings 13y ago

This guy is a little too souped on optional type-checking. This has existed in erlang for years, in the form of dialyzer (which allows for compile time validation of complex nested data structures), and in any dynamic language a good developer is using pre-checks & post-checks (in the case of js) or a combination of tagged values and pattern matching to ensure type-checking at runtime. It's a nice feature, but calling it "one of the biggest advancements to dynamic programming languages in the last few decades" is ignorant.

pbiggar 13y ago
OP here. I do actually believe what I said. Pre- and post-checks are of course possible, but I've rarely seen them used in practice. More importantly, they can't be used to provide any sort of correctness guarantee, which static typing can. I'm not sure what you mean by tagged values and pattern matching - I know what those concepts are, but I think you're saying they're widely used by good developers? I have not seen evidence for this. The reason I call it one of the biggest advancements is that it is actually being used in production, has low overhead (both in cognitive load and performance-wise), and actually handles the complexities of duck-typing. It shows that it is practical. (By contrast, Erlang is sufficiently different to most other dynamic languages, both in use case and semantics, that it is difficult to generalize from Erlang to say Python).
- wcummings 13y ago
  >Pre- and post-checks are of course possible, but I've rarely seen them used in practice. I agree, I wish more people (especially Javascript developers) saw the value of pre (and post!) checking. >The reason I call it one of the biggest advancements is that it is actually being used in production, has low overhead (both in cognitive load and performance-wise), and actually handles the complexities of duck-typing. It shows that it is practical. (By contrast, Erlang is sufficiently different to most other dynamic languages, both in use case and semantics, that it is difficult to generalize from Erlang to say Python). This is fair, I just meant to point out that conceptually this isn't new, it's just a new implementation. Can you expand a bit on what you said about duck-typing?