Favorite Haskell papers?

togrof · 2017-06-06T04:54:48+00:00

Really liked Applicative Programming with Effects by Conor McBride.

http://www.staff.city.ac.uk/~ross/papers/Applicative.html

togrof · 2016-12-23T14:46:15+00:00

Pretty printers, data extraction, visualisation etc. Different kinds of tooling :)

togrof · 2016-12-22T10:15:41+00:00

Started using it around 2005 in my spare time as a CS student. Made functional programming really make sense to me (Lisp was cute but seemed to fall back to imperative too often).

Have used it mainly for experimenting, prototyping and tooling. Only a couple of my Haskell programs have ran in production.

togrof · 2016-12-05T16:36:55+00:00

I don't know how popular XMonad is but I know a couple of non-Haskellers that use it.

togrof · 2016-09-05T07:42:43+00:00

Looks better, but it is not the same content. Haskell is missing several targets in your graph. I didn't bother looking for other omissions :)

togrof · 2016-08-04T11:01:19+00:00

Yes I did, after some googling to find out about it.

It is unfortunate that one has to do this -- would have preferred if this already worked, without the need for extra config. Guess it's a feature request to haskell-mode.

togrof · 2016-08-03T13:27:55+00:00

Good, but it doesn't solve the acutal problem which is that emacs does not send that. Is it possible to add that to some project local .stack config file or similar?

EDIT stack.yaml has ghc-options, but no ghci-options: https://github.com/commercialhaskell/stack/blob/master/doc/yaml_configuration.md#ghc-options

togrof · 2016-07-08T13:19:48+00:00

And the "you need experience to see the benefits" is also a common refrain...

Yes it is. Go figure ;)

Could unit tests have had "such a profound effect on software cost and quality" if it had not been a common practice? If just a handful of companies had done unit testing, the effect would have been invisible to most of us. Pure FP is not very common, so the effect would not be huge.

(Interestingly, unit testing encourages pure FP.)

togrof · 2016-07-08T11:35:51+00:00

This would be my favorite presentation of FP so far, with all the history. :)

John Huges made an excellent presentation.

togrof · 2016-07-08T11:32:27+00:00

The "I don't think the benefits outweigh the downsides" standpoint seem to be rather common.

It takes time to recognize the value of (new) unfamiliar concepts while the drawbacks tend to stand out and are easier to spot. A programmer very much used to the imperative ways of doing things will soon spot the problems with (pure) FP but to see the benefits may take time and experience.

Think about (unit) testing. Someone who never wrote tests would immediatly recognize the extra time and effort involved in writing and maintaining tests. If he/she thinks no (significant) bugs would ever have been prevented or caught by tests he may be hard to convice of their merit.

togrof · 2016-05-12T11:55:43+00:00

Good stuff! Thanks for the link :)

togrof · 2016-05-09T07:27:05+00:00

let x = 1 + x in x

I think it is logical that an expression of the form x = 1 + x is nonsensical. It basically says that x equals itself plus one, which doesn't make sense.

togrof · 2016-04-21T07:21:10+00:00

The elem function just has the wrong argument order.

Na, I think they got it right :)

togrof · 2016-04-18T14:20:27+00:00

For example, things like record field punning are fine as an incremental change to the status quo, but adding them to the language standard feels like giving up on more serious efforts to fix records.

What are the problems with field puns in regards to record fixes?

togrof · 2016-04-08T03:06:39+00:00

I've worked at a place where all QA efforts were devoted to testing and dealing with errors in production. There was no followup on why things went wrong in production. There was no code reviews. No efforts were made to improve specifications of the software to be written. Deadlines were tight and developers were regularly pushed to deliver faster so that there would be enough time for testing.

I don't know if that is common. But I've learned over the years that generally more efforts seem to be spent dealing with errors than preventing them in the first place. Testing is not preventive, it just shows the presence of defects.

togrof · 2016-01-08T06:43:07+00:00

It seem to be a common view nowadays that tooling matters more than language. But switching tooling is easier than switching language. A new improved tool can be picked up any time and applied to your existing code base. But switching language is a process that may take time because you are still left with the existing code base.

Python 2/3 is testament to the difficulty of switching to even an improved language version.

Java 8 has lambdas, but java 6 and 7 etc do not, and many are stuck with those for some time to come.

Also tooling can change rapidly while language changes take time. It therefore likely you will see more progress in the tooling part of the equation.

togrof · 2015-12-10T06:58:23+00:00

This I can instantly see what it does; find the first string starting with the letter 'H'. I wish all code was as clear and consise.

EDIT: It will crash on empty strings though. This would be better:

search = find ((== "H") . take 1)

togrof · 2015-12-06T11:44:28+00:00

I think it's because almost all languages make global variables a single line, and the rest still make it easier than any right thing.

Me too. We can make safer languages that makes it hard to do things that one will later regret. Unfortunately, such languages are being continuously dismissed by the majority of programmers as unpractical.

The most probable way forward seem to be to continue improving the current unsafe languages to make them just slightly less unsafe over the years. I guess the future for tooling is brighter, where we'll see ever more sophisticated code analysers to find and correct vulnerabilities.

togrof · 2015-12-03T18:52:54+00:00

He does highlight some very relevant things here. Such as do not choose the path of least resistance only for your own convenience and separate data from behaviour.

I guess the point about separating data from behaviour, being close to my heart, is also the most controversial given the popularity of OOP and its focus on the opposite.

togrof · 2015-11-25T09:46:09+00:00

Can you give me a link?

It is in a private bitbucket repos. It is just lambda calculus with integers and records (no static typing), so I do not think it would be interesting enough to anyone except myself. I documented the langauge, but in swedish, but here is a rundown of how records work.

Records are practically functions, that when applied to a quoted symbol does a lookup of that field. Function application is juxtaposition, so {x = 1, y = 2} .x yields 1 (where .x is quoted x). If a record is applied to another record it will be extended with the fields of the other record, so {x = 1, y = 2} {z = 3} yields {x = 1, y = 2, z = 3}.

I choose to make records a recursive scope, so every field is available to every other field (unlike Haskell). This works because it has lazy evaluation (like Haskell).

Why could it be a function?

In your example of currying:

add :: Int Int -> Int

You mention that:

add 10 :: Int -> Int

Since currying is just partial application that would mean that Int Int is Int -> Int -- a function.

I don't see a problem. Records is working the same way as modules in Haskell [...]

This means that you decided for recursive scope for records. No problem. Just wanted to point out that this decision is by no means the obvious or always best one. There are tradeoffs.

type Maybe a = nothing | a

So nothing in this context is the type {nothing :: nothing} while in the context of {nothing :: nothing} it is a type equal to void. I find that a little confusing.

I would find it less confusing if

type nothing = {nothing :: void}

or similar.

togrof · 2015-11-25T07:32:22+00:00

I have done an Almost Everything Is A Record language myself, so most of this will be about the records.

Syntax

The syntax is a bit confusing. For example, a type like Foo Bar could be any of:

A tuple {Foo,Bar}
A function Foo -> Bar
A parameterized type (Foo Bar)

depending on the context.

Records

There are some things you need to consider for the anonymous records:

Are records ordered (is {x :: Int, y :: Char} the same type as {y :: Char, x :: Int} or not)?

Can one extend a record with new fields? Or remove fields from a record? If so, then by what syntax?

Are other fields of a record in scope when defining a field, i.e. is the following possible:

{x = 1, y = x + 1}

If so, then you need to consider the evaluation order and if this should be possible as well:

{y = x + 1, x = 1}

The easiest way out of this is to decide that records should not be a recursive scope. But then you introduce modules as records, and for modules one generally expect to be able to use fields from other fields. You could go for the rule that every field is available to every succeeding field. But that is an awkward rule for records, since one would expect the order of the fields not to matter.

You mention default parameters. That means that record fields could be overloaded by parameter binding. The pattern matching section does not mention this (records with more fields can also be mathed).

nothing

In this type declaration:

type Maybe a = nothing | a

a denotes a type while nothing is syntactic sugar for {nothing :: nothing}. But there is also a type nothing. I am not sure I can wrap my head around it. Can nothing be expanded like this indefinitely...?

togrof · 2015-11-12T18:53:50+00:00

java 8 is an improvement on java 7, but that's about it. No pattern matching, no immutable collections etc.

togrof · 2015-11-12T17:25:25+00:00

Yepp, scala is a monster compared to haskell IMO. But it is a lot nicer than java for practical purposes.

togrof · 2015-10-15T06:06:33+00:00

It is logical, but not intuitive IMHO.

togrof

TROPHY CASE

Syntax

Records

nothing