a blog post

[Chris Cannam]

A personal blog post with something about Yeti, if anyone is interested:

http://thebreakfastpost.com/2013/01/08/functional-programming-and-the-joy-of-learning-something-again/

Do let me know if you spot any mistakes (likely, given my recent record).


Chris

[Christian Essl]

That's realy a great blogpost. Congratulations

[Madis Janson]

On the long errors part - writing typedefs often helps when the code has
complicated types. The compiler tries to replace matching parts of types
in error messages with the typedef names, whenever possible. It also tries
to omit parts of types that are not involved in the error.

I'm partially commenting because the initial naive error reporting that
the compiler once had was really quite terrible - competing with the C++
templates by spitting out error message consisting of types that filled
few pages of terminal window (and then stating that too bad, those types
don't match). So the HM inference has a potential for awful error
messages, but fortunately it's (mostly) curable disease here.

Another thing that helps is localizing type errors by declaring top-level
function types.

Both of these things can be done later than initially writing code. I've
sometimes written first "prototype" implementation without any type
declarations and then later converted it into "real" code by adding
declarations where it seems useful (to make it easier to maintain and
understand).

--
Reading or distributing any bit from this message is strongly prohibited.

[Chris Cannam]

On 8 January 2013 17:32, Madis Janson <ma...@cyber.ee> wrote:
> On the long errors part - writing typedefs often helps when the code has
> complicated types. The compiler tries to replace matching parts of types in
> error messages with the typedef names, whenever possible.

Ah, OK, I should look at those.

I have used opaque typedefs with some success for (surprise!) opaque
types, but I haven't really played with "transparent" typedefs yet.

One problem I had with typedefs is that it's not easy to experiment
with them in the repl:

> typedef t = number
> 1 as t
1:5: Unknown type: t

i.e. they go out of scope after each set of local bindings. And

> typedef t = number ; 1 as t
1 is number

(So did that typedef achieve anything? As opposed to an opaque typedef
where the result here is obvious)

Not sure whether there's anything to be done about this, just remarking on it.


Chris

[Madis]

On Tue, 8 Jan 2013, Chris Cannam wrote:

> On 8 January 2013 17:32, Madis Janson <ma...@cyber.ee> wrote:
>> On the long errors part - writing typedefs often helps when the code has
>> complicated types. The compiler tries to replace matching parts of types in
>> error messages with the typedef names, whenever possible.
>
> Ah, OK, I should look at those.
>
> I have used opaque typedefs with some success for (surprise!) opaque
> types, but I haven't really played with "transparent" typedefs yet.
>
> One problem I had with typedefs is that it's not easy to experiment
> with them in the repl:
>
>> typedef t = number
>> 1 as t
> 1:5: Unknown type: t

Yes, there is TODO entry about typedefs in REPL.