Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why we're supporting Typed Clojure

blog.circleci.com

Post reply on HN
Print view View original

41–50 of 77 posts

Re: Why we're supporting Typed Clojure

#41

Post by tel »

jafaku wrote: post #37
TylerE wrote: post #22

Earlier quoted context omitted.

I'd like to see your defintion of structural typing in PHP. (Hint: Not casts, not lots of manual gettype)

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->some…

The redundancy can be alleviated by type inference, but it's also kind of nice. The 'Response' on the left is your expectation about what $r is, while the one on the right is your implementation of that expectation. The separation is very important.

Of course, in this example, it's silly and type inference would be used to ensure that you don't need to write the left side.

The advantage is that before running your code you can suss out much greater degrees of what your code "could possibly mean". The \Closure bit is a start, but it needs to fail prior to running to be statically typed. It also could potentially include much more information like (\Closure[Http\Request -> Http\Response]) and reject even more bad arguments.

Re: Why we're supporting Typed Clojure

#42

Post by barrkel »

seanmcdirmid wrote: post #36
rayiner wrote: post #33

Earlier quoted context omitted.

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.

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?

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.

Re: Why we're supporting Typed Clojure

#43

Post by seanmcdirmid »

barrkel wrote: post #42
seanmcdirmid wrote: post #36

Earlier quoted context omitted.

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?

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…

That might work...but does it work in practice (i.e. do you have an example where this is being used?).

I've found that most IDEs support two kinds of compilers: the compiler used to generate code and find type errors, and a "presentation" compiler to provide interactive feedback that is error tolerant and can run in incomplete contexts. Java works this way, Scala worked this way (at least when I was working on the plugin), C# has a lot of infrastructure separate from the compiler to support its use in Visual Studio. A lot of work goes into this infrastructure beyond "writing a decent compiler," and emacs very simple language-aware interface didn't seem to support it very well (when I looked ~8 years ago).

Re: Why we're supporting Typed Clojure

#45

Post by tikhonj »

seanmcdirmid wrote: post #30
pbiggar wrote: post #4

Earlier quoted context omitted.

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.

Does emacs support language aware intelliense (auto complete) for any language? I thought the common case was support through CTAGs.

I know of two modes for OCaml: TypeRex[1] and Merlin[2]. I've used both, and they both work reasonably well. The problem with TypeRex is that it requires changing your build, so it's not an easy option for companies that have some sort of custom build system in place.

Happily, by the time I got around to working at a company like that, somebody had written Merlin which does not need anything like that. It even worked with js_of_ocaml, which was very impressive. I thought it was a very good tool.

[1]: http://www.typerex.org/

[2]: http://kiwi.iuwt.fr/~asmanur/blog/merlin/

Emacs also has good support for a few other languages. Haskell has ghc-mod[3] and scion[4], for example.

[3]: http://www.mew.org/~kazu/proj/ghc-mod/en/

[4]: https://github.com/nominolo/scion

Similarly, there is ENSIME[5] for Scala.

[5]: https://github.com/aemoncannon/ensime

You can also use eclim[6] with Emacs, which integrates with Eclipse to offer rich functionality for Java.

[6]: https://github.com/senny/emacs-eclim

Of course, Emacs has language-aware editing for Emacs Lisp by default :). You can get similar support for most other popular dynamically typed languages as well.

So yes, Emacs does support plenty of languages like that, although almost always through a plugin. Happily, with the new package manager, installing and managing plugins is now trivial.

Re: Why we're supporting Typed Clojure

#46

Post by moomin »

ambrosebs wrote: post #28
anaphor wrote: post #27

Earlier quoted context omitted.

One of the TR maintainers (samth?) told me on IRC a while ago that it is very infeasible to do global type inference (top level) for TR. So I'm not sure how much you could get done in so short a time.

Yep that's correct. I want a tool that infers a rough approximation of top-levels to accelerate the process of porting untyped code to be typed. The programmer would inspect the annotations manually and fix any inaccurate ones, and then run the type checker.

I'm far from an expert on this, but F# has no requirement for all forms to be explicitly typed, so I'm a bit puzzled as to why this is hard.

Re: Why we're supporting Typed Clojure

#47

Post by pjmlp »

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.

Re: Why we're supporting Typed Clojure

#48

Post by cabalamat »

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

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.

Re: Why we're supporting Typed Clojure

#49

Post by ambrosebs »

moomin wrote: post #46
ambrosebs wrote: post #28

Earlier quoted context omitted.

Yep that's correct. I want a tool that infers a rough approximation of top-levels to accelerate the process of porting untyped code to be typed. The programmer would inspect the annotations manually and fix any inaccurate ones, and then run the type checker.

I'm far from an expert on this, but F# has no requirement for all forms to be explicitly typed, so I'm a bit puzzled as to why this is hard.

Typed Clojure's type system is too rich to avoid top-level annotations. It's a similar situation to Scala.
Post reply on HN