

Programming at the specification level with Haskell - agocorona
https://www.fpcomplete.com/user/agocorona/EDSL-for-hard-working-IT-programmers

======
michaelochurch
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...](https://www.fpcomplete.com/user/agocorona/a-monad-for-reactive-
programming-part-1)

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!

~~~
agocorona
Hi

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

------
mijoharas
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...](https://www.fpcomplete.com/user/agocorona/EDSL-for-hard-working-
IT-programmers#composition-of-programs--runnable-example-)

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

~~~
mijoharas
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.

------
unfamiliar
"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.

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

~~~
michaelochurch
"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.

~~~
gclaramunt
I think the blessing and the curse of OOP is that is actually pretty good for
simulation (SIMULA got it right I guess :) ), so what you usually have is a
program that's a simulation of a process. Even the standard OO modelling
techniques encourage simulation of "real world" entities. But that direction
doesn't lead to the most efficient,composable , or easy to reason
abstractions. It doesn't help that the main abstraction mechanism in OO
(superclass/subtyping) is problematic enough that even most people recommend
moderation in its use.

~~~
noblethrasher
The actual big thing about computers (Turing Machines) is that they let us
simulate things, including other computers. But, once we recognize the fact
that some computers are “better” than others, we then realize that the
_amazing_ thing about computers is that they allow us simulate better
computers, it's just hard to do so.

Thus, the blessing and curse of OOP, respectively, is that it’s ideal for
building simulations (the actual point of computers), but also makes it really
easy to simulate a worse computer on top of better ones. So, the real tragedy
of “Enterprise” OOP is that it basically encourages programmers to first
simulate lame computers (e.g. by building frameworks), and then write programs
for them.

------
noelwelsh
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.

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

~~~
agocorona
I added a bit more context. Thanks

------
agocorona
Very sorry: [https://www.fpcomplete.com/user/agocorona/EDSL-for-hard-
work...](https://www.fpcomplete.com/user/agocorona/EDSL-for-hard-working-IT-
programmers)

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

------
tome
This seems to be a valid link:

[https://www.fpcomplete.com/user/agocorona/EDSL-for-hard-
work...](https://www.fpcomplete.com/user/agocorona/EDSL-for-hard-working-IT-
programmers)

