Re: a note on the Haskerl extension to Haskell [long]
I applaud the intention of the Haskerl group to make the use of Haskell
easier and, in the same spirit, I would like to suggest some further
extensions to make "literate" programming easier.
Most Haskell users (and certainly all Haskell compiler writers) also
use LaTeX, so I suggest that literate programming should be made easier
by integrating some LaTeX features into Haskell to enable automatic
pretty-printing of programs.
My first suggestion is that lists could be delimited by the itemize
environment e.g.
\begin{itemize}
first element,
second element,
long and involved third element,
fourth element
\end{itemize}
The printed version of this list would be of the form:
[first element,
second element,
long and involved
third element,
fourth element]
so indentation would be automatically taken care of.
Arrays could be similarly defined using the enumerate environment, so:
\begin{enumerate}
first, second, third
\end{enumerate}
would print as:
array (1,3) [1 := first,
2 := second,
3 := third]
This requires a little intelligence to work out the upper array bound,
but that is not hard.
The possibilities for mathematical programming are endless. For example:
\sum_{i=0}^{n} x_{i}
would be the sum of the first n+1 elements of the list x, and would be
printed using the sigma notation, which is much easier to read than the
Haskell equivalent.
It goes without saying that Haskerlatex (as I have dubbed it) would
print all variable names in italic, keywords in bold and so forth to
further aid the program reader.
I could go on and on about the advantages of these extensions, but I will
stop now as I would like the Haskerl group to have time to consider them
soon, as I presume it has a strictly limited lifetime.
Nick North
National Physical Laboratory
Re: a note on the Haskerl extension to Haskell [long]
I know it's late in the day for most of you (or already tomorrow),
but a colleague of mine here at Los Alamos has made a suggestion
I just have to pass along:
Will Partain writes
|We might then match against a list of Foos (type "[Foo]") as follows:
|
|case expr of
| /^{Foo1 _ {4}}({Foo2 _ _})+{Foo1 _ _}?.$/ -> ...
Another thing we really ought to do to demonstrate that we've arrived
and Haskell is good for real applications is to hold an obfuscated
Haskell contest. I volunteer to moderate.
--Joe
A note on the Haskerl extension to Haskell [long]
I would like to congratulate Mr. Partain on this visionary proposal. The time is right for such a language. I was particularly excited by the FWIM syntax but I would like to go even further and suggest that we consider including support for dc syntax[1]. This often-neglected language represents a significant advance on Perl's philosophy of maximum bang-per-byte of source code and yet is often easier to understand than the equivalent program written in Haskell with monads. [1] Unix manual page, dc(1). Denis Howe (Haskerl WG Member)
a note on the Haskerl extension to Haskell [long]
Non-strict, purely-functional languages, such as Haskell [1], are
perceived to be inadequate for everyday, get-the-job-done tasks; in
particular, they are seen to be "bad at I/O". Consequently, an
informal working group has been designing an extended variant of
Haskell to address these requirements, while remaining within a
non-strict, purely-functional framework.
The Perl language [2] is nothing if not "good for everyday,
get-the-job-done" tasks -- it puts UNIX at the programmer's
fingertips. Furthermore, perl is widely known, so we have chosen to
follow its lead, rather than invent our extensions ex nihilo. (For
our initial version, we do not mind a UNIX-biased design.)
What follows is an *informal* note about what we call the "Haskerl"
extension to Haskell. We especially welcome "major-gripe" comments
now, so that we can consider them before the first complete Haskerl
definition (sometime after FPCA, we hope).
Will Partain, group scribe ([EMAIL PROTECTED])
[full working group listed in the document]
.
Executive summary
~
For the disaffected Haskell programmer, we provide: regular
expressions, at-your-fingertips access to UNIX features, and
shorthand-laden figure-out-what-I-mean (FWIM) syntax.
For the disaffected Perl programmer, we provide: lazy evaluation,
referential transparency, Hindley-Milner type checking, polymorphism,
a rich set of builtin data types, and (recursive) user-defined data
types.
We achieve this, essentially, by adding Perl-like features to Haskell.
Background
~~
To keep matters short, we assume basic familiarity with both Haskell
and Perl. One additional non-standard Haskell idea we use heavily
herein is "monadic I/O" [3].
You may think of something of type "IO a" as being "a sequenced action
which eventually returns something of type "a". A main program is of
type "IO ()". The main functions used are "thenIO", "thenIO", and
"returnIO", thusly (for example):
main = io_action_1 `thenIO` ( \ result_1 ->
io_action_2 `thenIO_`
io_action_3 `thenIO` ( \ (_, _, result_3) ->
exitIO ( result_1 + result_3 )
))
`thenIO_` is just shorthand for "`thenIO` ( \ _ ->".
The above might be written in pseudo-C as:
main () {
result_1 = io_action_1;
io_action_2;
(_, _, result_3) /* yes, right... */ = io_action_3;
exit (result_1 + result_3);
}
The above is all fine, except the syntax leaves something to be
desired. That is one of the major points that Haskerl addresses.
Syntax for monadic I/O
~~
We steal back the {, }, and ; characters from if-you-don't-use-layout,
and use them instead for monad comprehensions of type "IO a". Braces
delimit such a comprehension. Semi-colon (;) is now, roughly,
"thenIO".
The example in the previous section may be written as:
main = {
result_1 <- io_action_1 ;
io_action_2 ;
(_, _, result_3) <- io_action_3 ;
exitIO (result_1 + result_3)
}
Which brings us to our next point ...
FWIM syntax (IO monad comprehensions)
~
The careful Haskell-aware reader of the example in the previous
section will note that the types really don't "work out". For
example, semi-colon ("thenIO") gives the appearance of working whether
or not an "io_action" gives a result or not.
Things do work because Haskerl takes Perl's approach of
figure-out-what-I-mean (FWIM) syntax. So: the general form of an IO
monad comprehension is:
{ io_thing_1 ; ... ; io_thing_N | result_value }
If an io_thing is of the form "result <- io_action", then the
subsequent semi-colon really is equivalent to "thenIO"; however, if
the io_thing is of the form "io_action" (no result bound), then the
semi-colon is equivalent to "thenIO_" (ignore-the-result variant).
Further, if an io_thing turns out to have type "[IO a]" (list of I/O
actions), then suitable wrapping will be inserted to deal with that
("listIO io_action `thenIO` ( \ result -> ... ", for those who care).
Finally, if the comprehension does not have an explicit
"result_value", the result from the last io_thing will be returned; if
the last io_thing has no result, then () will be returned (giving the
comprehension the type "IO ()", which is the type of a main program,
incidentally).
FWIM syntax ("if", for example)
FWIM syntax for monad comprehensions isn't quite enough for Perl-like
programming convenience; in particular, a few major control functions
need some special pleading.
"if", for example, normally has the type "Bool -> a -> a -> a".
However, that is inadequate if we want to do something like ...
if -f filename_string { -- check if a file exists; this is an IO action!
handle <- open filename_string
}
-- (it would be tiresome if we had to put on an "else")
(Obviously, this example could be wr
a note on the Haskerl extension to Haskell [long] Date: Thu, 1 Apr
Non-strict, purely-functional languages, such as Haskell [1], are perceived to be inadequate for everyday, get-the-job-done tasks; in particular, they are seen to be "bad at I/O". Consequently, an informal working group has been designing an extended variant of Haskell to address these requirements, while remaining within a non-strict, purely-functional framework. Can anyone give me an example---or a reference to an example---which shows that functional languages are "bad at I/O"? And why is Haskell perceived to be inadequate for "get-the-job-done" tasks? Since Lennart added the "Native" mode to hbc and since hbc provides access to many UNIX features (see page 4 of the latest user guide), I have been able to do anything I want (so far). In addition, I have written functions that check the command line arguments and route the input/output accordingly; I just pop these functions into a library and another IO task is made easy. However, I admit that the programs I write have simple I/O: read a "signal" (in the signal-processing sense) from a file, read some data structures from another file, crank the handle, produce output. David M. Goblirsch ([EMAIL PROTECTED]) The MITRE Corporation, McLean VA 22102 voice: (703) 883-5450 fax: (703) 883-6708
Re: a note on the Haskerl extension to Haskell [long]
| Lennart Augustsson (Chalmers) writes, "I haven't started adding | Haskerl to LML/HBC, but it shouldn't take long. By FPCA definitely." As Lennart was heard decrying excessive monadery as recently as September, I'm pleased to hear he's gotten on the bandwagon. That he's given himself over two months to implement this little extension is worrisome, however. --Joe
