
Idris 1.0 - insulanian
https://www.idris-lang.org/idris-1-0-released/
======
Y_Y
For anyone wondering what Idris is, it's pretty much Haskell with dependent
types. That is, it's easy to encode thing like "vector of length n" in the
type system, so you can go from concat :: Vec -> Vec -> Vec to concat : Vec n
-> Vec m -> Vec (n+m).

~~~
CJefferson
Yes, but it turns out you can do some cool things with dependent types.

I always felt, as a C++ programmer, that Haskell was just restricting me,
without providing me any real benefits (of course, other people's opinion can
vary!) -- on the other hand, Idris provides tools I can see as useful, things
like checking at compile time all file handles are correctly opened before
use, and closed after use (that's a very simple example, but just one type of
thing you can do)

~~~
Too
C++ (if not used as C with classes) is built around RAII and will also enforce
file handles to be opened before use and automatically closed when leaving
scope (no longer in use).

See
[https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rp-
leak)

~~~
lkitching
This isn't the same thing - Idris encodes the state machine in the type
system, C++ enforces it dynamically.

~~~
Too
Now std::ifstream isn't 100% idiomatic RAII (because constructor sets error
state instead of throwing and it also provides open/close-methods) but
generally you should be able to encode a safe file handle into the c++ type
system. Here is how i would compare it to what idris describes in
[https://media.readthedocs.org/pdf/idris/latest/idris.pdf](https://media.readthedocs.org/pdf/idris/latest/idris.pdf)

    
    
        * It is necessary to open a file for reading before reading it 
          > Enforced by RAII, create file handle(variable) is equivalent to opening file
        * Opening may fail, so the programmer should check whether opening was successful 
          > If opening file fails, exception is thrown when the handle is created, it is impossible to create/use an unopened handle. 
        * A file which is open for reading must not be written to, and vice versa 
          > Can be enforced with different types for reading and writing (ifstream vs ofstream). 
        * When finished, an open file handle should be closed  
          >  fstream is automatically closed when variable goes out of scope.
        * When a file is closed, its handle should no longer be used 
          > Here it's actually the other way around, the correct way to close a file is to get rid of the last handle refering to it. 
          > Hence a handle can't be used to write to a closed file since such a handle cannot exist in the first place.

~~~
lmm
> If opening file fails, exception is thrown when the handle is created, it is
> impossible to create/use an unopened handle.

Unfortunately C++ offers no way to track which exceptions any given function
might throw and/or enforce that they are handled.

> fstream is automatically closed when variable goes out of scope.

That works for the simple case where the variable exists on the stack of a
single function. C++ does not offer safety in the general case where you pass
a handle to/from functions, store it in data structures and so on. (You have
the option of runtime checks via shared_ptr etc, but at that point you have
very little assurance the file ever actually gets closed).

~~~
Too
Checked exceptions would be neat but still, if you don't catch the exception
it will be propagated further up the chain, so the claim that it is impossible
to create an unopened file handle still holds :)

Yes, object lifetime management is not provably safe in c++, due to lack of
borrow checker, but that's a general problem for all types of objects, not
specifically file management.

~~~
lmm
> Checked exceptions would be neat but still, if you don't catch the exception
> it will be propagated further up the chain, so the claim that it is
> impossible to create an unopened file handle still holds :)

True, but introducing invisible partiality to essentially all functions is a
pretty stiff cost.

> Yes, object lifetime management is not provably safe in c++, due to lack of
> borrow checker, but that's a general problem for all types of objects, not
> specifically file management.

Well, that's a question of language design philosophy. Object management is so
much more frequent than any other kind of resource management that it may be
worth treating as a special case, as most languages other than C++ do.

Be that as it may, the point is that the really cool thing about Idris is that
its type system is powerful enough to let you implement borrow-checker-like
functionality in "userspace" rather than needing it built into the language.
In theory one could use that (in an Idris-like language with a different
record feature, standard library and so on) to have Rust-style manual-but-safe
memory management for all objects, though I suspect that might be too
cumbersome to be practical.

------
david-given
Hey, this is out of the University of St.Andrews! I went there!

During my time they were a big Haskell shop, working with Glasgow University
(the G in ghc). There were also into custom research languages that nobody's
ever heard of like Napier and, erm, S-Algol (again with Glasgow; the S stands
for 'Scottish')...

I see that Idris generates real machine code. I see it goes through LLVM, so
the code quality should be decent; but I see a reference that the binary needs
to know where the compiler is, which makes me a bit worried about the needed
dependencies.

Additionally, apart from the dependent types, does Idris fix some of the
annoyances with Haskell --- modules, namespacing, field access, _shudder_
strings?

~~~
infinisil
Yes!

\- Idris' `String` type is _not_ just a list of characters, here [1] you can
see some relevant functions, I'm still trying to find the definition of
`String` though.

\- Functions can be overloaded in Idris, which enables declaring a field with
the same name on different records.

I'm not sure what you mean with modules and namespacing though

[1] [https://www.idris-
lang.org/docs/current/prelude_doc/docs/Pre...](https://www.idris-
lang.org/docs/current/prelude_doc/docs/Prelude.Strings.html)

~~~
efnx
Idris has namespacing instead of modules, which is great and allows for things
like locally scoped data declarations

------
gregwebs
The linked book has a freely available chapter 13 available that shows how to
create state machines with dependent types. Of course its easy in any
language, but with Idris you can ensure at compile time that all state
transitions in a program are valid.

[https://www.manning.com/books/type-driven-development-
with-i...](https://www.manning.com/books/type-driven-development-with-
idris#downloads)

~~~
dmix
The book just came out yesterday (March 31, 2017) too. It was a great idea to
time it with the release of 1.0:

[https://www.amazon.com/Type-driven-Development-Idris-
Edwin-B...](https://www.amazon.com/Type-driven-Development-Idris-Edwin-
Brady/dp/1617293024/)

I'd love to see another Haskell-esque language get mainstream adoption.
Especially one pushing programming in a new direction.

I love types, I just haven't had the chance to use Haskell in anything but toy
applications, the learning curve was very steep but so far rewarding, and led
me to miss it in when using the type system hacked onto Erlang/Elixir which is
(obviously) lacking as a result. Although still a step forward over other
languages. Looking forward to trying out Idris.

Edit: just noticed there's no Kindle version (yet?), that's too bad :(. Maybe
MEAP has a licensing deal to exclusively sell the digital versions?

~~~
gbersac
That's what happen for every Manning publication. Only the paperback version
is available on amazon. On the other hand, if you buy it on manning, you'll
get a pdf and an epub version.

~~~
zcoyle
They give you a mobi version as well.

------
ekidd
Congratulations on the big milestone! This really appeals to the same part of
my brain that likes (to varying degrees) Haskell, Rust and TypeScript.

Can Idris be used as a Coq-style "proof assistant"? From reading
[http://docs.idris-lang.org/en/latest/reference/elaborator-
re...](http://docs.idris-lang.org/en/latest/reference/elaborator-
reflection.html) , it looks like there was an older proof system that has
recently been replaced by something new, and I can't tell if Idris can still
be used as Coq replacement. Are there good tutorials on this?

EDIT: It seems like yes, it can be used for proofs? [http://docs.idris-
lang.org/en/latest/tutorial/theorems.html](http://docs.idris-
lang.org/en/latest/tutorial/theorems.html)

~~~
efnx
Yes, as far as I know it can be used for proofs - not having used it for
proofs myself I can't say much more

------
Entangled
Look guys, I love to see new languages every single day, I am a fan of
language design but for the love of god, can you post at least a HelloWorld
program in the front page?

And while we're at it, add some arrays, dictionaries and objects in a couple
more code examples. That's all we ask for.

Thanks and kudos!

~~~
eastWestMath
Did you not look at the examples section, the documentation, the tutorial, or
notice that there's a several-hundred page book on software development in
Idris? There's no shortage of code examples.

------
pjdorrell
My understanding of the promise of Idris is that anything you _want_ to put
into the type definitions for your application, you _can_ put into the type
definitions.

~~~
codygman
I've toyed around with using this example:

Imagine C++ template programming with C++ syntax, sane error messages, and
ability to use _any_ C++ code.

