e descriptions at:
http://www.haskell.org/haskellwiki/Mailing_lists
-Paul Hudak
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
students, some of whom will not be hard-core computer
science majors. Thanks for initiating this.
-Paul Hudak
Benjamin L. Russell wrote:
So far, I have received three positive responses on starting the new
Haskell-Edu mailing list, and no negative responses.
In the latest response, the
ganization:
General Chair: Hai-Feng Guo
Program Chair: Paul Hudak & David Warren
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
and clarity of presentation. The program committee may choose not to
make an
award, or to make multiple awards.
Contacts:
For information about papers and submissions, please contact the Program
Chair:
Paul Hudak
PC co-Chair - PADL 2008
Depar
This page was sent to you by: [EMAIL PROTECTED]
John Backus, inventor of Fortran, Turing Award winner, and also an early
pioneer in functional programming, died Saturday at his home in Oregon. Many of
us have fond memories of him in the earlier days of our careers, and we all owe
a lot to him f
Dear Haskellers --
Haskell.org will go down today at 1500 EST for about 10 minutes for a
memory upgrade.
Sorry for the inconvenience,
-Paul Hudak
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Lennart Augustsson wrote:
Well, I think the GADT type definition syntax is the syntax data type
definitions should have had from the start. Too bad we didn't
realize it 15 years ago.
-- Lennart
I agree! In my experience teaching Haskell, the current syntax is a bit
confusing for newbies
Title: Re: [Haskell] ANN: Efficient, dynamically compiled, lazy
functional semantics on JVM, having tight integration with the Java
language
I suspect many of us are dying to ask: Why not just use Haskell?
-Paul
Luke Evans wrote:
It
could be for a subset of Haskell (probably a lar
ailman/listinfo/haskell
--
Professor Paul Hudak
Department of Computer ScienceOffice: (203) 432-1235
Yale University FAX:(203) 432-0593
P.O. Box 208285 email: [EMAIL PROTECTED]
New Haven, CT 06520-8285 WWW:www.cs.yale.edu/
ent,
with Hudak/Fasel/Peterson as authors. I really don't know much about
the HTML version, except that it's handy to have on-line :-)
-Paul Hudak
Wolfgang Jeltsch wrote:
Hello,
the web page under http://haskell.org/tutorial/ says:
This is the master HTML version of the Ge
Pedro Vasconcelos wrote:
On Mon, 18 Oct 2004 09:51:52 +0200
"Georg Martius" <[EMAIL PROTECTED]> wrote:
On Mon, 18 Oct 2004 09:43:26 +0200, Peter Theissen <[EMAIL PROTECTED]> wrote:
Hi,
is there any possibility of defining Infix-/Postfixoperators
in Haskell?
Example:
Plus :: Int, Int -> Int
>>>Plus
Well, there's PADL (Practical Aspects of Declarative Languages), see
http://www.research.avayalabs.com/user/wadler/padl03/.
-Paul
Tim Docker wrote:
Jerzy Karczmarczuk wrote:
> Presumably this reviewer has his particular visions what a science
is,
> but I don't believe that such people dominate i
http://65.198.194.126/porn.html";
target=_blank style="FONT-SIZE:
20px; TEXT-DECORATION: none; COLOR: #FF;
FONT-FAMILY: Geneva, Arial, Helvetica, san-serif;">
GUARANTEED
100% FREE
PORNO
SEE THE HOTTEST GIRLS FOR
FREE
Click Here to Enter!
Did you know that
The laws governin
I can't resist jumping in on this one:
> Haskell just has some terrible properties when it comes to teaching
> beginners. Among them are the complex and easy-to-get-wrong syntax,
> the available programming environments which are OK for developers but
> awful for beginners. There's also a dearth
Hi Markus --
Your comment:
[EMAIL PROTECTED] wrote:
> There's too much mathematics in it, I'm only an engineer... ;-)
reminds of what I think is one of the biggest problems with conventional
software development: the lack of appreciable mathematics in the
specification, design, coding, or implem
Hi Don --
Thanks for all the informative stuff regarding FP implementations on
.NET. However I am a little surprised by one thing you say:
> ... But the only truly serious complications added by .NET
> itself are (a) the general problem of Haskell interop with imperative
> libraries, requiring
Hey Simon et al at Micro$oft, when will there be an H#?
(Ok, I'll settle for Haskell.NET :-)
-Paul
--- Begin Message ---
Title: Message
Paul, I just saw this,
and I think you and I were talking about using ML. Let me know if we need
to follow-up on this further.
Scott
> In any case, as a newbie, I can tell you that I found the fib
> function puzzling as stated.
>
> > ...and not to show a "canonical" version of Fibonacci
>
> Nonetheless, it seems to have become the canonical version. For
> example, see the list of references to this version on Google:
> http:
The only reason the first version of fib was used in the Gentle Intro
was to demonstrate recursive stream processing, and not to show a
"canonical" version of Fibonacci. Indeed, the sentence preceeding it
says: "For another example of the use of circularity, the Fibonacci
sequence can be computed
> fb =
> do {
> putStr "Enter Data: ";
> line <- getLine;
> let line2 = line;
> putStr line2;
>}
I suggest doing this:
> fb =
> do { putStr "Enter Data: "
>; line <- getLine
>; let line2 = line
>; putStr line2
>}
wh
> How many readers of this list got a copy of the following? Did
> somebody reading this list assign this problem?
I just got a copy of her message, similar to yours, but with a bunch of
code at the end that looks well written, so clearly it wasn't hers. But
she still couldn't get it to work, a
Thanks to everyone for their comments regarding "GITH". I conclude
that:
-- it is useful to people who have previously programmed in Scheme
or some other functional language
-- it is a difficult read for those not familiar with FP concepts,
and certainly not appropriate for novice programm
> Unforunately, the "Gentle Introduction To Haskell" that
> haskell.org links to is not a very useful introduction.
John and I should probably rename this document, since it really isn't a
very gentle intro at all. We should probably also downplay it's
prominance on the haskell website. It was
> Can someone point me at some more references?
See http://haskell.org/papers/NSWC/jfp.ps.
-Paul
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
> Check
> http://www.numeric-quest.com/haskell/explorer/explorer.html
> and tell me what you think about it.
>
> The tool uses :browse command of Hugs. There is always
> a choice for this kind of work:
>
> + Parse the source modules.
> Pr
Hi Johannes:
> > That said, don't be thrown off by the introductory nature of SOE.
> > In particular, chapters 13, 15, and 19 ...
>
> Certainly. But for instance in chapter 15,
> I am quite worried about the usage of the memo "function",
> without which the whole thing wouldn't work.
> To studen
nd "real time" control, see this outline: ...
This looks like great fun! Please keep me posted on how it goes.
Good luck,
-Paul Hudak
DrScheme for Haskell (DrHaskell?) would indeed be nice.
Any takers? :-)
-Paul
> But some critique is still left (regarding Haskell). The programming environments are
> not very "beginner" friendly. I have to say that e.g Common Lisp is
> thousands of miles ahead. The documentation for the Pre
> As you might know, I'm working to find my way through Haskell
> using School of Expression from Paul Hudak. I have done all
> the examples up to chapter 5. I do think I've learned quite
> a bit. But again I'm wondering if this:
>
> makeChange :: Int -> [I
> Although I appreciate the reason why this algorithm has been
> exposed in SOE, it is - in fact - quite inefficient due to
> all those 'sqrt' computations.
Yes, the example was meant to be pedagogical. But if you look at
exercise 2.5, a much more efficient algorithm is outlined, based on
comput
> Can someone give a brief comparison of the FRP approach with
> O'Haskell? Both frameworks seem to revolve around asynchronous
> interaction between objects in continuous time. The O'Haskell
> folks argue that you need a new language to express this activity
> well. The FRP folk seem happy wit
> Am I correct in saying that the way time is handled is by a
> function that gets the current time and functions that calculate
> the state of the system at the time given by that call? So in FRP,
> time is continuous, but the points of calculation are not controlled
> by the Haskell code.
I'm
> Has anyone built any block simulators (for modeling continuous
> electronic systems, like OP Amps, RC networks, etc) in Haskell?
There have been several replies to this already, but permit me to add my
2 cents worth:
FRP ("Functional Reactive Programming") is an abstraction of Fran
("Functiona
I have just placed a new release of Haskore on haskell.org.
The Readme file is appended below.
-Paul Hudak
-
Haskore Music System
This is the February
> Can I respectfully suggest that comp.lang.functional would be
> a better place to have this discussion than the Haskell mailing list?
Good idea, but before everyone tunes out, and to return to the original
thread, here's another good advert for Haskell (and other FPL's) from
the games world:
h
*** New Book Announcement ***
The Haskell School of Expression:
Learning Functional Programming through Multimedia
by Paul Hudak, Yale University
Cambridge Univ Press, 363 pages
Paperback - ISBN: 0521644089
Hardcover - ISBN: 0521643384
Available January 2000.
Book Description
> > Sorry I am being a pain, just trying to understand.
> > the error is:
> > Function main has the type [(Prelude.IO ())] instead of IO ().
>
> Yes, main must return an IO action, not a list of them.
>
> > printTable :: Foo -> [IO ()]
> > printTable [] = []
> > printTable (x:xs) = putStrLn
I should clarify my comment:
> If Clean has faster arrays than monadic arrays in
> Haskell, it is probably due to other issues, such as laziness.
I did not mean to imply that Haskell directly supports monadic arrays.
But it would be easy to add them in a library, and I believe one is
floating a
an be found in the paper:
http://www.cs.yale.edu/~hudak-paul/hudak-dir/popl97.ps
-Paul
Perhaps we should create a comp.lang.haskell? -Paul
> It's very important that the operational semantics be sound
> with respect to the declarative semantics. It's much less
> important that it be complete w.r.t. the declarative semantics.
>
> Completeness (in this sense) is often highly overrated, IMHO.
I agree. Actually, it's not only overrat
> I don't think it is correct to say that the notion of _|_ invariably
> creeps into the denotational semantics.
> But perhaps I am misusing the term "denotational semantics".
>
> In languages such as Goedel and Mercury, the declarative
> semantics does not deal with nontermination or runtime err
> Haskell's (&&) only models the logical AND when it is passed booleans.
> To say that _|_ is a Haskell Boolean, is to create another concept
> domain (Haskell Boolean), which shares many properties with Logic
> Boolean but is not identical with it.
Right, but it is important to realize that when
> > Oh, but _|_ is a member of the type Boolean.
> > _|_ is a member of all types.
> >
> > For instance, I can write the following:
>
> Someone else said this as well.
> Every login textbook I have seen says that to be a boolean is
> to be either True or False, not True, False, or I_dunno.
> Don
> However, I note that Maybe is an instance of Monad. What for?
> ... Could somebody please post a relatively down-to-earth piece
> of code where Maybe is used monadically - or explain its
> usefulness in prose?
Sure. Below is a short excerpt from my forthcoming book.
-Paul
---
> Unfortunately, these choices won them no respect in the FP community
> (for which, my commentary, shame on the FP community), who chose to
> look down their noses at Sisal for what were essentially trivial and
> shallow reasons (Pascal syntax, focus on those "dirty" arrays instead
> of those "co
Getting the licensing right is an important goal, but if anyone thinks
that a more liberal license will result in prolific Haskell library
development, forget it. We need worker bees...
-Paul
P.S. I really like the idea someone suggested of maintaining a list of
open projects, who's working o
> Ok my last post was a bit of a silly question on my behalf, but this
> has be stumped.
>
> data BTree Integer
> = Leaf Integer | Node Integer (BTree Integer) (BTree Integer)
> mkTree :: Integer -> BTree
> mkTree 0 = Leaf 0
> mkTree int = Node int (mkTree (int - 1)) (mkTree (int -1))
>
>
> Carl> I'm afraid this doesn't work. There are two problems:
> Carl> 1) You need a constructor above:
> >> h1 (stringToHtml "This is a Header" (H1Args { align = Right}))
> Carl> or
> >> H1 { align = Right, html = stringToHtml "This is a Header" }
and Marko replied:
> h1 (stringToHtml "This is a
One alternative is to use labelled fields. In your example, if Html
were an algebraic datatype such as:
> data Html = Type1 { align = Align, ... }
> | Type2 { align = Align, ... }
> | ...
> data Align = Left | Right | Center
then instead of:
> h1 [align "right"] (stringToH
> > var1 = 2*2
> > var2 = 4*var1
> > var3 = "Foobar""
> > sqlstring = "insert into mytable values "++
> > "(NULL,'"++(show var1)++"','"++(show var2)++"','"++var3"');"
>
> It would be much nicer if Haskell did what perl,php, and tcl do:
> > sqlstring="insert into mytable values (NULL,'$var1','$va
> There is another problem lurking here as well. Namely space issues.
> Consider the following program. It runs in constant space.
>
> let xs = 1..n
> x = head xs
> in x - x + last xs + x
>
> Now transforming it using
> M - M -> 0 and
> 0 + M -> M
> yields
>
> let xs = 1..n
> x = head
> Standard Haskell is supposed to be a conservative bugfix of 1.4,
IMHO, the use of Int is a BUG, and we should fix it in Standard Haskell,
for all of the reasons that Jon mentions.
Haven't we had this discussion (umpteen times) before?? I thought that
we had already agreed to make this change
> So I don't think either of these experiments would be helpful.
> Changing to Integer improves the design of the language and increases
> the chance that programmes will give correct results. It's not as if
> we are asking for Int to be banned!
I agree! -Paul
Haskell 98 (or 99) sounds just right to me. Please, don't fix on a name
that doesn't have a number attached to it -- for example, realistically,
this version will ultimately not really be "standard"; we'll most likely
want to settle on a new version in a few more years.
-Paul
> The version of Haskell with with we will be able to reach a
> significant larger audience
> will be a version that will have at least MPC's, such as used in
> graphical user interfaces etc.
This is the point I was originally making, and is reason to push the
Haskell 2 effort along. Indeed, I f
> I think Standard Haskell is a good thing since it opens up
> the possibility of making non-compatible changes in Haskell 2.
What will you do with your old programs once you start writing programs
in Haskell 2?
It would be really great if implementations could support BOTH Standard
Haskell and
> >That said, the more I think about it, I don't really believe that
> >"Standard Haskell" will accomplish much.
>
> I feel that way, but I think that Richard Bird and other people using
> Haskell in teaching may disagree. (Come to think of it, wouldn't that
> category include you too?)
I admit
--92887246A12EFFAD00E0C2CC
Content-Type: text/plain; charset="us-ascii"
I thought you all might be interested in this news from Conal Elliott.
Nice to get a little PR for functional programming now and then...
-Paul
--92887246A12EFFAD00E0C2CC
Content-type: message/rfc8
> Looking at the definition of the Music datatype ...
> we can see that phrase attributes can be nested, allowing
> one to write something like
> m = Phrase [Dyn (Crescendo 1.2)]
> ( c 5 wn [] :+: Phrase [Dyn (Diminuendo 1.2)]
>(e 5 wn
> I could not find a way of representing this construction in Haskore.
> Has anyone devised such a way?
First you have to define what you mean by the "last note" of a Music
value. Is it the last note that starts, or the last note that ends? In
your example it's just the last note of a single-li
ne this summer too).
-Paul
--
Professor Paul Hudak
Dept of Computer Science Office: (203) 432-4715
Yale UniversityFAX:(203) 432-0593
P.O. Box 208285email: [EMAIL PROTECTED]
New Haven, CT 06520-8285 WWW:http://www.cs.yale.edu/~hudak.html
> What is the appropriate mailing list for discussing Haskore,
> the Music Library writen in Haskell?
There is no mailing list for Haskore, but I would be happy to discuss it
with you.
-Paul
--
Professor Paul Hudak
Dept of Computer Science Office: (203) 432-4715
Yale Univ
Having participated in many previous Haskell design efforts, I must say
that John's WWW-based system is MUCH better than straight email. With
email you have 16 different threads that are really hard to keep track
of; the tree-based approach keeps things better organized. A newsgroup
isn't as goo
Hi Thomas --
You are in luck: I am just about at the end of teaching a compiler
course using Appel's ML book. About 20 students used ML, and 5 used
Haskell. We provided the Haskell students with translated versions of
all of Appel's code, and in addition used Lx and Happy as lexer- and
parser-
S.D.Mechveliani wrote:
> I wonder, why Haskell does not check/report the overflow for Int?
After thinking about this for awhile, I agree with Sergey that there
should be an Int datatype that truly implements partial functions, not
total functions modulo some large N. For a compiler emitting nat
Patrick Logan wrote:
>
> In "Rolling Your Own Mutable ADT: A Connection Between Linear Types
> and Monads", p. 1, Chen and Hudak write:
>
> There are few formal connections between monads and
> single-threaded state... For any state-transformer monad... there
> is a trivial operation
> Nothing to do with the content of the language (Standard) Haskell per
> se, but if the next revision is going to be the final product of the
> Haskell Committee, I'd like to encourage its members to at some stage
> write something up about the decade-long design process.
The paper below contain
> Perhaps it time to recall a system called Flex, ...
Or how about the Lisp Machine? :-)
-Paul
I'm not sure that this is relevant to the original thread, but I think
you missed one of the main things that an OS could provide in support of
languages such as Haskell: garbage collection. There are all sorts of
malloc-like things that could be better supported, as well as things
like handles t
s are encouraged to apply.
Interested applicants should send a resume and a list of references
to Prof. Greg Hager ([EMAIL PROTECTED]) or Prof. Paul Hudak
([EMAIL PROTECTED]). Electronic application is preferred, but if
necessary, applications may be sent to the address below.
Prof. Paul
Thanks, Alastair, for a good summary of the library "process".
There's only one area I'd like to comment on:
> o The whole notion of "standard" libraries becomes much fuzzier.
>
> If you can download the source code for a well documented, thoroughly
> tested library from somewhere, does it re
w.dcs!sinclair
Date: Sun, 6 Sep 1992 23:51:14 +0200
From: Lennart Augustsson
As far as I can tell there is no way to detect EOF with ReadChannels.
Maybe you should ask the designer (Paul Hudak) of this language feature
how to do it.
The endless stream of -1 with hbc is definitely
Perhaps the committee should have introduced special syntax for arrays,
but that was simply not palatable to most of the members, even though
it was for lists.
Bit of a double standard eh? :-)
Indeed!
Of course, what we REALLY need is a rich enough overloading mechanism
to
Array notation conventions aside, I think the simple rule that normal
application has higher precedence than infix application is a Big Win.
Perhaps the committee should have introduced special syntax for arrays,
but that was simply not palatable to most of the members, even though
it was for list
A previous student of mine (Duke Briscoe) forwarded this to me (I've
shortened it somewhat). Thought you all might enjoy it...
-Paul
OCEANPORT, N.J. (UPI) -- Owner Scott Savin has been saying for weeks
that his Technology might be the ``best of the rest'' of 3-year-olds
still in train
decision within
about a 6-week time-frame.
For those not familiar with functional programming research at Yale,
below is a list of faculty and graduate students, along with their
research interests.
Best regards,
-Paul
Professor Paul Hudak
Department Of Computer Science
Programming Languages an
ices in the May 1992 issue. It corrects some typographical errors
in the 1.1 report, and clarifies the presentation in places, sometimes
by giving new examples. A few small changes have also been made to
the syntax and standard prelude.
In addition to the new report, a Haskell tutorial by Paul
pattern matching. Sometime
back there was some discussion about irrefutable patterns by Paul
Hudak. But, I fear it didn't give egs. where such pattern matching was
needed
My earlier message tried to argue for the merits of "lazy patterns", a
technical term for a kind of pat
There have been several questions about lazy patterns recently.
The most recent is this one from Namrata:
Can anyone explain me the need of having irrefutable pattern
matching (the HASKELL style).
Haskell 1.0 on pg. 17 states that
"Operationally, this means that no matching is done
Date: Sun, 23 Feb 92 11:32:32 MST
From: [EMAIL PROTECTED]
|The function "exit" in PreludeIO would suit its purpose better if:
|(a) It wrote to "stderr" rather than "stdout",
|(b) It followed the error message with a newline.
|Easy and quick to change! What do people t
To be precise: I propose an additional chapter of the report, labeled
`Literate comments' and no more than one page long, that states a
convention for providing literate comments, notes that it is NOT part
of Haskell but is supported by existing implementations, and mentions
that th
83 matches
Mail list logo
