<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=text/html;charset=iso-8859-1 http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.18882"></HEAD>
<BODY style="PADDING-LEFT: 10px; PADDING-RIGHT: 10px; PADDING-TOP: 15px"
id=MailContainerBody leftMargin=0 topMargin=0 CanvasTabStop="true"
name="Compose message area">
<DIV><FONT size=4 face="LM Mono 12">
<DIV><FONT size=4 face="LM Mono 12">Dear Neil,</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=4 face="LM Mono 12">Neil: For GHC in particular, they currently
have a build system that works, what's the benefit of changing the build
system?</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=4 face="LM Mono 12">John:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=4 face="LM Mono 12">To make it even better. As I pointed out in
my GHC ticket system feature request ticket (<A
href="">http://hackage.haskell.org/trac/ghc/ticket/3912</A>) 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.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=4 face="LM Mono 12">The real question, however, is can we do
better? and I believe the answer to be resoundingly yes.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=4 face="LM Mono 12">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.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=4 face="LM Mono 12">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."</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=4 face="LM Mono 12">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?</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=4 face="LM Mono 12">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.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=4 face="LM Mono 12">Neil: I think anywhere there is currently an
embedded language is a good<BR>candidate for replacing with Haskell and a
DSL/library. This includes<BR>Makefile's (and other places like buildbot
etc)</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=4 face="LM Mono 12">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.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=4 face="LM Mono 12">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.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=4 face="LM Mono 12">John:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=4 face="LM Mono 12">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.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=4 face="LM Mono 12">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.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=4 face="LM Mono 12">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.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=4 face="LM Mono 12">I said earlier "Dependencies among files I
anticipate could be treated as a type."</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=4 face="LM Mono 12">Neil: I'd be very surprised if that was
possible.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=4 face="LM Mono 12">John: Wait and see. You have given me
something special Neil. You have given me evidence of
non-obviousness.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=4 face="LM Mono 12">I said earlier "I hope to use
quasi-quotation to compensate for the syntactic overhead that general purpose
computer programming languages have."</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=4 face="LM Mono 12">Neil: Haskell has very little syntactic
overhead. If you write a program in<BR>quasi-quotes you didn't really write a
Haskell program (and all your<BR>easily maintainable etc arguments are
reduced).</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=4 face="LM Mono 12">John:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=4 face="LM Mono 12">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.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=4 face="LM Mono 12">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.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=4 face="LM Mono 12">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.</FONT></DIV></FONT></DIV></BODY></HTML>