Programming at the specification level with Haskell

https://www.fpcomplete.com/user/agocorona/EDSL-for-hard-working-IT-programmers

by agocorona • 11 years ago

43 28 11 years ago

fpcomplete.com

tome2• 11 years ago

This seems to be a valid link:

https://www.fpcomplete.com/user/agocorona/EDSL-for-hard-work...

unfamiliar• 11 years ago

"Object-oriented programming is an exceptionally bad idea which could only have originated in California." - Dijkstra

I don't think this is a real quotation.

pestaa• 11 years ago

You are right.

http://programmers.stackexchange.com/questions/99166/dijkstr...

Although, OOP is still a mess.

jimmaswell• 11 years ago

It's hardly any kind of "mess". It's the most practical and intuitive to reason about choice for a significant amount of work that needs to be done. FP excels at some cases but not all of them. Contorting all of my OOP code into a functional structure would be a nightmare.

tormeh• 11 years ago

It originated at Simula in Oslo and was vastly superior to the C/FORTRAN programming that came before it, but whatever.

michaelochurch3• 11 years ago

"Object-oriented programming" is like "God" or "feminism"-- pointless to debate until you define terms, and ranging from the agreeable/probable to the ridiculous depending on precisely how terms are defined.

The original idea was that, when a piece of software becomes complex, it should be factored out and given a simpler interface. Alan Kay used the cell as a metaphor: it's a complex machine that interacts with the rest of the body using a simpler language of chemical and electrical signals. And that turned out to be such a good idea that you see it even in non-OOP programming tools. Haskell's type classes are a comparable idea. FP picks the best noun (immutable data) and verb (referentially transparent function) for most purposes (of course, the world is stateful and there's some debate over how to manage that). At scale, we also have to deal with the "adjective problem" because we want to be able to code against abstractions rather than (less stable) implementations.

For example, it's a good thing that languages support a File object (an abstraction that Unix is built on) that allows application programmers to avoid having to know what kind of "file" they are dealing with. It's nice being able to use the same language (open/read/write/close) regardless of the physical machinery that the file lives on.

The problem is that corporate OOP has become complexity for it's own sake. Alan Kay wasn't saying, "Go out and design massive, complicated objects". He was only proposing strategies for when complexity became inevitable. Unfortunately, Business OOP (a bastardization of OOP, which had some good ideas at its core) rewards complexity, and you have "enterprise architects" who can't code but are paid to generate massive tangles of lines and boxes.

agocorona8• 11 years ago

Very sorry: https://www.fpcomplete.com/user/agocorona/EDSL-for-hard-work...

agocorona8• 11 years ago

It seems that there is no way to change the original URL

sctb• 11 years ago

Thanks, we updated the URL.

mijoharas3• 11 years ago

Does anyone else get "Base.hs@493:1-493:2 parse error on input `" on trying to run the code snippet in https://www.fpcomplete.com/user/agocorona/EDSL-for-hard-work...

Am I misusing fpcomplete, or does the code snippet not work?

tome2• 11 years ago

Looks like a bug in FPComplete. There's only one use of backticks there and changing it to another form doesn't fix the error.

mijoharas3• 11 years ago

I realised that it was the main module that needed to be run, after switching to this module (I also deleted some things causing syntax errors in base.hs) and selecting it as the build target the example worked as expected. I think it's because I'm not so familiar with fpcomplete.

agocorona8• 11 years ago

Too bad. I fixed it

noelwelsh• 11 years ago

This article assumes too much background -- not of Haskell but of the authors prior work. It starts off: "I have a problem: How I present the few applicative and monadic combinators that I just developed."

Ummm ... which combinators? At least provide a link to the prior article that I assume introduced them. As introductions go, this article's introduction doesn't do a very good job.

agocorona8• 11 years ago

No, I mean "the combinators that I just developed and want to explain here".

agocorona8• 11 years ago

I added a bit more context. Thanks

mijoharas3• 11 years ago

You're right, he does link to the article (at least I think it's the one that is being referred to), but not until "Enter the monad" which seems later than it shoud be. Here is the link:

https://www.fpcomplete.com/user/agocorona/monad-reactive-pro...

michaelochurch3• 11 years ago

OP: a question about some of your earlier work. In particular, I'm reading through your "A Monad For Reactive Programming, Part 1". https://www.fpcomplete.com/user/agocorona/a-monad-for-reacti...

I see a lot of higher-rank types, like this:

    data Event = forall a. Event EvType a

as opposed to:

    data Event a = Event EvType a

These mean different things. In the former, an Event has to be able to hold any a, and that doesn't really make sense (unless I'm misinterpreting something) because the only value that inhabits all types a is undefined/bottom.

Or is that what you want? Is there a reason why you use higher-rank types (which make my brain hurt, require a lot of language extensions, etc.) rather than parameterized types? If so, could you spell that out?

Another example is this:

    data EventF = forall m b c. EventF  (b → Transient m c)

Again, I'm not really familiar with what you're doing so it's quite possible that using higher-rank types is exactly what you want (see: ST Monad and Lenses, where rank-2 types are crucial). I'm just having a hard time seeing it.

Thanks!

agocorona8• 11 years ago

In the case of events, it is because I later have to store different event types in a List

so I define the list as [Event] . That is the container that feed the monad with events.

If I define Event as you suggest, I would need a existential type anyway.

    data Event a = Event EvType a

    data ListEvents= forall a.[Event a]

In the case of the continuations, I need to use a state monad that store this EventF data And I need to "erase" in some way the types to allow it to store them all for all events, no matter wich a and b they produce. I know that if in

    x :: IO a

    f :: a -> m b

If within the monad definition I store f (the rest of the computation) in the state monad, the type of this continuation when executed will be (m b) and it accept values of type `a` so I can coerce the continuation to this type even if I "erased" it when i put it in the state monad.

Anyway this approach has some problems that I solved in the second part

Programming at the specification level with Haskell

Related Stories