Dear Neil,
Neil: For GHC in particular, they currently have a build system that works,
what's the benefit of changing the build system?
John:
To make it even better. As I pointed out in my GHC ticket system feature
request ticket (http://hackage.haskell.org/trac/ghc/ticket/3912) the build
system is an octopus. It has tentacles that reaches into every aspect of what
everyone is doing. I would also disagree that GHC has a build system that
works. In its present condition it is fragile and sufficient time consuming
that no one in their right mind would attempt to build it on a regular basis
themselves personally. The task needs to be deferred to an automaton. This
results in delays and paper work. People having to write back and forth to each
other to discuss the problem. It is worse than this, however. This creates
distance that will cause some things to fall through the cracks.
The real question, however, is can we do better? and I believe the answer to be
resoundingly yes.
The present way of doing things is complicated and error prone even though it
is deceptively easy comparatively speaking. Shell scripts are easy to write,
but are a nightmare to maintain due to all sorts of things they don't get
right. It is what we have gotten used to, however. A faulty way of doing things
has become a part of the institution. Sounding perhaps a little like Steve Jobs
such things are a black mark on the human spirit.
It is not my interest to be someone who mocks you from the side lines and you
have to say in response to him, "Try doing it yourself." I am willing to pay my
dues and not just be a critic, but someone who is in the muck working on a
solution. So my response to Simon Marlow's most recent e-mail is, "Fair enough.
I'll take that as a challenge."
Neil: As Simon says, I've got some experience using Haskell for writing build
scripts. I had a fork of the Yhc build script written in Haskell, for example.
I think it's a very good idea in general. For GHC in particular, they currently
have a build system that works, what's the benefit of changing the build system?
John: I suppose my remark earlier about selling refrigerators to Eskimos might
be applicable here. I have partially address this already. I just haven't
gotten into all the details.
Neil: I think anywhere there is currently an embedded language is a good
candidate for replacing with Haskell and a DSL/library. This includes
Makefile's (and other places like buildbot etc)
John: You also spoke of the article and big O notation. I'll comment on that
later since it will prove to be a distraction at the moment.
Neil: There are lots of things your build system can isolate you from, but the
weirdities of shells are not one of them. You'll still have craziness with
spaces, different programs requiring slashes (/) or (\) in different
directions, path lengths (lower on Win2003 than XP). You've got a chance of
abstracting some away, but it's not a panacea.
John:
I would disagree, but to disagree means that I have to go into some of the
detail concerning how I intend to implement the code. It isn't merely that I
hope to write it in Haskell. I am bringing with me other ideas as well. There
is a lot of wrong thinking that we have become accustomed to. We have become
accustomed to using a Domain Specific Language (DSL) to describe file system
path names and such things as URLs.
One of the things that I intend to do is work with path names in a manner that
is similar how it is done in Lisp, encoded as a data structure and not as a
string. Though it is less convenient, it is precise. These aspects to the
problem that you mention, the engineering constraints, can then be encoded as
types. For example, a path name that requires backward slash as opposed to
forward slash as the path name component separator correspond to different,
albeit related, types. This stems from the fact that the type system does not
merely consider ground types that refer to specific things like units of
measure that are fixed, but also shades of gray. This is a U.S. unit as opposed
to a British unit thanks to the Curry-Howard correspondence.
I will likely be exploring the limits of the Haskell type system. There are no
dependent types for example, but this does not mean that the Haskell type
system is insufficiently powerful to record a good size chunk of the explicit
or implicit specification with precision. One possible area of research might
be to examine how as built deviations from the specification, known as bugs,
can be encoded using types.
I said earlier "Dependencies among files I anticipate could be treated as a
type."
Neil: I'd be very surprised if that was possible.
John: Wait and see. You have given me something special Neil. You have given me
evidence of non-obviousness.
I said earlier "I hope to use quasi-quotation to compensate for the syntactic
overhead that general purpose computer programming languages have."
Neil: Haskell has very little syntactic overhead. If you write a program in
quasi-quotes you didn't really write a Haskell program (and all your
easily maintainable etc arguments are reduced).
John:
I would disagree here as well. I would concede that if the domain specific
language were not useful and therefore unfamiliar to the maintainer you would
have a point, however. Some care is needed to achieve a proper balance, kind of
like the choice between short and long versions of command line options. Some
command line options are so often used that an experienced user will have no
trouble identifying them even though they are cryptic whereas less used command
line options will need something less terse.
I would disagree with you that the use of quasi-quotes would cause the language
to cease to be Haskell in that Haskell is a general purpose language. The
domain specific language is there to make important activities convenient by
avoiding the syntactic overhead a general purpose computer programming language
causes. The downside of having a domain specific language is that you are
trapped. You can't step outside of it. Even Haskell that appears unrecognizable
due to the heavy use of quasi-quotes will retain the ability to step outside.
Again, some care is needed to achieve a balance. The degree of convenience
given to you by the domain specific language cannot be so great as to
discourage the use of conventional Haskell where appropriate.
You have brought attention to some of the potential pitfalls that I certainly
need to be aware of. You brought up a few other things, but this letter has to
end some where. I may write further later.
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
