Hi, Good find!
NB: I just skimmed the paper so far, but it is a long-term area of interest
for me...
I find most of these visual systems awkward to use in practice. Quite often
this is because they have very poor interface designs (they are like old
modal CAD systems). This is troublesome, leading many - I believe - to
suggest that the idea is not plausible.
I think that a usable visual programming language is possible but it would
have to be a good graphical tool rather than just a translation of a textual
language.
I am encouraged by the FP notion of the creation of new glue, as if you
could create new control structures and domain specific languages. Once this
concept has been incorporated, i.e. the user-development of new visual
syntax as first class then I think we will see some progress in VPLs.
Unfortunately this is a big task, to my mind it involves revising our
current method of building interactive software (the event loop) to make it
more modular and reasonable to expect users to contribute new modules or
systems thereof. The FP community have delivered a number of promising
architectures (Haggis, Fudgets, Exene) in this area as has Rob Pike
(newsqueak, 8 and a half, mux?).
My interest in the area was peaked by a presentation on VPL. VPL was
exceptionally usable dataflow image-processing oriented system. It had
functions as first class objects and apply.
http://www.camazotz.com/vplpaper.html
On related note the types of a function adding two integers together, two
lists of integers together and dataflow or pipe adding two streams of
integers together would seem to be similar. Does anyone know of some formal
work on this, what are the terms I would use to investigate?
I think you can see where I'm going with this - the user has a notion of
'things connected together', but without being too concerned about the
underlying system. I imagine a 'live' type system flagging up mismatches. I
think there is analagous situation when beginners try to plumb monads
together with pure code. The idea would be to get visual syntax to help out.
Consider the conversation, "Oh, you can connect red stripey objects together
but when you want to join up a blue object you need a red/blue adaptor".
cheers,
Toby
----- Original Message -----
From: "Jason J. Libsch" <jlibsch@mail.wesleyan.edu>
To: <haskell-cafe@haskell.org>
Sent: Monday, April 02, 2001 5:57 PM
Subject: Visual Haskell
> I recently ran across a paper, Visual Haskell- a First Attempt, and was
> tremendously impressed. Has anybody here played with this language or
> read the paper? I would be interested to hear other's opinion on such a
> language.
>
> http://ptolemy.eecs.berkeley.edu/~johnr/papers/visual.html
>
>
> /jason
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
From jlibsch@mail.wesleyan.edu Mon Apr 2 20:39:20 2001
Date: Mon, 2 Apr 2001 15:39:20 -0400 (EDT)
From: Jason J. Libsch jlibsch@mail.wesleyan.edu
Subject: Visual Haskell
The reason that this paper so peaked my interest is that i have been
working on a system that is tremendously similar to the one described in
this paper- it's as if Dr. Reekie Van Eck phreaked my head or notebooks
(unfortunatly, my designs have not progressed past pen and paper.) from
the other side of the world. My take on the project is that such a
language would be the ideal langauge for begining programmers.
1) As Toby stated, the Strong Typeing of Haskell allows for a 'syntaxless'
development environment. Only inputs and outputs that type correctly can
connect. This means that all code that can be written will compile!
2) Easy to navigate through code. If a fn is foreign to the user, she
need only click on it to bring up its the underlying code.
3) It seems to me that such an environment would strongly encourage
collaboration. Having two mouse pointers dragging compenents around is
much less foreign of an asthetic than text just randomly poping up here
and there, or some such text based equivalent. The analogy i have been
working with is: two mouse pointers on the same screen can work together
like two hands- one can hold a wrench on the bolt while the other turns
the screw, while two clarets in action is like listening to two people
talk at once.
4) A visual environment allows for the seemless integration of advanced
code development tools as CVS (isn't CVS just a fancy C^z, C^ [Shift] z
?) Help or Code Documentation, etc.
5) Ability to truly design from the top down- all the way from the Gui.
An integrated GUI construction tool would be right at home in a visual
language.
6) Much more elaborate and illuminating comment system. Allowing for
dashed outlines and arrows pointing at code to be integrated into a
comment, to be shown only on the comment's mouse over event. Can drag
components (fn block) into comment, which can be clicked on to bring up
that comment in hyper text fassion, etc.
Modeling the visual language after a function langauge makes tons of
sence. Once you take this step, the visual systax follows nicely, and, i
think, looks and feels very clean.
My appologies for such the gushing tennor of this letter. I know much of
the praise i sing for a Visual Haskell is generic visual programming
propoganda, and that visual langauges for software development haven't
taken off. I think that the coupeling of a high level, robust,
funcitonal language with the visual paradime solves many visual
langauge problems, and, furthermore, presents new benfits all together.
I am eager to hear the opinions of this list.
my best,
/jason libsch
On Mon, 2 Apr 2001, Toby Watson wrote:
> Hi, Good find!
>
> NB: I just skimmed the paper so far, but it is a long-term area of interest
> for me...
>
> I find most of these visual systems awkward to use in practice. Quite often
> this is because they have very poor interface designs (they are like old
> modal CAD systems). This is troublesome, leading many - I believe - to
> suggest that the idea is not plausible.
>
> I think that a usable visual programming language is possible but it would
> have to be a good graphical tool rather than just a translation of a textual
> language.
>
> I am encouraged by the FP notion of the creation of new glue, as if you
> could create new control structures and domain specific languages. Once this
> concept has been incorporated, i.e. the user-development of new visual
> syntax as first class then I think we will see some progress in VPLs.
> Unfortunately this is a big task, to my mind it involves revising our
> current method of building interactive software (the event loop) to make it
> more modular and reasonable to expect users to contribute new modules or
> systems thereof. The FP community have delivered a number of promising
> architectures (Haggis, Fudgets, Exene) in this area as has Rob Pike
> (newsqueak, 8 and a half, mux?).
>
> My interest in the area was peaked by a presentation on VPL. VPL was
> exceptionally usable dataflow image-processing oriented system. It had
> functions as first class objects and apply.
> http://www.camazotz.com/vplpaper.html
>
> On related note the types of a function adding two integers together, two
> lists of integers together and dataflow or pipe adding two streams of
> integers together would seem to be similar. Does anyone know of some formal
> work on this, what are the terms I would use to investigate?
>
> I think you can see where I'm going with this - the user has a notion of
> 'things connected together', but without being too concerned about the
> underlying system. I imagine a 'live' type system flagging up mismatches. I
> think there is analagous situation when beginners try to plumb monads
> together with pure code. The idea would be to get visual syntax to help out.
> Consider the conversation, "Oh, you can connect red stripey objects together
> but when you want to join up a blue object you need a red/blue adaptor".
>
> cheers,
> Toby
>
> ----- Original Message -----
> From: "Jason J. Libsch" <jlibsch@mail.wesleyan.edu>
> To: <haskell-cafe@haskell.org>
> Sent: Monday, April 02, 2001 5:57 PM
> Subject: Visual Haskell
>
>
> > I recently ran across a paper, Visual Haskell- a First Attempt, and was
> > tremendously impressed. Has anybody here played with this language or
> > read the paper? I would be interested to hear other's opinion on such a
> > language.
> >
> > http://ptolemy.eecs.berkeley.edu/~johnr/papers/visual.html
> >
> >
> > /jason
> >
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
>
>
From jans@numeric-quest.com Mon Apr 2 22:37:35 2001
Date: Mon, 2 Apr 2001 17:37:35 -0400 (EDT)
From: Jan Skibinski jans@numeric-quest.com
Subject: Visual Haskell
On Mon, 2 Apr 2001, Jason J. Libsch wrote:
> The reason that this paper so peaked my interest is that i have been
> working on a system that is tremendously similar to the one described in
> this paper- it's as if Dr. Reekie Van Eck phreaked my head or notebooks
> (unfortunatly, my designs have not progressed past pen and paper.) from
> the other side of the world. My take on the project is that such a
> language would be the ideal langauge for begining programmers.
The pictures in the paper look somehow familiar to what
I had invented and implemented in Smalltalk once upon
a time for a commercial product. It was more of
a hack, but a good hack, I believe.
This perhaps gives me a right to these two comments:
If you try to be too generic you might end up with
something that is too complex for a beginner but too
dumb for an expert user. I've seen two Smalltalk
packages which attempted connecting "phone books" to
"editors" and to other gimmicks and would end up
with some incomprehensible jungle of wires, inputs
and outputs .. and some limitations that would
force you to do textual programming anyway.
However, for a specific application domain this should
work perfectly well. My experience with my own package
was such that the visual interface was a high selling
point, and the salesmen loved it too: they could
use it to design all sorts of demos and then hand them
over to their junior people to carry on with the demos.
So perhaps you would do better if you'd tone down your
entusiasm a bit about generality of visual programming
("an ideal language for beginning programmers") and
focus on some domain specific applications instead.
This does not mean that you could not reuse the
framework. Quite to contrary! For example, I had
supported two different libraries of nodes (with
pretty icons): one for DSP and another for simulation
of noise control in ventilation systems. Two different
applications, two different audiences, two different
libraries, but the framework was the same.
Jan
From brian@boutel.co.nz Tue Apr 3 04:36:54 2001
Date: Tue, 03 Apr 2001 15:36:54 +1200
From: Brian Boutel brian@boutel.co.nz
Subject: "Lambda Dance", Haskell polemic,...
Jerzy Karczmarczuk wrote:
> 2. You neglect, and I suspect that you do it on purpose, that the main
> driving force behind the evolution of Haskell is *RESEARCH*. An issue
> absent from many "popular" languages which are meant to be
> immediately
> exploitable with very flat learning curve.
This is not what is said in the Preface to the Haskell Report.
"It was decided that a committee should be formed to design such a
language, providing faster communication of new ideas, a stable
foundation for real applications development, and a vehicle through
which others would be encouraged to use functional languages."
And the first goal:
"1.It should be suitable for teaching, research, and applications,
including building large systems."
I think it is fair to say that Haskell has not been as successful in
achieving its goals as we would have liked. Tbe points made about
libraries are good ones. The problem seems to be the lack of
well-coordinated, well-funded, development resources - and this is a
problem with most open-source, volunteer-staffed efforts. Some of these
are nevertheless very successful, because, despite their weaknesses,
they do the job better that the proprietary competition. Why then has
Haskell not done as well as sendmail or apache? Perhaps because the
battleground is different. To get people to adopt Haskell (or any other
new language) is an issue of availability of people-skills, and
subjective quasi-religious arguments about the merits of one language
against another, not about which of two products does a well-defined
task better. To win that battle you need massive resources and apparent
commitment, as was the case with Sun and Java. Why did Sun do that? Did
it have anything to do with the real merits of Java?
--brian
From djelovic@sezampro.yu Tue Apr 3 07:39:30 2001
Date: Tue, 3 Apr 2001 08:39:30 +0200
From: Dejan Jelovic djelovic@sezampro.yu
Subject: "Lambda Dance", Haskell polemic,... (Jerzy Karczmarczuk)
Jerzy Karczmarczuk wrote:
> 1. I didn't find ANYTHING about FP on your pages,
> only that accusations.
I already explained that was not an accusation.
How does it follow that since there's nothing else about FP on my website
that I "never had anything to do with functional languages"? Do you really
think that the 10 pages or so on my website describe the composite of
everything I ever did?
> 2. I don't remember any of your eventual contribution to discussion
> lists, newsgroups, etc. I might be wrong. Please give some references,
> publications, functional software, etc. I will apologize then
> immediately, with regret, but also with satisfaction that the Truth won.
I have never before posted anything on FP to any list or newsgroups. In fact
I subscribed to this list only when I saw your message in the list archives.
But that's irrelevant. Do you think that everybody that has ever used a
functional laguage has contributed to discussion lists and newsgroups?
> 3. Personally you don't care about Haskell. Your page *explicitly*
> discourages local people from touching functional languages, the
> category of people you want to hire is a very strong signal.
> A potential employer who does what you did serves the devil, don't
> try to suggest that this isn't relevant.
Nonsense. I'm hiring C++ and Java programmers because I need help with the
C++ and Java projects I do. I don't see how that would discourage anybody
from learning about other languages?
And why would you assume that I personally don't care about Haskell? You
seem to be piling these assumptions about me at random.
> 1. Saying that the Haskell community offers Hugs98, and not
> mentioning neither GHC, nor NHC is either incompetent or
> provocative.
Hugs is the distribution that's suggested to newcommers. It didn't seem
relevant to talk about other distributions if we are talking about people
migrating to Haskell.
> 2. A decent programming language *must* be stable. If the main
> criterion of the "quality" you attribute to programming languages
> is the speed of its modifications, I wonder what don't you accuse
> of staleness your favourite languages: Java and C++.
Again, wrong assumptions. Neither C++ nor Java are not my favourite
language. I don't have a favourite language.
The fact that Java has not grown for a number of years is a horror. The
language lacks support for types with value semantics, generic types and
other useful facilities. Those have all been proposed but Sun has not moved
to implement them.
C++ is more expressive. The only addition I can think of right now that
would be worth the added complexity would be Java-like inner classes and
anonymous classes and functions.
I was actually contemplating writing about the above things. But it just so
happened that I wrote about Haskell first. I don't understand why the order
in which I write things is bothering you? Or did you expect to come and find
a complete 200-page analysis of all popular programming languages?
But again, this is irrelevant. I was not talking about the language. In fact
I said that Haskell is superior to Python, Perl and Ruby at the very
beginning of my article. But the Haskell website and the _distributions_
seem to be moving at a slower pace.
> Hugs 2001???? Are you sure that you really know what does it mean
> a STANDARD?
Yes. Haskell 98 is a standard. Hugs is a product. It doesn't have to be
called Hugs 98. It can be called Hugs 2001, Hugs XP, Hugs ME, Visual Hugs :)
or any other attractive name.
Anybody programming in Haskell will benefit from other users migrating to
it. More users means more vendors and more libraries.
Perception is one of the factors that influences the number of users.
Commercial world knows this. Microsoft incremented the version of Word from
2.0 to 6.0 in order to avoid having Word perceived as less mature than
WordPerfect. The incremented the Visual C++ version from 2.0 to 4.0 in order
to match Borland C++. Sun called Java 1.2 "Java 2". Etc.
The examples above are extreme and, IMO, slightly dishonest. I just brought
them up to illustrate the point vividly. Calling the Hugs February 2001
distribution "Hugs 2001" is not dishonest, it's just good marketing.
> 1. Oh yes. Thousands of books about Ruby. Actually one, in Japanese.
> Have you looked here:
> http://www.haskell.org/bookshelf/
> This is comparable with Python. Of course, Python IS more popular,
> but - -
I included Ruby in the trio because it fits the scripting language
phenomenon. Python is the one to compare against due to similar starting
positions.
Go to a bookstore. The fact that many books on Haskell have been published
doesn't mean that many people are buying them. The bookstores I visit in the
States have a number of books on Perl and Python. If they carry books on
Haskell at all that's usually one title hidden somewhere on the shelf.
Also, it is a known fact that books on specific products ("Teach Yourself
Visual C++ in 21 Days") greatly outsell books on programming languages ("The
C++ Programming Language"). Guess of which kind are Haskell books?
> 2. You neglect, and I suspect that you do it on purpose, that the main
> driving force behind the evolution of Haskell is *RESEARCH*. An issue
> absent from many "popular" languages which are meant to be
> immediately exploitable with very flat learning curve.
Flat learning curve is ideal. Since that's not possible, the smallest
possible barrier to entry is the next best thing. Why does that bother you?
>The documentation on line is sufficiently good that e.g. -
> my students won't even think about going and trying to buy a book.
No doubt. Ditto for Python and Java.
But that's besides the point. If Haskell was more popular the publishing
industry would be on the bandwagon. No? Remember, I brought up the number of
books sold as a way to gauge the popularity of Haskell in relation to
Python.
> Still, there are more publications on FP every month that I can
> digest. What about Python? Java?
Do you have _any_ idea what the average programmer is reading these days?
_Nothing_. Not one trade publication, not one book. (See "Rapid Development"
for statistics on this.)
DDJ is probably one of the most popular trade magazines. Its circulation is
155,000. What percentage of the working programmers is that?
How big is the membership in IEEE or ACM? How many practicing programmers
read IEEE Software, let alone any of the Journals?
All those publications on FP are _not_ reaching the average programmer.
> > BTW, you seem to be well-informed about who this Jelovic is. Why don't
you
> > share that knowledge with us? :)
>
> Oh, but I did.
> You seem to be a self-appointed specialist on functional languages, who
> expresses in public some very dubious truths, which I find harmful.
I never said I was a specialist. Do only specialists get a voice?
> > 1. I didn't accuse anybody of anything. I was just curious about why
people
> > aren't using Haskell and started to think about it.
>
> I understood this in such a way.
You seem to be the only one. On this list and off. Doesn't this tell you
anything?
> You are explicitly negative in your *judgement*.
I said that the language is good, but that the distributions are not good
enough to facilliate widespead use. A number of people on this list agreed.
Why is this giving you an ulcer?
> There are hundreds of libraries of Java classes and C++ classes
> and procedures which are distributed separately. The "standard"
> GNU distribution of C++ is quite limited, there is no point in
> overloading the standard environment by things whose usage
> is limited. The ease of installation is also important.
The standard Java library is actually quite comprehensive. I'd go so far to
say that it's one of the main reasons why Java has spread so quickly.
The standard C++ library is too small. That's a problem with C++. But the
language spread before GUIs and before the Web when people required less.
If Haskell is to have a chance its distribution(s) must have a comprehensive
library.
> BTW. the GHC "standard" distribution has an adequate amount of runtime
> support for normal tasks. It worked for me without any problem.
You underestimate the value of a large community and lots of vendors. In my
last project I had to manipulate some graphic files in various formats. For
C++ and Java I had turnkey solutions. (Java being better as it has a
standard Image class while for C++ no standard exists.) The closest thing I
found for Haskell is a GD wrapper with limited functionality.
> RRight. I found one point worth mentioning. Wonderful, splendid, and
> original. Hereby I declare that you are the winner of this discussion,
> and I am the loser.
Relax. I was just nitpicking in order to get a rise out of you.
So far you have used "silly", "incompetent", "accuse", "Truth", "serve the
devil", "moral", "nasty", "dubious" and "harmful". Funny how people are
eager to use such qualifications over the Internet but avoid saying them
when they have to look the other person in the eyes, don't you think?
You also didn't have the common courtesy and courage to CC: me on your
initial posting to this list.
Dejan
http://www.jelovic.com
From chak@cse.unsw.edu.au Tue Apr 3 09:43:33 2001
Date: Tue, 03 Apr 2001 18:43:33 +1000
From: Manuel M. T. Chakravarty chak@cse.unsw.edu.au
Subject: "Lambda Dance", Haskell polemic,...
"Wojciech Moczydlowski, Jr" <khaliff@astercity.net> wrote,
> On Tue, 3 Apr 2001, Brian Boutel wrote:
>
> > they do the job better that the proprietary competition. Why then has
> > Haskell not done as well as sendmail or apache? Perhaps because the
> > battleground is different. To get people to adopt Haskell (or any other
>
> > brian
>
> IMO, what's also important, is an infamous memory consumption. Everybody
> seems to ignore it, but by now I wouldn't use Haskell in a commercial product,
> because of this little inconvenience. For me, it doesn't matter much if a
> language is slow - as far as it's not very slow, it's ok. More important for
> me is the predictability. I have to know how much memory my program will
> eat. And in Haskell, with ghc the only sure answer is:
> "Very much".
After profiling and removing space leaks? In what kind of
applications did you encounter this problem?
> The lack of standard arrays, with update in O(1) time, and hashtables is
> another thing. Every time I write a larger program, I use lists - with an
> unpleasant feeling that my favourite language forces me to use either
> nonstandard extensions or uneffective solutions. I think that IO
> arrays/hashtables should be in standard. Because they are in IO - they could
> work efficiently. Yes, I know about MArray/IArray. Yet I couldn't find
> information in sources about complexity of array operations.
> And they aren't Haskell 98 compliant.
This is - again - the problem of a lack of standard
libraries. This is a problem, a very serious one, and it is
being worked on. More hands => more solutions, faster.
> I'm also curious about what you think about the purpose of Haskell. I
> personally consider it *the* language to write compilers.
> But what can you do in it besided, that wouldn't be as easy in other languages?
I found Simon Marlow's http server a quite convincing
example of how Haskell can shine in an application that is
very far from the typical applications in which functional
languages excel. Granted, it is not H98, but that the
latter is lacking some "real world" functionality like
support for concurrency and exceptions is well known and
there are meanwhile convincing proposals for these
features. (Standardisation is always slower than
invention...)
Cheers,
Manuel
From khaliff@astercity.net Tue Apr 3 10:10:43 2001
Date: Tue, 3 Apr 2001 11:10:43 +0200 (CEST)
From: Wojciech Moczydlowski, Jr khaliff@astercity.net
Subject: "Lambda Dance", Haskell polemic,...
On Tue, 3 Apr 2001, Manuel M. T. Chakravarty wrote:
> "Wojciech Moczydlowski, Jr" <khaliff@astercity.net> wrote,
>
> > IMO, what's also important, is an infamous memory consumption. Everybody
> > seems to ignore it, but by now I wouldn't use Haskell in a commercial product,
> > because of this little inconvenience. For me, it doesn't matter much if a
> > language is slow - as far as it's not very slow, it's ok. More important for
> > me is the predictability. I have to know how much memory my program will
> > eat. And in Haskell, with ghc the only sure answer is:
> > "Very much".
>
> After profiling and removing space leaks? In what kind of
> applications did you encounter this problem?
I tried to profile my toy C compiler. The profiles simply didn't
work - the graph didn't convey any informations. I've informed about the bug
and let it go.
And besides, after rough testing, it seemed that memory usage grows linear
with a compiled program size. It was OK. But during the
compilation of 200KB program, my compiler ate AFAIR about 30MB of memory.
> This is - again - the problem of a lack of standard
> libraries. This is a problem, a very serious one, and it is
> being worked on. More hands => more solutions, faster.
I know that almost every problem Haskell has is caused by lack of
people.
> I found Simon Marlow's http server a quite convincing
> example of how Haskell can shine in an application that is
> very far from the typical applications in which functional
In a "Advanced functional programming" class at Warsaw University this year,
the group is striving to write a DNS server in Ocaml. I'm curious whether
they'll succeed.
> Manuel
Wojciech Moczydlowski, Jr
From karczma@info.unicaen.fr Tue Apr 3 13:14:22 2001
Date: Tue, 03 Apr 2001 13:14:22 +0100
From: Jerzy Karczmarczuk karczma@info.unicaen.fr
Subject: Haskell polemic,...
Brian Boutel wrote:
>
> Jerzy Karczmarczuk wrote:
>
> > 2. You neglect, and I suspect that you do it on purpose, that the
> > main driving force behind the evolution of Haskell is *RESEARCH*.
> > An issue absent from many "popular" languages which are meant to
> > be immediately exploitable with very flat learning curve.
>
> This is not what is said in the Preface to the Haskell Report.
>
> "It was decided that a committee should be formed to design such a
> language, providing faster communication of new ideas, a stable
> foundation for real applications development, and a vehicle through
> which others would be encouraged to use functional languages."
>
> And the first goal:
>
> "1.It should be suitable for teaching, research, and applications,
> including building large systems."
>
> I think it is fair to say that Haskell has not been as successful in
> achieving its goals as we would have liked. Tbe points made about
> libraries are good ones. The problem seems to be the lack of
> well-coordinated, well-funded, development resources
...
What is not said in the Preface?
That the research factor is rather weak (if present at all) in the
development of *other* mentioned languages?
This, and only this was my point here. Research is consuming human
resources. The Python (Perl) world may concentrate more actively on
producing new scripts, interfaces, etc. I cannot be sure, but I doubt
very strongly that the FP community will devote too much attention
to the marketing issues (say, forcing some people to produce Hugs01.02,
Hugs01.03, Hugs01.04, etc. every month, just to prove that Hugs is
better and progressing faster than Word Perfect).
[[Btw. I read the words "stable foundation" there in the cited
fragment of the Preface]].
The Preface says that the language should be suitable... etc. Still,
the main driving force behind its evolution UNTIL NOW was research.
With growing number of Gurus who leave academic institutions, and
should adapt to the "real world", the situation may change fast, and
I sincerely hope so, but comparing the First Goal of the Preface
with the historical evolution of our favourite language is like
comparing the First Article (or the First Ammendment) of a typical
nice Constitution, with the historical evolution of the concerned
country. It takes some time before the correspondence between the
two becomes real.
The implementors should work on improving the quality of the code.
But the question of libraries is more complicated, without an active
demand of the users, the idea of producing just the basic set is
the only possible. Almost all great scientific software libraries in
the world grew up by a long distillation and optimization process from
concrete *user* packages. On the other hand, if some non-users
prefer just to criticize...
Jerzy Karczmarczuk
Caen, France
From karczma@info.unicaen.fr Tue Apr 3 13:31:46 2001
Date: Tue, 03 Apr 2001 13:31:46 +0100
From: Jerzy Karczmarczuk karczma@info.unicaen.fr
Subject: Visual Haskell /long comment/
"Jason J. Libsch" wrote:
>
> I recently ran across a paper, Visual Haskell- a First Attempt, and was
> tremendously impressed. Has anybody here played with this language or
> read the paper? I would be interested to hear other's opinion on such a
> language.
I didn't play, I don't know what is the real status of the
implementation,
but I read the paper of Hideki John Reekie quite a time ago.
And his thesis.
http://ptolemy.eecs.berkeley.edu/~johnr/papers/thesis.html
All this is extremely interesting. Is it promising?
It depends on whether the visual, dataflow approach to the interfacing
of practically usable languages is considered promising. The area seems
alive.
http://cui.unige.ch/eao/www/Visual/
http://cuisung.unige.ch/Visual/Freeman/VL.html
Dataflow-oriented packages are not so rare either. Simulink, Scicos, IBM
OPen DX, Khoros, SciRUN, WiT. The connexion tool within MCAD.
Visio and all this business well known by some people reading this list.
Of course: LabView!
(And there was even a music generator ("tracker") called Buzz which
had such an interface, quite well adapted to all kind of DSP algorithms,
but I cannot find it any more.)
//Not too many attachments to the functional world. E.g. Cantata, the
dataflow interface to Khoros library is an integrator of imperative
modules.//
Using lazy streams as the basic protocol for implementing "heavy run"
machines is nice, but - probably - not so easy to implement efficiently,
and the dataflow approach is particularly interesting in the domain of
scientific data processing, where brutal power cannot be disregarded.
What is the opinion of people working on Hawk? Lava?
There was - some time ago - a short discussion on those issues (if
I don't confuse names the first posting was by Yoann Padioleau).
There are several problems with functional visual programming. It is
not so easy to design a recursive function, to "plug-in" higher-order
functions, to exploit currying, polymorphism, etc. Simple graphs are
simple and nice.
Simple textual definitions are simple as well...
Complicated graphs are simply horrible!
I suspect that HJR did not progress too much in his approach, and
I won't blame him (I would love being able to work along this
direction, but I feel frightened). There are also other directions,
perhaps distantly related, but worth analysing.
Visual Prolog.
The Object Flow paradigm.
etc...
Toby Watson wrote:
> I find most of these visual systems awkward to use in practice.
> Quite often this is because they have very poor interface designs
> (they are like old modal CAD systems). This is troublesome, leading
> many - I believe - to suggest that the idea is not plausible.
>
> I think that a usable visual programming language is possible but
> it would have to be a good graphical tool rather than just a
> translation of a textual language.
NOT just a graphical tool. The problem - as I see it, having played
quite a lot with Khoros, Simulink, Labview... is deeper, is conceptual.
In Labview you define a for-loop, an iterative block, by embedding
the relevant instructions into a "cage" which defines local iteration
variables. Toby might say that, exactly, this is an awkward textual
code transposition - only that there is no textual code. The iteration
*concept* has been squeezed into an interface which is not adapted.
In Simulink this is better.
You can produce a loop which is a stream iterator, and even - which
you can't do trivially at all - you can produce a "tight loop", where
there is an immediate (*not delayed*) feedback between the input
and the output.
This requires a *constraint-solving* procedure!
> On related note the types of a function adding two integers
> together, two lists of integers together and dataflow or pipe adding
> two streams of integers together would seem to be similar. Does
> anyone know of some formal work on this, what are the terms I would
> use to investigate?
I am not acquainted with formal works, especially in a typed framework,
but related stuff is described already in Abelson & Sussman^2.
Types are wonderful. But Jason exaggerates:
> 1) As Toby stated, the Strong Typeing of Haskell allows for a
> 'syntaxless' development environment. Only inputs and outputs that
> type correctly can connect. This means that all code that can be
> written will compile!
>
> 2) Easy to navigate through code. If a fn is foreign to the user, she
> need only click on it to bring up its the underlying code.
1. The refusal to connect inappropriate nodes means simply that the
visual editor has incorporated the type checker. Mind you: you are
not "just writing". While connecting you perform a lot of semantic
analysis.
This can be done textually as well for primitive languages.
But for polymorphic nodes, for higher-order functions, for
"curried nodes" the life might be much harder.
2. Many-level textual editors, or visual interfaces to Basic exist.
You click, and the block opens.
This is the way the interfaces to Khoros, Dx, Simulink, Labview etc.
operate.
I fell in love with that.
I am sane again now, after crying in despair seeing 18 simultaneously
open windows, and not knowing really how to reuse the code, how
to reassemble identical parts in order to share them.
Theoretically it is not complicated. Practically it requires a LOT
of experience and patience.
I agree with Jan Skibinski that it is *much* better to
adapt this kind of interfacing to concrete, applicative domains
rather than making a universal paradigmatic world from it.
End users may love it. Students are fascinated by it. (But Matthias
Felleisen - from our conversation - seems to be a bit reluctant:
from the pedagogical perspective it is too easy to play with graphics
and to forget about the structure of the program, about the sense
of it. Nice for simple, and only for simple tasks. [We talked about
Scheme, of course]).
Personally I don't know. But I am still fascinated. Lazy streams are
not the only underlying model, one may - obviously - exploit the
continuations. Or use the event/token propagation along the links. But
this drives as far from Haskell.
More links, just to prove you that I've been thinking about visual
side of FP for some time:
http://www.cs.ucl.ac.uk/staff/L.Braine/researchdocs.html
http://www.cs.orst.edu/~burnett/vpl.html
And, of course, something about Lucid
(not to confound with Lucent)
http://lucy.uvic.ca/pm/contents.html
Jerzy Karczmarczuk
Caen, France
From matt@immute.net Tue Apr 3 22:18:15 2001
Date: Tue, 3 Apr 2001 16:18:15 -0500
From: matt hellige matt@immute.net
Subject: Visual Haskell [and visual music langages]
[Jerzy Karczmarczuk <karczma@info.unicaen.fr>]
> (And there was even a music generator ("tracker") called Buzz which
> had such an interface, quite well adapted to all kind of DSP algorithms,
> but I cannot find it any more.)
>
buzz is still around and under active development, but i don't have a
reference for it. in a similar vein, but somewhat more advanced (and
professional), are MAX/MSP, as commercial product from cycling74, Pd
(which is a different, open-source, offshoot of the project that originally
kicked off MAX), and jMax (also open source), which is related to Pd and MAX,
but done in Java and also open-source. all of those products are primarily
the work of miller puckette at ircam, although i'm not sure how involved
he is in MAX anymore.
MAX/MSP: http://www.cycling74.com/products/max.html
Pd: http://www.pure-data.org
jMax: http://www.ircam.fr/jmax/
all of these products (particularly MAX) are quite successful and highly
regarded in the experimental music community, but there is, in my opinion,
a lot of ugliness in the implementation. one look at the example code for
writing new "externals" in Pd will put a pretty sour taste in the mouth
of most programmers -- it consists of a lot of very ugly c code. it's crossed
my mind on many occasions that this is a field that could potentially see
quite a fuitful real-world application of functional programming, for two
main reasons:
- in many cases, the end user is not a hugely experienced programmer,
and either lacks enough knowledge or is too intimidated to write
extensions his or herself. functional programming solves this problem
in some cases by being much clearer (MANY MANY times clearer than the
Pd code) and easier to learn and read (for some people).
- functional programming seems like it may map quite well to many of
the concepts already used in these visual languages.
- because of the success of this type of software, and the increasing
popularity of the music made using it, this area could be a good
opportunity for functional programming in the real world, as well as
a good opportunity to introduce a whole new class of users to its
concepts and advantages.
it also may be an interesting proving ground for some more advanced features of
modern functional languages:
- performance. audio processing is notoriously intensive, so any remaining
performance problems in the functional language implementation could make
or break the product.
- integration. certainly parts of the core program, and possibly extensions,
would want to be written in an imperative style, either for performance,
or because there are well-known and already implemented algorithms for
certain dsp tasks. the functional language would need to support clean
integration with other languages for that reason.
- a good i/o model and lazy evaluation. many tasks in these environments
consist primarily of consuming on infinite stream of input, performing some
transformation, and producing an infinite stream of output. modern
functional languages have a very good model for such tasks, and lazy
evaluation comes in very handy here, also, allowing the programmer to
express things much more closely to the way the algorithm is actually
understood.
- a good type system. something many of these languages rather lack is a
powerful and expressive way of ensuring that connections are "correct".
this could neatly solve that problem.
in any case, i'd love to see more research in that area...
m
--
matt hellige matt@immute.net
http://matt.immute.net
From chak@cse.unsw.edu.au Wed Apr 4 07:52:42 2001
Date: Wed, 04 Apr 2001 16:52:42 +1000
From: Manuel M. T. Chakravarty chak@cse.unsw.edu.au
Subject: "Lambda Dance", Haskell polemic,...
"Wojciech Moczydlowski, Jr" <khaliff@astercity.net> wrote,
> On Tue, 3 Apr 2001, Manuel M. T. Chakravarty wrote:
>
> > "Wojciech Moczydlowski, Jr" <khaliff@astercity.net> wrote,
> >
> > > IMO, what's also important, is an infamous memory consumption. Everybody
> > > seems to ignore it, but by now I wouldn't use Haskell in a commercial product,
> > > because of this little inconvenience. For me, it doesn't matter much if a
> > > language is slow - as far as it's not very slow, it's ok. More important for
> > > me is the predictability. I have to know how much memory my program will
> > > eat. And in Haskell, with ghc the only sure answer is:
> > > "Very much".
> >
> > After profiling and removing space leaks? In what kind of
> > applications did you encounter this problem?
>
> I tried to profile my toy C compiler. The profiles simply didn't
> work - the graph didn't convey any informations. I've informed about the bug
> and let it go.
> And besides, after rough testing, it seemed that memory usage grows linear
> with a compiled program size. It was OK. But during the
> compilation of 200KB program, my compiler ate AFAIR about 30MB of memory.
How much memory is gcc eating for a 200KB program? If you
were to a write a toy C compiler in C++ or Java, do you
think, it would eat significantly less memory without
seriously tuning of the memory management?
Manuel
From khaliff@astercity.net Wed Apr 4 09:59:01 2001
Date: Wed, 4 Apr 2001 10:59:01 +0200 (CEST)
From: Wojciech Moczydlowski khaliff@astercity.net
Subject: "Lambda Dance", Haskell polemic,...
On Wed, 4 Apr 2001, Manuel M. T. Chakravarty wrote:
> How much memory is gcc eating for a 200KB program? If you
I've just recompiled my compiler and tried it on 200K program full of
"writeDec(5)" instructions. What really amazed me was that the compiler
has eaten in fact less memory than gcc, which has been ran on a similar C
program, full of printfs.
But things changed dramatically, when I used programs full of "i = 5"
statementes. gcc has eaten only 5M memory while my compiler quickly acquired
90M and still wanted more.
I guess I'll put out my complaint about memory usage, until I try to locate
the memory leak.
> were to a write a toy C compiler in C++ or Java, do you
> think, it would eat significantly less memory without
> seriously tuning of the memory management?
>
> Manuel
In C++? Yes. Because I have full control of the allocated memory.
Wojciech Moczydlowski, Jr
From Toby Watson" Intuitively the following scenarios seem to be related, can anyone point my
in the direction of formal work on this, or give me the formal terms I need
to search around?
1. Adding two integers together: Int -> Int -> Int
2. Adding two lists of Integers together: [Int] -> [Int] -> [Int]
3. Adding two lazy streams of integers together, possibly in seperate
(parallel) processes for example.
cheers,
Toby
From Tom.Pledger@peace.com Thu Apr 5 21:25:07 2001
Date: Fri, 6 Apr 2001 08:25:07 +1200
From: Tom Pledger Tom.Pledger@peace.com
Subject: Question about typing
Toby Watson writes:
| Intuitively the following scenarios seem to be related, can anyone
| point my in the direction of formal work on this, or give me the
| formal terms I need to search around?
|
| 1. Adding two integers together: Int -> Int -> Int
|
| 2. Adding two lists of Integers together: [Int] -> [Int] -> [Int]
If you're adding each element of the first list to the element in the
corresponding position in the second list, it's usually called
zipping. The zipWith function in the prelude takes as its parameter a
function of type a->b->c (your scenario 1) and returns a function of
type [a]->[b]->[c] (your scenario 2).
If you're adding every element of the first list to every element of
the second list, it's sometimes called diagonalisation.
| 3. Adding two lazy streams of integers together, possibly in seperate
| (parallel) processes for example.
I think the term `zipping' can apply to most container types, even
those with branching structures which don't look like half an actual
zip.
Regards,
Tom
From jans@numeric-quest.com Thu Apr 5 22:15:01 2001
Date: Thu, 5 Apr 2001 17:15:01 -0400 (EDT)
From: Jan Skibinski jans@numeric-quest.com
Subject: Question about typing
On Fri, 6 Apr 2001, Tom Pledger wrote:
> If you're adding every element of the first list to every element of
> the second list, it's sometimes called diagonalisation.
I do not know where this definition came from but it
does not make sense to me. It is zipping that looks
like a diagonalization, not the other way around.
[f ai bj | ai <- a, bj <- b]
This looks like an outer product of two vectors,
or a matrix represented as a linear vector of
dimension n x m, where n = length a, m = length b.
If f = (*) then it is really the outer product.
[ai * bj | (ai, bj) <- zip a b]
But this is a list of diagonal elements of the
outer product above, providing that n == m.
Jan
From erkok@cse.ogi.edu Thu Apr 5 15:54:28 2001
Date: Thu, 05 Apr 2001 07:54:28 -0700
From: Levent Erkok erkok@cse.ogi.edu
Subject: Question about typing
Tom Pledger wrote:
>
> Toby Watson writes:
> | Intuitively the following scenarios seem to be related, can anyone
> | point my in the direction of formal work on this, or give me the
> | formal terms I need to search around?
> |
> | 1. Adding two integers together: Int -> Int -> Int
> |
> | 2. Adding two lists of Integers together: [Int] -> [Int] -> [Int]
>
> If you're adding each element of the first list to the element in the
> corresponding position in the second list, it's usually called
> zipping. The zipWith function in the prelude takes as its parameter a
> function of type a->b->c (your scenario 1) and returns a function of
> type [a]->[b]->[c] (your scenario 2).
Jeff Lewis implemented zip comprehensions in the latest versions of both
GHC and Hugs. This notation provides special syntax to deal with the
second case above nicely.
You can say:
[x + y | x <- [1,2,3,4,5]
| y <- [5,6,7,8]]
to get:
[6,8,10,12]
The shorther list determines the final length (could of course be
infinite.)
It's an extension of the usual syntax, so multiple generators are OK
too:
[x + y | x <- [1,2,3,4,5], z <- [3, 4, 5], (x+z) `mod`2 == 1
| y <- [5,6,7,8], y `mod` 2 == 0]
gives:
[7, 10]
It's a great notation that avoids zipWith's. (You need to start hugs
with -98 and GHC needs -fglasgow-exts for zip comprehensions to be
recognized.)
-Levent.
From ingo@ele.kth.se Fri Apr 6 15:23:17 2001
Date: Fri, 6 Apr 2001 16:23:17 +0200 (MET DST)
From: Ingo Sander ingo@ele.kth.se
Subject: Visual Haskell /long comment/
On Tue, 3 Apr 2001, Jerzy Karczmarczuk wrote:
> I don't know what is the real status of the
> implementation,
> but I read the paper of Hideki John Reekie quite a time ago.
> And his thesis.
>
> http://ptolemy.eecs.berkeley.edu/~johnr/papers/thesis.html
>
> Using lazy streams as the basic protocol for implementing "heavy run"
> machines is nice, but - probably - not so easy to implement efficiently,
> and the dataflow approach is particularly interesting in the domain of
> scientific data processing, where brutal power cannot be disregarded.
>
> What is the opinion of people working on Hawk? Lava?
>
I am not working on Hawk or Lava, but Reekie's work has been a key
inspiration for our research, which is the development of the ForSyDe
(Formal System Design) methodology, developed for the design of systems
on a chip. The architecture for such systems is a single chip integrating
many different components, such as microprocessor and DSP cores, memories
and custom hardware.
We use Haskell as a modelling language in a similar way as
Reekie described in chapters 5 and 6 of his Ph.D. thesis. Higher-order
functions like scanlS and mapS, called skeletons in our methodology, are
used as process constructors implementing a synchronous computational
model.
We extend Reekies approach targeting applications that control both
control
and data flow parts. In addition, we also cover the synthesis process,
i.e. the transformation from an ideal system model written in Haskell,
into C-code for the software parts and VHDL-code for the hardware parts.
During the synthesis process we use the property, that each skeleton has a
hardware and software interpretation, e.g. a process 'scanlS f m' has a
finite state machine as its interpretation and is translated into the
corresponding VHDL (for hardware) structure, where f describes the next
state decoder and m determines the memory elements. Thus, we do not
compile the Haskell code with a traditional compiler, but interpret the
structures (skeletons) in the system model in order to get an effective
hardware/software implementation of the system model.
Back to your question, we believe that such an approach
- raises the abstraction level compared to traditional methods starting
from VHDL/C++
- allows for formal design transformation
- leads to an efficient implementation using the interpretation of
higher-order functions into hardware and software
- allows the incorporation of formal methods because of Haskells
formal semantics
If you want to more about our approach please the following WWW-page
containing a number of publications about the ForSyDe methodology:
http://www.ele.kth.se/~ingo/
Ingo Sander
From andrew@andrewcooke.free-online.co.uk Sat Apr 7 13:07:44 2001
Date: Sat, 7 Apr 2001 13:07:44 +0100
From: andrew@andrewcooke.free-online.co.uk andrew@andrewcooke.free-online.co.uk
Subject: Question about typing
Is there a class that both lists and lazy streams could implement, so
that zip et al could be more general? The distinction between 2 and 3
below seems a bit arbitrary. Something like fmap/Functor? (If there
is, I guess it could apply to 1 too?; if not, why not - is it
impractical (efficiency?) or just wrong?)
Curious,
Andrew
On Thu, Apr 05, 2001 at 06:19:30PM +0100, Toby Watson wrote:
> Intuitively the following scenarios seem to be related, can anyone point my
> in the direction of formal work on this, or give me the formal terms I need
> to search around?
>
> 1. Adding two integers together: Int -> Int -> Int
>
> 2. Adding two lists of Integers together: [Int] -> [Int] -> [Int]
>
> 3. Adding two lazy streams of integers together, possibly in seperate
> (parallel) processes for example.
>
>
> cheers,
> Toby
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
--
http://www.andrewcooke.free-online.co.uk/index.html
From matth@mindspring.com Sun Apr 8 02:46:00 2001
Date: Sat, 07 Apr 2001 20:46:00 -0500
From: Matt Harden matth@mindspring.com
Subject: Question about typing
In a lazy language like Haskell, a list is essentially the same as a
lazy stream, though I'm not well versed in the parallel stuff...
Anyway, it can be quite desirable to be able to "zip" together data
structures other than lists; trees or arrays for example. The standard
prelude and library does not include any class to do this. I played
with this awhile back, and came up with the following:
module Zip where
import Prelude hiding (zip, zipWith, zipWith3, zip3)
class (Functor f) => ZipFunctor f where
-- "zap" stands for "zip apply"
-- it applies a set of functions to a set
-- of arguments, producing a set of results
zap :: f (a->b) -> f a -> f b
instance ZipFunctor [] where
(f:fs) `zap` (x:xs) = f x : fs `zap` xs
_ `zap` _ = []
instance ZipFunctor Maybe where
(Just f) `zap` (Just x) = Just (f x)
_ `zap` _ = Nothing
zipWith :: (ZipFunctor f) => (a->b->c) -> f a -> f b -> f c
zipWith f xs ys = f `fmap` xs `zap` ys
zipWith3 :: (ZipFunctor f) => (a->b->c->d)->f a->f b->f c->f d
zipWith3 f xs ys zs = f `fmap` xs `zap` ys `zap` zs
zip :: ZipFunctor f => f a -> f b -> f (a,b)
zip = zipWith (,)
zip3 :: ZipFunctor f => f a -> f b -> f c -> f (a,b,c)
zip3 = zipWith3 (,,)
One can easily create ZipFunctor instances for trees and other data
structures. I can provide examples if you like. With multiple
parameter type classes (MPTCs, they are not in Haskell 98) as well as
functional dependencies (also not in h98), one can also create a
"Zippable" class to generalize the zip function over multiple tuple
types and eliminate zip3, zip4, etc.
I don't know of any way to make option 1 below equivalent to the other
two; I think it is impossible with Haskell's current type systems.
However, you can create an "Id" type, which is a wrapper that holds
exactly one instance of another type. Id happens to trivially be a
Functor and a Monad, is also trivially a ZipFunctor, and can be defined
as a newtype to eliminate overhead in the compiled program. Then you
would have option 1 as follows:
1. Adding two integers together: Id Int -> Id Int -> Id Int
The function for all three options would then be (zipWith (+)).
Hope this helps,
Matt
andrew@andrewcooke.free-online.co.uk wrote:
>
> Is there a class that both lists and lazy streams could implement, so
> that zip et al could be more general? The distinction between 2 and 3
> below seems a bit arbitrary. Something like fmap/Functor? (If there
> is, I guess it could apply to 1 too?; if not, why not - is it
> impractical (efficiency?) or just wrong?)
>
> Curious,
> Andrew
>
> On Thu, Apr 05, 2001 at 06:19:30PM +0100, Toby Watson wrote:
> > Intuitively the following scenarios seem to be related, can anyone point my
> > in the direction of formal work on this, or give me the formal terms I need
> > to search around?
> >
> > 1. Adding two integers together: Int -> Int -> Int
> >
> > 2. Adding two lists of Integers together: [Int] -> [Int] -> [Int]
> >
> > 3. Adding two lazy streams of integers together, possibly in seperate
> > (parallel) processes for example.
> >
> >
> > cheers,
> > Toby
> >
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
>
> --
> http://www.andrewcooke.free-online.co.uk/index.html
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
From andrew@andrewcooke.free-online.co.uk Sun Apr 8 10:14:34 2001
Date: Sun, 8 Apr 2001 10:14:34 +0100
From: andrew@andrewcooke.free-online.co.uk andrew@andrewcooke.free-online.co.uk
Subject: Question about typing
On Sat, Apr 07, 2001 at 08:46:00PM -0500, Matt Harden wrote:
> In a lazy language like Haskell, a list is essentially the same as a
> lazy stream
Sorry. I've been using Haskell a few months now, and I really did
know that, but got so confused going round in circles with a similar
problem I'm working on myself that nothing was clear any more.
Thanks for the clear reply + class.
Andrew
--
http://www.andrewcooke.free-online.co.uk/index.html
From qrczak@knm.org.pl Sun Apr 8 12:34:45 2001
Date: 8 Apr 2001 11:34:45 GMT
From: Marcin 'Qrczak' Kowalczyk qrczak@knm.org.pl
Subject: Question about typing
Sat, 07 Apr 2001 20:46:00 -0500, Matt Harden <matth@mindspring.com> pisze:
> class (Functor f) => ZipFunctor f where
> -- "zap" stands for "zip apply"
> -- it applies a set of functions to a set
> -- of arguments, producing a set of results
> zap :: f (a->b) -> f a -> f b
This is nice as long as the type is fully polymorphic. Unfortunately
this is not always the case in reality.
Let's take unboxed flat sequences (unboxed vectors). Imagine we have
data UVector a
class Seq c a | c -> a
instance Seq (UVector Bool) Bool
instance Seq (UVector Char) Char
instance Seq (UVector Int) Int
-- etc.
(in fact I do have this). Class Seq provides various operations common
to sequences. There are no problems with operations involving sequences
of the same type (e.g. splitAt), but it's not obvious how to handle map
and zipWith.
BTW. Alternatively it could be expressed thus:
data UVector a
class Seq c a
instance Seq UVector Bool
instance Seq UVector Char
instance Seq UVector Int
-- etc.
but it disallows certain abstractions, like conversion of an immutable
container to a mutable container independently of its kind. This
doesn't change the problem with map.
I found a way to express map and zipWith, but it's quite ugly. I would
be happy to have a better way.
class Map c' a' c a | c' -> a', c -> a, c' a -> c, c a' -> c' where
map :: (a' -> a) -> c' -> c
class (Map c a c a, ...) => Seq c a
-- Class Seq requires method map which doesn't chage the
-- element type.
instance Map [a] a [b] b
-- map on lists is more general than mere Seq requires:
-- it's fully polymorphic wrt. the element type.
instance Seq [a] a
-- This instance alone implies only Map [a] a [a] a.
class IArray c a
-- This is a class of immutable arrays, provided by ghc.
newtype IArrayToVector c a = V (c Int a)
-- Convert an immutable array to a flat sequence.
-- (In fact I have done this a bit differently; it doesn't
-- matter now.)
instance (IArray c a', IArray c a) => Map (c Int a') a' (c Int a) a
-- As long as both element types are ok for an immutable array,
-- vector derived from the array can be mapped from one to
-- the other.
instance IArray c a => Seq (c Int a) a
-- This implies only Map (c Int a) a (c Int a) a.
data UArray k a
instance IArray UArray Bool
instance IArray UArray Char
instance IArray UArray Int
-- etc. This is provided by ghc.
type UVector = IArrayToVector UArray
-- There are instances Seq (UVector a) a for particular choices
-- of a, and more: instances Map (UVector a') a' (UVector a) a
-- for particular choices of a' and a.
-- zipWith is similar to map, only more complicated:
class ZipWith c1 a1 c2 a2 c a
| c1 -> a1, c2 -> a2, c -> a,
c1 a -> c, c a1 -> c1, c2 a -> c, c a2 -> c2
where
zipWith :: (a1 -> a2 -> a) -> c1 -> c2 -> c
-- zipWith3 is even more ugly.
An alternative way is this: remove Map class, have map as a standalone
function which converts a container to a list, maps the list, and
converts it back. Disadvantages are that it applies only to things
which can be sensibly converted to a list, and that if mapping of a
dictionary is specified as preserving the keys (actually the key is
in the function argument but not in the result), then it must recreate
the dictionary structure from scratch.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From dpt@math.harvard.edu Sun Apr 8 17:38:27 2001
Date: Sun, 8 Apr 2001 12:38:27 -0400
From: Dylan Thurston dpt@math.harvard.edu
Subject: Question about typing
On Sun, Apr 08, 2001 at 11:34:45AM +0000, Marcin 'Qrczak' Kowalczyk wrote:
> ...
> I found a way to express map and zipWith, but it's quite ugly. I would
> be happy to have a better way.
>
> class Map c' a' c a | c' -> a', c -> a, c' a -> c, c a' -> c' where
> map :: (a' -> a) -> c' -> c
> ...
> -- zipWith is similar to map, only more complicated:
> class ZipWith c1 a1 c2 a2 c a
> | c1 -> a1, c2 -> a2, c -> a,
> c1 a -> c, c a1 -> c1, c2 a -> c, c a2 -> c2
> where
> zipWith :: (a1 -> a2 -> a) -> c1 -> c2 -> c
> ...
You raise many interesting question, but let me ask about one: why the
specific choice of functional dependencies above? Why is "c' a -> c"
necessary for Map? Why doesn't ZipWith include, e.g., "c1 a2 -> c2"?
(I don't have a lot of experience with these functional
dependencies...)
From princepawn@earthlink.net Sun Apr 8 19:20:29 2001
Date: Sun, 8 Apr 2001 11:20:29 -0700 (PDT)
From: Terrence Brannon princepawn@earthlink.net
Subject: What do you think about Mercury?
I have decided to escape the world of Perl into something more
definitional. I gave up on CAML and Erlang because they contain
imperative elements and I am tired of that form of coding. So, I have
narrowed it down to Haskell and Mercury.
The attractive things about Haskell are:
- automatic generation of concurrent programs from normal
source... instead of sending msgs to processes like in Erlang.
- large user base
- possible real job in industry (with Galois Connections).
- several books based on it
- binaries available (even for my mac os x box already!).
So, with that said,
http://www.cs.mu.oz.au/research/mercury/information/comparison_with_haskell.html
lists a number of advantages of Mercury over Haskell. And both Haskell
and Mercury did well in the ICFP.
Does anyone have anything to say about these criticisms? There were
two particular things in the list that caught my attention:
1- Haskell is a pure functional language, but I don't see any support
for backtracking or other logic features... but my guess is you have
some way of handling this? How?
2- Mercury's mode system provides support for subtypes. For example, you
can declare that a function whose argument is a discriminated union
type accepts only a subset of the possible constructors for that type,
and the mode system will enforce this.
From fjh@cs.mu.oz.au Mon Apr 9 05:30:01 2001
Date: Mon, 9 Apr 2001 14:30:01 +1000
From: Fergus Henderson fjh@cs.mu.oz.au
Subject: What do you think about Mercury?
On 08-Apr-2001, Terrence Brannon <princepawn@earthlink.net> wrote:
>
> 1- Haskell is a pure functional language, but I don't see any support
> for backtracking or other logic features... but my guess is you have
> some way of handling this? How?
The usual way of handling backtracking in Haskell is using lazy lists.
See Phil Wadler's 1985 paper [1].
For an example of this, I've attached a program for solving the
8-queens problem; you can compare this one with the Mercury version
in tests/benchmarks/queens.m in the mercury-tests distribution.
(Probably neither this one nor the Mercury one are ideal style,
but I happened to have them lying around...)
So backtracking is really not that hard to emulate in a lazy functional
language. Supporting logic variables and constraint solving is a lot
more cumbersome, however.
References
[1] Philip Wadler: How to Replace Failure by a List of Successes: A
method for exception handling, backtracking, and pattern matching in
lazy functional languages. FPCA 1985: 113-128
-- main = print_all_solns 8
main = print_soln_count 9
print_soln_count :: Int -> IO ()
print_soln_count n = putStrLn (show (length (solutions n)))
print_all_solns :: Int -> IO ()
print_all_solns n = sequence (map show_soln (solutions n))
solutions :: Int -> [[Int]]
solutions n = queens (start n)
show_soln :: Show a => a -> IO ()
show_soln soln = putStrLn (show soln)
start :: Int -> [Int]
start n = [1 .. n]
queens :: [Int] -> [[Int]]
queens start_posn = [ posn | posn <- qperm start_posn, safe posn ]
qperm :: [t] -> [[t]]
qperm [] = [[]]
qperm (x:xs) = [(y:zs) | zs <- qperm ys, (y,ys) <- qdelete (x:xs) ]
qdelete :: [t] -> [(t,[t])]
qdelete [] = []
qdelete (x:xs) = ((x,xs) : [ (y,(x:ys)) | (y,ys) <- qdelete xs ])
safe :: [Int] -> Bool
safe [] = True
safe (n:l) = nodiag n 1 l && safe l
nodiag :: Int -> Int -> [Int] -> Bool
nodiag _ _ [] = True
nodiag b d (n:l) = d /= n - b && d /= b - n && nodiag b (d+1) l
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
From karczma@info.unicaen.fr Mon Apr 9 13:08:48 2001
Date: Mon, 09 Apr 2001 13:08:48 +0100
From: Jerzy Karczmarczuk karczma@info.unicaen.fr
Subject: Backtracking (Was: What do you think about Mercury?)
Fergus Henderson wrote:
> On 08-Apr-2001, Terrence Brannon wrote:
> >
> > 1- Haskell is a pure functional language, but I don't see any support
> > for backtracking or other logic features... but my guess is you have
> > some way of handling this? How?
>
> The usual way of handling backtracking in Haskell is using lazy lists.
> See Phil Wadler's 1985 paper [1].
>
> For an example of this, I've attached a program for solving the
> 8-queens problem; you can compare this one with the Mercury version
...
This is a way to deal with *data backtracking*. Sure, most of
classical combinatoric algorithms belong to this category, the gene-
ration of permutations/combinations, 8 queens, etc. And of course
the non-deterministic parsing.
But there is also the question of *control backtracking*, used to
emulate iterations, etc. This may be implemented functionally as
well by using continuations. You may have conditional continuations,
multiple continuations,...
Unfortunately such techniques are rarely taught.
I suspect that Mark Jones' Prolog implementation in Haskell/Gofer
used them, but I don't remember the details.
Jerzy Karczmarczuk
Caen, France
From Yoann.Padioleau@irisa.fr Mon Apr 9 13:33:47 2001
Date: 09 Apr 2001 14:33:47 +0200
From: Yoann Padioleau Yoann.Padioleau@irisa.fr
Subject: Question about typing
Matt Harden <matth@mindspring.com> writes:
>
> zip :: ZipFunctor f => f a -> f b -> f (a,b)
> zip = zipWith (,)
> zip3 :: ZipFunctor f => f a -> f b -> f c -> f (a,b,c)
> zip3 = zipWith3 (,,)
>
> One can easily create ZipFunctor instances for trees and other data
> structures. I can provide examples if you like. With multiple
> parameter type classes (MPTCs, they are not in Haskell 98) as well as
> functional dependencies (also not in h98), one can also create a
> "Zippable" class to generalize the zip function over multiple tuple
> types and eliminate zip3, zip4, etc.
can you explain how you do that ?? (i dont know what is
functional dependencies, but i think i understand multiple parameter type classes
and i dont see how do make something that avoid to define a zip3 zip4 ....
From fjh@cs.mu.oz.au Mon Apr 9 15:43:24 2001
Date: Tue, 10 Apr 2001 00:43:24 +1000
From: Fergus Henderson fjh@cs.mu.oz.au
Subject: Backtracking (Was: What do you think about Mercury?)
On 09-Apr-2001, Jerzy Karczmarczuk <karczma@info.unicaen.fr> wrote:
> Fergus Henderson wrote:
> > The usual way of handling backtracking in Haskell is using lazy lists.
...
> This is a way to deal with *data backtracking*. Sure, most of
> classical combinatoric algorithms belong to this category, the gene-
> ration of permutations/combinations, 8 queens, etc. And of course
> the non-deterministic parsing.
>
> But there is also the question of *control backtracking*, used to
> emulate iterations, etc. This may be implemented functionally as
> well by using continuations.
Using continuations to implement backtracking is another important idiom,
I agree. (In fact, that is how the new back-end for the Mercury compiler
deals with backtracking Mercury code: it converts it into C (or IL, or Java)
code that uses continuation passing to handle the backtracing.)
However, in a lazy functional language, I'm not sure that you can so easily
or usefully distinguish between _control_ backtracking and _data_ backtracking.
In a lazy functional language the control flow is mainly implicit
rather than explicit, and is determined by the data flow.
> You may have conditional continuations, multiple continuations,...
If you use other lazy data structures, e.g. lazy trees rather than lazy
lists, then you can do the same kinds of things that you could do using
conditional or multiple continuations.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
From qrczak@knm.org.pl Mon Apr 9 14:40:42 2001
Date: 9 Apr 2001 13:40:42 GMT
From: Marcin 'Qrczak' Kowalczyk qrczak@knm.org.pl
Subject: What do you think about Mercury?
Mon, 9 Apr 2001 14:30:01 +1000, Fergus Henderson <fjh@cs.mu.oz.au> pisze:
> For an example of this, I've attached a program for solving the
> 8-queens problem;
Here is mine, also using the list monad together with the state monad
(uses StateT [] and not ListT State, so the state is restored during
backtracking and not permanent).
import Monad;import MonadState;main=mapM_(\s->mapM_ putStrLn$[]:[take
8$replicate i '.'++'Q':repeat '.'|i<-s])$evalStateT(mapM(\i->msum[do
(/)<-get;guard$i/j;put(\x y->y/=j&&x+y/=i+j&&x-y/=i-j&&x/y);return j
|j<-a])a)(\_ _->True);a=[0..7]
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From qrczak@knm.org.pl Mon Apr 9 14:27:51 2001
Date: 9 Apr 2001 13:27:51 GMT
From: Marcin 'Qrczak' Kowalczyk qrczak@knm.org.pl
Subject: Question about typing
Sun, 8 Apr 2001 12:38:27 -0400, Dylan Thurston <dpt@math.harvard.edu> pisze:
> > class Map c' a' c a | c' -> a', c -> a, c' a -> c, c a' -> c' where
> > map :: (a' -> a) -> c' -> c
> > ...
> > -- zipWith is similar to map, only more complicated:
> > class ZipWith c1 a1 c2 a2 c a
> > | c1 -> a1, c2 -> a2, c -> a,
> > c1 a -> c, c a1 -> c1, c2 a -> c, c a2 -> c2
> > where
> > zipWith :: (a1 -> a2 -> a) -> c1 -> c2 -> c
> > ...
>
> You raise many interesting question, but let me ask about one: why the
> specific choice of functional dependencies above? Why is "c' a -> c"
> necessary for Map?
To make the type of "map f xs" determinable from types of f and xs.
The idea is that instances of map will be made only for "the same"
container applied to potentially different element types (where
the concept of "the same" is not formal, because c is the container
already applied to the element type).
If map could arbitrarily convert the shape of containers, there would
be more ambiguities. In particular "map f (map g xs)" would be always
ambiguous (nothing says what container to use for the intermediate
value).
Conversion is done similarly to fromIntegral: as composition of
functions which convert a container to and from a common universal
type: a list (which is a list of pairs in the case of dictionaries).
A perhaps unusual thing is that when the instance of a class like Map
is determined to be [a] a [b] b, then type variables a and b become
unconstrained. I'm not sure if it causes problems. Generally it seems
to be important which exactly type variables are constrained, e.g. for
resolving ambiguities and for the monomorphism restriction. The
bright side of this is that even though map is generally overloaded
over element types, it has an instance of the type equivalent to
Prelude's map: fully polymorphic wrt. element types.
> Why doesn't ZipWith include, e.g., "c1 a2 -> c2"?
When a is determined (it must be determined by other means anyway,
otherwise the instance is ambiguous, and c1 a2 -> c2 would not help
here), c1 a -> c, c a2 -> c2. So this dependency is implied by others.
I hope I haven't overlooked anything.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From erik@meijcrosoft.com Mon Apr 9 18:09:38 2001
Date: Mon, 9 Apr 2001 10:09:38 -0700
From: Erik Meijer erik@meijcrosoft.com
Subject: Backtracking (Was: What do you think about Mercury?)
Several people, including myself in my long forgotten thesis, have shown
that these are equivalent.
Erik
----- Original Message -----
From: "Jerzy Karczmarczuk" <karczma@info.unicaen.fr>
Cc: <haskell-cafe@haskell.org>
Sent: Monday, April 09, 2001 5:08 AM
Subject: Backtracking (Was: What do you think about Mercury?)
> Fergus Henderson wrote:
>
> > On 08-Apr-2001, Terrence Brannon wrote:
> > >
> > > 1- Haskell is a pure functional language, but I don't see any support
> > > for backtracking or other logic features... but my guess is you have
> > > some way of handling this? How?
> >
> > The usual way of handling backtracking in Haskell is using lazy lists.
> > See Phil Wadler's 1985 paper [1].
> >
> > For an example of this, I've attached a program for solving the
> > 8-queens problem; you can compare this one with the Mercury version
> ...
>
> This is a way to deal with *data backtracking*. Sure, most of
> classical combinatoric algorithms belong to this category, the gene-
> ration of permutations/combinations, 8 queens, etc. And of course
> the non-deterministic parsing.
>
>
> But there is also the question of *control backtracking*, used to
> emulate iterations, etc. This may be implemented functionally as
> well by using continuations. You may have conditional continuations,
> multiple continuations,...
> Unfortunately such techniques are rarely taught.
>
> I suspect that Mark Jones' Prolog implementation in Haskell/Gofer
> used them, but I don't remember the details.
>
>
> Jerzy Karczmarczuk
> Caen, France
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
From chak@cse.unsw.edu.au Tue Apr 10 02:16:27 2001
Date: Tue, 10 Apr 2001 11:16:27 +1000
From: Manuel M. T. Chakravarty chak@cse.unsw.edu.au
Subject: What do you think about Mercury?
qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) wrote,
> Mon, 9 Apr 2001 14:30:01 +1000, Fergus Henderson <fjh@cs.mu.oz.au> pisze:
>
> > For an example of this, I've attached a program for solving the
> > 8-queens problem;
>
> Here is mine, also using the list monad together with the state monad
> (uses StateT [] and not ListT State, so the state is restored during
> backtracking and not permanent).
>
> import Monad;import MonadState;main=mapM_(\s->mapM_ putStrLn$[]:[take
> 8$replicate i '.'++'Q':repeat '.'|i<-s])$evalStateT(mapM(\i->msum[do
> (/)<-get;guard$i/j;put(\x y->y/=j&&x+y/=i+j&&x-y/=i-j&&x/y);return j
> |j<-a])a)(\_ _->True);a=[0..7]
I always knew that inside Haskell there is a Perl trying to
get out!
Manuel
From elf@sandburst.com Tue Apr 10 03:43:48 2001
Date: Mon, 9 Apr 2001 22:43:48 -0400
From: Mieszko Lis elf@sandburst.com
Subject: What do you think about Mercury?
On Tue, Apr 10, 2001 at 11:16:27AM +1000, Manuel M. T. Chakravarty wrote:
> I always knew that inside Haskell there is a Perl trying to
> get out!
import List;q _ _ 0 _=[[]];q u i r k=let{b=[x+1|x<-u,-1>x||x>0,x<k];d=i\\map abs b}in concatMap(\p->[p:x|x<-q(-p:p:b)(i\\[p])(r-1)k])d;main=print$q[][1..8]8 8
(158 chars, but the output is quite ugly)
:)
-- Mieszko
From matth@mindspring.com Tue Apr 10 03:48:27 2001
Date: Mon, 09 Apr 2001 21:48:27 -0500
From: Matt Harden matth@mindspring.com
Subject: Question about typing
I won't try to explain functional dependencies, because I don't
understand them all that well, there is documentation, and others on
this list could explain them much better than I can.
Here is an example of how to implement a polymorphic zip (used together
with the ZipFunctor I defined earlier):
> class Zippable a f b | a -> f b, f b -> a where
> zip :: a -> f b
>
> instance (ZipFunctor f) => Zippable (f a,f b) f (a,b) where
> zip (xs,ys) =
> fmap (,) xs `zap` ys
>
> instance (ZipFunctor f) => Zippable (f a,f b,f c) f (a,b,c) where
> zip (xs,ys,zs) =
> fmap (,,) xs `zap` ys `zap` zs
>
> instance (ZipFunctor f) =>
> Zippable (f a,f b,f c,f d) f (a,b,c,d) where
> zip (xs1,xs2,xs3,xs4) =
> fmap (,,,) xs1 `zap` xs2 `zap` xs3 `zap` xs4
>
> -- Hopefully you can see how to define instances for more tuples
>
Nothing stops us from adding `unzip` to the class as well, but I left
that out to keep it short. Without functional dependencies, the type
system would have difficulty with type inference, and we would have to
put type declarations all over the place when using these classes. By
the way, I should point out that these zip functions aren't used exactly
the same way as the current zip functions. They convert a tuple of
lists into a list of tuples. So, here's a demonstration of the
difference:
> -- here is the old zip3 function
> zip3 [1..5] "abcd" [0.0,3.14] == [(1,'a',0.0),(2,'b',3.14)]
>
> -- and here is the new zip
> zip ([1..5],"abcd",[0.0,3,14]) == [(1,'a',0.0),(2,'b',3.14)]
Yoann Padioleau wrote:
>
> Matt Harden <matth@mindspring.com> writes:
> >
> > zip :: ZipFunctor f => f a -> f b -> f (a,b)
> > zip = zipWith (,)
> > zip3 :: ZipFunctor f => f a -> f b -> f c -> f (a,b,c)
> > zip3 = zipWith3 (,,)
> >
> > One can easily create ZipFunctor instances for trees and other data
> > structures. I can provide examples if you like. With multiple
> > parameter type classes (MPTCs, they are not in Haskell 98) as well as
> > functional dependencies (also not in h98), one can also create a
> > "Zippable" class to generalize the zip function over multiple tuple
> > types and eliminate zip3, zip4, etc.
>
> can you explain how you do that ?? (i dont know what is
> functional dependencies, but i think i understand multiple parameter type classes
> and i dont see how do make something that avoid to define a zip3 zip4 ....
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
From fjh@cs.mu.oz.au Tue Apr 10 03:49:20 2001
Date: Tue, 10 Apr 2001 12:49:20 +1000
From: Fergus Henderson fjh@cs.mu.oz.au
Subject: What do you think about Mercury?
On 08-Apr-2001, Terrence Brannon <princepawn@earthlink.net> wrote:
>
> I have decided to escape the world of Perl into something more
> definitional. I gave up on CAML and Erlang because they contain
> imperative elements and I am tired of that form of coding. So, I have
> narrowed it down to Haskell and Mercury.
...
> http://www.cs.mu.oz.au/research/mercury/information/comparison_with_haskell.html
That page really only describes the differences in the type systems.
A very important distinction between Mercury and Haskell which that page
just skims over is that Haskell is lazy by default, and Mercury is not.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
From karczma@info.unicaen.fr Tue Apr 10 12:04:57 2001
Date: Tue, 10 Apr 2001 12:04:57 +0100
From: Jerzy Karczmarczuk karczma@info.unicaen.fr
Subject: Dimensional analysis with fundeps (some physics comments)
[[MOVED FROM haskell TO haskell-cafe]]
Nothing to do with Haskell. Pure computer scientists, not
interested in physics might not find anything in this posting.
Tom Pledger wrote:
//about dimensions, units...//
> If you clearly make the type system deal with dimensions rather than
> units, there's no problem with plugging in multiple unit systems. You
> just have to pick a scale for the representation.
>
> newtype Dimensioned mass length time rep = Dimensioned rep
>
> type Mass rep = Dimensioned One Zero Zero rep
>
> kg, lb :: Num a => Mass a
> kg = dm 1
> lb = dm 0.4535924
>
> Angles are dimensionless. (Think of the Taylor series for trig
> functions.)
>
> radian, degree :: Unit
> radian = dm 1
> degree = dm (pi/180)
The distinction between dimensions and units may seem for some of
you utterly trivial. Mass is a mass, kg -> lb, etc. are just conversion
factors. Angles are dimensionless.
It was not so trivial for the authors of SI, and for some speculative
physicists, who are not all dead yet. The problem is: what is a
*fundamental*, *universal* constant?
You see, those constants establish our unit systems!
Many, really many among my friends don't hesitate to work in a frame
where the speed of light is equal to 1. Yes, ONE, dimensionless. Then,
passing from length to time is just a unit conversion, and all
velocities are dimensionless.
(Like, say, steradians in SI?...)
Who needs candelas?
Who needs Amperes
What is the dimension of a mole? (In SI it is an independent unit)
Who needs Kelvins?
Everybody (within a particular mafia I happen to know) knows very
well that the temperature is/should be measured in energy units,
i.e., the Boltzmann constant k is equal to 1, dimensionless.
Now, even if you won't (probably) find people who would claim
that the status of k or c is the same as PI/180, the question
"what is a unit" has no unambiguous and non-conventional answer.
You may put the universal gravitational constant to 1. Or simply
put to 1 the Plankeon mass, and get rid of all the mass
"dimensional units".
==
And if you leave the world of classical physics, and start to analyze
the structure of quantum theories you may get some nasty surprises.
//Now I have to trivialize a bit//
(First, most people who do some calculations in QM put the Planck
constant equal to 1, so the energy is inverse time...)
Some quantities which should - for geometric reasons - have fixed
dimensions, such as the "force" of a field respecting Laplace
equation: ~1/r^2 (Newton, Coulomb),
get what is called the "anomalous dimension", instead of 2 one has
to play with r^(2+x), with x fractional (some people, I suppose that
Andrew Kennedy is one of them, don't like such things...).
Now, if something which should be - classically - dimensionless,
say p^0 acquires this anomaloud dimension p^x, then the only
computationally sane way of dealing with it is to introduce a new
"universal" (?) dimensional constant q, such that the expression
above may be written as (p/q)^x in appropriate units of p and q.
Then, no x may do any harm. This phenomenon, the "dimensional
transmutation" suggests that it is not clear which is the set of
universal dimensional quantities in quantum world.
==
I like all papers about dimensions, and it is very refreshing to
see how people squeeze them into the type systems. (Or play with
geometrical "navigation" in a dimensional world:
http://mail.collegestudent.com/gda01/GDA01.HTM
http://physics.nist.gov/cuu/Units/SIdiagram.html
)
I believe, however, that one should not forget that all that is
*conventional*.
Jerzy Karczmarczuk
Caen, France
From fjh@cs.mu.oz.au Wed Apr 11 02:02:04 2001
Date: Wed, 11 Apr 2001 11:02:04 +1000
From: Fergus Henderson fjh@cs.mu.oz.au
Subject: Dimensional analysis with fundeps (some physics comments)
On 10-Apr-2001, Jerzy Karczmarczuk <karczma@info.unicaen.fr> wrote:
> Tom Pledger wrote:
> //about dimensions, units...//
>
> > If you clearly make the type system deal with dimensions rather than
> > units, there's no problem with plugging in multiple unit systems. You
> > just have to pick a scale for the representation.
> >
> > newtype Dimensioned mass length time rep = Dimensioned rep
> >
> > type Mass rep = Dimensioned One Zero Zero rep
> >
> > kg, lb :: Num a => Mass a
> > kg = dm 1
> > lb = dm 0.4535924
> >
> > Angles are dimensionless. (Think of the Taylor series for trig
> > functions.)
> >
> > radian, degree :: Unit
> > radian = dm 1
> > degree = dm (pi/180)
>
> The distinction between dimensions and units may seem for some of
> you utterly trivial. Mass is a mass, kg -> lb, etc. are just conversion
> factors. Angles are dimensionless.
>
> It was not so trivial for the authors of SI, and for some speculative
> physicists, who are not all dead yet. The problem is: what is a
> *fundamental*, *universal* constant?
>
> You see, those constants establish our unit systems!
>
> Many, really many among my friends don't hesitate to work in a frame
> where the speed of light is equal to 1. Yes, ONE, dimensionless. Then,
> passing from length to time is just a unit conversion, and all
> velocities are dimensionless.
...
> one should not forget that all that is *conventional*.
Right. So, from a programming perspective, the question is this:
which conventions are most useful?
If we treat angles as dimensionless, then the type system won't give us much
help in detecting errors when we have e.g. confused radians with degrees.
But this kind of error is a common programming error -- for example,
we (the Mercury team) made that mistake while writing our ICFP competition
entry this year, and from discussion with the Haskell team that came 3rd,
I think they did too, IIRC.
So from a programming perspective, I think it may be a good idea to
treat angles as a separate dimension. Note that you can still express
things like Taylor series expansions easily enough, you just have to
divide by the appropriate unit first.
Actually in the system proposed in this thread, I suppose the type system
does give you some help in detecting or avoiding those kinds of errors,
even if angles are not a separate unit, because in this system ordinary
numbers are not the same as dimensionless units, and so you have to insert
an explicit conversion to convert between numbers and dimensionless units,
and that gives you the opportunity to consider whether the right expression
to convert `angle' from a number to a Unit is `toUnit angle', `angle * radian',
or `angle * degree'. Still, the need to insert explicit `toUnits' is
annoying, and it would be nice to have a system where every number was
already a dimensionless unit. In that case, the argument for making
angles a separate dimension would be stronger.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
From ashley@semantic.org Wed Apr 11 02:16:51 2001
Date: Tue, 10 Apr 2001 18:16:51 -0700
From: Ashley Yakeley ashley@semantic.org
Subject: Dimensional analysis with fundeps (some physics comments)
I'm cross-posting this to the Libraries list...
At 2001-04-10 18:02, Fergus Henderson wrote:
>Still, the need to insert explicit `toUnits' is
>annoying, and it would be nice to have a system where every number was
>already a dimensionless unit.
That's easy:
--
type Unit rep = Dimensioned Zero Zero Zero rep;
instance (Real a) => Real (Unit a) where
{
-- put instances here
};
--
Of course you'll have to appropriately declare superclasses of Real, such
as Num, Ord, Show, Eq etc.
--
Ashley Yakeley, Seattle WA
From ashley@semantic.org Wed Apr 11 03:46:22 2001
Date: Tue, 10 Apr 2001 19:46:22 -0700
From: Ashley Yakeley ashley@semantic.org
Subject: Dimensional analysis with fundeps (some physics comments)
At 2001-05-01 18:28, Terrence Brannon wrote:
>"has Ashley
>shown in her example a means of automating a toUnits imperative in
>Haskell that must be done explicitly in Mercury?"
...his...
--
Ashley Yakeley, Seattle WA
From ashley@semantic.org Wed Apr 11 05:51:07 2001
Date: Tue, 10 Apr 2001 21:51:07 -0700
From: Ashley Yakeley ashley@semantic.org
Subject: Dimensional analysis with fundeps (some physics comments)
--Emailer_-1225003723
Content-Type: text/plain; charset="US-ASCII"
At 2001-04-10 18:16, I wrote:
>That's easy:
>
>--
>type Unit rep = Dimensioned Zero Zero Zero rep;
>
>instance (Real a) => Real (Unit a) where
> {
> -- put instances here
> };
>--
>
>Of course you'll have to appropriately declare superclasses of Real, such
>as Num, Ord, Show, Eq etc.
I've put this together in the enclosed files (same as previously posted
to the libraries list), which derive from anatoli's work.
--
Ashley Yakeley, Seattle WA
--Emailer_-1225003723
Content-Type: application/octet-stream; name="MarkerType.hs";
x-mac-type="54455854";
x-mac-creator="522A6368"
Content-transfer-encoding: base64
Content-Disposition: Attachment; filename="MarkerType.hs"
LS0gVGhpcyBpcyB3cml0dGVuIGluIEhhc2tlbGwuCm1vZHVsZSBNYXJrZXJUeXBlIHdoZXJlCgl7
CgktLSBCb29sZWFucyBleHByZXNzZWQgYXMgSGFza2VsbCB0eXBlcy4KCWRhdGEgVHJ1ZTsKCWRh
dGEgRmFsc2U7CgkKCWNsYXNzIElzIGE7CglpbnN0YW5jZSBJcyBUcnVlOwoKCWNsYXNzIElzbnQg
YTsKCWluc3RhbmNlIElzbnQgRmFsc2U7CgoJY2xhc3MgRWl0aGVySXMgYSBiOwoJaW5zdGFuY2Ug
RWl0aGVySXMgVHJ1ZSBiOwoJaW5zdGFuY2UgRWl0aGVySXMgRmFsc2UgVHJ1ZTsKCgljbGFzcyBC
b3RoQXJlIGEgYjsKCWluc3RhbmNlIEJvdGhBcmUgVHJ1ZSBUcnVlOwoJCgljbGFzcyBOb3QgYSBi
IHwgYSAtPiBiOwoJaW5zdGFuY2UgTm90IFRydWUgRmFsc2U7CglpbnN0YW5jZSBOb3QgRmFsc2Ug
VHJ1ZTsKCQoJY2xhc3MgT3IgYSBiIGMgfCBhIGIgLT4gYzsKCWluc3RhbmNlIE9yIFRydWUgYiBU
cnVlOwoJaW5zdGFuY2UgT3IgRmFsc2UgYiBiOwoJCgljbGFzcyBBbmQgYSBiIGMgfCBhIGIgLT4g
YzsKCWluc3RhbmNlIEFuZCBUcnVlIGIgYjsKCWluc3RhbmNlIEFuZCBGYWxzZSBiIEZhbHNlOwoK
CXstLQoJSW50ZWdlcnMgZXhwcmVzc2VkIGFzIEhhc2tlbGwgdHlwZXMuIFplcm8gaXMgMC4KCUlm
IHR5cGUgYSBpcyBaZXJvIG9yIHBvc2l0aXZlLCB0aGVuIChTdWNjIGEpIGlzIHBvc2l0aXZlOwoJ
aWYgdHlwZSBhIGlzIFplcm8gb3IgbmVnYXRpdmUsIHRoZW4gKFByZWQgYSkgaXMgbmVnYXRpdmUu
CglUaGlzIGlzIHZlcnkgY3J1ZGUgYW5kIHNob3VsZCBiZSByZXBsYWNlZCB3aXRoIHNpZ24tbWFn
bml0dWRlIAoJcmVwcmVzZW50YXRpb24uCgktLX0KCglkYXRhIFplcm87CglkYXRhIFN1Y2MgbjsK
CWRhdGEgUHJlZCBuOwoKCXR5cGUgT25lID0gU3VjYyBaZXJvOwoJdHlwZSBUd28gPSBTdWNjIE9u
ZTsKCXR5cGUgVGhyZWUgPSBTdWNjIFR3bzsKCXR5cGUgTWludXNPbmUgPSBQcmVkIFplcm87Cgl0
eXBlIE1pbnVzVHdvID0gUHJlZCBNaW51c09uZTsKCXR5cGUgTWludXNUaHJlZSA9IFByZWQgTWlu
dXNUd287CgoJY2xhc3MgU3VjY2Vzc29yIGEgYiB8IGEgLT4gYjsKCWluc3RhbmNlIFN1Y2Nlc3Nv
ciBaZXJvIE9uZTsKCWluc3RhbmNlIFN1Y2Nlc3NvciAoU3VjYyBhKSAoU3VjYyAoU3VjYyBhKSk7
CglpbnN0YW5jZSBTdWNjZXNzb3IgKFByZWQgYSkgYTsKCgljbGFzcyBQcmVkZWNlc3NvciBhIGIg
fCBhIC0+IGI7CglpbnN0YW5jZSBQcmVkZWNlc3NvciBaZXJvIE1pbnVzT25lOwoJaW5zdGFuY2Ug
UHJlZGVjZXNzb3IgKFN1Y2MgYSkgYTsKCWluc3RhbmNlIFByZWRlY2Vzc29yIChQcmVkIGEpIChQ
cmVkIChQcmVkIGEpKTsKCgljbGFzcyBBdExlYXN0IGEgYjsgLS0gYSA+PSBiCglpbnN0YW5jZSBB
dExlYXN0IFplcm8gWmVybzsKCWluc3RhbmNlIEF0TGVhc3QgKFN1Y2MgYSkgWmVybzsKCWluc3Rh
bmNlIEF0TGVhc3QgWmVybyAoUHJlZCBiKTsKCWluc3RhbmNlIEF0TGVhc3QgKFN1Y2MgYSkgKFBy
ZWQgYik7CglpbnN0YW5jZSAoQXRMZWFzdCBhIGIpID0+IEF0TGVhc3QgKFN1Y2MgYSkgKFN1Y2Mg
Yik7CglpbnN0YW5jZSAoQXRMZWFzdCBhIGIpID0+IEF0TGVhc3QgKFByZWQgYSkgKFByZWQgYik7
CgoJY2xhc3MgTmF0dXJhbCBhOwoJaW5zdGFuY2UgTmF0dXJhbCBaZXJvOwoJaW5zdGFuY2UgTmF0
dXJhbCAoU3VjYyBhKTsKCgljbGFzcyBBdExlYXN0T25lIGE7CglpbnN0YW5jZSAoTmF0dXJhbCBh
KSA9PiBBdExlYXN0T25lIChTdWNjIGEpOwoKCWNsYXNzIEV2ZW4gYTsKCWluc3RhbmNlIEV2ZW4g
WmVybzsKCWluc3RhbmNlIChFdmVuIGEpID0+IEV2ZW4gKFN1Y2MgKFN1Y2MgYSkpOwoJaW5zdGFu
Y2UgKEV2ZW4gYSkgPT4gRXZlbiAoUHJlZCAoUHJlZCBhKSk7CgoJLS0gSW50ZWdlciBhZGRpdGlv
bi4gQm90aCBvcGVyYW5kcyBhcmUgZWl0aGVyIHBvc2l0aXZlLCBuZWdhdGl2ZQoJLS0gb3IgemVy
bywgc28gd2UgY29uc2lkZXIgMyozPTkgY2FzZXMuCgljbGFzcyBBZGQgYSBiIGMgfCBhIGIgLT4g
YzsKCglpbnN0YW5jZSBBZGQgWmVybyBaZXJvIFplcm87CgoJaW5zdGFuY2UgQWRkIFplcm8gKFN1
Y2MgYikgKFN1Y2MgYik7CglpbnN0YW5jZSBBZGQgWmVybyAoUHJlZCBiKSAoUHJlZCBiKTsKCglp
bnN0YW5jZSBBZGQgKFN1Y2MgYikgWmVybyAoU3VjYyBiKTsKCWluc3RhbmNlIEFkZCAoUHJlZCBi
KSBaZXJvIChQcmVkIGIpOwoKCWluc3RhbmNlIEFkZCBhIGIgYyA9PiBBZGQgKFN1Y2MgYSkgKFN1
Y2MgYikgKFN1Y2MgKFN1Y2MgYykpOwoJaW5zdGFuY2UgQWRkIGEgYiBjID0+IEFkZCAoUHJlZCBh
KSAoUHJlZCBiKSAoUHJlZCAoUHJlZCBjKSk7CgoJaW5zdGFuY2UgQWRkIGEgYiBjID0+IEFkZCAo
U3VjYyBhKSAoUHJlZCBiKSBjOwoJaW5zdGFuY2UgQWRkIGEgYiBjID0+IEFkZCAoUHJlZCBhKSAo
U3VjYyBiKSBjOwoKCS0tIFN1YnRyYWN0aW9uIGlzIHZlcnkgc2ltaWxhciB0byBhZGRpdGlvbi4K
CWNsYXNzIFN1YiBhIGIgYyB8IGEgYiAtPiBjOwoKCWluc3RhbmNlIFN1YiBaZXJvIFplcm8gWmVy
bzsKCglpbnN0YW5jZSBTdWIgWmVybyAoU3VjYyBiKSAoUHJlZCBiKTsKCWluc3RhbmNlIFN1YiBa
ZXJvIChQcmVkIGIpIChTdWNjIGIpOwoKCWluc3RhbmNlIFN1YiAoU3VjYyBiKSBaZXJvIChTdWNj
IGIpOwoJaW5zdGFuY2UgU3ViIChQcmVkIGIpIFplcm8gKFByZWQgYik7CgoJaW5zdGFuY2UgU3Vi
IGEgYiBjID0+IFN1YiAoU3VjYyBhKSAoU3VjYyBiKSBjOwoJaW5zdGFuY2UgU3ViIGEgYiBjID0+
IFN1YiAoUHJlZCBhKSAoUHJlZCBiKSBjOwoKCWluc3RhbmNlIFN1YiBhIGIgYyA9PiBTdWIgKFN1
Y2MgYSkgKFByZWQgYikgKFN1Y2MgKFN1Y2MgYykpOwoJaW5zdGFuY2UgU3ViIGEgYiBjID0+IFN1
YiAoUHJlZCBhKSAoU3VjYyBiKSAoUHJlZCAoUHJlZCBjKSk7Cgl9Cg==
--Emailer_-1225003723
Content-Type: application/octet-stream; name="Dimension.hs";
x-mac-type="54455854";
x-mac-creator="522A6368"
Content-transfer-encoding: base64
Content-Disposition: Attachment; filename="Dimension.hs"
LS0gVGhpcyBpcyB3cml0dGVuIGluIEhhc2tlbGwuCm1vZHVsZSBEaW1lbnNpb24KCShwbHVzLG1p
bnVzLHRpbWVzLGRpdmJ5LAoJRGltZW5zaW9uZWQsCglVbml0LE1hc3MsTGVuZ3RoLFRpbWUsCgl1
bml0LGtpbG9ncmFtbWUsbWV0cmUsc2Vjb25kCgkpIHdoZXJlCgl7CglpbXBvcnQgTWFya2VyVHlw
ZTsKCgl7LS0KCUEgRGltZW5zaW9uZWQgdHlwZSBjYXJyaWVzIGFsb25nIGV4cG9uZW50cyBmb3Ig
dGhyZWUgYmFzaWMKCWRpbWVuc2lvbnM6IG1hc3MsIGxlbmd0aCwgYW5kIHRpbWUuCgktLX0KCglu
ZXd0eXBlIERpbWVuc2lvbmVkIG1hc3MgbGVuZ3RoIHRpbWUgcmVwID0gTWtEaW1lbnNpb25lZCBy
ZXA7CgoJLS0gU29tZSBoYW5keSBhYmJyZXZpYXRpb25zLgoJdHlwZSBVbml0IHJlcAk9IERpbWVu
c2lvbmVkIFplcm8gWmVybyBaZXJvIHJlcDsKCXR5cGUgTWFzcyByZXAJPSBEaW1lbnNpb25lZCBP
bmUgIFplcm8gWmVybyByZXA7Cgl0eXBlIExlbmd0aCByZXAJPSBEaW1lbnNpb25lZCBaZXJvIE9u
ZSAgWmVybyByZXA7Cgl0eXBlIFRpbWUgcmVwCT0gRGltZW5zaW9uZWQgWmVybyBaZXJvIE9uZSAg
cmVwOwoJCgktLSBpbnN0YW5jZSBwcm9wZXJ0aWVzIGZvciBEaW1lbnNpb25lZHMgaW4gZ2VuZXJh
bCBhbmQgVW5pdHMKCS0tIGluIHBhcnRpY3VsYXIKCXVuZGltZW5zaW9uMSAgZiAoTWtEaW1lbnNp
b25lZCB4KSA9IGYgeDsKCXVuZGltZW5zaW9uMXIgZiB4ID0gTWtEaW1lbnNpb25lZCAodW5kaW1l
bnNpb24xIGYgeCk7Cgl1bmRpbWVuc2lvbjIgIGYgKE1rRGltZW5zaW9uZWQgeCkgKE1rRGltZW5z
aW9uZWQgeSkgPSBmIHggeTsKCXVuZGltZW5zaW9uMnIgZiB4IHkgPSBNa0RpbWVuc2lvbmVkICh1
bmRpbWVuc2lvbjIgZiB4IHkpOwoKCWluc3RhbmNlIChFcSByZXApID0+IEVxIChEaW1lbnNpb25l
ZCBtYXNzIGxlbmd0aCB0aW1lIHJlcCkgd2hlcmUKCQl7CgkJKD09KSA9IHVuZGltZW5zaW9uMiAo
PT0pOwoJCX07CgoJaW5zdGFuY2UgKE9yZCByZXApID0+IE9yZCAoRGltZW5zaW9uZWQgbWFzcyBs
ZW5ndGggdGltZSByZXApIHdoZXJlCgkJewoJCWNvbXBhcmUgPSB1bmRpbWVuc2lvbjIgY29tcGFy
ZTsKCQl9OwoKCWluc3RhbmNlIChTaG93IHJlcCkgPT4gU2hvdyAoVW5pdCByZXApIHdoZXJlCgkJ
ewoJCXNob3cgPSB1bmRpbWVuc2lvbjEgc2hvdzsKCQl9OwoKCWluc3RhbmNlIChOdW0gcmVwKSA9
PiBOdW0gKFVuaXQgcmVwKSB3aGVyZQoJCXsKCQkoKykJCQk9IHVuZGltZW5zaW9uMnIgKCspOwoJ
CSgtKQkJCT0gdW5kaW1lbnNpb24yciAoLSk7CgkJKCopCQkJPSB1bmRpbWVuc2lvbjJyICgqKTsK
CQluZWdhdGUJCT0gdW5kaW1lbnNpb24xciBuZWdhdGU7CgkJYWJzCQkJPSB1bmRpbWVuc2lvbjFy
IGFiczsKCQlzaWdudW0JCT0gdW5kaW1lbnNpb24xciBzaWdudW07CgkJZnJvbUludGVnZXIJPSBN
a0RpbWVuc2lvbmVkIC4gZnJvbUludGVnZXI7CgkJZnJvbUludAkJPSBNa0RpbWVuc2lvbmVkIC4g
ZnJvbUludDsKCQl9OwoKCWluc3RhbmNlIChSZWFsIHJlcCkgPT4gUmVhbCAoVW5pdCByZXApIHdo
ZXJlCgkJewoJCXRvUmF0aW9uYWwgPSB1bmRpbWVuc2lvbjEgdG9SYXRpb25hbDsKCQl9OwoKCWlu
c3RhbmNlIChGcmFjdGlvbmFsIHJlcCkgPT4gRnJhY3Rpb25hbCAoVW5pdCByZXApIHdoZXJlCgkJ
ewoJCSgvKQkJCQk9IHVuZGltZW5zaW9uMnIgKC8pOwoJCXJlY2lwCQkJPSB1bmRpbWVuc2lvbjFy
IHJlY2lwOwoJCWZyb21SYXRpb25hbAk9IE1rRGltZW5zaW9uZWQgLiBmcm9tUmF0aW9uYWw7CgkJ
ZnJvbURvdWJsZQkJPSBNa0RpbWVuc2lvbmVkIC4gZnJvbURvdWJsZTsKCQl9OwoKCWluc3RhbmNl
IChGbG9hdGluZyByZXApID0+IEZsb2F0aW5nIChVbml0IHJlcCkgd2hlcmUKCQl7CgkJcGkJCT0J
TWtEaW1lbnNpb25lZCBwaTsKCQlleHAJCT0JdW5kaW1lbnNpb24xciBleHA7CgkJbG9nCQk9CXVu
ZGltZW5zaW9uMXIgbG9nOwoJCXNxcnQJPQl1bmRpbWVuc2lvbjFyIHNxcnQ7CgkJKCoqKQk9CXVu
ZGltZW5zaW9uMnIgKCoqKTsKCQlsb2dCYXNlCT0JdW5kaW1lbnNpb24yciBsb2dCYXNlOwoJCXNp
bgkJPQl1bmRpbWVuc2lvbjFyIHNpbjsKCQljb3MJCT0JdW5kaW1lbnNpb24xciBjb3M7CgkJdGFu
CQk9CXVuZGltZW5zaW9uMXIgdGFuOwoJCWFzaW4JPQl1bmRpbWVuc2lvbjFyIGFzaW47CgkJYWNv
cwk9CXVuZGltZW5zaW9uMXIgYWNvczsKCQlhdGFuCT0JdW5kaW1lbnNpb24xciBhdGFuOwoJCXNp
bmgJPQl1bmRpbWVuc2lvbjFyIHNpbmg7CgkJY29zaAk9CXVuZGltZW5zaW9uMXIgY29zaDsKCQl0
YW5oCT0JdW5kaW1lbnNpb24xciB0YW5oOwoJCWFzaW5oCT0JdW5kaW1lbnNpb24xciBhc2luaDsK
CQlhY29zaAk9CXVuZGltZW5zaW9uMXIgYWNvc2g7CgkJYXRhbmgJPQl1bmRpbWVuc2lvbjFyIGF0
YW5oOwoJCX07CgkKCWluc3RhbmNlIChSZWFsRnJhYyByZXApID0+IFJlYWxGcmFjIChVbml0IHJl
cCkgd2hlcmUKCQl7CgkJcHJvcGVyRnJhY3Rpb24gKE1rRGltZW5zaW9uZWQgeCkgPSAocCxNa0Rp
bWVuc2lvbmVkIHEpIHdoZXJlCgkJCXsKCQkJKHAscSkgPSBwcm9wZXJGcmFjdGlvbiB4OwoJCQl9
OwoJCXRydW5jYXRlCQk9IHVuZGltZW5zaW9uMSB0cnVuY2F0ZTsKCQlyb3VuZAkJCT0gdW5kaW1l
bnNpb24xIHJvdW5kOwoJCWNlaWxpbmcJCQk9IHVuZGltZW5zaW9uMSBjZWlsaW5nOwoJCWZsb29y
CQkJPSB1bmRpbWVuc2lvbjEgZmxvb3I7CgkJfTsKCQoJaW5zdGFuY2UgKFJlYWxGbG9hdCByZXAp
ID0+IFJlYWxGbG9hdCAoVW5pdCByZXApIHdoZXJlCgkJewoJCWZsb2F0UmFkaXgJCT0gdW5kaW1l
bnNpb24xIGZsb2F0UmFkaXg7CgkJZmxvYXREaWdpdHMJCT0gdW5kaW1lbnNpb24xIGZsb2F0RGln
aXRzOwoJCWZsb2F0UmFuZ2UJCT0gdW5kaW1lbnNpb24xIGZsb2F0UmFuZ2U7CgkJZGVjb2RlRmxv
YXQJCT0gdW5kaW1lbnNpb24xIGRlY29kZUZsb2F0OwoJCWVuY29kZUZsb2F0IHggaQk9IE1rRGlt
ZW5zaW9uZWQgKGVuY29kZUZsb2F0IHggaSk7CgkJZXhwb25lbnQJCT0gdW5kaW1lbnNpb24xIGV4
cG9uZW50OwoJCXNpZ25pZmljYW5kCQk9IHVuZGltZW5zaW9uMXIgc2lnbmlmaWNhbmQ7CgkJc2Nh
bGVGbG9hdCBpCT0gdW5kaW1lbnNpb24xciAoc2NhbGVGbG9hdCBpKTsKCQlpc05hTgkJCT0gdW5k
aW1lbnNpb24xIGlzTmFOOwoJCWlzSW5maW5pdGUJCT0gdW5kaW1lbnNpb24xIGlzSW5maW5pdGU7
CgkJaXNEZW5vcm1hbGl6ZWQJPSB1bmRpbWVuc2lvbjEgaXNEZW5vcm1hbGl6ZWQ7CgkJaXNOZWdh
dGl2ZVplcm8JPSB1bmRpbWVuc2lvbjEgaXNOZWdhdGl2ZVplcm87CgkJaXNJRUVFCQkJPSB1bmRp
bWVuc2lvbjEgaXNJRUVFOwoJCWF0YW4yCQkJPSB1bmRpbWVuc2lvbjJyIGF0YW4yOwoJCX07CgoJ
LS0gWW91IGNhbiBhZGQgb3Igc3VidHJhY3Qgb25seSBpZGVudGljYWxseSBkaW1lbnNpb25lZCBx
dWFudGl0aWVzLgoJcGx1cywgbWludXMgOjogTnVtIHJlcCA9PgoJCURpbWVuc2lvbmVkIG1hc3Mg
bGVuZ3RoIHRpbWUgcmVwIC0+CgkJRGltZW5zaW9uZWQgbWFzcyBsZW5ndGggdGltZSByZXAgLT4K
CQlEaW1lbnNpb25lZCBtYXNzIGxlbmd0aCB0aW1lIHJlcDsKCXBsdXMgIChNa0RpbWVuc2lvbmVk
IHgpIChNa0RpbWVuc2lvbmVkIHkpID0gTWtEaW1lbnNpb25lZCAoeCt5KTsKCW1pbnVzIChNa0Rp
bWVuc2lvbmVkIHgpIChNa0RpbWVuc2lvbmVkIHkpID0gTWtEaW1lbnNpb25lZCAoeC15KTsKCgkt
LSBZb3UgY2FuIG11bHRpcGx5IGFueSB0d28gZGltZW5zaW9uZWQgcXVhbnRpdGllczsgZXhwb25l
bnRzCgktLSBmcm9tIHRoZSBvcGVyYW5kcyBhZGQgdXAgaW4gdGhlIHJlc3VsdC4KCXRpbWVzIDo6
IChOdW0gcmVwLAoJCUFkZCBtYXNzIG1hc3MnIG1hc3MnJywKCQlBZGQgbGVuZ3RoIGxlbmd0aCcg
bGVuZ3RoJycsCgkJQWRkIHRpbWUgdGltZScgdGltZScnKSA9PgoJCURpbWVuc2lvbmVkIG1hc3Mg
bGVuZ3RoIHRpbWUgcmVwIC0+CgkJRGltZW5zaW9uZWQgbWFzcycgbGVuZ3RoJyB0aW1lJyByZXAg
LT4KCQlEaW1lbnNpb25lZCBtYXNzJycgbGVuZ3RoJycgdGltZScnIHJlcDsKCXRpbWVzIChNa0Rp
bWVuc2lvbmVkIHgpIChNa0RpbWVuc2lvbmVkIHkpID0gTWtEaW1lbnNpb25lZCAoeCAqIHkpOwoK
CS0tIFNpbWlsYXJseSBmb3IgZGl2aXNpb24sIGV4Y2VwdCBleHBvbmVudHMgYXJlIHN1YnRyYWN0
ZWQuCglkaXZieSA6OiAoRnJhY3Rpb25hbCByZXAsCgkJU3ViIG1hc3MgbWFzcycgbWFzcycnLAoJ
CVN1YiBsZW5ndGggbGVuZ3RoJyBsZW5ndGgnJywKCQlTdWIgdGltZSB0aW1lJyB0aW1lJycpID0+
CgkJRGltZW5zaW9uZWQgbWFzcyBsZW5ndGggdGltZSByZXAgLT4KCQlEaW1lbnNpb25lZCBtYXNz
JyBsZW5ndGgnIHRpbWUnIHJlcCAtPgoJCURpbWVuc2lvbmVkIG1hc3MnJyBsZW5ndGgnJyB0aW1l
JycgcmVwOwoJZGl2YnkgKE1rRGltZW5zaW9uZWQgeCkgKE1rRGltZW5zaW9uZWQgeSkgPSBNa0Rp
bWVuc2lvbmVkICh4IC8geSk7CgoJLS0gYmFzZSB1bml0cyBhcyBTSS4KCWtpbG9ncmFtbWUJOjog
KE51bSByZXApID0+IE1hc3MgcmVwOwoJa2lsb2dyYW1tZQk9IChNa0RpbWVuc2lvbmVkIDEpOwoJ
bWV0cmUJCTo6IChOdW0gcmVwKSA9PiBMZW5ndGggcmVwOwoJbWV0cmUJCT0gKE1rRGltZW5zaW9u
ZWQgMSk7CglzZWNvbmQJCTo6IChOdW0gcmVwKSA9PiBUaW1lIHJlcDsKCXNlY29uZAkJPSAoTWtE
aW1lbnNpb25lZCAxKTsKCXVuaXQJCTo6IChOdW0gcmVwKSA9PiBVbml0IHJlcDsKCXVuaXQJCT0g
MTsKCX0K
--Emailer_-1225003723--
From fjh@cs.mu.oz.au Wed Apr 11 06:12:14 2001
Date: Wed, 11 Apr 2001 15:12:14 +1000
From: Fergus Henderson fjh@cs.mu.oz.au
Subject: Dimensional analysis with fundeps (some physics comments)
On 01-May-2001, Terrence Brannon <princepawn@earthlink.net> wrote:
>
> my question (primarily for Fergus) is: "has Ashley
> shown in her example a means of automating a toUnits imperative in
> Haskell that must be done explicitly in Mercury?"
Yes. In Haskell, there's some syntactic sugar attached to every numeric
literal: "123" is defined to mean "fromInteger 123", where "fromInteger"
is an overloaded (class member) function defined in the standard Prelude.
In Mercury, if you want "fromInteger" or "toUnit", then you need
to write it explicitly.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
From ashley@semantic.org Thu Apr 19 09:34:41 2001
Date: Thu, 19 Apr 2001 01:34:41 -0700
From: Ashley Yakeley ashley@semantic.org
Subject: Dimensional analysis with fundeps
--Emailer_-1223820195
Content-Type: text/plain; charset="US-ASCII"
At 2001-04-09 10:29, Dylan Thurston wrote:
>I hadn't thought about doing rational arithmetic with GCDs. Might be
>nice.
Herewith my attempt. I can't test it though, it runs afoul of one of the
many bugs in Hugs' type-extension handling, and I haven't been able to
run GHC on my MacOS X box.
--
Ashley Yakeley, Seattle WA
--Emailer_-1223820195
Content-Type: application/octet-stream; name="MarkerType.hs";
x-mac-type="54455854";
x-mac-creator="522A6368"
Content-transfer-encoding: base64
Content-Disposition: Attachment; filename="MarkerType.hs"
LS0gVGhpcyBpcyB3cml0dGVuIGluIEhhc2tlbGwuCm1vZHVsZSBNYXJrZXJUeXBlIHdoZXJlCgl7
CglkYXRhIFNpbmdsZXRvbiBhID0gU2luZ2xldG9uOwoKCWluc3RhbmNlIFNob3cgKFNpbmdsZXRv
biBhKSB3aGVyZQoJCXsKCQlzaG93IFNpbmdsZXRvbiA9ICJzaW5nbGV0b24iOwoJCX07CgoJLS0g
Qm9vbGVhbnMgZXhwcmVzc2VkIGFzIEhhc2tlbGwgdHlwZXMuCglkYXRhIFRydWU7CglkYXRhIEZh
bHNlOwoJCgljbGFzcyBCb29sZWFuVHlwZSBhOwoJaW5zdGFuY2UgQm9vbGVhblR5cGUgVHJ1ZTsK
CWluc3RhbmNlIEJvb2xlYW5UeXBlIEZhbHNlOwoKCWNsYXNzIElzIGE7CglpbnN0YW5jZSBJcyBU
cnVlOwoKCWNsYXNzIElzbnQgYTsKCWluc3RhbmNlIElzbnQgRmFsc2U7CgoJY2xhc3MgRWl0aGVy
SXMgYSBiOwoJaW5zdGFuY2UgRWl0aGVySXMgVHJ1ZSBiOwoJaW5zdGFuY2UgRWl0aGVySXMgRmFs
c2UgVHJ1ZTsKCgljbGFzcyBCb3RoQXJlIGEgYjsKCWluc3RhbmNlIEJvdGhBcmUgVHJ1ZSBUcnVl
OwoJCgljbGFzcyBOb3QgYSBiIHwgYSAtPiBiOwoJaW5zdGFuY2UgTm90IFRydWUgRmFsc2U7Cglp
bnN0YW5jZSBOb3QgRmFsc2UgVHJ1ZTsKCQoJY2xhc3MgT3IgYSBiIGMgfCBhIGIgLT4gYzsKCWlu
c3RhbmNlIE9yIFRydWUgYiBUcnVlOwoJaW5zdGFuY2UgT3IgRmFsc2UgYiBiOwoJCgljbGFzcyBB
bmQgYSBiIGMgfCBhIGIgLT4gYzsKCWluc3RhbmNlIEFuZCBUcnVlIGIgYjsKCWluc3RhbmNlIEFu
ZCBGYWxzZSBiIEZhbHNlOwoKCWNsYXNzIFBpY2sgd2hpY2ggdCBmIHIgfCB3aGljaCB0IGYgLT4g
cjsKCWluc3RhbmNlIFBpY2sgVHJ1ZSAgdCBmIHQ7CglpbnN0YW5jZSBQaWNrIEZhbHNlIHQgZiBm
OwoKCXstLQoJSW50ZWdlcnMgZXhwcmVzc2VkIGFzIEhhc2tlbGwgdHlwZXMuIFplcm8gaXMgMC4K
CUlmIHR5cGUgYSBpcyBaZXJvIG9yIHBvc2l0aXZlLCB0aGVuIChTdWNjIGEpIGlzIHBvc2l0aXZl
OwoJaWYgdHlwZSBhIGlzIFplcm8gb3IgbmVnYXRpdmUsIHRoZW4gKFByZWQgYSkgaXMgbmVnYXRp
dmUuCglUaGlzIGlzIHZlcnkgY3J1ZGUgYW5kIHNob3VsZCBiZSByZXBsYWNlZCB3aXRoIHNpZ24t
bWFnbml0dWRlIAoJcmVwcmVzZW50YXRpb24uCgktLX0KCglkYXRhIFplcm87CglkYXRhIFN1Y2Mg
bjsKCWRhdGEgUHJlZCBuOwoKCWNsYXNzIE5hdHVyYWxUeXBlIGE7CglpbnN0YW5jZSBOYXR1cmFs
VHlwZSBaZXJvOwoJaW5zdGFuY2UgTmF0dXJhbFR5cGUgKFN1Y2MgYSk7CgoJY2xhc3MgSW50ZWdl
clR5cGUgYTsKCWluc3RhbmNlIEludGVnZXJUeXBlIFplcm87CglpbnN0YW5jZSBJbnRlZ2VyVHlw
ZSAoU3VjYyBhKTsKCWluc3RhbmNlIEludGVnZXJUeXBlIChQcmVkIGEpOwoKCXR5cGUgT25lCT0g
U3VjYyBaZXJvOwoJdHlwZSBUd28JPSBTdWNjIE9uZTsKCXR5cGUgVGhyZWUJPSBTdWNjIFR3bzsK
CXR5cGUgRm91cgk9IFN1Y2MgVGhyZWU7Cgl0eXBlIEZpdmUJPSBTdWNjIEZvdXI7Cgl0eXBlIFNp
eAk9IFN1Y2MgRml2ZTsKCXR5cGUgU2V2ZW4JPSBTdWNjIFNpeDsKCXR5cGUgRWlnaHQJPSBTdWNj
IFNldmVuOwoJdHlwZSBOaW5lCT0gU3VjYyBFaWdodDsKCXR5cGUgVGVuCT0gU3VjYyBOaW5lOwoJ
dHlwZSBNaW51c09uZSA9IFByZWQgWmVybzsKCXR5cGUgTWludXNUd28gPSBQcmVkIE1pbnVzT25l
OwoJdHlwZSBNaW51c1RocmVlID0gUHJlZCBNaW51c1R3bzsKCgljbGFzcyBTdWNjZXNzb3IgYSBi
IHwgYSAtPiBiOwoJaW5zdGFuY2UgU3VjY2Vzc29yIFplcm8gT25lOwoJaW5zdGFuY2UgU3VjY2Vz
c29yIChTdWNjIGEpIChTdWNjIChTdWNjIGEpKTsKCWluc3RhbmNlIFN1Y2Nlc3NvciAoUHJlZCBh
KSBhOwoKCWNsYXNzIFByZWRlY2Vzc29yIGEgYiB8IGEgLT4gYjsKCWluc3RhbmNlIFByZWRlY2Vz
c29yIFplcm8gTWludXNPbmU7CglpbnN0YW5jZSBQcmVkZWNlc3NvciAoU3VjYyBhKSBhOwoJaW5z
dGFuY2UgUHJlZGVjZXNzb3IgKFByZWQgYSkgKFByZWQgKFByZWQgYSkpOwoKCWNsYXNzIElzQXRM
ZWFzdCBhIGIgYyB8IGEgYiAtPiBjOyAtLSBjID09IChhID49IGIpCglpbnN0YW5jZSBJc0F0TGVh
c3QgWmVybyBaZXJvIFRydWU7CgoJaW5zdGFuY2UgSXNBdExlYXN0IFplcm8gKFByZWQgYikgVHJ1
ZTsKCWluc3RhbmNlIElzQXRMZWFzdCBaZXJvIChTdWNjIGIpIEZhbHNlOwoKCWluc3RhbmNlIElz
QXRMZWFzdCAoU3VjYyBhKSBaZXJvIFRydWU7CglpbnN0YW5jZSBJc0F0TGVhc3QgKFByZWQgYSkg
WmVybyBGYWxzZTsKCglpbnN0YW5jZSBJc0F0TGVhc3QgKFN1Y2MgYSkgKFByZWQgYikgVHJ1ZTsK
CWluc3RhbmNlIElzQXRMZWFzdCAoUHJlZCBhKSAoU3VjYyBiKSBGYWxzZTsKCglpbnN0YW5jZSAo
SXNBdExlYXN0IGEgYiBjKSA9PiBJc0F0TGVhc3QgKFN1Y2MgYSkgKFN1Y2MgYikgYzsKCWluc3Rh
bmNlIChJc0F0TGVhc3QgYSBiIGMpID0+IElzQXRMZWFzdCAoUHJlZCBhKSAoUHJlZCBiKSBjOwoK
CWNsYXNzIElzRXZlbiBhIGUgfCBhIC0+IGU7CglpbnN0YW5jZSBJc0V2ZW4gWmVybyBUcnVlOwoJ
aW5zdGFuY2UgKElzRXZlbiBhIGUsTm90IGUgbmUpID0+IElzRXZlbiAoU3VjYyBhKSBuZTsKCWlu
c3RhbmNlIChJc0V2ZW4gYSBlLE5vdCBlIG5lKSA9PiBJc0V2ZW4gKFByZWQgYSkgbmU7CgoJY2xh
c3MgQXRMZWFzdCBhIGI7IC0tIGEgPj0gYgoJaW5zdGFuY2UgKElzQXRMZWFzdCBhIGIgVHJ1ZSkg
PT4gQXRMZWFzdCBhIGI7CgoJY2xhc3MgQXRMZWFzdE9uZSBhOwoJaW5zdGFuY2UgKE5hdHVyYWxU
eXBlIGEpID0+IEF0TGVhc3RPbmUgKFN1Y2MgYSk7CgoJLS0gSW50ZWdlciBhZGRpdGlvbi4gQm90
aCBvcGVyYW5kcyBhcmUgZWl0aGVyIHBvc2l0aXZlLCBuZWdhdGl2ZQoJLS0gb3IgemVybywgc28g
d2UgY29uc2lkZXIgMyozPTkgY2FzZXMuCgljbGFzcyBBZGQgYSBiIGMgfCBhIGIgLT4gYzsKCglp
bnN0YW5jZSBBZGQgWmVybyBaZXJvIFplcm87CgoJaW5zdGFuY2UgQWRkIFplcm8gKFN1Y2MgYikg
KFN1Y2MgYik7CglpbnN0YW5jZSBBZGQgWmVybyAoUHJlZCBiKSAoUHJlZCBiKTsKCglpbnN0YW5j
ZSBBZGQgKFN1Y2MgYikgWmVybyAoU3VjYyBiKTsKCWluc3RhbmNlIEFkZCAoUHJlZCBiKSBaZXJv
IChQcmVkIGIpOwoKCWluc3RhbmNlIEFkZCBhIGIgYyA9PiBBZGQgKFN1Y2MgYSkgKFN1Y2MgYikg
KFN1Y2MgKFN1Y2MgYykpOwoJaW5zdGFuY2UgQWRkIGEgYiBjID0+IEFkZCAoUHJlZCBhKSAoUHJl
ZCBiKSAoUHJlZCAoUHJlZCBjKSk7CgoJaW5zdGFuY2UgQWRkIGEgYiBjID0+IEFkZCAoU3VjYyBh
KSAoUHJlZCBiKSBjOwoJaW5zdGFuY2UgQWRkIGEgYiBjID0+IEFkZCAoUHJlZCBhKSAoU3VjYyBi
KSBjOwoKCWNsYXNzIE5lZ2F0ZSBhIGIgfCBhIC0+IGI7CglpbnN0YW5jZSBOZWdhdGUgWmVybyBa
ZXJvOwoJaW5zdGFuY2UgKE5lZ2F0ZSBhIGIpID0+IE5lZ2F0ZSAoU3VjYyBhKSAoUHJlZCBiKTsK
CWluc3RhbmNlIChOZWdhdGUgYSBiKSA9PiBOZWdhdGUgKFByZWQgYSkgKFN1Y2MgYik7CgoJY2xh
c3MgU3ViIGEgYiBjIHwgYSBiIC0+IGM7CgoJaW5zdGFuY2UgU3ViIFplcm8gWmVybyBaZXJvOwoK
CWluc3RhbmNlIE5lZ2F0ZSBiIGMgPT4gU3ViIFplcm8gKFN1Y2MgYikgKFByZWQgYyk7CglpbnN0
YW5jZSBOZWdhdGUgYiBjID0+IFN1YiBaZXJvIChQcmVkIGIpIChTdWNjIGMpOwoKCWluc3RhbmNl
IFN1YiAoU3VjYyBiKSBaZXJvIChTdWNjIGIpOwoJaW5zdGFuY2UgU3ViIChQcmVkIGIpIFplcm8g
KFByZWQgYik7CgoJaW5zdGFuY2UgU3ViIGEgYiBjID0+IFN1YiAoU3VjYyBhKSAoU3VjYyBiKSBj
OwoJaW5zdGFuY2UgU3ViIGEgYiBjID0+IFN1YiAoUHJlZCBhKSAoUHJlZCBiKSBjOwoKCWluc3Rh
bmNlIFN1YiBhIGIgYyA9PiBTdWIgKFN1Y2MgYSkgKFByZWQgYikgKFN1Y2MgKFN1Y2MgYykpOwoJ
aW5zdGFuY2UgU3ViIGEgYiBjID0+IFN1YiAoUHJlZCBhKSAoU3VjYyBiKSAoUHJlZCAoUHJlZCBj
KSk7CgoJY2xhc3MgQWJzIGEgYiB8IGEgLT4gYjsKCWluc3RhbmNlIEFicyBaZXJvIFplcm87Cglp
bnN0YW5jZSBBYnMgKFN1Y2MgYSkgKFN1Y2MgYSk7CglpbnN0YW5jZSAoQWJzIGEgYikgPT4gQWJz
IChQcmVkIGEpIChTdWNjIGIpOwoKCWNsYXNzIEdDRCBhIGIgZ2NkIHwgYSBiIC0+IGdjZDsKCWlu
c3RhbmNlIEdDRCBaZXJvIGIgYjsKCWluc3RhbmNlIEdDRCAoU3VjYyBhKSBaZXJvIChTdWNjIGEp
OwoJaW5zdGFuY2UKCQkoCgkJU3ViIGEgYiBhbWIsCgkJQWJzIGFtYiBkaWZmLAoJCUlzQXRMZWFz
dCBaZXJvIGFtYiBhYmlnZ2VyLAoJCVBpY2sgYWJpZ2dlciBiIGEgc21hbGxlciwKCQlHQ0QgKFN1
Y2Mgc21hbGxlcikgZGlmZiBnY2QKCQkpCgkJPT4gR0NEIChTdWNjIGEpIChTdWNjIGIpIGdjZDsK
CgktLSBvbmx5IGluc3RhbmNlcyBmb3IgYSBtb2QgYiA9PSAwCgljbGFzcyBEaXZpZGUgYSBiIGMg
fCBhIGIgLT4gYzsKCWluc3RhbmNlCgkJKAoJCU5lZ2F0ZSBhIG5hLAoJCU5lZ2F0ZSBiIG5iLAoJ
CURpdmlkZSBuYSAoU3VjYyBuYikgYwoJCSkKCQk9PiBEaXZpZGUgYSAoUHJlZCBiKSBjOwoJaW5z
dGFuY2UgRGl2aWRlIFplcm8gKFN1Y2MgYikgWmVybzsKCWluc3RhbmNlCgkJKAoJCVN1YiBhIGIg
YW1iLAoJCURpdmlkZSBhbWIgKFN1Y2MgYikgYwoJCSkKCQk9PiBEaXZpZGUgKFN1Y2MgYSkgKFN1
Y2MgYikgKFN1Y2MgYyk7CglpbnN0YW5jZQoJCSgKCQlBZGQgYSBiIGFwYiwKCQlEaXZpZGUgYXBi
IChTdWNjIGIpIGMKCQkpCgkJPT4gRGl2aWRlIChQcmVkIGEpIChTdWNjIGIpIChQcmVkIGMpOwoJ
CglkYXRhIFJhdGlvbmFsVHlwZSBudW0gZGVub207CgkKCWNsYXNzIE1ha2VSYXRpb25hbCBuIGQg
ciB8IG4gZCAtPiByOwoJaW5zdGFuY2UKCQkoCgkJR0NEIG4gZCBnY2QsCgkJRGl2aWRlIG4gZ2Nk
IG51bSwKCQlEaXZpZGUgZCBnY2QgZGVub20KCQkpCgkJPT4gTWFrZVJhdGlvbmFsIG4gZCAoUmF0
aW9uYWxUeXBlIG51bSBkZW5vbSk7Cgl9Cg==
--Emailer_-1223820195--
From mark@chaos.x-philes.com Mon Apr 23 04:19:36 2001
Date: Sun, 22 Apr 2001 23:19:36 -0400 (EDT)
From: Mark Carroll mark@chaos.x-philes.com
Subject: Novice question
Is this a good place for novice questions? I have just started to try to
learn Haskell, and am using Hugs to start with. When I write the
not-very-useful function,
greaterthan 0 _ _ = False
greaterthan _ (x:xs) (y:ys) = x > y
and test it,
Main> greaterthan 2 [3] [4]
False
Main> greaterthan 3 [4] [3]
True
Main> greaterthan 0 [4] [3]
False
Main> greaterthan 0 [] []
ERROR: Unresolved overloading
*** Type : Ord a => Bool
*** Expression : greaterthan 0 [] []
Main>
...I don't understand what the problem is. I'm guessing that the problem
is with the use of > and it not knowing which 'version' of > to use, but
it doesn't need to know because we're not matching with that line anyway.
I hope that didn't sound quite as confused as I am. (-:
Is there anything easy someone can say that will enlighten me as to why
things are as they are?
(I understand that Ord is a set of types and that you can probably only
apply > to things that are in it, and that > is overloaded somehow.)
Thanks.
-- Mark
From Tom.Pledger@peace.com Mon Apr 23 04:41:47 2001
Date: Mon, 23 Apr 2001 15:41:47 +1200
From: Tom Pledger Tom.Pledger@peace.com
Subject: Novice question
Mark Carroll writes:
| Is this a good place for novice questions?
Yes, either here or on http://haskell.org/wiki/wiki
| greaterthan 0 _ _ = False
| greaterthan _ (x:xs) (y:ys) = x > y
:
| Main> greaterthan 0 [] []
| ERROR: Unresolved overloading
| *** Type : Ord a => Bool
| *** Expression : greaterthan 0 [] []
|
| Main>
|
| ...I don't understand what the problem is. I'm guessing that the problem
| is with the use of > and it not knowing which 'version' of > to use, but
| it doesn't need to know because we're not matching with that line anyway.
| I hope that didn't sound quite as confused as I am. (-:
Your guess is basically right. The error can be fixed by specifying
`the type of element that the lists do not contain', so to speak.
greaterthan 0 [] ([] :: [()]) -- empty list of ()
greaterthan 0 [] ([] :: [Bool]) -- empty list of Bool
greaterthan 0 [] "" -- empty list of Char
This need for an explicit type signature is quite common in
out-of-context tests at an interpreter's prompt, but rarer in actual
programs.
HTH.
Tom
From fjh@cs.mu.oz.au Mon Apr 23 18:43:44 2001
Date: Tue, 24 Apr 2001 03:43:44 +1000
From: Fergus Henderson fjh@cs.mu.oz.au
Subject: Novice question
On 22-Apr-2001, Mark Carroll <mark@chaos.x-philes.com> wrote:
> greaterthan 0 _ _ = False
> greaterthan _ (x:xs) (y:ys) = x > y
...
> Main> greaterthan 0 [] []
> ERROR: Unresolved overloading
> *** Type : Ord a => Bool
> *** Expression : greaterthan 0 [] []
>
> ...I don't understand what the problem is. I'm guessing that the problem
> is with the use of > and it not knowing which 'version' of > to use,
Yes.
> but it doesn't need to know because we're not matching with that line anyway.
The type checker doesn't know that.
The type checker only takes into account the types of the arguments,
not their values, so it can't tell when an ambiguity like this
doesn't matter because the ambiguous code won't be executed.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
From shae@webwitches.com Sun Apr 29 13:54:03 2001
Date: Sun, 29 Apr 2001 15:54:03 +0300
From: Shae Erisson shae@webwitches.com
Subject: tutorial and other random bits
Hi, I've started learning Haskell, but I'm coming from a Python/Java/SQL/etc background.
I've learned a bit of elisp and scheme in my travels, but Haskell is very very different even from those two.
The gentle introduction seems more like a brickbat to me, the best things I've found so far are homework assignments from various CS classes around the world.
I've looked for a good irc channel dedicated to haskell, and not found one. I've also searched for a tutorial that works along the same lines as the Python tutorial, and not found one.
I have lots of complete beginner questions...
Also, it seems the Haskell Wiki has lost many pages again. Would it be possible to use MoinMoin instead of pyWiki?
I looked at the "applications written in Haskell" links, but many of the links are dead.
I have found some sample code by searching google, but I'd really like to find a library of small pieces of demo code showing the various idioms and useful basics. Does such a thing exist?
Thanks,
----
Shae Matijs Erisson - http://www.webwitches.com/~shae/
From khchoi@ruby.kaist.ac.kr Sun Apr 29 14:53:09 2001
Date: Sun, 29 Apr 2001 22:53:09 +0900 (KST)
From: Kwanghoon Choi khchoi@ruby.kaist.ac.kr
Subject: tutorial and other random bits
Hi,
I have an OLD web page entitled "Haskell Programming in the Imaginary World".
The web page contains only several small Haskell programs and it just
reflects my unorganized thoughts and programs. Some of them may not follow
the Haskell 98 definition. So, it may not be the one that you are looking for.
But I had the same opinion as yours when I made the web page.
> I have found some sample code by searching google, but I'd really like
> to find a library of small pieces of demo code showing the
> various idioms and useful basics. Does such a thing exist?
http://pllab.kaist.ac.kr/~khchoi/haskell/
Kwanghoon
On Sun, 29 Apr 2001, Shae Erisson wrote:
> Hi, I've started learning Haskell, but I'm coming from a Python/Java/SQL/etc background.
> I've learned a bit of elisp and scheme in my travels, but Haskell is very very different even from those two.
>
> The gentle introduction seems more like a brickbat to me, the best things I've found so far are homework assignments from various CS classes around the world.
>
> I've looked for a good irc channel dedicated to haskell, and not found one. I've also searched for a tutorial that works along the same lines as the Python tutorial, and not found one.
>
> I have lots of complete beginner questions...
>
> Also, it seems the Haskell Wiki has lost many pages again. Would it be possible to use MoinMoin instead of pyWiki?
>
> I looked at the "applications written in Haskell" links, but many of the links are dead.
> I have found some sample code by searching google, but I'd really like to find a library
> of small pieces of demo code showing the various idioms and useful basics. Does such a thing exist?
> Thanks,
> ----
> Shae Matijs Erisson - http://www.webwitches.com/~shae/
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
From djelovic@sezampro.yu Sun Apr 1 21:02:29 2001
From: djelovic@sezampro.yu (Dejan Jelovic)
Date: Sun, 1 Apr 2001 22:02:29 +0200
Subject: "Lambda Dance", Haskell polemic, etc. on O'Reilly site
Message-ID: <002401c0bae6$af7fb300$7600a8c0@katana>
Jerzy Karczmarczuk wrote:
> Over and over again the same silly song, by a person who - visibly -
> had never anything to do with functional languages, who thinks now
> about hiring some C and java programmers living in Belgrade
I don't understand how you deduced I "never had anything to do with
functional languages"? Any how is it relevant to the subject at hand that
I'm hiring Java and C++ (not C) programmers in Belgrade?
> but who
> writes such silly, incompetent things as:
>
> > And there is an air of staleness: where new versions of these other
> > languages appear frequently, the Haskell community is offering you
> > Hugs98.
I don't see why what I said is silly or incompetent? The Haskell Compiler
and Interpreters page at haskell.org suggests Hugs98 for newcomers. While
you and I know that the latest version of Hugs has been released two weeks
ago, a curious visitor will wonder why there isn't Hugs 2001.
And the Haskell website is updated rarely in contrast with, say, the Python
website.
> Delovic points out that some languages became "immensely" popular,
> as e.g. Ruby, and that Haskell is marginal. Hm. this extremely
> orthodox Japanese essence of O-O programming may have some practical
> merits, especially those which come from shameless borrowing from
> Eiffel, Sather, Clu and Common Lisp, but calling Haskell "marginal"
> or "obscure" informs us not what is Haskell, but who is Jelovic.
Compared to the usage of C++, Java or Python, the usage of Haskell is
_marginal_. Visit the computer section of your local bookstore if you need
to be reminded of that.
BTW, you seem to be well-informed about who this Jelovic is. Why don't you
share that knowledge with us? :)
> He accuses the Haskell community of not providing libraries...
Two errors here:
1. I didn't accuse anybody of anything. I was just curious about why people
aren't using Haskell and started to think about it. There's a saying among
Program Managers at Microsoft that "thinking is writing". I subscribe to
that. I often write about things I think about in order to explore the
issues. If I think other people might be interested in the end result, I
post it.
2. I didn't say that the Haskell community has not provided the libraries. I
said the Haskell community hasn't provided the libraries together with the
compiler in one standard distribution. I think that's needed in order to
lower the barrier to entry.
> Perhaps there is *one* point worth mentioning: the necessity to
> publish papers about Haskell far from such journals as JFP or HOSC,
> but to try to reach DrDobbs etc.
Funny. You said at the beginning of your message that there is "NOTHING"
serious there. :)
Dejan
http://www.jelovic.com
From bhalchin@hotmail.com Sun Apr 1 22:56:53 2001
From: bhalchin@hotmail.com (Bill Halchin)
Date: Sun, 01 Apr 2001 21:56:53
Subject: "Lambda Dance", Haskell polemic, etc. on O'Reilly site
Message-ID:
Hello,
I think Dejan has written in a good spirit and has many cogent
points, especially for example with regard to Python. I guess the
bottom line is don't be too think-skinned about what seems to me to
be constructive criticism. In the FPL community, it is easy to
maintain a siege mentality. Before I worked at Microsoft Hotmail.
I asked one person (well known) who does research at Microsoft
Research on Haskell. I asked him if any projects inside Microsoft
were implemented using Haskell and he said no. Of course, this is
not his fault. Management has to see that they are not going "out on
a limb" to use FPLs. I know that Sun wrote at least one tool in
Scheme (albeit it doesn't have ref. transparency).
Regards,
Bill Halchin
>From: "Dejan Jelovic"
>To:
>CC:
>Subject: Re: "Lambda Dance", Haskell polemic, etc. on O'Reilly site
>Date: Sun, 1 Apr 2001 22:02:29 +0200
>
>Jerzy Karczmarczuk wrote:
>
> > Over and over again the same silly song, by a person who - visibly -
> > had never anything to do with functional languages, who thinks now
> > about hiring some C and java programmers living in Belgrade
>
>I don't understand how you deduced I "never had anything to do with
>functional languages"? Any how is it relevant to the subject at hand that
>I'm hiring Java and C++ (not C) programmers in Belgrade?
>
> > but who
> > writes such silly, incompetent things as:
> >
> > > And there is an air of staleness: where new versions of these other
> > > languages appear frequently, the Haskell community is offering you
> > > Hugs98.
>
>I don't see why what I said is silly or incompetent? The Haskell Compiler
>and Interpreters page at haskell.org suggests Hugs98 for newcomers. While
>you and I know that the latest version of Hugs has been released two weeks
>ago, a curious visitor will wonder why there isn't Hugs 2001.
>
>And the Haskell website is updated rarely in contrast with, say, the Python
>website.
>
> > Delovic points out that some languages became "immensely" popular,
> > as e.g. Ruby, and that Haskell is marginal. Hm. this extremely
> > orthodox Japanese essence of O-O programming may have some practical
> > merits, especially those which come from shameless borrowing from
> > Eiffel, Sather, Clu and Common Lisp, but calling Haskell "marginal"
> > or "obscure" informs us not what is Haskell, but who is Jelovic.
>
>Compared to the usage of C++, Java or Python, the usage of Haskell is
>_marginal_. Visit the computer section of your local bookstore if you need
>to be reminded of that.
>
>BTW, you seem to be well-informed about who this Jelovic is. Why don't you
>share that knowledge with us? :)
>
> > He accuses the Haskell community of not providing libraries...
>
>Two errors here:
>
>1. I didn't accuse anybody of anything. I was just curious about why people
>aren't using Haskell and started to think about it. There's a saying among
>Program Managers at Microsoft that "thinking is writing". I subscribe to
>that. I often write about things I think about in order to explore the
>issues. If I think other people might be interested in the end result, I
>post it.
>
>2. I didn't say that the Haskell community has not provided the libraries.
>I
>said the Haskell community hasn't provided the libraries together with the
>compiler in one standard distribution. I think that's needed in order to
>lower the barrier to entry.
>
> > Perhaps there is *one* point worth mentioning: the necessity to
> > publish papers about Haskell far from such journals as JFP or HOSC,
> > but to try to reach DrDobbs etc.
>
>Funny. You said at the beginning of your message that there is "NOTHING"
>serious there. :)
>
>Dejan
>http://www.jelovic.com
>
>
>
>_______________________________________________
>Haskell-Cafe mailing list
>Haskell-Cafe@haskell.org
>http://www.haskell.org/mailman/listinfo/haskell-cafe
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
From karczma@info.unicaen.fr Mon Apr 2 13:10:25 2001
From: karczma@info.unicaen.fr (Jerzy Karczmarczuk)
Date: Mon, 02 Apr 2001 13:10:25 +0100
Subject: "Lambda Dance", Haskell polemic,...
References: <002401c0bae6$af7fb300$7600a8c0@katana>
Message-ID: <3AC86C31.39BB80FD@info.unicaen.fr>
Dejan Jelovic wrote:
>
> Jerzy Karczmarczuk wrote:
>
> > Over and over again the same silly song, by a person who - visibly -
> > had never anything to do with functional languages, who thinks now
> > about hiring some C and java programmers living in Belgrade
>
> I don't understand how you deduced I "never had anything to do with
> functional languages"? Any how is it relevant to the subject at hand that
> I'm hiring Java and C++ (not C) programmers in Belgrade?
Well, I managed to annoy you. Sorry. I exploded. I still think you
merited
a good part of it, although I might reformulate it more calmly today.
1. I didn't find ANYTHING about FP on your pages, only that accusations.
2. I don't remember any of your eventual contribution to discussion
lists,
newsgroups, etc. I might be wrong. Please give some references,
publications, functional software, etc. I will apologize then
immediately,
with regret, but also with satisfaction that the Truth won.
3. Personally you don't care about Haskell. Your page *explicitly*
discourages local people from touching functional languages, the
category
of people you want to hire is a very strong signal.
A potential employer who does what you did serves the devil, don't
try
to suggest that this isn't relevant.
> > but who
> > writes such silly, incompetent things as:
> >
> > > And there is an air of staleness: where new versions of these other
> > > languages appear frequently, the Haskell community is offering you
> > > Hugs98.
>
> I don't see why what I said is silly or incompetent? The Haskell Compiler
> and Interpreters page at haskell.org suggests Hugs98 for newcomers. While
> you and I know that the latest version of Hugs has been released two weeks
> ago, a curious visitor will wonder why there isn't Hugs 2001.
>
> And the Haskell website is updated rarely in contrast with, say, the Python
> website.
1. Saying that the Haskell community offers Hugs98, and not mentioning
neither
GHC, nor NHC is either incompetent or provocative. Sorry. It is not
my intent
to quarrel, nor to offense anybody. But presenting such limited
information
on your page is a very bad job for the community. Very bad and not
too moral.
2. A decent programming language *must* be stable. If the main criterion
of
the "quality" you attribute to programming languages is the speed of
its
modifications, I wonder what don't you accuse of staleness your
favourite
languages: Java and C++.
3. The fact that Hugs is suggested as a good introductory implementation
- because it is inexpensive in resource consumption and interactive -
is a
very good point, not an argument against. It has nothing to do btw.
with
your opinion of the *language*, just another pretext to say nasty
things.
Hugs 2001???? Are you sure that you really know what does it mean
a STANDARD?
Show me C++2001, please.
> > Delovic points out that some languages became "immensely" popular,
> > as e.g. Ruby, and that Haskell is marginal. Hm. this extremely
> > orthodox Japanese essence of O-O programming may have some practical
> > merits, especially those which come from shameless borrowing from
> > Eiffel, Sather, Clu and Common Lisp, but calling Haskell "marginal"
> > or "obscure" informs us not what is Haskell, but who is Jelovic.
>
> Compared to the usage of C++, Java or Python, the usage of Haskell is
> _marginal_. Visit the computer section of your local bookstore if you need
> to be reminded of that.
[Sorry for the error in your name. Fingerslip.]
1. Oh yes. Thousands of books about Ruby. Actually one, in Japanese.
Have you looked here:
http://www.haskell.org/bookshelf/
This is comparable with Python. Of course, Python IS more popular,
but - -
2. You neglect, and I suspect that you do it on purpose, that the main
driving force behind the evolution of Haskell is *RESEARCH*. An issue
absent from many "popular" languages which are meant to be
immediately
exploitable with very flat learning curve. Haskell is vivid at
universi-
ties, almost every decent higher-education establishment has its
imple-
mentation. The documentation on line is sufficiently good that e.g. -
my
students won't even think about going and trying to buy a book.
Money...
[[University libraries, at least in France is another issue. We are
*not*
doing a good job here...]]
Still, there are more publications on FP every month that I can
digest.
What about Python? Java?
> BTW, you seem to be well-informed about who this Jelovic is. Why don't you
> share that knowledge with us? :)
Oh, but I did.
You seem to be a self-appointed specialist on functional languages, who
expresses in public some very dubious truths, which I find harmful.
That's
all. I know nothing about your status nor the colour of your tongue, I
am
speaking about your image in *this* context. Most of people reading this
forum will shrug, and throw to the waste-paper basket both postings,
yours
and mine, and this is good. Nothing more to say about you, and if you
wish,
I may reformulate my statements:
"Such biased and incomplete assessment of functional languages should be
treated not as an information about those languages, but as an
information
about the competence and/or good will of the Author".
> > He accuses the Haskell community of not providing libraries...
>
> Two errors here:
>
> 1. I didn't accuse anybody of anything. I was just curious about why people
> aren't using Haskell and started to think about it.
I understood this in such a way. You didn't ask questions "why", I
haven't seen
this curiosity. Perhaps I missed something vitally important between
lines.
You are explicitly negative in your *judgement*.
> 2. I didn't say that the Haskell community has not provided the libraries. I
> said the Haskell community hasn't provided the libraries together with the
> compiler in one standard distribution. I think that's needed in order to
> lower the barrier to entry.
There are hundreds of libraries of Java classes and C++ classes and
procedures
which are distributed separately. The "standard" GNU distribution of C++
is
quite limited, there is no point in overloading the standard environment
by
things whose usage is limited. The ease of installation is also
important.
BTW. the GHC "standard" distribution has an adequate amount of runtime
support
for normal tasks. It worked for me without any problem.
(And, the "standard" libraries of platform-specific C distributions:
M.Soft,
Borland, Solaris etc. are quite different...)
> > Perhaps there is *one* point worth mentioning: the necessity to
> > publish papers about Haskell far from such journals as JFP or HOSC,
> > but to try to reach DrDobbs etc.
>
> Funny. You said at the beginning of your message that there is "NOTHING"
> serious there. :)
RRight. I found one point worth mentioning. Wonderful, splendid, and
original.
Hereby I declare that you are the winner of this discussion, and I am
the
loser. Complete KO.
=====================
Bill Halchin defends D. J.:
> I think Dejan has written in a good spirit and has many cogent
> points, especially for example with regard to Python. I guess the
> bottom line is don't be too think-skinned about what seems to me to
> be constructive criticism. In the FPL community, it is easy to
> maintain a siege mentality.
I scratch my head, and I cannot understand how could I recognize from
the incriminated page the "constructive criticism" and "good spirit".
What I have seen is a total negation, not a single good word, some
cheap pieces of advice (about the publications), and plenty of
misunderstanding (about the relation between the liveness and the
frequency of changes of a language).
It is very easy to criticize a programming language, especially the one
you don't like nor use personally. This is so cheap, that I find it
simply disgusting. (So, I have even *defended* PERL on another forum,
although I don't like it.)
I have nothing personal against Dejan Jelovic. My "contribution" to the
FP community is - in this context - to show that our opponents are, hmm,
how to say it, in order to avoid offensive words - basing their
criticism
on false premises, and they perhaps should learn what is the current
status of the proposed implementations, before publishing their
"analyses".
Jerzy Karczmarczuk
Caen, France
From v-julsew@microsoft.com Mon Apr 2 14:57:21 2001
From: v-julsew@microsoft.com (Julian Seward (Intl Vendor))
Date: Mon, 2 Apr 2001 06:57:21 -0700
Subject: "Lambda Dance", Haskell polemic, etc. on O'Reilly site
Message-ID: <68B95AA1648D1840AB0083CC63E57AD60F22F8@red-msg-06.redmond.corp.microsoft.com>
S. Alexander Jacobsen wrote:
| Although I think Haskell is a beautiful language, Jelovic is right on
his
| core points, Haskell implementations don't meet the needs of=20
| the working programmer.
[...]
I also largely agree with Jelovic, and I take what he says as
constructive criticism.
One observation at least as regards Perl and Python is that=20
Haskell has a very much more academically-intense heritage,
whereas Perl and (guessing here) Python were motivated more=20
by end-user need. GHC and Hugs suffer from tensions between=20
being research vehicles and being practical implementations=20
suitable for end-users. I'd guess that Perl and Python don't=20
suffer from such tensions, so their implementors can concentrate=20
more directly on providing excellent implementations suitable=20
for widespread use.
I say nothing about Ruby because I know nothing about it.
A second observation is that Perl and Python are both single
-implementation languages, which makes it easier to have a=20
coherent set of libraries. Haskell, by contrast, isn't
-- there are at least 4 available implementations (hbc, hugs,
nhc, ghc). The core language (Haskell98) is supported by all
of these, but there isn't a coherent story on the libraries.
We are working on that. This plurality of implementations has
worked well for the diverse research interests centered around
Haskell. I think there is now a growing feeling that we need
to standardise the libraries more and put more emphasis on=20
end-user issues -- the kind of things Jelovic mentions --
if Haskell is to have a long-term future.
Here at GHC HQ we are trying hard to make GHC into a suitable
vehicle for widespread use. The upcoming GHC version 5 should
go some way to addressing issues of installability, library
coverage and speed of compilation.
As Simon Marlow pointed out, if you feel motivated to help us
work on the libraries, that would be excellent.
I think it's worth clarifying a couple of potential misunderstandings
with the original posting:
-- The current version of Hugs is called hugs98 not because
the implementation was last revised in 1998 but because it
implements the language as standardised in 1998. Hugs is
actively maintained.
-- Hugs is not the only Haskell implementation. Ours, GHC,=20
strives hard to provide a coherent, complete set of libraries
in the standard distribution. NHC is also moving in that
direction. We are not yet there, but are, at least, proceeding.
J
From alex@shop.com Mon Apr 2 15:59:46 2001
From: alex@shop.com (S. Alexander Jacobson)
Date: Mon, 2 Apr 2001 10:59:46 -0400 (Eastern Daylight Time)
Subject: "Lambda Dance", Haskell polemic, etc. on O'Reilly site
In-Reply-To: <68B95AA1648D1840AB0083CC63E57AD60F22F8@red-msg-06.redmond.corp.microsoft.com>
Message-ID:
FYI, there are multiple python implementations out there.
See
http://starbase.neosoft.com/~claird/comp.lang.python/python_varieties.html
Of particular note here is Vyper implemented in OCAML, which adds tail
calls, list comprehensions, lexical scoping, full garbage collection, and
pattern matching to Python...
-Alex-
___________________________________________________________________
S. Alexander Jacobson Shop.Com
1-646-638-2300 voice The Easiest Way To Shop (sm)
On Mon, 2 Apr 2001, Julian Seward (Intl Vendor) wrote:
>
> S. Alexander Jacobsen wrote:
>
> | Although I think Haskell is a beautiful language, Jelovic is right on
> his
> | core points, Haskell implementations don't meet the needs of
> | the working programmer.
> [...]
>
> I also largely agree with Jelovic, and I take what he says as
> constructive criticism.
>
> One observation at least as regards Perl and Python is that
> Haskell has a very much more academically-intense heritage,
> whereas Perl and (guessing here) Python were motivated more
> by end-user need. GHC and Hugs suffer from tensions between
> being research vehicles and being practical implementations
> suitable for end-users. I'd guess that Perl and Python don't
> suffer from such tensions, so their implementors can concentrate
> more directly on providing excellent implementations suitable
> for widespread use.
>
> I say nothing about Ruby because I know nothing about it.
>
> A second observation is that Perl and Python are both single
> -implementation languages, which makes it easier to have a
> coherent set of libraries. Haskell, by contrast, isn't
> -- there are at least 4 available implementations (hbc, hugs,
> nhc, ghc). The core language (Haskell98) is supported by all
> of these, but there isn't a coherent story on the libraries.
> We are working on that. This plurality of implementations has
> worked well for the diverse research interests centered around
> Haskell. I think there is now a growing feeling that we need
> to standardise the libraries more and put more emphasis on
> end-user issues -- the kind of things Jelovic mentions --
> if Haskell is to have a long-term future.
>
> Here at GHC HQ we are trying hard to make GHC into a suitable
> vehicle for widespread use. The upcoming GHC version 5 should
> go some way to addressing issues of installability, library
> coverage and speed of compilation.
>
> As Simon Marlow pointed out, if you feel motivated to help us
> work on the libraries, that would be excellent.
>
> I think it's worth clarifying a couple of potential misunderstandings
> with the original posting:
>
> -- The current version of Hugs is called hugs98 not because
> the implementation was last revised in 1998 but because it
> implements the language as standardised in 1998. Hugs is
> actively maintained.
>
> -- Hugs is not the only Haskell implementation. Ours, GHC,
> strives hard to provide a coherent, complete set of libraries
> in the standard distribution. NHC is also moving in that
> direction. We are not yet there, but are, at least, proceeding.
>
> J
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
From qrczak@knm.org.pl Mon Apr 2 17:27:11 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 2 Apr 2001 16:27:11 GMT
Subject: "Lambda Dance", Haskell polemic, etc. on O'Reilly site
References:
Message-ID:
Mon, 2 Apr 2001 10:59:46 -0400 (Eastern Daylight Time), S. Alexander Jacobson pisze:
> http://starbase.neosoft.com/~claird/comp.lang.python/python_varieties.html
>
> Of particular note here is Vyper implemented in OCAML, which adds tail
> calls, list comprehensions, lexical scoping, full garbage collection, and
> pattern matching to Python...
I was unable to run Vyper (after solving problems with compilation
it does just SIGSEGV). But list comprehensions, lexical scoping and
an improved garbage collection (cycles are collected) are already
in CPython (well, lexical scoping is in beta versions). Python is
changing quite fast.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From jlibsch@mail.wesleyan.edu Mon Apr 2 17:57:46 2001
From: jlibsch@mail.wesleyan.edu (Jason J. Libsch)
Date: Mon, 2 Apr 2001 12:57:46 -0400 (EDT)
Subject: Visual Haskell
In-Reply-To: <20010402160103.A1F82255CB@www.haskell.org>
Message-ID:
I recently ran across a paper, Visual Haskell- a First Attempt, and was
tremendously impressed. Has anybody here played with this language or
read the paper? I would be interested to hear other's opinion on such a
language.
http://ptolemy.eecs.berkeley.edu/~johnr/papers/visual.html
/jason
From Toby Watson"
Message-ID: <02cb01c0bb9c$a41a8e70$9301010a@tobe>
Hi, Good find!
NB: I just skimmed the paper so far, but it is a long-term area of interest
for me...
I find most of these visual systems awkward to use in practice. Quite often
this is because they have very poor interface designs (they are like old
modal CAD systems). This is troublesome, leading many - I believe - to
suggest that the idea is not plausible.
I think that a usable visual programming language is possible but it would
have to be a good graphical tool rather than just a translation of a textual
language.
I am encouraged by the FP notion of the creation of new glue, as if you
could create new control structures and domain specific languages. Once this
concept has been incorporated, i.e. the user-development of new visual
syntax as first class then I think we will see some progress in VPLs.
Unfortunately this is a big task, to my mind it involves revising our
current method of building interactive software (the event loop) to make it
more modular and reasonable to expect users to contribute new modules or
systems thereof. The FP community have delivered a number of promising
architectures (Haggis, Fudgets, Exene) in this area as has Rob Pike
(newsqueak, 8 and a half, mux?).
My interest in the area was peaked by a presentation on VPL. VPL was
exceptionally usable dataflow image-processing oriented system. It had
functions as first class objects and apply.
http://www.camazotz.com/vplpaper.html
On related note the types of a function adding two integers together, two
lists of integers together and dataflow or pipe adding two streams of
integers together would seem to be similar. Does anyone know of some formal
work on this, what are the terms I would use to investigate?
I think you can see where I'm going with this - the user has a notion of
'things connected together', but without being too concerned about the
underlying system. I imagine a 'live' type system flagging up mismatches. I
think there is analagous situation when beginners try to plumb monads
together with pure code. The idea would be to get visual syntax to help out.
Consider the conversation, "Oh, you can connect red stripey objects together
but when you want to join up a blue object you need a red/blue adaptor".
cheers,
Toby
----- Original Message -----
From: "Jason J. Libsch"
To:
Sent: Monday, April 02, 2001 5:57 PM
Subject: Visual Haskell
> I recently ran across a paper, Visual Haskell- a First Attempt, and was
> tremendously impressed. Has anybody here played with this language or
> read the paper? I would be interested to hear other's opinion on such a
> language.
>
> http://ptolemy.eecs.berkeley.edu/~johnr/papers/visual.html
>
>
> /jason
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
From jlibsch@mail.wesleyan.edu Mon Apr 2 20:39:20 2001
From: jlibsch@mail.wesleyan.edu (Jason J. Libsch)
Date: Mon, 2 Apr 2001 15:39:20 -0400 (EDT)
Subject: Visual Haskell
In-Reply-To: <02cb01c0bb9c$a41a8e70$9301010a@tobe>
Message-ID:
The reason that this paper so peaked my interest is that i have been
working on a system that is tremendously similar to the one described in
this paper- it's as if Dr. Reekie Van Eck phreaked my head or notebooks
(unfortunatly, my designs have not progressed past pen and paper.) from
the other side of the world. My take on the project is that such a
language would be the ideal langauge for begining programmers.
1) As Toby stated, the Strong Typeing of Haskell allows for a 'syntaxless'
development environment. Only inputs and outputs that type correctly can
connect. This means that all code that can be written will compile!
2) Easy to navigate through code. If a fn is foreign to the user, she
need only click on it to bring up its the underlying code.
3) It seems to me that such an environment would strongly encourage
collaboration. Having two mouse pointers dragging compenents around is
much less foreign of an asthetic than text just randomly poping up here
and there, or some such text based equivalent. The analogy i have been
working with is: two mouse pointers on the same screen can work together
like two hands- one can hold a wrench on the bolt while the other turns
the screw, while two clarets in action is like listening to two people
talk at once.
4) A visual environment allows for the seemless integration of advanced
code development tools as CVS (isn't CVS just a fancy C^z, C^ [Shift] z
?) Help or Code Documentation, etc.
5) Ability to truly design from the top down- all the way from the Gui.
An integrated GUI construction tool would be right at home in a visual
language.
6) Much more elaborate and illuminating comment system. Allowing for
dashed outlines and arrows pointing at code to be integrated into a
comment, to be shown only on the comment's mouse over event. Can drag
components (fn block) into comment, which can be clicked on to bring up
that comment in hyper text fassion, etc.
Modeling the visual language after a function langauge makes tons of
sence. Once you take this step, the visual systax follows nicely, and, i
think, looks and feels very clean.
My appologies for such the gushing tennor of this letter. I know much of
the praise i sing for a Visual Haskell is generic visual programming
propoganda, and that visual langauges for software development haven't
taken off. I think that the coupeling of a high level, robust,
funcitonal language with the visual paradime solves many visual
langauge problems, and, furthermore, presents new benfits all together.
I am eager to hear the opinions of this list.
my best,
/jason libsch
On Mon, 2 Apr 2001, Toby Watson wrote:
> Hi, Good find!
>
> NB: I just skimmed the paper so far, but it is a long-term area of interest
> for me...
>
> I find most of these visual systems awkward to use in practice. Quite often
> this is because they have very poor interface designs (they are like old
> modal CAD systems). This is troublesome, leading many - I believe - to
> suggest that the idea is not plausible.
>
> I think that a usable visual programming language is possible but it would
> have to be a good graphical tool rather than just a translation of a textual
> language.
>
> I am encouraged by the FP notion of the creation of new glue, as if you
> could create new control structures and domain specific languages. Once this
> concept has been incorporated, i.e. the user-development of new visual
> syntax as first class then I think we will see some progress in VPLs.
> Unfortunately this is a big task, to my mind it involves revising our
> current method of building interactive software (the event loop) to make it
> more modular and reasonable to expect users to contribute new modules or
> systems thereof. The FP community have delivered a number of promising
> architectures (Haggis, Fudgets, Exene) in this area as has Rob Pike
> (newsqueak, 8 and a half, mux?).
>
> My interest in the area was peaked by a presentation on VPL. VPL was
> exceptionally usable dataflow image-processing oriented system. It had
> functions as first class objects and apply.
> http://www.camazotz.com/vplpaper.html
>
> On related note the types of a function adding two integers together, two
> lists of integers together and dataflow or pipe adding two streams of
> integers together would seem to be similar. Does anyone know of some formal
> work on this, what are the terms I would use to investigate?
>
> I think you can see where I'm going with this - the user has a notion of
> 'things connected together', but without being too concerned about the
> underlying system. I imagine a 'live' type system flagging up mismatches. I
> think there is analagous situation when beginners try to plumb monads
> together with pure code. The idea would be to get visual syntax to help out.
> Consider the conversation, "Oh, you can connect red stripey objects together
> but when you want to join up a blue object you need a red/blue adaptor".
>
> cheers,
> Toby
>
> ----- Original Message -----
> From: "Jason J. Libsch"
> To:
> Sent: Monday, April 02, 2001 5:57 PM
> Subject: Visual Haskell
>
>
> > I recently ran across a paper, Visual Haskell- a First Attempt, and was
> > tremendously impressed. Has anybody here played with this language or
> > read the paper? I would be interested to hear other's opinion on such a
> > language.
> >
> > http://ptolemy.eecs.berkeley.edu/~johnr/papers/visual.html
> >
> >
> > /jason
> >
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
>
>
From jans@numeric-quest.com Mon Apr 2 22:37:35 2001
From: jans@numeric-quest.com (Jan Skibinski)
Date: Mon, 2 Apr 2001 17:37:35 -0400 (EDT)
Subject: Visual Haskell
In-Reply-To:
Message-ID:
On Mon, 2 Apr 2001, Jason J. Libsch wrote:
> The reason that this paper so peaked my interest is that i have been
> working on a system that is tremendously similar to the one described in
> this paper- it's as if Dr. Reekie Van Eck phreaked my head or notebooks
> (unfortunatly, my designs have not progressed past pen and paper.) from
> the other side of the world. My take on the project is that such a
> language would be the ideal langauge for begining programmers.
The pictures in the paper look somehow familiar to what
I had invented and implemented in Smalltalk once upon
a time for a commercial product. It was more of
a hack, but a good hack, I believe.
This perhaps gives me a right to these two comments:
If you try to be too generic you might end up with
something that is too complex for a beginner but too
dumb for an expert user. I've seen two Smalltalk
packages which attempted connecting "phone books" to
"editors" and to other gimmicks and would end up
with some incomprehensible jungle of wires, inputs
and outputs .. and some limitations that would
force you to do textual programming anyway.
However, for a specific application domain this should
work perfectly well. My experience with my own package
was such that the visual interface was a high selling
point, and the salesmen loved it too: they could
use it to design all sorts of demos and then hand them
over to their junior people to carry on with the demos.
So perhaps you would do better if you'd tone down your
entusiasm a bit about generality of visual programming
("an ideal language for beginning programmers") and
focus on some domain specific applications instead.
This does not mean that you could not reuse the
framework. Quite to contrary! For example, I had
supported two different libraries of nodes (with
pretty icons): one for DSP and another for simulation
of noise control in ventilation systems. Two different
applications, two different audiences, two different
libraries, but the framework was the same.
Jan
From brian@boutel.co.nz Tue Apr 3 04:36:54 2001
From: brian@boutel.co.nz (Brian Boutel)
Date: Tue, 03 Apr 2001 15:36:54 +1200
Subject: "Lambda Dance", Haskell polemic,...
References: <002401c0bae6$af7fb300$7600a8c0@katana> <3AC86C31.39BB80FD@info.unicaen.fr>
Message-ID: <3AC94556.AF4B25B5@boutel.co.nz>
Jerzy Karczmarczuk wrote:
> 2. You neglect, and I suspect that you do it on purpose, that the main
> driving force behind the evolution of Haskell is *RESEARCH*. An issue
> absent from many "popular" languages which are meant to be
> immediately
> exploitable with very flat learning curve.
This is not what is said in the Preface to the Haskell Report.
"It was decided that a committee should be formed to design such a
language, providing faster communication of new ideas, a stable
foundation for real applications development, and a vehicle through
which others would be encouraged to use functional languages."
And the first goal:
"1.It should be suitable for teaching, research, and applications,
including building large systems."
I think it is fair to say that Haskell has not been as successful in
achieving its goals as we would have liked. Tbe points made about
libraries are good ones. The problem seems to be the lack of
well-coordinated, well-funded, development resources - and this is a
problem with most open-source, volunteer-staffed efforts. Some of these
are nevertheless very successful, because, despite their weaknesses,
they do the job better that the proprietary competition. Why then has
Haskell not done as well as sendmail or apache? Perhaps because the
battleground is different. To get people to adopt Haskell (or any other
new language) is an issue of availability of people-skills, and
subjective quasi-religious arguments about the merits of one language
against another, not about which of two products does a well-defined
task better. To win that battle you need massive resources and apparent
commitment, as was the case with Sun and Java. Why did Sun do that? Did
it have anything to do with the real merits of Java?
--brian
From djelovic@sezampro.yu Tue Apr 3 07:39:30 2001
From: djelovic@sezampro.yu (Dejan Jelovic)
Date: Tue, 3 Apr 2001 08:39:30 +0200
Subject: "Lambda Dance", Haskell polemic,... (Jerzy Karczmarczuk)
References: <20010402160104.1D6FC255CE@www.haskell.org>
Message-ID: <00f901c0bc08$d7cf6f30$7600a8c0@katana>
Jerzy Karczmarczuk wrote:
> 1. I didn't find ANYTHING about FP on your pages,
> only that accusations.
I already explained that was not an accusation.
How does it follow that since there's nothing else about FP on my website
that I "never had anything to do with functional languages"? Do you really
think that the 10 pages or so on my website describe the composite of
everything I ever did?
> 2. I don't remember any of your eventual contribution to discussion
> lists, newsgroups, etc. I might be wrong. Please give some references,
> publications, functional software, etc. I will apologize then
> immediately, with regret, but also with satisfaction that the Truth won.
I have never before posted anything on FP to any list or newsgroups. In fact
I subscribed to this list only when I saw your message in the list archives.
But that's irrelevant. Do you think that everybody that has ever used a
functional laguage has contributed to discussion lists and newsgroups?
> 3. Personally you don't care about Haskell. Your page *explicitly*
> discourages local people from touching functional languages, the
> category of people you want to hire is a very strong signal.
> A potential employer who does what you did serves the devil, don't
> try to suggest that this isn't relevant.
Nonsense. I'm hiring C++ and Java programmers because I need help with the
C++ and Java projects I do. I don't see how that would discourage anybody
from learning about other languages?
And why would you assume that I personally don't care about Haskell? You
seem to be piling these assumptions about me at random.
> 1. Saying that the Haskell community offers Hugs98, and not
> mentioning neither GHC, nor NHC is either incompetent or
> provocative.
Hugs is the distribution that's suggested to newcommers. It didn't seem
relevant to talk about other distributions if we are talking about people
migrating to Haskell.
> 2. A decent programming language *must* be stable. If the main
> criterion of the "quality" you attribute to programming languages
> is the speed of its modifications, I wonder what don't you accuse
> of staleness your favourite languages: Java and C++.
Again, wrong assumptions. Neither C++ nor Java are not my favourite
language. I don't have a favourite language.
The fact that Java has not grown for a number of years is a horror. The
language lacks support for types with value semantics, generic types and
other useful facilities. Those have all been proposed but Sun has not moved
to implement them.
C++ is more expressive. The only addition I can think of right now that
would be worth the added complexity would be Java-like inner classes and
anonymous classes and functions.
I was actually contemplating writing about the above things. But it just so
happened that I wrote about Haskell first. I don't understand why the order
in which I write things is bothering you? Or did you expect to come and find
a complete 200-page analysis of all popular programming languages?
But again, this is irrelevant. I was not talking about the language. In fact
I said that Haskell is superior to Python, Perl and Ruby at the very
beginning of my article. But the Haskell website and the _distributions_
seem to be moving at a slower pace.
> Hugs 2001???? Are you sure that you really know what does it mean
> a STANDARD?
Yes. Haskell 98 is a standard. Hugs is a product. It doesn't have to be
called Hugs 98. It can be called Hugs 2001, Hugs XP, Hugs ME, Visual Hugs :)
or any other attractive name.
Anybody programming in Haskell will benefit from other users migrating to
it. More users means more vendors and more libraries.
Perception is one of the factors that influences the number of users.
Commercial world knows this. Microsoft incremented the version of Word from
2.0 to 6.0 in order to avoid having Word perceived as less mature than
WordPerfect. The incremented the Visual C++ version from 2.0 to 4.0 in order
to match Borland C++. Sun called Java 1.2 "Java 2". Etc.
The examples above are extreme and, IMO, slightly dishonest. I just brought
them up to illustrate the point vividly. Calling the Hugs February 2001
distribution "Hugs 2001" is not dishonest, it's just good marketing.
> 1. Oh yes. Thousands of books about Ruby. Actually one, in Japanese.
> Have you looked here:
> http://www.haskell.org/bookshelf/
> This is comparable with Python. Of course, Python IS more popular,
> but - -
I included Ruby in the trio because it fits the scripting language
phenomenon. Python is the one to compare against due to similar starting
positions.
Go to a bookstore. The fact that many books on Haskell have been published
doesn't mean that many people are buying them. The bookstores I visit in the
States have a number of books on Perl and Python. If they carry books on
Haskell at all that's usually one title hidden somewhere on the shelf.
Also, it is a known fact that books on specific products ("Teach Yourself
Visual C++ in 21 Days") greatly outsell books on programming languages ("The
C++ Programming Language"). Guess of which kind are Haskell books?
> 2. You neglect, and I suspect that you do it on purpose, that the main
> driving force behind the evolution of Haskell is *RESEARCH*. An issue
> absent from many "popular" languages which are meant to be
> immediately exploitable with very flat learning curve.
Flat learning curve is ideal. Since that's not possible, the smallest
possible barrier to entry is the next best thing. Why does that bother you?
>The documentation on line is sufficiently good that e.g. -
> my students won't even think about going and trying to buy a book.
No doubt. Ditto for Python and Java.
But that's besides the point. If Haskell was more popular the publishing
industry would be on the bandwagon. No? Remember, I brought up the number of
books sold as a way to gauge the popularity of Haskell in relation to
Python.
> Still, there are more publications on FP every month that I can
> digest. What about Python? Java?
Do you have _any_ idea what the average programmer is reading these days?
_Nothing_. Not one trade publication, not one book. (See "Rapid Development"
for statistics on this.)
DDJ is probably one of the most popular trade magazines. Its circulation is
155,000. What percentage of the working programmers is that?
How big is the membership in IEEE or ACM? How many practicing programmers
read IEEE Software, let alone any of the Journals?
All those publications on FP are _not_ reaching the average programmer.
> > BTW, you seem to be well-informed about who this Jelovic is. Why don't
you
> > share that knowledge with us? :)
>
> Oh, but I did.
> You seem to be a self-appointed specialist on functional languages, who
> expresses in public some very dubious truths, which I find harmful.
I never said I was a specialist. Do only specialists get a voice?
> > 1. I didn't accuse anybody of anything. I was just curious about why
people
> > aren't using Haskell and started to think about it.
>
> I understood this in such a way.
You seem to be the only one. On this list and off. Doesn't this tell you
anything?
> You are explicitly negative in your *judgement*.
I said that the language is good, but that the distributions are not good
enough to facilliate widespead use. A number of people on this list agreed.
Why is this giving you an ulcer?
> There are hundreds of libraries of Java classes and C++ classes
> and procedures which are distributed separately. The "standard"
> GNU distribution of C++ is quite limited, there is no point in
> overloading the standard environment by things whose usage
> is limited. The ease of installation is also important.
The standard Java library is actually quite comprehensive. I'd go so far to
say that it's one of the main reasons why Java has spread so quickly.
The standard C++ library is too small. That's a problem with C++. But the
language spread before GUIs and before the Web when people required less.
If Haskell is to have a chance its distribution(s) must have a comprehensive
library.
> BTW. the GHC "standard" distribution has an adequate amount of runtime
> support for normal tasks. It worked for me without any problem.
You underestimate the value of a large community and lots of vendors. In my
last project I had to manipulate some graphic files in various formats. For
C++ and Java I had turnkey solutions. (Java being better as it has a
standard Image class while for C++ no standard exists.) The closest thing I
found for Haskell is a GD wrapper with limited functionality.
> RRight. I found one point worth mentioning. Wonderful, splendid, and
> original. Hereby I declare that you are the winner of this discussion,
> and I am the loser.
Relax. I was just nitpicking in order to get a rise out of you.
So far you have used "silly", "incompetent", "accuse", "Truth", "serve the
devil", "moral", "nasty", "dubious" and "harmful". Funny how people are
eager to use such qualifications over the Internet but avoid saying them
when they have to look the other person in the eyes, don't you think?
You also didn't have the common courtesy and courage to CC: me on your
initial posting to this list.
Dejan
http://www.jelovic.com
From chak@cse.unsw.edu.au Tue Apr 3 09:43:33 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Tue, 03 Apr 2001 18:43:33 +1000
Subject: "Lambda Dance", Haskell polemic,...
In-Reply-To:
References: <3AC94556.AF4B25B5@boutel.co.nz>
Message-ID: <20010403184333O.chak@cse.unsw.edu.au>
"Wojciech Moczydlowski, Jr" wrote,
> On Tue, 3 Apr 2001, Brian Boutel wrote:
>
> > they do the job better that the proprietary competition. Why then has
> > Haskell not done as well as sendmail or apache? Perhaps because the
> > battleground is different. To get people to adopt Haskell (or any other
>
> > brian
>
> IMO, what's also important, is an infamous memory consumption. Everybody
> seems to ignore it, but by now I wouldn't use Haskell in a commercial product,
> because of this little inconvenience. For me, it doesn't matter much if a
> language is slow - as far as it's not very slow, it's ok. More important for
> me is the predictability. I have to know how much memory my program will
> eat. And in Haskell, with ghc the only sure answer is:
> "Very much".
After profiling and removing space leaks? In what kind of
applications did you encounter this problem?
> The lack of standard arrays, with update in O(1) time, and hashtables is
> another thing. Every time I write a larger program, I use lists - with an
> unpleasant feeling that my favourite language forces me to use either
> nonstandard extensions or uneffective solutions. I think that IO
> arrays/hashtables should be in standard. Because they are in IO - they could
> work efficiently. Yes, I know about MArray/IArray. Yet I couldn't find
> information in sources about complexity of array operations.
> And they aren't Haskell 98 compliant.
This is - again - the problem of a lack of standard
libraries. This is a problem, a very serious one, and it is
being worked on. More hands => more solutions, faster.
> I'm also curious about what you think about the purpose of Haskell. I
> personally consider it *the* language to write compilers.
> But what can you do in it besided, that wouldn't be as easy in other languages?
I found Simon Marlow's http server a quite convincing
example of how Haskell can shine in an application that is
very far from the typical applications in which functional
languages excel. Granted, it is not H98, but that the
latter is lacking some "real world" functionality like
support for concurrency and exceptions is well known and
there are meanwhile convincing proposals for these
features. (Standardisation is always slower than
invention...)
Cheers,
Manuel
From khaliff@astercity.net Tue Apr 3 10:10:43 2001
From: khaliff@astercity.net (Wojciech Moczydlowski, Jr)
Date: Tue, 3 Apr 2001 11:10:43 +0200 (CEST)
Subject: "Lambda Dance", Haskell polemic,...
In-Reply-To: <20010403184333O.chak@cse.unsw.edu.au>
Message-ID:
On Tue, 3 Apr 2001, Manuel M. T. Chakravarty wrote:
> "Wojciech Moczydlowski, Jr" wrote,
>
> > IMO, what's also important, is an infamous memory consumption. Everybody
> > seems to ignore it, but by now I wouldn't use Haskell in a commercial product,
> > because of this little inconvenience. For me, it doesn't matter much if a
> > language is slow - as far as it's not very slow, it's ok. More important for
> > me is the predictability. I have to know how much memory my program will
> > eat. And in Haskell, with ghc the only sure answer is:
> > "Very much".
>
> After profiling and removing space leaks? In what kind of
> applications did you encounter this problem?
I tried to profile my toy C compiler. The profiles simply didn't
work - the graph didn't convey any informations. I've informed about the bug
and let it go.
And besides, after rough testing, it seemed that memory usage grows linear
with a compiled program size. It was OK. But during the
compilation of 200KB program, my compiler ate AFAIR about 30MB of memory.
> This is - again - the problem of a lack of standard
> libraries. This is a problem, a very serious one, and it is
> being worked on. More hands => more solutions, faster.
I know that almost every problem Haskell has is caused by lack of
people.
> I found Simon Marlow's http server a quite convincing
> example of how Haskell can shine in an application that is
> very far from the typical applications in which functional
In a "Advanced functional programming" class at Warsaw University this year,
the group is striving to write a DNS server in Ocaml. I'm curious whether
they'll succeed.
> Manuel
Wojciech Moczydlowski, Jr
From karczma@info.unicaen.fr Tue Apr 3 13:14:22 2001
From: karczma@info.unicaen.fr (Jerzy Karczmarczuk)
Date: Tue, 03 Apr 2001 13:14:22 +0100
Subject: Haskell polemic,...
References: <002401c0bae6$af7fb300$7600a8c0@katana> <3AC86C31.39BB80FD@info.unicaen.fr> <3AC94556.AF4B25B5@boutel.co.nz>
Message-ID: <3AC9BE9E.1824BDC7@info.unicaen.fr>
Brian Boutel wrote:
>
> Jerzy Karczmarczuk wrote:
>
> > 2. You neglect, and I suspect that you do it on purpose, that the
> > main driving force behind the evolution of Haskell is *RESEARCH*.
> > An issue absent from many "popular" languages which are meant to
> > be immediately exploitable with very flat learning curve.
>
> This is not what is said in the Preface to the Haskell Report.
>
> "It was decided that a committee should be formed to design such a
> language, providing faster communication of new ideas, a stable
> foundation for real applications development, and a vehicle through
> which others would be encouraged to use functional languages."
>
> And the first goal:
>
> "1.It should be suitable for teaching, research, and applications,
> including building large systems."
>
> I think it is fair to say that Haskell has not been as successful in
> achieving its goals as we would have liked. Tbe points made about
> libraries are good ones. The problem seems to be the lack of
> well-coordinated, well-funded, development resources
...
What is not said in the Preface?
That the research factor is rather weak (if present at all) in the
development of *other* mentioned languages?
This, and only this was my point here. Research is consuming human
resources. The Python (Perl) world may concentrate more actively on
producing new scripts, interfaces, etc. I cannot be sure, but I doubt
very strongly that the FP community will devote too much attention
to the marketing issues (say, forcing some people to produce Hugs01.02,
Hugs01.03, Hugs01.04, etc. every month, just to prove that Hugs is
better and progressing faster than Word Perfect).
[[Btw. I read the words "stable foundation" there in the cited
fragment of the Preface]].
The Preface says that the language should be suitable... etc. Still,
the main driving force behind its evolution UNTIL NOW was research.
With growing number of Gurus who leave academic institutions, and
should adapt to the "real world", the situation may change fast, and
I sincerely hope so, but comparing the First Goal of the Preface
with the historical evolution of our favourite language is like
comparing the First Article (or the First Ammendment) of a typical
nice Constitution, with the historical evolution of the concerned
country. It takes some time before the correspondence between the
two becomes real.
The implementors should work on improving the quality of the code.
But the question of libraries is more complicated, without an active
demand of the users, the idea of producing just the basic set is
the only possible. Almost all great scientific software libraries in
the world grew up by a long distillation and optimization process from
concrete *user* packages. On the other hand, if some non-users
prefer just to criticize...
Jerzy Karczmarczuk
Caen, France
From karczma@info.unicaen.fr Tue Apr 3 13:31:46 2001
From: karczma@info.unicaen.fr (Jerzy Karczmarczuk)
Date: Tue, 03 Apr 2001 13:31:46 +0100
Subject: Visual Haskell /long comment/
References:
Message-ID: <3AC9C2B2.A9730A13@info.unicaen.fr>
"Jason J. Libsch" wrote:
>
> I recently ran across a paper, Visual Haskell- a First Attempt, and was
> tremendously impressed. Has anybody here played with this language or
> read the paper? I would be interested to hear other's opinion on such a
> language.
I didn't play, I don't know what is the real status of the
implementation,
but I read the paper of Hideki John Reekie quite a time ago.
And his thesis.
http://ptolemy.eecs.berkeley.edu/~johnr/papers/thesis.html
All this is extremely interesting. Is it promising?
It depends on whether the visual, dataflow approach to the interfacing
of practically usable languages is considered promising. The area seems
alive.
http://cui.unige.ch/eao/www/Visual/
http://cuisung.unige.ch/Visual/Freeman/VL.html
Dataflow-oriented packages are not so rare either. Simulink, Scicos, IBM
OPen DX, Khoros, SciRUN, WiT. The connexion tool within MCAD.
Visio and all this business well known by some people reading this list.
Of course: LabView!
(And there was even a music generator ("tracker") called Buzz which
had such an interface, quite well adapted to all kind of DSP algorithms,
but I cannot find it any more.)
//Not too many attachments to the functional world. E.g. Cantata, the
dataflow interface to Khoros library is an integrator of imperative
modules.//
Using lazy streams as the basic protocol for implementing "heavy run"
machines is nice, but - probably - not so easy to implement efficiently,
and the dataflow approach is particularly interesting in the domain of
scientific data processing, where brutal power cannot be disregarded.
What is the opinion of people working on Hawk? Lava?
There was - some time ago - a short discussion on those issues (if
I don't confuse names the first posting was by Yoann Padioleau).
There are several problems with functional visual programming. It is
not so easy to design a recursive function, to "plug-in" higher-order
functions, to exploit currying, polymorphism, etc. Simple graphs are
simple and nice.
Simple textual definitions are simple as well...
Complicated graphs are simply horrible!
I suspect that HJR did not progress too much in his approach, and
I won't blame him (I would love being able to work along this
direction, but I feel frightened). There are also other directions,
perhaps distantly related, but worth analysing.
Visual Prolog.
The Object Flow paradigm.
etc...
Toby Watson wrote:
> I find most of these visual systems awkward to use in practice.
> Quite often this is because they have very poor interface designs
> (they are like old modal CAD systems). This is troublesome, leading
> many - I believe - to suggest that the idea is not plausible.
>
> I think that a usable visual programming language is possible but
> it would have to be a good graphical tool rather than just a
> translation of a textual language.
NOT just a graphical tool. The problem - as I see it, having played
quite a lot with Khoros, Simulink, Labview... is deeper, is conceptual.
In Labview you define a for-loop, an iterative block, by embedding
the relevant instructions into a "cage" which defines local iteration
variables. Toby might say that, exactly, this is an awkward textual
code transposition - only that there is no textual code. The iteration
*concept* has been squeezed into an interface which is not adapted.
In Simulink this is better.
You can produce a loop which is a stream iterator, and even - which
you can't do trivially at all - you can produce a "tight loop", where
there is an immediate (*not delayed*) feedback between the input
and the output.
This requires a *constraint-solving* procedure!
> On related note the types of a function adding two integers
> together, two lists of integers together and dataflow or pipe adding
> two streams of integers together would seem to be similar. Does
> anyone know of some formal work on this, what are the terms I would
> use to investigate?
I am not acquainted with formal works, especially in a typed framework,
but related stuff is described already in Abelson & Sussman^2.
Types are wonderful. But Jason exaggerates:
> 1) As Toby stated, the Strong Typeing of Haskell allows for a
> 'syntaxless' development environment. Only inputs and outputs that
> type correctly can connect. This means that all code that can be
> written will compile!
>
> 2) Easy to navigate through code. If a fn is foreign to the user, she
> need only click on it to bring up its the underlying code.
1. The refusal to connect inappropriate nodes means simply that the
visual editor has incorporated the type checker. Mind you: you are
not "just writing". While connecting you perform a lot of semantic
analysis.
This can be done textually as well for primitive languages.
But for polymorphic nodes, for higher-order functions, for
"curried nodes" the life might be much harder.
2. Many-level textual editors, or visual interfaces to Basic exist.
You click, and the block opens.
This is the way the interfaces to Khoros, Dx, Simulink, Labview etc.
operate.
I fell in love with that.
I am sane again now, after crying in despair seeing 18 simultaneously
open windows, and not knowing really how to reuse the code, how
to reassemble identical parts in order to share them.
Theoretically it is not complicated. Practically it requires a LOT
of experience and patience.
I agree with Jan Skibinski that it is *much* better to
adapt this kind of interfacing to concrete, applicative domains
rather than making a universal paradigmatic world from it.
End users may love it. Students are fascinated by it. (But Matthias
Felleisen - from our conversation - seems to be a bit reluctant:
from the pedagogical perspective it is too easy to play with graphics
and to forget about the structure of the program, about the sense
of it. Nice for simple, and only for simple tasks. [We talked about
Scheme, of course]).
Personally I don't know. But I am still fascinated. Lazy streams are
not the only underlying model, one may - obviously - exploit the
continuations. Or use the event/token propagation along the links. But
this drives as far from Haskell.
More links, just to prove you that I've been thinking about visual
side of FP for some time:
http://www.cs.ucl.ac.uk/staff/L.Braine/researchdocs.html
http://www.cs.orst.edu/~burnett/vpl.html
And, of course, something about Lucid
(not to confound with Lucent)
http://lucy.uvic.ca/pm/contents.html
Jerzy Karczmarczuk
Caen, France
From matt@immute.net Tue Apr 3 22:18:15 2001
From: matt@immute.net (matt hellige)
Date: Tue, 3 Apr 2001 16:18:15 -0500
Subject: Visual Haskell [and visual music langages]
In-Reply-To: <3AC9C2B2.A9730A13@info.unicaen.fr>; from karczma@info.unicaen.fr on Tue, Apr 03, 2001 at 01:31:46PM +0100
References: <3AC9C2B2.A9730A13@info.unicaen.fr>
Message-ID: <20010403161815.A18856@metro.immute.net>
[Jerzy Karczmarczuk ]
> (And there was even a music generator ("tracker") called Buzz which
> had such an interface, quite well adapted to all kind of DSP algorithms,
> but I cannot find it any more.)
>
buzz is still around and under active development, but i don't have a
reference for it. in a similar vein, but somewhat more advanced (and
professional), are MAX/MSP, as commercial product from cycling74, Pd
(which is a different, open-source, offshoot of the project that originally
kicked off MAX), and jMax (also open source), which is related to Pd and MAX,
but done in Java and also open-source. all of those products are primarily
the work of miller puckette at ircam, although i'm not sure how involved
he is in MAX anymore.
MAX/MSP: http://www.cycling74.com/products/max.html
Pd: http://www.pure-data.org
jMax: http://www.ircam.fr/jmax/
all of these products (particularly MAX) are quite successful and highly
regarded in the experimental music community, but there is, in my opinion,
a lot of ugliness in the implementation. one look at the example code for
writing new "externals" in Pd will put a pretty sour taste in the mouth
of most programmers -- it consists of a lot of very ugly c code. it's crossed
my mind on many occasions that this is a field that could potentially see
quite a fuitful real-world application of functional programming, for two
main reasons:
- in many cases, the end user is not a hugely experienced programmer,
and either lacks enough knowledge or is too intimidated to write
extensions his or herself. functional programming solves this problem
in some cases by being much clearer (MANY MANY times clearer than the
Pd code) and easier to learn and read (for some people).
- functional programming seems like it may map quite well to many of
the concepts already used in these visual languages.
- because of the success of this type of software, and the increasing
popularity of the music made using it, this area could be a good
opportunity for functional programming in the real world, as well as
a good opportunity to introduce a whole new class of users to its
concepts and advantages.
it also may be an interesting proving ground for some more advanced features of
modern functional languages:
- performance. audio processing is notoriously intensive, so any remaining
performance problems in the functional language implementation could make
or break the product.
- integration. certainly parts of the core program, and possibly extensions,
would want to be written in an imperative style, either for performance,
or because there are well-known and already implemented algorithms for
certain dsp tasks. the functional language would need to support clean
integration with other languages for that reason.
- a good i/o model and lazy evaluation. many tasks in these environments
consist primarily of consuming on infinite stream of input, performing some
transformation, and producing an infinite stream of output. modern
functional languages have a very good model for such tasks, and lazy
evaluation comes in very handy here, also, allowing the programmer to
express things much more closely to the way the algorithm is actually
understood.
- a good type system. something many of these languages rather lack is a
powerful and expressive way of ensuring that connections are "correct".
this could neatly solve that problem.
in any case, i'd love to see more research in that area...
m
--
matt hellige matt@immute.net
http://matt.immute.net
From chak@cse.unsw.edu.au Wed Apr 4 07:52:42 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Wed, 04 Apr 2001 16:52:42 +1000
Subject: "Lambda Dance", Haskell polemic,...
In-Reply-To:
References: <20010403184333O.chak@cse.unsw.edu.au>
Message-ID: <20010404165242H.chak@cse.unsw.edu.au>
"Wojciech Moczydlowski, Jr" wrote,
> On Tue, 3 Apr 2001, Manuel M. T. Chakravarty wrote:
>
> > "Wojciech Moczydlowski, Jr" wrote,
> >
> > > IMO, what's also important, is an infamous memory consumption. Everybody
> > > seems to ignore it, but by now I wouldn't use Haskell in a commercial product,
> > > because of this little inconvenience. For me, it doesn't matter much if a
> > > language is slow - as far as it's not very slow, it's ok. More important for
> > > me is the predictability. I have to know how much memory my program will
> > > eat. And in Haskell, with ghc the only sure answer is:
> > > "Very much".
> >
> > After profiling and removing space leaks? In what kind of
> > applications did you encounter this problem?
>
> I tried to profile my toy C compiler. The profiles simply didn't
> work - the graph didn't convey any informations. I've informed about the bug
> and let it go.
> And besides, after rough testing, it seemed that memory usage grows linear
> with a compiled program size. It was OK. But during the
> compilation of 200KB program, my compiler ate AFAIR about 30MB of memory.
How much memory is gcc eating for a 200KB program? If you
were to a write a toy C compiler in C++ or Java, do you
think, it would eat significantly less memory without
seriously tuning of the memory management?
Manuel
From khaliff@astercity.net Wed Apr 4 09:59:01 2001
From: khaliff@astercity.net (Wojciech Moczydlowski)
Date: Wed, 4 Apr 2001 10:59:01 +0200 (CEST)
Subject: "Lambda Dance", Haskell polemic,...
In-Reply-To: <20010404165242H.chak@cse.unsw.edu.au>
Message-ID:
On Wed, 4 Apr 2001, Manuel M. T. Chakravarty wrote:
> How much memory is gcc eating for a 200KB program? If you
I've just recompiled my compiler and tried it on 200K program full of
"writeDec(5)" instructions. What really amazed me was that the compiler
has eaten in fact less memory than gcc, which has been ran on a similar C
program, full of printfs.
But things changed dramatically, when I used programs full of "i = 5"
statementes. gcc has eaten only 5M memory while my compiler quickly acquired
90M and still wanted more.
I guess I'll put out my complaint about memory usage, until I try to locate
the memory leak.
> were to a write a toy C compiler in C++ or Java, do you
> think, it would eat significantly less memory without
> seriously tuning of the memory management?
>
> Manuel
In C++? Yes. Because I have full control of the allocated memory.
Wojciech Moczydlowski, Jr
From Toby Watson"
Intuitively the following scenarios seem to be related, can anyone point my
in the direction of formal work on this, or give me the formal terms I need
to search around?
1. Adding two integers together: Int -> Int -> Int
2. Adding two lists of Integers together: [Int] -> [Int] -> [Int]
3. Adding two lazy streams of integers together, possibly in seperate
(parallel) processes for example.
cheers,
Toby
From Tom.Pledger@peace.com Thu Apr 5 21:25:07 2001
From: Tom.Pledger@peace.com (Tom Pledger)
Date: Fri, 6 Apr 2001 08:25:07 +1200
Subject: Question about typing
In-Reply-To: <06ca01c0bdf4$99781eb0$9301010a@tobe>
References: <06ca01c0bdf4$99781eb0$9301010a@tobe>
Message-ID: <15052.54435.749697.27922@waytogo.peace.co.nz>
Toby Watson writes:
| Intuitively the following scenarios seem to be related, can anyone
| point my in the direction of formal work on this, or give me the
| formal terms I need to search around?
|
| 1. Adding two integers together: Int -> Int -> Int
|
| 2. Adding two lists of Integers together: [Int] -> [Int] -> [Int]
If you're adding each element of the first list to the element in the
corresponding position in the second list, it's usually called
zipping. The zipWith function in the prelude takes as its parameter a
function of type a->b->c (your scenario 1) and returns a function of
type [a]->[b]->[c] (your scenario 2).
If you're adding every element of the first list to every element of
the second list, it's sometimes called diagonalisation.
| 3. Adding two lazy streams of integers together, possibly in seperate
| (parallel) processes for example.
I think the term `zipping' can apply to most container types, even
those with branching structures which don't look like half an actual
zip.
Regards,
Tom
From jans@numeric-quest.com Thu Apr 5 22:15:01 2001
From: jans@numeric-quest.com (Jan Skibinski)
Date: Thu, 5 Apr 2001 17:15:01 -0400 (EDT)
Subject: Question about typing
In-Reply-To: <15052.54435.749697.27922@waytogo.peace.co.nz>
Message-ID:
On Fri, 6 Apr 2001, Tom Pledger wrote:
> If you're adding every element of the first list to every element of
> the second list, it's sometimes called diagonalisation.
I do not know where this definition came from but it
does not make sense to me. It is zipping that looks
like a diagonalization, not the other way around.
[f ai bj | ai <- a, bj <- b]
This looks like an outer product of two vectors,
or a matrix represented as a linear vector of
dimension n x m, where n = length a, m = length b.
If f = (*) then it is really the outer product.
[ai * bj | (ai, bj) <- zip a b]
But this is a list of diagonal elements of the
outer product above, providing that n == m.
Jan
From erkok@cse.ogi.edu Thu Apr 5 15:54:28 2001
From: erkok@cse.ogi.edu (Levent Erkok)
Date: Thu, 05 Apr 2001 07:54:28 -0700
Subject: Question about typing
References: <06ca01c0bdf4$99781eb0$9301010a@tobe>
Message-ID: <3ACC8724.35B27974@cse.ogi.edu>
Tom Pledger wrote:
>
> Toby Watson writes:
> | Intuitively the following scenarios seem to be related, can anyone
> | point my in the direction of formal work on this, or give me the
> | formal terms I need to search around?
> |
> | 1. Adding two integers together: Int -> Int -> Int
> |
> | 2. Adding two lists of Integers together: [Int] -> [Int] -> [Int]
>
> If you're adding each element of the first list to the element in the
> corresponding position in the second list, it's usually called
> zipping. The zipWith function in the prelude takes as its parameter a
> function of type a->b->c (your scenario 1) and returns a function of
> type [a]->[b]->[c] (your scenario 2).
Jeff Lewis implemented zip comprehensions in the latest versions of both
GHC and Hugs. This notation provides special syntax to deal with the
second case above nicely.
You can say:
[x + y | x <- [1,2,3,4,5]
| y <- [5,6,7,8]]
to get:
[6,8,10,12]
The shorther list determines the final length (could of course be
infinite.)
It's an extension of the usual syntax, so multiple generators are OK
too:
[x + y | x <- [1,2,3,4,5], z <- [3, 4, 5], (x+z) `mod`2 == 1
| y <- [5,6,7,8], y `mod` 2 == 0]
gives:
[7, 10]
It's a great notation that avoids zipWith's. (You need to start hugs
with -98 and GHC needs -fglasgow-exts for zip comprehensions to be
recognized.)
-Levent.
From ingo@ele.kth.se Fri Apr 6 15:23:17 2001
From: ingo@ele.kth.se (Ingo Sander)
Date: Fri, 6 Apr 2001 16:23:17 +0200 (MET DST)
Subject: Visual Haskell /long comment/
In-Reply-To: <3AC9C2B2.A9730A13@info.unicaen.fr>
Message-ID:
On Tue, 3 Apr 2001, Jerzy Karczmarczuk wrote:
> I don't know what is the real status of the
> implementation,
> but I read the paper of Hideki John Reekie quite a time ago.
> And his thesis.
>
> http://ptolemy.eecs.berkeley.edu/~johnr/papers/thesis.html
>
> Using lazy streams as the basic protocol for implementing "heavy run"
> machines is nice, but - probably - not so easy to implement efficiently,
> and the dataflow approach is particularly interesting in the domain of
> scientific data processing, where brutal power cannot be disregarded.
>
> What is the opinion of people working on Hawk? Lava?
>
I am not working on Hawk or Lava, but Reekie's work has been a key
inspiration for our research, which is the development of the ForSyDe
(Formal System Design) methodology, developed for the design of systems
on a chip. The architecture for such systems is a single chip integrating
many different components, such as microprocessor and DSP cores, memories
and custom hardware.
We use Haskell as a modelling language in a similar way as
Reekie described in chapters 5 and 6 of his Ph.D. thesis. Higher-order
functions like scanlS and mapS, called skeletons in our methodology, are
used as process constructors implementing a synchronous computational
model.
We extend Reekies approach targeting applications that control both
control
and data flow parts. In addition, we also cover the synthesis process,
i.e. the transformation from an ideal system model written in Haskell,
into C-code for the software parts and VHDL-code for the hardware parts.
During the synthesis process we use the property, that each skeleton has a
hardware and software interpretation, e.g. a process 'scanlS f m' has a
finite state machine as its interpretation and is translated into the
corresponding VHDL (for hardware) structure, where f describes the next
state decoder and m determines the memory elements. Thus, we do not
compile the Haskell code with a traditional compiler, but interpret the
structures (skeletons) in the system model in order to get an effective
hardware/software implementation of the system model.
Back to your question, we believe that such an approach
- raises the abstraction level compared to traditional methods starting
from VHDL/C++
- allows for formal design transformation
- leads to an efficient implementation using the interpretation of
higher-order functions into hardware and software
- allows the incorporation of formal methods because of Haskells
formal semantics
If you want to more about our approach please the following WWW-page
containing a number of publications about the ForSyDe methodology:
http://www.ele.kth.se/~ingo/
Ingo Sander
From andrew@andrewcooke.free-online.co.uk Sat Apr 7 13:07:44 2001
From: andrew@andrewcooke.free-online.co.uk (andrew@andrewcooke.free-online.co.uk)
Date: Sat, 7 Apr 2001 13:07:44 +0100
Subject: Question about typing
In-Reply-To: <06ca01c0bdf4$99781eb0$9301010a@tobe>; from toby@tui.co.uk on Thu, Apr 05, 2001 at 06:19:30PM +0100
References: <06ca01c0bdf4$99781eb0$9301010a@tobe>
Message-ID: <20010407130744.A3251@liron>
Is there a class that both lists and lazy streams could implement, so
that zip et al could be more general? The distinction between 2 and 3
below seems a bit arbitrary. Something like fmap/Functor? (If there
is, I guess it could apply to 1 too?; if not, why not - is it
impractical (efficiency?) or just wrong?)
Curious,
Andrew
On Thu, Apr 05, 2001 at 06:19:30PM +0100, Toby Watson wrote:
> Intuitively the following scenarios seem to be related, can anyone point my
> in the direction of formal work on this, or give me the formal terms I need
> to search around?
>
> 1. Adding two integers together: Int -> Int -> Int
>
> 2. Adding two lists of Integers together: [Int] -> [Int] -> [Int]
>
> 3. Adding two lazy streams of integers together, possibly in seperate
> (parallel) processes for example.
>
>
> cheers,
> Toby
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
--
http://www.andrewcooke.free-online.co.uk/index.html
From matth@mindspring.com Sun Apr 8 02:46:00 2001
From: matth@mindspring.com (Matt Harden)
Date: Sat, 07 Apr 2001 20:46:00 -0500
Subject: Question about typing
References: <06ca01c0bdf4$99781eb0$9301010a@tobe> <20010407130744.A3251@liron>
Message-ID: <3ACFC2D8.2B3A3359@mindspring.com>
In a lazy language like Haskell, a list is essentially the same as a
lazy stream, though I'm not well versed in the parallel stuff...
Anyway, it can be quite desirable to be able to "zip" together data
structures other than lists; trees or arrays for example. The standard
prelude and library does not include any class to do this. I played
with this awhile back, and came up with the following:
module Zip where
import Prelude hiding (zip, zipWith, zipWith3, zip3)
class (Functor f) => ZipFunctor f where
-- "zap" stands for "zip apply"
-- it applies a set of functions to a set
-- of arguments, producing a set of results
zap :: f (a->b) -> f a -> f b
instance ZipFunctor [] where
(f:fs) `zap` (x:xs) = f x : fs `zap` xs
_ `zap` _ = []
instance ZipFunctor Maybe where
(Just f) `zap` (Just x) = Just (f x)
_ `zap` _ = Nothing
zipWith :: (ZipFunctor f) => (a->b->c) -> f a -> f b -> f c
zipWith f xs ys = f `fmap` xs `zap` ys
zipWith3 :: (ZipFunctor f) => (a->b->c->d)->f a->f b->f c->f d
zipWith3 f xs ys zs = f `fmap` xs `zap` ys `zap` zs
zip :: ZipFunctor f => f a -> f b -> f (a,b)
zip = zipWith (,)
zip3 :: ZipFunctor f => f a -> f b -> f c -> f (a,b,c)
zip3 = zipWith3 (,,)
One can easily create ZipFunctor instances for trees and other data
structures. I can provide examples if you like. With multiple
parameter type classes (MPTCs, they are not in Haskell 98) as well as
functional dependencies (also not in h98), one can also create a
"Zippable" class to generalize the zip function over multiple tuple
types and eliminate zip3, zip4, etc.
I don't know of any way to make option 1 below equivalent to the other
two; I think it is impossible with Haskell's current type systems.
However, you can create an "Id" type, which is a wrapper that holds
exactly one instance of another type. Id happens to trivially be a
Functor and a Monad, is also trivially a ZipFunctor, and can be defined
as a newtype to eliminate overhead in the compiled program. Then you
would have option 1 as follows:
1. Adding two integers together: Id Int -> Id Int -> Id Int
The function for all three options would then be (zipWith (+)).
Hope this helps,
Matt
andrew@andrewcooke.free-online.co.uk wrote:
>
> Is there a class that both lists and lazy streams could implement, so
> that zip et al could be more general? The distinction between 2 and 3
> below seems a bit arbitrary. Something like fmap/Functor? (If there
> is, I guess it could apply to 1 too?; if not, why not - is it
> impractical (efficiency?) or just wrong?)
>
> Curious,
> Andrew
>
> On Thu, Apr 05, 2001 at 06:19:30PM +0100, Toby Watson wrote:
> > Intuitively the following scenarios seem to be related, can anyone point my
> > in the direction of formal work on this, or give me the formal terms I need
> > to search around?
> >
> > 1. Adding two integers together: Int -> Int -> Int
> >
> > 2. Adding two lists of Integers together: [Int] -> [Int] -> [Int]
> >
> > 3. Adding two lazy streams of integers together, possibly in seperate
> > (parallel) processes for example.
> >
> >
> > cheers,
> > Toby
> >
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
>
> --
> http://www.andrewcooke.free-online.co.uk/index.html
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
From andrew@andrewcooke.free-online.co.uk Sun Apr 8 10:14:34 2001
From: andrew@andrewcooke.free-online.co.uk (andrew@andrewcooke.free-online.co.uk)
Date: Sun, 8 Apr 2001 10:14:34 +0100
Subject: Question about typing
In-Reply-To: <3ACFC2D8.2B3A3359@mindspring.com>; from matth@mindspring.com on Sat, Apr 07, 2001 at 08:46:00PM -0500
References: <06ca01c0bdf4$99781eb0$9301010a@tobe> <20010407130744.A3251@liron> <3ACFC2D8.2B3A3359@mindspring.com>
Message-ID: <20010408101434.A10261@liron>
On Sat, Apr 07, 2001 at 08:46:00PM -0500, Matt Harden wrote:
> In a lazy language like Haskell, a list is essentially the same as a
> lazy stream
Sorry. I've been using Haskell a few months now, and I really did
know that, but got so confused going round in circles with a similar
problem I'm working on myself that nothing was clear any more.
Thanks for the clear reply + class.
Andrew
--
http://www.andrewcooke.free-online.co.uk/index.html
From qrczak@knm.org.pl Sun Apr 8 12:34:45 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 8 Apr 2001 11:34:45 GMT
Subject: Question about typing
References: <06ca01c0bdf4$99781eb0$9301010a@tobe> <20010407130744.A3251@liron> <3ACFC2D8.2B3A3359@mindspring.com>
Message-ID:
Sat, 07 Apr 2001 20:46:00 -0500, Matt Harden pisze:
> class (Functor f) => ZipFunctor f where
> -- "zap" stands for "zip apply"
> -- it applies a set of functions to a set
> -- of arguments, producing a set of results
> zap :: f (a->b) -> f a -> f b
This is nice as long as the type is fully polymorphic. Unfortunately
this is not always the case in reality.
Let's take unboxed flat sequences (unboxed vectors). Imagine we have
data UVector a
class Seq c a | c -> a
instance Seq (UVector Bool) Bool
instance Seq (UVector Char) Char
instance Seq (UVector Int) Int
-- etc.
(in fact I do have this). Class Seq provides various operations common
to sequences. There are no problems with operations involving sequences
of the same type (e.g. splitAt), but it's not obvious how to handle map
and zipWith.
BTW. Alternatively it could be expressed thus:
data UVector a
class Seq c a
instance Seq UVector Bool
instance Seq UVector Char
instance Seq UVector Int
-- etc.
but it disallows certain abstractions, like conversion of an immutable
container to a mutable container independently of its kind. This
doesn't change the problem with map.
I found a way to express map and zipWith, but it's quite ugly. I would
be happy to have a better way.
class Map c' a' c a | c' -> a', c -> a, c' a -> c, c a' -> c' where
map :: (a' -> a) -> c' -> c
class (Map c a c a, ...) => Seq c a
-- Class Seq requires method map which doesn't chage the
-- element type.
instance Map [a] a [b] b
-- map on lists is more general than mere Seq requires:
-- it's fully polymorphic wrt. the element type.
instance Seq [a] a
-- This instance alone implies only Map [a] a [a] a.
class IArray c a
-- This is a class of immutable arrays, provided by ghc.
newtype IArrayToVector c a = V (c Int a)
-- Convert an immutable array to a flat sequence.
-- (In fact I have done this a bit differently; it doesn't
-- matter now.)
instance (IArray c a', IArray c a) => Map (c Int a') a' (c Int a) a
-- As long as both element types are ok for an immutable array,
-- vector derived from the array can be mapped from one to
-- the other.
instance IArray c a => Seq (c Int a) a
-- This implies only Map (c Int a) a (c Int a) a.
data UArray k a
instance IArray UArray Bool
instance IArray UArray Char
instance IArray UArray Int
-- etc. This is provided by ghc.
type UVector = IArrayToVector UArray
-- There are instances Seq (UVector a) a for particular choices
-- of a, and more: instances Map (UVector a') a' (UVector a) a
-- for particular choices of a' and a.
-- zipWith is similar to map, only more complicated:
class ZipWith c1 a1 c2 a2 c a
| c1 -> a1, c2 -> a2, c -> a,
c1 a -> c, c a1 -> c1, c2 a -> c, c a2 -> c2
where
zipWith :: (a1 -> a2 -> a) -> c1 -> c2 -> c
-- zipWith3 is even more ugly.
An alternative way is this: remove Map class, have map as a standalone
function which converts a container to a list, maps the list, and
converts it back. Disadvantages are that it applies only to things
which can be sensibly converted to a list, and that if mapping of a
dictionary is specified as preserving the keys (actually the key is
in the function argument but not in the result), then it must recreate
the dictionary structure from scratch.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From dpt@math.harvard.edu Sun Apr 8 17:38:27 2001
From: dpt@math.harvard.edu (Dylan Thurston)
Date: Sun, 8 Apr 2001 12:38:27 -0400
Subject: Question about typing
In-Reply-To: ; from qrczak@knm.org.pl on Sun, Apr 08, 2001 at 11:34:45AM +0000
References: <06ca01c0bdf4$99781eb0$9301010a@tobe> <20010407130744.A3251@liron> <3ACFC2D8.2B3A3359@mindspring.com>
Message-ID: <20010408123827.B1246@math.harvard.edu>
On Sun, Apr 08, 2001 at 11:34:45AM +0000, Marcin 'Qrczak' Kowalczyk wrote:
> ...
> I found a way to express map and zipWith, but it's quite ugly. I would
> be happy to have a better way.
>
> class Map c' a' c a | c' -> a', c -> a, c' a -> c, c a' -> c' where
> map :: (a' -> a) -> c' -> c
> ...
> -- zipWith is similar to map, only more complicated:
> class ZipWith c1 a1 c2 a2 c a
> | c1 -> a1, c2 -> a2, c -> a,
> c1 a -> c, c a1 -> c1, c2 a -> c, c a2 -> c2
> where
> zipWith :: (a1 -> a2 -> a) -> c1 -> c2 -> c
> ...
You raise many interesting question, but let me ask about one: why the
specific choice of functional dependencies above? Why is "c' a -> c"
necessary for Map? Why doesn't ZipWith include, e.g., "c1 a2 -> c2"?
(I don't have a lot of experience with these functional
dependencies...)
From princepawn@earthlink.net Sun Apr 8 19:20:29 2001
From: princepawn@earthlink.net (Terrence Brannon)
Date: Sun, 8 Apr 2001 11:20:29 -0700 (PDT)
Subject: What do you think about Mercury?
Message-ID: <200104081820.LAA13674@avocet.mail.pas.earthlink.net>
I have decided to escape the world of Perl into something more
definitional. I gave up on CAML and Erlang because they contain
imperative elements and I am tired of that form of coding. So, I have
narrowed it down to Haskell and Mercury.
The attractive things about Haskell are:
- automatic generation of concurrent programs from normal
source... instead of sending msgs to processes like in Erlang.
- large user base
- possible real job in industry (with Galois Connections).
- several books based on it
- binaries available (even for my mac os x box already!).
So, with that said,
http://www.cs.mu.oz.au/research/mercury/information/comparison_with_haskell.html
lists a number of advantages of Mercury over Haskell. And both Haskell
and Mercury did well in the ICFP.
Does anyone have anything to say about these criticisms? There were
two particular things in the list that caught my attention:
1- Haskell is a pure functional language, but I don't see any support
for backtracking or other logic features... but my guess is you have
some way of handling this? How?
2- Mercury's mode system provides support for subtypes. For example, you
can declare that a function whose argument is a discriminated union
type accepts only a subset of the possible constructors for that type,
and the mode system will enforce this.
From fjh@cs.mu.oz.au Mon Apr 9 05:30:01 2001
From: fjh@cs.mu.oz.au (Fergus Henderson)
Date: Mon, 9 Apr 2001 14:30:01 +1000
Subject: What do you think about Mercury?
In-Reply-To: <200104081820.LAA13674@avocet.mail.pas.earthlink.net>
References: <200104081820.LAA13674@avocet.mail.pas.earthlink.net>
Message-ID: <20010409143001.A17405@hg.cs.mu.oz.au>
On 08-Apr-2001, Terrence Brannon wrote:
>
> 1- Haskell is a pure functional language, but I don't see any support
> for backtracking or other logic features... but my guess is you have
> some way of handling this? How?
The usual way of handling backtracking in Haskell is using lazy lists.
See Phil Wadler's 1985 paper [1].
For an example of this, I've attached a program for solving the
8-queens problem; you can compare this one with the Mercury version
in tests/benchmarks/queens.m in the mercury-tests distribution.
(Probably neither this one nor the Mercury one are ideal style,
but I happened to have them lying around...)
So backtracking is really not that hard to emulate in a lazy functional
language. Supporting logic variables and constraint solving is a lot
more cumbersome, however.
References
[1] Philip Wadler: How to Replace Failure by a List of Successes: A
method for exception handling, backtracking, and pattern matching in
lazy functional languages. FPCA 1985: 113-128
-- main = print_all_solns 8
main = print_soln_count 9
print_soln_count :: Int -> IO ()
print_soln_count n = putStrLn (show (length (solutions n)))
print_all_solns :: Int -> IO ()
print_all_solns n = sequence (map show_soln (solutions n))
solutions :: Int -> [[Int]]
solutions n = queens (start n)
show_soln :: Show a => a -> IO ()
show_soln soln = putStrLn (show soln)
start :: Int -> [Int]
start n = [1 .. n]
queens :: [Int] -> [[Int]]
queens start_posn = [ posn | posn <- qperm start_posn, safe posn ]
qperm :: [t] -> [[t]]
qperm [] = [[]]
qperm (x:xs) = [(y:zs) | zs <- qperm ys, (y,ys) <- qdelete (x:xs) ]
qdelete :: [t] -> [(t,[t])]
qdelete [] = []
qdelete (x:xs) = ((x,xs) : [ (y,(x:ys)) | (y,ys) <- qdelete xs ])
safe :: [Int] -> Bool
safe [] = True
safe (n:l) = nodiag n 1 l && safe l
nodiag :: Int -> Int -> [Int] -> Bool
nodiag _ _ [] = True
nodiag b d (n:l) = d /= n - b && d /= b - n && nodiag b (d+1) l
--
Fergus Henderson | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: | -- the last words of T. S. Garp.
From karczma@info.unicaen.fr Mon Apr 9 13:08:48 2001
From: karczma@info.unicaen.fr (Jerzy Karczmarczuk)
Date: Mon, 09 Apr 2001 13:08:48 +0100
Subject: Backtracking (Was: What do you think about Mercury?)
References: <200104081820.LAA13674@avocet.mail.pas.earthlink.net> <20010409143001.A17405@hg.cs.mu.oz.au>
Message-ID: <3AD1A650.42924FFB@info.unicaen.fr>
Fergus Henderson wrote:
> On 08-Apr-2001, Terrence Brannon wrote:
> >
> > 1- Haskell is a pure functional language, but I don't see any support
> > for backtracking or other logic features... but my guess is you have
> > some way of handling this? How?
>
> The usual way of handling backtracking in Haskell is using lazy lists.
> See Phil Wadler's 1985 paper [1].
>
> For an example of this, I've attached a program for solving the
> 8-queens problem; you can compare this one with the Mercury version
...
This is a way to deal with *data backtracking*. Sure, most of
classical combinatoric algorithms belong to this category, the gene-
ration of permutations/combinations, 8 queens, etc. And of course
the non-deterministic parsing.
But there is also the question of *control backtracking*, used to
emulate iterations, etc. This may be implemented functionally as
well by using continuations. You may have conditional continuations,
multiple continuations,...
Unfortunately such techniques are rarely taught.
I suspect that Mark Jones' Prolog implementation in Haskell/Gofer
used them, but I don't remember the details.
Jerzy Karczmarczuk
Caen, France
From Yoann.Padioleau@irisa.fr Mon Apr 9 13:33:47 2001
From: Yoann.Padioleau@irisa.fr (Yoann Padioleau)
Date: 09 Apr 2001 14:33:47 +0200
Subject: Question about typing
In-Reply-To: Matt Harden's message of "Sat, 07 Apr 2001 20:46:00 -0500"
References: <06ca01c0bdf4$99781eb0$9301010a@tobe> <20010407130744.A3251@liron> <3ACFC2D8.2B3A3359@mindspring.com>
Message-ID:
Matt Harden writes:
>
> zip :: ZipFunctor f => f a -> f b -> f (a,b)
> zip = zipWith (,)
> zip3 :: ZipFunctor f => f a -> f b -> f c -> f (a,b,c)
> zip3 = zipWith3 (,,)
>
> One can easily create ZipFunctor instances for trees and other data
> structures. I can provide examples if you like. With multiple
> parameter type classes (MPTCs, they are not in Haskell 98) as well as
> functional dependencies (also not in h98), one can also create a
> "Zippable" class to generalize the zip function over multiple tuple
> types and eliminate zip3, zip4, etc.
can you explain how you do that ?? (i dont know what is
functional dependencies, but i think i understand multiple parameter type classes
and i dont see how do make something that avoid to define a zip3 zip4 ....
From fjh@cs.mu.oz.au Mon Apr 9 15:43:24 2001
From: fjh@cs.mu.oz.au (Fergus Henderson)
Date: Tue, 10 Apr 2001 00:43:24 +1000
Subject: Backtracking (Was: What do you think about Mercury?)
In-Reply-To: <3AD1A650.42924FFB@info.unicaen.fr>; from Jerzy Karczmarczuk on Mon, Apr 09, 2001 at 01:08:48PM +0100
References: <200104081820.LAA13674@avocet.mail.pas.earthlink.net> <20010409143001.A17405@hg.cs.mu.oz.au> <3AD1A650.42924FFB@info.unicaen.fr>
Message-ID: <20010410004323.A24106@murlibobo.cs.mu.OZ.AU>
On 09-Apr-2001, Jerzy Karczmarczuk wrote:
> Fergus Henderson wrote:
> > The usual way of handling backtracking in Haskell is using lazy lists.
...
> This is a way to deal with *data backtracking*. Sure, most of
> classical combinatoric algorithms belong to this category, the gene-
> ration of permutations/combinations, 8 queens, etc. And of course
> the non-deterministic parsing.
>
> But there is also the question of *control backtracking*, used to
> emulate iterations, etc. This may be implemented functionally as
> well by using continuations.
Using continuations to implement backtracking is another important idiom,
I agree. (In fact, that is how the new back-end for the Mercury compiler
deals with backtracking Mercury code: it converts it into C (or IL, or Java)
code that uses continuation passing to handle the backtracing.)
However, in a lazy functional language, I'm not sure that you can so easily
or usefully distinguish between _control_ backtracking and _data_ backtracking.
In a lazy functional language the control flow is mainly implicit
rather than explicit, and is determined by the data flow.
> You may have conditional continuations, multiple continuations,...
If you use other lazy data structures, e.g. lazy trees rather than lazy
lists, then you can do the same kinds of things that you could do using
conditional or multiple continuations.
--
Fergus Henderson | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: | -- the last words of T. S. Garp.
From qrczak@knm.org.pl Mon Apr 9 14:40:42 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 9 Apr 2001 13:40:42 GMT
Subject: What do you think about Mercury?
References: <200104081820.LAA13674@avocet.mail.pas.earthlink.net> <20010409143001.A17405@hg.cs.mu.oz.au>
Message-ID:
Mon, 9 Apr 2001 14:30:01 +1000, Fergus Henderson pisze:
> For an example of this, I've attached a program for solving the
> 8-queens problem;
Here is mine, also using the list monad together with the state monad
(uses StateT [] and not ListT State, so the state is restored during
backtracking and not permanent).
import Monad;import MonadState;main=mapM_(\s->mapM_ putStrLn$[]:[take
8$replicate i '.'++'Q':repeat '.'|i<-s])$evalStateT(mapM(\i->msum[do
(/)<-get;guard$i/j;put(\x y->y/=j&&x+y/=i+j&&x-y/=i-j&&x/y);return j
|j<-a])a)(\_ _->True);a=[0..7]
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From qrczak@knm.org.pl Mon Apr 9 14:27:51 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 9 Apr 2001 13:27:51 GMT
Subject: Question about typing
References: <06ca01c0bdf4$99781eb0$9301010a@tobe> <20010407130744.A3251@liron> <3ACFC2D8.2B3A3359@mindspring.com> <20010408123827.B1246@math.harvard.edu>
Message-ID:
Sun, 8 Apr 2001 12:38:27 -0400, Dylan Thurston pisze:
> > class Map c' a' c a | c' -> a', c -> a, c' a -> c, c a' -> c' where
> > map :: (a' -> a) -> c' -> c
> > ...
> > -- zipWith is similar to map, only more complicated:
> > class ZipWith c1 a1 c2 a2 c a
> > | c1 -> a1, c2 -> a2, c -> a,
> > c1 a -> c, c a1 -> c1, c2 a -> c, c a2 -> c2
> > where
> > zipWith :: (a1 -> a2 -> a) -> c1 -> c2 -> c
> > ...
>
> You raise many interesting question, but let me ask about one: why the
> specific choice of functional dependencies above? Why is "c' a -> c"
> necessary for Map?
To make the type of "map f xs" determinable from types of f and xs.
The idea is that instances of map will be made only for "the same"
container applied to potentially different element types (where
the concept of "the same" is not formal, because c is the container
already applied to the element type).
If map could arbitrarily convert the shape of containers, there would
be more ambiguities. In particular "map f (map g xs)" would be always
ambiguous (nothing says what container to use for the intermediate
value).
Conversion is done similarly to fromIntegral: as composition of
functions which convert a container to and from a common universal
type: a list (which is a list of pairs in the case of dictionaries).
A perhaps unusual thing is that when the instance of a class like Map
is determined to be [a] a [b] b, then type variables a and b become
unconstrained. I'm not sure if it causes problems. Generally it seems
to be important which exactly type variables are constrained, e.g. for
resolving ambiguities and for the monomorphism restriction. The
bright side of this is that even though map is generally overloaded
over element types, it has an instance of the type equivalent to
Prelude's map: fully polymorphic wrt. element types.
> Why doesn't ZipWith include, e.g., "c1 a2 -> c2"?
When a is determined (it must be determined by other means anyway,
otherwise the instance is ambiguous, and c1 a2 -> c2 would not help
here), c1 a -> c, c a2 -> c2. So this dependency is implied by others.
I hope I haven't overlooked anything.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From erik@meijcrosoft.com Mon Apr 9 18:09:38 2001
From: erik@meijcrosoft.com (Erik Meijer)
Date: Mon, 9 Apr 2001 10:09:38 -0700
Subject: Backtracking (Was: What do you think about Mercury?)
References: <200104081820.LAA13674@avocet.mail.pas.earthlink.net> <20010409143001.A17405@hg.cs.mu.oz.au> <3AD1A650.42924FFB@info.unicaen.fr>
Message-ID: <001501c0c117$ddd890a0$34b11eac@redmond.corp.microsoft.com>
Several people, including myself in my long forgotten thesis, have shown
that these are equivalent.
Erik
----- Original Message -----
From: "Jerzy Karczmarczuk"
Cc:
Sent: Monday, April 09, 2001 5:08 AM
Subject: Backtracking (Was: What do you think about Mercury?)
> Fergus Henderson wrote:
>
> > On 08-Apr-2001, Terrence Brannon wrote:
> > >
> > > 1- Haskell is a pure functional language, but I don't see any support
> > > for backtracking or other logic features... but my guess is you have
> > > some way of handling this? How?
> >
> > The usual way of handling backtracking in Haskell is using lazy lists.
> > See Phil Wadler's 1985 paper [1].
> >
> > For an example of this, I've attached a program for solving the
> > 8-queens problem; you can compare this one with the Mercury version
> ...
>
> This is a way to deal with *data backtracking*. Sure, most of
> classical combinatoric algorithms belong to this category, the gene-
> ration of permutations/combinations, 8 queens, etc. And of course
> the non-deterministic parsing.
>
>
> But there is also the question of *control backtracking*, used to
> emulate iterations, etc. This may be implemented functionally as
> well by using continuations. You may have conditional continuations,
> multiple continuations,...
> Unfortunately such techniques are rarely taught.
>
> I suspect that Mark Jones' Prolog implementation in Haskell/Gofer
> used them, but I don't remember the details.
>
>
> Jerzy Karczmarczuk
> Caen, France
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
From chak@cse.unsw.edu.au Tue Apr 10 02:16:27 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Tue, 10 Apr 2001 11:16:27 +1000
Subject: What do you think about Mercury?
In-Reply-To:
References: <200104081820.LAA13674@avocet.mail.pas.earthlink.net>
<20010409143001.A17405@hg.cs.mu.oz.au>
Message-ID: <20010410111627P.chak@cse.unsw.edu.au>
qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) wrote,
> Mon, 9 Apr 2001 14:30:01 +1000, Fergus Henderson pisze:
>
> > For an example of this, I've attached a program for solving the
> > 8-queens problem;
>
> Here is mine, also using the list monad together with the state monad
> (uses StateT [] and not ListT State, so the state is restored during
> backtracking and not permanent).
>
> import Monad;import MonadState;main=mapM_(\s->mapM_ putStrLn$[]:[take
> 8$replicate i '.'++'Q':repeat '.'|i<-s])$evalStateT(mapM(\i->msum[do
> (/)<-get;guard$i/j;put(\x y->y/=j&&x+y/=i+j&&x-y/=i-j&&x/y);return j
> |j<-a])a)(\_ _->True);a=[0..7]
I always knew that inside Haskell there is a Perl trying to
get out!
Manuel
From elf@sandburst.com Tue Apr 10 03:43:48 2001
From: elf@sandburst.com (Mieszko Lis)
Date: Mon, 9 Apr 2001 22:43:48 -0400
Subject: What do you think about Mercury?
In-Reply-To: <20010410111627P.chak@cse.unsw.edu.au>; from chak@cse.unsw.edu.au on Tue, Apr 10, 2001 at 11:16:27AM +1000
References: <200104081820.LAA13674@avocet.mail.pas.earthlink.net> <20010409143001.A17405@hg.cs.mu.oz.au> <20010410111627P.chak@cse.unsw.edu.au>
Message-ID: <20010409224348.A29838@sandburst.com>
On Tue, Apr 10, 2001 at 11:16:27AM +1000, Manuel M. T. Chakravarty wrote:
> I always knew that inside Haskell there is a Perl trying to
> get out!
import List;q _ _ 0 _=[[]];q u i r k=let{b=[x+1|x<-u,-1>x||x>0,x[p:x|x<-q(-p:p:b)(i\\[p])(r-1)k])d;main=print$q[][1..8]8 8
(158 chars, but the output is quite ugly)
:)
-- Mieszko
From matth@mindspring.com Tue Apr 10 03:48:27 2001
From: matth@mindspring.com (Matt Harden)
Date: Mon, 09 Apr 2001 21:48:27 -0500
Subject: Question about typing
References: <06ca01c0bdf4$99781eb0$9301010a@tobe> <20010407130744.A3251@liron> <3ACFC2D8.2B3A3359@mindspring.com>
Message-ID: <3AD2747B.D98F011C@mindspring.com>
I won't try to explain functional dependencies, because I don't
understand them all that well, there is documentation, and others on
this list could explain them much better than I can.
Here is an example of how to implement a polymorphic zip (used together
with the ZipFunctor I defined earlier):
> class Zippable a f b | a -> f b, f b -> a where
> zip :: a -> f b
>
> instance (ZipFunctor f) => Zippable (f a,f b) f (a,b) where
> zip (xs,ys) =
> fmap (,) xs `zap` ys
>
> instance (ZipFunctor f) => Zippable (f a,f b,f c) f (a,b,c) where
> zip (xs,ys,zs) =
> fmap (,,) xs `zap` ys `zap` zs
>
> instance (ZipFunctor f) =>
> Zippable (f a,f b,f c,f d) f (a,b,c,d) where
> zip (xs1,xs2,xs3,xs4) =
> fmap (,,,) xs1 `zap` xs2 `zap` xs3 `zap` xs4
>
> -- Hopefully you can see how to define instances for more tuples
>
Nothing stops us from adding `unzip` to the class as well, but I left
that out to keep it short. Without functional dependencies, the type
system would have difficulty with type inference, and we would have to
put type declarations all over the place when using these classes. By
the way, I should point out that these zip functions aren't used exactly
the same way as the current zip functions. They convert a tuple of
lists into a list of tuples. So, here's a demonstration of the
difference:
> -- here is the old zip3 function
> zip3 [1..5] "abcd" [0.0,3.14] == [(1,'a',0.0),(2,'b',3.14)]
>
> -- and here is the new zip
> zip ([1..5],"abcd",[0.0,3,14]) == [(1,'a',0.0),(2,'b',3.14)]
Yoann Padioleau wrote:
>
> Matt Harden writes:
> >
> > zip :: ZipFunctor f => f a -> f b -> f (a,b)
> > zip = zipWith (,)
> > zip3 :: ZipFunctor f => f a -> f b -> f c -> f (a,b,c)
> > zip3 = zipWith3 (,,)
> >
> > One can easily create ZipFunctor instances for trees and other data
> > structures. I can provide examples if you like. With multiple
> > parameter type classes (MPTCs, they are not in Haskell 98) as well as
> > functional dependencies (also not in h98), one can also create a
> > "Zippable" class to generalize the zip function over multiple tuple
> > types and eliminate zip3, zip4, etc.
>
> can you explain how you do that ?? (i dont know what is
> functional dependencies, but i think i understand multiple parameter type classes
> and i dont see how do make something that avoid to define a zip3 zip4 ....
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
From fjh@cs.mu.oz.au Tue Apr 10 03:49:20 2001
From: fjh@cs.mu.oz.au (Fergus Henderson)
Date: Tue, 10 Apr 2001 12:49:20 +1000
Subject: What do you think about Mercury?
In-Reply-To: <200104081820.LAA13674@avocet.mail.pas.earthlink.net>
References: <200104081820.LAA13674@avocet.mail.pas.earthlink.net>
Message-ID: <20010410124920.A15391@hg.cs.mu.oz.au>
On 08-Apr-2001, Terrence Brannon wrote:
>
> I have decided to escape the world of Perl into something more
> definitional. I gave up on CAML and Erlang because they contain
> imperative elements and I am tired of that form of coding. So, I have
> narrowed it down to Haskell and Mercury.
...
> http://www.cs.mu.oz.au/research/mercury/information/comparison_with_haskell.html
That page really only describes the differences in the type systems.
A very important distinction between Mercury and Haskell which that page
just skims over is that Haskell is lazy by default, and Mercury is not.
--
Fergus Henderson | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: | -- the last words of T. S. Garp.
From karczma@info.unicaen.fr Tue Apr 10 12:04:57 2001
From: karczma@info.unicaen.fr (Jerzy Karczmarczuk)
Date: Tue, 10 Apr 2001 12:04:57 +0100
Subject: Dimensional analysis with fundeps (some physics comments)
References: <20010409163645.27981.qmail@web1504.mail.yahoo.com> <15058.11840.95448.506908@waytogo.peace.co.nz>
Message-ID: <3AD2E8D9.5264FD24@info.unicaen.fr>
[[MOVED FROM haskell TO haskell-cafe]]
Nothing to do with Haskell. Pure computer scientists, not
interested in physics might not find anything in this posting.
Tom Pledger wrote:
//about dimensions, units...//
> If you clearly make the type system deal with dimensions rather than
> units, there's no problem with plugging in multiple unit systems. You
> just have to pick a scale for the representation.
>
> newtype Dimensioned mass length time rep = Dimensioned rep
>
> type Mass rep = Dimensioned One Zero Zero rep
>
> kg, lb :: Num a => Mass a
> kg = dm 1
> lb = dm 0.4535924
>
> Angles are dimensionless. (Think of the Taylor series for trig
> functions.)
>
> radian, degree :: Unit
> radian = dm 1
> degree = dm (pi/180)
The distinction between dimensions and units may seem for some of
you utterly trivial. Mass is a mass, kg -> lb, etc. are just conversion
factors. Angles are dimensionless.
It was not so trivial for the authors of SI, and for some speculative
physicists, who are not all dead yet. The problem is: what is a
*fundamental*, *universal* constant?
You see, those constants establish our unit systems!
Many, really many among my friends don't hesitate to work in a frame
where the speed of light is equal to 1. Yes, ONE, dimensionless. Then,
passing from length to time is just a unit conversion, and all
velocities are dimensionless.
(Like, say, steradians in SI?...)
Who needs candelas?
Who needs Amperes
What is the dimension of a mole? (In SI it is an independent unit)
Who needs Kelvins?
Everybody (within a particular mafia I happen to know) knows very
well that the temperature is/should be measured in energy units,
i.e., the Boltzmann constant k is equal to 1, dimensionless.
Now, even if you won't (probably) find people who would claim
that the status of k or c is the same as PI/180, the question
"what is a unit" has no unambiguous and non-conventional answer.
You may put the universal gravitational constant to 1. Or simply
put to 1 the Plankeon mass, and get rid of all the mass
"dimensional units".
==
And if you leave the world of classical physics, and start to analyze
the structure of quantum theories you may get some nasty surprises.
//Now I have to trivialize a bit//
(First, most people who do some calculations in QM put the Planck
constant equal to 1, so the energy is inverse time...)
Some quantities which should - for geometric reasons - have fixed
dimensions, such as the "force" of a field respecting Laplace
equation: ~1/r^2 (Newton, Coulomb),
get what is called the "anomalous dimension", instead of 2 one has
to play with r^(2+x), with x fractional (some people, I suppose that
Andrew Kennedy is one of them, don't like such things...).
Now, if something which should be - classically - dimensionless,
say p^0 acquires this anomaloud dimension p^x, then the only
computationally sane way of dealing with it is to introduce a new
"universal" (?) dimensional constant q, such that the expression
above may be written as (p/q)^x in appropriate units of p and q.
Then, no x may do any harm. This phenomenon, the "dimensional
transmutation" suggests that it is not clear which is the set of
universal dimensional quantities in quantum world.
==
I like all papers about dimensions, and it is very refreshing to
see how people squeeze them into the type systems. (Or play with
geometrical "navigation" in a dimensional world:
http://mail.collegestudent.com/gda01/GDA01.HTM
http://physics.nist.gov/cuu/Units/SIdiagram.html
)
I believe, however, that one should not forget that all that is
*conventional*.
Jerzy Karczmarczuk
Caen, France
From fjh@cs.mu.oz.au Wed Apr 11 02:02:04 2001
From: fjh@cs.mu.oz.au (Fergus Henderson)
Date: Wed, 11 Apr 2001 11:02:04 +1000
Subject: Dimensional analysis with fundeps (some physics comments)
In-Reply-To: <3AD2E8D9.5264FD24@info.unicaen.fr>
References: <20010409163645.27981.qmail@web1504.mail.yahoo.com> <15058.11840.95448.506908@waytogo.peace.co.nz> <3AD2E8D9.5264FD24@info.unicaen.fr>
Message-ID: <20010411110204.A21968@hg.cs.mu.oz.au>
On 10-Apr-2001, Jerzy Karczmarczuk wrote:
> Tom Pledger wrote:
> //about dimensions, units...//
>
> > If you clearly make the type system deal with dimensions rather than
> > units, there's no problem with plugging in multiple unit systems. You
> > just have to pick a scale for the representation.
> >
> > newtype Dimensioned mass length time rep = Dimensioned rep
> >
> > type Mass rep = Dimensioned One Zero Zero rep
> >
> > kg, lb :: Num a => Mass a
> > kg = dm 1
> > lb = dm 0.4535924
> >
> > Angles are dimensionless. (Think of the Taylor series for trig
> > functions.)
> >
> > radian, degree :: Unit
> > radian = dm 1
> > degree = dm (pi/180)
>
> The distinction between dimensions and units may seem for some of
> you utterly trivial. Mass is a mass, kg -> lb, etc. are just conversion
> factors. Angles are dimensionless.
>
> It was not so trivial for the authors of SI, and for some speculative
> physicists, who are not all dead yet. The problem is: what is a
> *fundamental*, *universal* constant?
>
> You see, those constants establish our unit systems!
>
> Many, really many among my friends don't hesitate to work in a frame
> where the speed of light is equal to 1. Yes, ONE, dimensionless. Then,
> passing from length to time is just a unit conversion, and all
> velocities are dimensionless.
...
> one should not forget that all that is *conventional*.
Right. So, from a programming perspective, the question is this:
which conventions are most useful?
If we treat angles as dimensionless, then the type system won't give us much
help in detecting errors when we have e.g. confused radians with degrees.
But this kind of error is a common programming error -- for example,
we (the Mercury team) made that mistake while writing our ICFP competition
entry this year, and from discussion with the Haskell team that came 3rd,
I think they did too, IIRC.
So from a programming perspective, I think it may be a good idea to
treat angles as a separate dimension. Note that you can still express
things like Taylor series expansions easily enough, you just have to
divide by the appropriate unit first.
Actually in the system proposed in this thread, I suppose the type system
does give you some help in detecting or avoiding those kinds of errors,
even if angles are not a separate unit, because in this system ordinary
numbers are not the same as dimensionless units, and so you have to insert
an explicit conversion to convert between numbers and dimensionless units,
and that gives you the opportunity to consider whether the right expression
to convert `angle' from a number to a Unit is `toUnit angle', `angle * radian',
or `angle * degree'. Still, the need to insert explicit `toUnits' is
annoying, and it would be nice to have a system where every number was
already a dimensionless unit. In that case, the argument for making
angles a separate dimension would be stronger.
--
Fergus Henderson | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: | -- the last words of T. S. Garp.
From ashley@semantic.org Wed Apr 11 02:16:51 2001
From: ashley@semantic.org (Ashley Yakeley)
Date: Tue, 10 Apr 2001 18:16:51 -0700
Subject: Dimensional analysis with fundeps (some physics comments)
Message-ID: <200104110116.SAA01777@mail4.halcyon.com>
I'm cross-posting this to the Libraries list...
At 2001-04-10 18:02, Fergus Henderson wrote:
>Still, the need to insert explicit `toUnits' is
>annoying, and it would be nice to have a system where every number was
>already a dimensionless unit.
That's easy:
--
type Unit rep = Dimensioned Zero Zero Zero rep;
instance (Real a) => Real (Unit a) where
{
-- put instances here
};
--
Of course you'll have to appropriately declare superclasses of Real, such
as Num, Ord, Show, Eq etc.
--
Ashley Yakeley, Seattle WA
From ashley@semantic.org Wed Apr 11 03:46:22 2001
From: ashley@semantic.org (Ashley Yakeley)
Date: Tue, 10 Apr 2001 19:46:22 -0700
Subject: Dimensional analysis with fundeps (some physics comments)
Message-ID: <200104110246.TAA10096@mail4.halcyon.com>
At 2001-05-01 18:28, Terrence Brannon wrote:
>"has Ashley
>shown in her example a means of automating a toUnits imperative in
>Haskell that must be done explicitly in Mercury?"
...his...
--
Ashley Yakeley, Seattle WA
From ashley@semantic.org Wed Apr 11 05:51:07 2001
From: ashley@semantic.org (Ashley Yakeley)
Date: Tue, 10 Apr 2001 21:51:07 -0700
Subject: Dimensional analysis with fundeps (some physics comments)
Message-ID: <200104110451.VAA21188@mail4.halcyon.com>
--Emailer_-1225003723
Content-Type: text/plain; charset="US-ASCII"
At 2001-04-10 18:16, I wrote:
>That's easy:
>
>--
>type Unit rep = Dimensioned Zero Zero Zero rep;
>
>instance (Real a) => Real (Unit a) where
> {
> -- put instances here
> };
>--
>
>Of course you'll have to appropriately declare superclasses of Real, such
>as Num, Ord, Show, Eq etc.
I've put this together in the enclosed files (same as previously posted
to the libraries list), which derive from anatoli's work.
--
Ashley Yakeley, Seattle WA
--Emailer_-1225003723
Content-Type: application/octet-stream; name="MarkerType.hs";
x-mac-type="54455854";
x-mac-creator="522A6368"
Content-transfer-encoding: base64
Content-Disposition: Attachment; filename="MarkerType.hs"
LS0gVGhpcyBpcyB3cml0dGVuIGluIEhhc2tlbGwuCm1vZHVsZSBNYXJrZXJUeXBlIHdoZXJlCgl7
CgktLSBCb29sZWFucyBleHByZXNzZWQgYXMgSGFza2VsbCB0eXBlcy4KCWRhdGEgVHJ1ZTsKCWRh
dGEgRmFsc2U7CgkKCWNsYXNzIElzIGE7CglpbnN0YW5jZSBJcyBUcnVlOwoKCWNsYXNzIElzbnQg
YTsKCWluc3RhbmNlIElzbnQgRmFsc2U7CgoJY2xhc3MgRWl0aGVySXMgYSBiOwoJaW5zdGFuY2Ug
RWl0aGVySXMgVHJ1ZSBiOwoJaW5zdGFuY2UgRWl0aGVySXMgRmFsc2UgVHJ1ZTsKCgljbGFzcyBC
b3RoQXJlIGEgYjsKCWluc3RhbmNlIEJvdGhBcmUgVHJ1ZSBUcnVlOwoJCgljbGFzcyBOb3QgYSBi
IHwgYSAtPiBiOwoJaW5zdGFuY2UgTm90IFRydWUgRmFsc2U7CglpbnN0YW5jZSBOb3QgRmFsc2Ug
VHJ1ZTsKCQoJY2xhc3MgT3IgYSBiIGMgfCBhIGIgLT4gYzsKCWluc3RhbmNlIE9yIFRydWUgYiBU
cnVlOwoJaW5zdGFuY2UgT3IgRmFsc2UgYiBiOwoJCgljbGFzcyBBbmQgYSBiIGMgfCBhIGIgLT4g
YzsKCWluc3RhbmNlIEFuZCBUcnVlIGIgYjsKCWluc3RhbmNlIEFuZCBGYWxzZSBiIEZhbHNlOwoK
CXstLQoJSW50ZWdlcnMgZXhwcmVzc2VkIGFzIEhhc2tlbGwgdHlwZXMuIFplcm8gaXMgMC4KCUlm
IHR5cGUgYSBpcyBaZXJvIG9yIHBvc2l0aXZlLCB0aGVuIChTdWNjIGEpIGlzIHBvc2l0aXZlOwoJ
aWYgdHlwZSBhIGlzIFplcm8gb3IgbmVnYXRpdmUsIHRoZW4gKFByZWQgYSkgaXMgbmVnYXRpdmUu
CglUaGlzIGlzIHZlcnkgY3J1ZGUgYW5kIHNob3VsZCBiZSByZXBsYWNlZCB3aXRoIHNpZ24tbWFn
bml0dWRlIAoJcmVwcmVzZW50YXRpb24uCgktLX0KCglkYXRhIFplcm87CglkYXRhIFN1Y2MgbjsK
CWRhdGEgUHJlZCBuOwoKCXR5cGUgT25lID0gU3VjYyBaZXJvOwoJdHlwZSBUd28gPSBTdWNjIE9u
ZTsKCXR5cGUgVGhyZWUgPSBTdWNjIFR3bzsKCXR5cGUgTWludXNPbmUgPSBQcmVkIFplcm87Cgl0
eXBlIE1pbnVzVHdvID0gUHJlZCBNaW51c09uZTsKCXR5cGUgTWludXNUaHJlZSA9IFByZWQgTWlu
dXNUd287CgoJY2xhc3MgU3VjY2Vzc29yIGEgYiB8IGEgLT4gYjsKCWluc3RhbmNlIFN1Y2Nlc3Nv
ciBaZXJvIE9uZTsKCWluc3RhbmNlIFN1Y2Nlc3NvciAoU3VjYyBhKSAoU3VjYyAoU3VjYyBhKSk7
CglpbnN0YW5jZSBTdWNjZXNzb3IgKFByZWQgYSkgYTsKCgljbGFzcyBQcmVkZWNlc3NvciBhIGIg
fCBhIC0+IGI7CglpbnN0YW5jZSBQcmVkZWNlc3NvciBaZXJvIE1pbnVzT25lOwoJaW5zdGFuY2Ug
UHJlZGVjZXNzb3IgKFN1Y2MgYSkgYTsKCWluc3RhbmNlIFByZWRlY2Vzc29yIChQcmVkIGEpIChQ
cmVkIChQcmVkIGEpKTsKCgljbGFzcyBBdExlYXN0IGEgYjsgLS0gYSA+PSBiCglpbnN0YW5jZSBB
dExlYXN0IFplcm8gWmVybzsKCWluc3RhbmNlIEF0TGVhc3QgKFN1Y2MgYSkgWmVybzsKCWluc3Rh
bmNlIEF0TGVhc3QgWmVybyAoUHJlZCBiKTsKCWluc3RhbmNlIEF0TGVhc3QgKFN1Y2MgYSkgKFBy
ZWQgYik7CglpbnN0YW5jZSAoQXRMZWFzdCBhIGIpID0+IEF0TGVhc3QgKFN1Y2MgYSkgKFN1Y2Mg
Yik7CglpbnN0YW5jZSAoQXRMZWFzdCBhIGIpID0+IEF0TGVhc3QgKFByZWQgYSkgKFByZWQgYik7
CgoJY2xhc3MgTmF0dXJhbCBhOwoJaW5zdGFuY2UgTmF0dXJhbCBaZXJvOwoJaW5zdGFuY2UgTmF0
dXJhbCAoU3VjYyBhKTsKCgljbGFzcyBBdExlYXN0T25lIGE7CglpbnN0YW5jZSAoTmF0dXJhbCBh
KSA9PiBBdExlYXN0T25lIChTdWNjIGEpOwoKCWNsYXNzIEV2ZW4gYTsKCWluc3RhbmNlIEV2ZW4g
WmVybzsKCWluc3RhbmNlIChFdmVuIGEpID0+IEV2ZW4gKFN1Y2MgKFN1Y2MgYSkpOwoJaW5zdGFu
Y2UgKEV2ZW4gYSkgPT4gRXZlbiAoUHJlZCAoUHJlZCBhKSk7CgoJLS0gSW50ZWdlciBhZGRpdGlv
bi4gQm90aCBvcGVyYW5kcyBhcmUgZWl0aGVyIHBvc2l0aXZlLCBuZWdhdGl2ZQoJLS0gb3IgemVy
bywgc28gd2UgY29uc2lkZXIgMyozPTkgY2FzZXMuCgljbGFzcyBBZGQgYSBiIGMgfCBhIGIgLT4g
YzsKCglpbnN0YW5jZSBBZGQgWmVybyBaZXJvIFplcm87CgoJaW5zdGFuY2UgQWRkIFplcm8gKFN1
Y2MgYikgKFN1Y2MgYik7CglpbnN0YW5jZSBBZGQgWmVybyAoUHJlZCBiKSAoUHJlZCBiKTsKCglp
bnN0YW5jZSBBZGQgKFN1Y2MgYikgWmVybyAoU3VjYyBiKTsKCWluc3RhbmNlIEFkZCAoUHJlZCBi
KSBaZXJvIChQcmVkIGIpOwoKCWluc3RhbmNlIEFkZCBhIGIgYyA9PiBBZGQgKFN1Y2MgYSkgKFN1
Y2MgYikgKFN1Y2MgKFN1Y2MgYykpOwoJaW5zdGFuY2UgQWRkIGEgYiBjID0+IEFkZCAoUHJlZCBh
KSAoUHJlZCBiKSAoUHJlZCAoUHJlZCBjKSk7CgoJaW5zdGFuY2UgQWRkIGEgYiBjID0+IEFkZCAo
U3VjYyBhKSAoUHJlZCBiKSBjOwoJaW5zdGFuY2UgQWRkIGEgYiBjID0+IEFkZCAoUHJlZCBhKSAo
U3VjYyBiKSBjOwoKCS0tIFN1YnRyYWN0aW9uIGlzIHZlcnkgc2ltaWxhciB0byBhZGRpdGlvbi4K
CWNsYXNzIFN1YiBhIGIgYyB8IGEgYiAtPiBjOwoKCWluc3RhbmNlIFN1YiBaZXJvIFplcm8gWmVy
bzsKCglpbnN0YW5jZSBTdWIgWmVybyAoU3VjYyBiKSAoUHJlZCBiKTsKCWluc3RhbmNlIFN1YiBa
ZXJvIChQcmVkIGIpIChTdWNjIGIpOwoKCWluc3RhbmNlIFN1YiAoU3VjYyBiKSBaZXJvIChTdWNj
IGIpOwoJaW5zdGFuY2UgU3ViIChQcmVkIGIpIFplcm8gKFByZWQgYik7CgoJaW5zdGFuY2UgU3Vi
IGEgYiBjID0+IFN1YiAoU3VjYyBhKSAoU3VjYyBiKSBjOwoJaW5zdGFuY2UgU3ViIGEgYiBjID0+
IFN1YiAoUHJlZCBhKSAoUHJlZCBiKSBjOwoKCWluc3RhbmNlIFN1YiBhIGIgYyA9PiBTdWIgKFN1
Y2MgYSkgKFByZWQgYikgKFN1Y2MgKFN1Y2MgYykpOwoJaW5zdGFuY2UgU3ViIGEgYiBjID0+IFN1
YiAoUHJlZCBhKSAoU3VjYyBiKSAoUHJlZCAoUHJlZCBjKSk7Cgl9Cg==
--Emailer_-1225003723
Content-Type: application/octet-stream; name="Dimension.hs";
x-mac-type="54455854";
x-mac-creator="522A6368"
Content-transfer-encoding: base64
Content-Disposition: Attachment; filename="Dimension.hs"
LS0gVGhpcyBpcyB3cml0dGVuIGluIEhhc2tlbGwuCm1vZHVsZSBEaW1lbnNpb24KCShwbHVzLG1p
bnVzLHRpbWVzLGRpdmJ5LAoJRGltZW5zaW9uZWQsCglVbml0LE1hc3MsTGVuZ3RoLFRpbWUsCgl1
bml0LGtpbG9ncmFtbWUsbWV0cmUsc2Vjb25kCgkpIHdoZXJlCgl7CglpbXBvcnQgTWFya2VyVHlw
ZTsKCgl7LS0KCUEgRGltZW5zaW9uZWQgdHlwZSBjYXJyaWVzIGFsb25nIGV4cG9uZW50cyBmb3Ig
dGhyZWUgYmFzaWMKCWRpbWVuc2lvbnM6IG1hc3MsIGxlbmd0aCwgYW5kIHRpbWUuCgktLX0KCglu
ZXd0eXBlIERpbWVuc2lvbmVkIG1hc3MgbGVuZ3RoIHRpbWUgcmVwID0gTWtEaW1lbnNpb25lZCBy
ZXA7CgoJLS0gU29tZSBoYW5keSBhYmJyZXZpYXRpb25zLgoJdHlwZSBVbml0IHJlcAk9IERpbWVu
c2lvbmVkIFplcm8gWmVybyBaZXJvIHJlcDsKCXR5cGUgTWFzcyByZXAJPSBEaW1lbnNpb25lZCBP
bmUgIFplcm8gWmVybyByZXA7Cgl0eXBlIExlbmd0aCByZXAJPSBEaW1lbnNpb25lZCBaZXJvIE9u
ZSAgWmVybyByZXA7Cgl0eXBlIFRpbWUgcmVwCT0gRGltZW5zaW9uZWQgWmVybyBaZXJvIE9uZSAg
cmVwOwoJCgktLSBpbnN0YW5jZSBwcm9wZXJ0aWVzIGZvciBEaW1lbnNpb25lZHMgaW4gZ2VuZXJh
bCBhbmQgVW5pdHMKCS0tIGluIHBhcnRpY3VsYXIKCXVuZGltZW5zaW9uMSAgZiAoTWtEaW1lbnNp
b25lZCB4KSA9IGYgeDsKCXVuZGltZW5zaW9uMXIgZiB4ID0gTWtEaW1lbnNpb25lZCAodW5kaW1l
bnNpb24xIGYgeCk7Cgl1bmRpbWVuc2lvbjIgIGYgKE1rRGltZW5zaW9uZWQgeCkgKE1rRGltZW5z
aW9uZWQgeSkgPSBmIHggeTsKCXVuZGltZW5zaW9uMnIgZiB4IHkgPSBNa0RpbWVuc2lvbmVkICh1
bmRpbWVuc2lvbjIgZiB4IHkpOwoKCWluc3RhbmNlIChFcSByZXApID0+IEVxIChEaW1lbnNpb25l
ZCBtYXNzIGxlbmd0aCB0aW1lIHJlcCkgd2hlcmUKCQl7CgkJKD09KSA9IHVuZGltZW5zaW9uMiAo
PT0pOwoJCX07CgoJaW5zdGFuY2UgKE9yZCByZXApID0+IE9yZCAoRGltZW5zaW9uZWQgbWFzcyBs
ZW5ndGggdGltZSByZXApIHdoZXJlCgkJewoJCWNvbXBhcmUgPSB1bmRpbWVuc2lvbjIgY29tcGFy
ZTsKCQl9OwoKCWluc3RhbmNlIChTaG93IHJlcCkgPT4gU2hvdyAoVW5pdCByZXApIHdoZXJlCgkJ
ewoJCXNob3cgPSB1bmRpbWVuc2lvbjEgc2hvdzsKCQl9OwoKCWluc3RhbmNlIChOdW0gcmVwKSA9
PiBOdW0gKFVuaXQgcmVwKSB3aGVyZQoJCXsKCQkoKykJCQk9IHVuZGltZW5zaW9uMnIgKCspOwoJ
CSgtKQkJCT0gdW5kaW1lbnNpb24yciAoLSk7CgkJKCopCQkJPSB1bmRpbWVuc2lvbjJyICgqKTsK
CQluZWdhdGUJCT0gdW5kaW1lbnNpb24xciBuZWdhdGU7CgkJYWJzCQkJPSB1bmRpbWVuc2lvbjFy
IGFiczsKCQlzaWdudW0JCT0gdW5kaW1lbnNpb24xciBzaWdudW07CgkJZnJvbUludGVnZXIJPSBN
a0RpbWVuc2lvbmVkIC4gZnJvbUludGVnZXI7CgkJZnJvbUludAkJPSBNa0RpbWVuc2lvbmVkIC4g
ZnJvbUludDsKCQl9OwoKCWluc3RhbmNlIChSZWFsIHJlcCkgPT4gUmVhbCAoVW5pdCByZXApIHdo
ZXJlCgkJewoJCXRvUmF0aW9uYWwgPSB1bmRpbWVuc2lvbjEgdG9SYXRpb25hbDsKCQl9OwoKCWlu
c3RhbmNlIChGcmFjdGlvbmFsIHJlcCkgPT4gRnJhY3Rpb25hbCAoVW5pdCByZXApIHdoZXJlCgkJ
ewoJCSgvKQkJCQk9IHVuZGltZW5zaW9uMnIgKC8pOwoJCXJlY2lwCQkJPSB1bmRpbWVuc2lvbjFy
IHJlY2lwOwoJCWZyb21SYXRpb25hbAk9IE1rRGltZW5zaW9uZWQgLiBmcm9tUmF0aW9uYWw7CgkJ
ZnJvbURvdWJsZQkJPSBNa0RpbWVuc2lvbmVkIC4gZnJvbURvdWJsZTsKCQl9OwoKCWluc3RhbmNl
IChGbG9hdGluZyByZXApID0+IEZsb2F0aW5nIChVbml0IHJlcCkgd2hlcmUKCQl7CgkJcGkJCT0J
TWtEaW1lbnNpb25lZCBwaTsKCQlleHAJCT0JdW5kaW1lbnNpb24xciBleHA7CgkJbG9nCQk9CXVu
ZGltZW5zaW9uMXIgbG9nOwoJCXNxcnQJPQl1bmRpbWVuc2lvbjFyIHNxcnQ7CgkJKCoqKQk9CXVu
ZGltZW5zaW9uMnIgKCoqKTsKCQlsb2dCYXNlCT0JdW5kaW1lbnNpb24yciBsb2dCYXNlOwoJCXNp
bgkJPQl1bmRpbWVuc2lvbjFyIHNpbjsKCQljb3MJCT0JdW5kaW1lbnNpb24xciBjb3M7CgkJdGFu
CQk9CXVuZGltZW5zaW9uMXIgdGFuOwoJCWFzaW4JPQl1bmRpbWVuc2lvbjFyIGFzaW47CgkJYWNv
cwk9CXVuZGltZW5zaW9uMXIgYWNvczsKCQlhdGFuCT0JdW5kaW1lbnNpb24xciBhdGFuOwoJCXNp
bmgJPQl1bmRpbWVuc2lvbjFyIHNpbmg7CgkJY29zaAk9CXVuZGltZW5zaW9uMXIgY29zaDsKCQl0
YW5oCT0JdW5kaW1lbnNpb24xciB0YW5oOwoJCWFzaW5oCT0JdW5kaW1lbnNpb24xciBhc2luaDsK
CQlhY29zaAk9CXVuZGltZW5zaW9uMXIgYWNvc2g7CgkJYXRhbmgJPQl1bmRpbWVuc2lvbjFyIGF0
YW5oOwoJCX07CgkKCWluc3RhbmNlIChSZWFsRnJhYyByZXApID0+IFJlYWxGcmFjIChVbml0IHJl
cCkgd2hlcmUKCQl7CgkJcHJvcGVyRnJhY3Rpb24gKE1rRGltZW5zaW9uZWQgeCkgPSAocCxNa0Rp
bWVuc2lvbmVkIHEpIHdoZXJlCgkJCXsKCQkJKHAscSkgPSBwcm9wZXJGcmFjdGlvbiB4OwoJCQl9
OwoJCXRydW5jYXRlCQk9IHVuZGltZW5zaW9uMSB0cnVuY2F0ZTsKCQlyb3VuZAkJCT0gdW5kaW1l
bnNpb24xIHJvdW5kOwoJCWNlaWxpbmcJCQk9IHVuZGltZW5zaW9uMSBjZWlsaW5nOwoJCWZsb29y
CQkJPSB1bmRpbWVuc2lvbjEgZmxvb3I7CgkJfTsKCQoJaW5zdGFuY2UgKFJlYWxGbG9hdCByZXAp
ID0+IFJlYWxGbG9hdCAoVW5pdCByZXApIHdoZXJlCgkJewoJCWZsb2F0UmFkaXgJCT0gdW5kaW1l
bnNpb24xIGZsb2F0UmFkaXg7CgkJZmxvYXREaWdpdHMJCT0gdW5kaW1lbnNpb24xIGZsb2F0RGln
aXRzOwoJCWZsb2F0UmFuZ2UJCT0gdW5kaW1lbnNpb24xIGZsb2F0UmFuZ2U7CgkJZGVjb2RlRmxv
YXQJCT0gdW5kaW1lbnNpb24xIGRlY29kZUZsb2F0OwoJCWVuY29kZUZsb2F0IHggaQk9IE1rRGlt
ZW5zaW9uZWQgKGVuY29kZUZsb2F0IHggaSk7CgkJZXhwb25lbnQJCT0gdW5kaW1lbnNpb24xIGV4
cG9uZW50OwoJCXNpZ25pZmljYW5kCQk9IHVuZGltZW5zaW9uMXIgc2lnbmlmaWNhbmQ7CgkJc2Nh
bGVGbG9hdCBpCT0gdW5kaW1lbnNpb24xciAoc2NhbGVGbG9hdCBpKTsKCQlpc05hTgkJCT0gdW5k
aW1lbnNpb24xIGlzTmFOOwoJCWlzSW5maW5pdGUJCT0gdW5kaW1lbnNpb24xIGlzSW5maW5pdGU7
CgkJaXNEZW5vcm1hbGl6ZWQJPSB1bmRpbWVuc2lvbjEgaXNEZW5vcm1hbGl6ZWQ7CgkJaXNOZWdh
dGl2ZVplcm8JPSB1bmRpbWVuc2lvbjEgaXNOZWdhdGl2ZVplcm87CgkJaXNJRUVFCQkJPSB1bmRp
bWVuc2lvbjEgaXNJRUVFOwoJCWF0YW4yCQkJPSB1bmRpbWVuc2lvbjJyIGF0YW4yOwoJCX07CgoJ
LS0gWW91IGNhbiBhZGQgb3Igc3VidHJhY3Qgb25seSBpZGVudGljYWxseSBkaW1lbnNpb25lZCBx
dWFudGl0aWVzLgoJcGx1cywgbWludXMgOjogTnVtIHJlcCA9PgoJCURpbWVuc2lvbmVkIG1hc3Mg
bGVuZ3RoIHRpbWUgcmVwIC0+CgkJRGltZW5zaW9uZWQgbWFzcyBsZW5ndGggdGltZSByZXAgLT4K
CQlEaW1lbnNpb25lZCBtYXNzIGxlbmd0aCB0aW1lIHJlcDsKCXBsdXMgIChNa0RpbWVuc2lvbmVk
IHgpIChNa0RpbWVuc2lvbmVkIHkpID0gTWtEaW1lbnNpb25lZCAoeCt5KTsKCW1pbnVzIChNa0Rp
bWVuc2lvbmVkIHgpIChNa0RpbWVuc2lvbmVkIHkpID0gTWtEaW1lbnNpb25lZCAoeC15KTsKCgkt
LSBZb3UgY2FuIG11bHRpcGx5IGFueSB0d28gZGltZW5zaW9uZWQgcXVhbnRpdGllczsgZXhwb25l
bnRzCgktLSBmcm9tIHRoZSBvcGVyYW5kcyBhZGQgdXAgaW4gdGhlIHJlc3VsdC4KCXRpbWVzIDo6
IChOdW0gcmVwLAoJCUFkZCBtYXNzIG1hc3MnIG1hc3MnJywKCQlBZGQgbGVuZ3RoIGxlbmd0aCcg
bGVuZ3RoJycsCgkJQWRkIHRpbWUgdGltZScgdGltZScnKSA9PgoJCURpbWVuc2lvbmVkIG1hc3Mg
bGVuZ3RoIHRpbWUgcmVwIC0+CgkJRGltZW5zaW9uZWQgbWFzcycgbGVuZ3RoJyB0aW1lJyByZXAg
LT4KCQlEaW1lbnNpb25lZCBtYXNzJycgbGVuZ3RoJycgdGltZScnIHJlcDsKCXRpbWVzIChNa0Rp
bWVuc2lvbmVkIHgpIChNa0RpbWVuc2lvbmVkIHkpID0gTWtEaW1lbnNpb25lZCAoeCAqIHkpOwoK
CS0tIFNpbWlsYXJseSBmb3IgZGl2aXNpb24sIGV4Y2VwdCBleHBvbmVudHMgYXJlIHN1YnRyYWN0
ZWQuCglkaXZieSA6OiAoRnJhY3Rpb25hbCByZXAsCgkJU3ViIG1hc3MgbWFzcycgbWFzcycnLAoJ
CVN1YiBsZW5ndGggbGVuZ3RoJyBsZW5ndGgnJywKCQlTdWIgdGltZSB0aW1lJyB0aW1lJycpID0+
CgkJRGltZW5zaW9uZWQgbWFzcyBsZW5ndGggdGltZSByZXAgLT4KCQlEaW1lbnNpb25lZCBtYXNz
JyBsZW5ndGgnIHRpbWUnIHJlcCAtPgoJCURpbWVuc2lvbmVkIG1hc3MnJyBsZW5ndGgnJyB0aW1l
JycgcmVwOwoJZGl2YnkgKE1rRGltZW5zaW9uZWQgeCkgKE1rRGltZW5zaW9uZWQgeSkgPSBNa0Rp
bWVuc2lvbmVkICh4IC8geSk7CgoJLS0gYmFzZSB1bml0cyBhcyBTSS4KCWtpbG9ncmFtbWUJOjog
KE51bSByZXApID0+IE1hc3MgcmVwOwoJa2lsb2dyYW1tZQk9IChNa0RpbWVuc2lvbmVkIDEpOwoJ
bWV0cmUJCTo6IChOdW0gcmVwKSA9PiBMZW5ndGggcmVwOwoJbWV0cmUJCT0gKE1rRGltZW5zaW9u
ZWQgMSk7CglzZWNvbmQJCTo6IChOdW0gcmVwKSA9PiBUaW1lIHJlcDsKCXNlY29uZAkJPSAoTWtE
aW1lbnNpb25lZCAxKTsKCXVuaXQJCTo6IChOdW0gcmVwKSA9PiBVbml0IHJlcDsKCXVuaXQJCT0g
MTsKCX0K
--Emailer_-1225003723--
From fjh@cs.mu.oz.au Wed Apr 11 06:12:14 2001
From: fjh@cs.mu.oz.au (Fergus Henderson)
Date: Wed, 11 Apr 2001 15:12:14 +1000
Subject: Dimensional analysis with fundeps (some physics comments)
In-Reply-To: <15087.25276.355189.814894@gargle.gargle.HOWL>
References: <200104110116.SAA01777@mail4.halcyon.com> <15087.25276.355189.814894@gargle.gargle.HOWL>
Message-ID: <20010411151214.A3831@hg.cs.mu.oz.au>
On 01-May-2001, Terrence Brannon wrote:
>
> my question (primarily for Fergus) is: "has Ashley
> shown in her example a means of automating a toUnits imperative in
> Haskell that must be done explicitly in Mercury?"
Yes. In Haskell, there's some syntactic sugar attached to every numeric
literal: "123" is defined to mean "fromInteger 123", where "fromInteger"
is an overloaded (class member) function defined in the standard Prelude.
In Mercury, if you want "fromInteger" or "toUnit", then you need
to write it explicitly.
--
Fergus Henderson | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: | -- the last words of T. S. Garp.
From ashley@semantic.org Thu Apr 19 09:34:41 2001
From: ashley@semantic.org (Ashley Yakeley)
Date: Thu, 19 Apr 2001 01:34:41 -0700
Subject: Dimensional analysis with fundeps
Message-ID: <200104190834.BAA12439@mail4.halcyon.com>
--Emailer_-1223820195
Content-Type: text/plain; charset="US-ASCII"
At 2001-04-09 10:29, Dylan Thurston wrote:
>I hadn't thought about doing rational arithmetic with GCDs. Might be
>nice.
Herewith my attempt. I can't test it though, it runs afoul of one of the
many bugs in Hugs' type-extension handling, and I haven't been able to
run GHC on my MacOS X box.
--
Ashley Yakeley, Seattle WA
--Emailer_-1223820195
Content-Type: application/octet-stream; name="MarkerType.hs";
x-mac-type="54455854";
x-mac-creator="522A6368"
Content-transfer-encoding: base64
Content-Disposition: Attachment; filename="MarkerType.hs"
LS0gVGhpcyBpcyB3cml0dGVuIGluIEhhc2tlbGwuCm1vZHVsZSBNYXJrZXJUeXBlIHdoZXJlCgl7
CglkYXRhIFNpbmdsZXRvbiBhID0gU2luZ2xldG9uOwoKCWluc3RhbmNlIFNob3cgKFNpbmdsZXRv
biBhKSB3aGVyZQoJCXsKCQlzaG93IFNpbmdsZXRvbiA9ICJzaW5nbGV0b24iOwoJCX07CgoJLS0g
Qm9vbGVhbnMgZXhwcmVzc2VkIGFzIEhhc2tlbGwgdHlwZXMuCglkYXRhIFRydWU7CglkYXRhIEZh
bHNlOwoJCgljbGFzcyBCb29sZWFuVHlwZSBhOwoJaW5zdGFuY2UgQm9vbGVhblR5cGUgVHJ1ZTsK
CWluc3RhbmNlIEJvb2xlYW5UeXBlIEZhbHNlOwoKCWNsYXNzIElzIGE7CglpbnN0YW5jZSBJcyBU
cnVlOwoKCWNsYXNzIElzbnQgYTsKCWluc3RhbmNlIElzbnQgRmFsc2U7CgoJY2xhc3MgRWl0aGVy
SXMgYSBiOwoJaW5zdGFuY2UgRWl0aGVySXMgVHJ1ZSBiOwoJaW5zdGFuY2UgRWl0aGVySXMgRmFs
c2UgVHJ1ZTsKCgljbGFzcyBCb3RoQXJlIGEgYjsKCWluc3RhbmNlIEJvdGhBcmUgVHJ1ZSBUcnVl
OwoJCgljbGFzcyBOb3QgYSBiIHwgYSAtPiBiOwoJaW5zdGFuY2UgTm90IFRydWUgRmFsc2U7Cglp
bnN0YW5jZSBOb3QgRmFsc2UgVHJ1ZTsKCQoJY2xhc3MgT3IgYSBiIGMgfCBhIGIgLT4gYzsKCWlu
c3RhbmNlIE9yIFRydWUgYiBUcnVlOwoJaW5zdGFuY2UgT3IgRmFsc2UgYiBiOwoJCgljbGFzcyBB
bmQgYSBiIGMgfCBhIGIgLT4gYzsKCWluc3RhbmNlIEFuZCBUcnVlIGIgYjsKCWluc3RhbmNlIEFu
ZCBGYWxzZSBiIEZhbHNlOwoKCWNsYXNzIFBpY2sgd2hpY2ggdCBmIHIgfCB3aGljaCB0IGYgLT4g
cjsKCWluc3RhbmNlIFBpY2sgVHJ1ZSAgdCBmIHQ7CglpbnN0YW5jZSBQaWNrIEZhbHNlIHQgZiBm
OwoKCXstLQoJSW50ZWdlcnMgZXhwcmVzc2VkIGFzIEhhc2tlbGwgdHlwZXMuIFplcm8gaXMgMC4K
CUlmIHR5cGUgYSBpcyBaZXJvIG9yIHBvc2l0aXZlLCB0aGVuIChTdWNjIGEpIGlzIHBvc2l0aXZl
OwoJaWYgdHlwZSBhIGlzIFplcm8gb3IgbmVnYXRpdmUsIHRoZW4gKFByZWQgYSkgaXMgbmVnYXRp
dmUuCglUaGlzIGlzIHZlcnkgY3J1ZGUgYW5kIHNob3VsZCBiZSByZXBsYWNlZCB3aXRoIHNpZ24t
bWFnbml0dWRlIAoJcmVwcmVzZW50YXRpb24uCgktLX0KCglkYXRhIFplcm87CglkYXRhIFN1Y2Mg
bjsKCWRhdGEgUHJlZCBuOwoKCWNsYXNzIE5hdHVyYWxUeXBlIGE7CglpbnN0YW5jZSBOYXR1cmFs
VHlwZSBaZXJvOwoJaW5zdGFuY2UgTmF0dXJhbFR5cGUgKFN1Y2MgYSk7CgoJY2xhc3MgSW50ZWdl
clR5cGUgYTsKCWluc3RhbmNlIEludGVnZXJUeXBlIFplcm87CglpbnN0YW5jZSBJbnRlZ2VyVHlw
ZSAoU3VjYyBhKTsKCWluc3RhbmNlIEludGVnZXJUeXBlIChQcmVkIGEpOwoKCXR5cGUgT25lCT0g
U3VjYyBaZXJvOwoJdHlwZSBUd28JPSBTdWNjIE9uZTsKCXR5cGUgVGhyZWUJPSBTdWNjIFR3bzsK
CXR5cGUgRm91cgk9IFN1Y2MgVGhyZWU7Cgl0eXBlIEZpdmUJPSBTdWNjIEZvdXI7Cgl0eXBlIFNp
eAk9IFN1Y2MgRml2ZTsKCXR5cGUgU2V2ZW4JPSBTdWNjIFNpeDsKCXR5cGUgRWlnaHQJPSBTdWNj
IFNldmVuOwoJdHlwZSBOaW5lCT0gU3VjYyBFaWdodDsKCXR5cGUgVGVuCT0gU3VjYyBOaW5lOwoJ
dHlwZSBNaW51c09uZSA9IFByZWQgWmVybzsKCXR5cGUgTWludXNUd28gPSBQcmVkIE1pbnVzT25l
OwoJdHlwZSBNaW51c1RocmVlID0gUHJlZCBNaW51c1R3bzsKCgljbGFzcyBTdWNjZXNzb3IgYSBi
IHwgYSAtPiBiOwoJaW5zdGFuY2UgU3VjY2Vzc29yIFplcm8gT25lOwoJaW5zdGFuY2UgU3VjY2Vz
c29yIChTdWNjIGEpIChTdWNjIChTdWNjIGEpKTsKCWluc3RhbmNlIFN1Y2Nlc3NvciAoUHJlZCBh
KSBhOwoKCWNsYXNzIFByZWRlY2Vzc29yIGEgYiB8IGEgLT4gYjsKCWluc3RhbmNlIFByZWRlY2Vz
c29yIFplcm8gTWludXNPbmU7CglpbnN0YW5jZSBQcmVkZWNlc3NvciAoU3VjYyBhKSBhOwoJaW5z
dGFuY2UgUHJlZGVjZXNzb3IgKFByZWQgYSkgKFByZWQgKFByZWQgYSkpOwoKCWNsYXNzIElzQXRM
ZWFzdCBhIGIgYyB8IGEgYiAtPiBjOyAtLSBjID09IChhID49IGIpCglpbnN0YW5jZSBJc0F0TGVh
c3QgWmVybyBaZXJvIFRydWU7CgoJaW5zdGFuY2UgSXNBdExlYXN0IFplcm8gKFByZWQgYikgVHJ1
ZTsKCWluc3RhbmNlIElzQXRMZWFzdCBaZXJvIChTdWNjIGIpIEZhbHNlOwoKCWluc3RhbmNlIElz
QXRMZWFzdCAoU3VjYyBhKSBaZXJvIFRydWU7CglpbnN0YW5jZSBJc0F0TGVhc3QgKFByZWQgYSkg
WmVybyBGYWxzZTsKCglpbnN0YW5jZSBJc0F0TGVhc3QgKFN1Y2MgYSkgKFByZWQgYikgVHJ1ZTsK
CWluc3RhbmNlIElzQXRMZWFzdCAoUHJlZCBhKSAoU3VjYyBiKSBGYWxzZTsKCglpbnN0YW5jZSAo
SXNBdExlYXN0IGEgYiBjKSA9PiBJc0F0TGVhc3QgKFN1Y2MgYSkgKFN1Y2MgYikgYzsKCWluc3Rh
bmNlIChJc0F0TGVhc3QgYSBiIGMpID0+IElzQXRMZWFzdCAoUHJlZCBhKSAoUHJlZCBiKSBjOwoK
CWNsYXNzIElzRXZlbiBhIGUgfCBhIC0+IGU7CglpbnN0YW5jZSBJc0V2ZW4gWmVybyBUcnVlOwoJ
aW5zdGFuY2UgKElzRXZlbiBhIGUsTm90IGUgbmUpID0+IElzRXZlbiAoU3VjYyBhKSBuZTsKCWlu
c3RhbmNlIChJc0V2ZW4gYSBlLE5vdCBlIG5lKSA9PiBJc0V2ZW4gKFByZWQgYSkgbmU7CgoJY2xh
c3MgQXRMZWFzdCBhIGI7IC0tIGEgPj0gYgoJaW5zdGFuY2UgKElzQXRMZWFzdCBhIGIgVHJ1ZSkg
PT4gQXRMZWFzdCBhIGI7CgoJY2xhc3MgQXRMZWFzdE9uZSBhOwoJaW5zdGFuY2UgKE5hdHVyYWxU
eXBlIGEpID0+IEF0TGVhc3RPbmUgKFN1Y2MgYSk7CgoJLS0gSW50ZWdlciBhZGRpdGlvbi4gQm90
aCBvcGVyYW5kcyBhcmUgZWl0aGVyIHBvc2l0aXZlLCBuZWdhdGl2ZQoJLS0gb3IgemVybywgc28g
d2UgY29uc2lkZXIgMyozPTkgY2FzZXMuCgljbGFzcyBBZGQgYSBiIGMgfCBhIGIgLT4gYzsKCglp
bnN0YW5jZSBBZGQgWmVybyBaZXJvIFplcm87CgoJaW5zdGFuY2UgQWRkIFplcm8gKFN1Y2MgYikg
KFN1Y2MgYik7CglpbnN0YW5jZSBBZGQgWmVybyAoUHJlZCBiKSAoUHJlZCBiKTsKCglpbnN0YW5j
ZSBBZGQgKFN1Y2MgYikgWmVybyAoU3VjYyBiKTsKCWluc3RhbmNlIEFkZCAoUHJlZCBiKSBaZXJv
IChQcmVkIGIpOwoKCWluc3RhbmNlIEFkZCBhIGIgYyA9PiBBZGQgKFN1Y2MgYSkgKFN1Y2MgYikg
KFN1Y2MgKFN1Y2MgYykpOwoJaW5zdGFuY2UgQWRkIGEgYiBjID0+IEFkZCAoUHJlZCBhKSAoUHJl
ZCBiKSAoUHJlZCAoUHJlZCBjKSk7CgoJaW5zdGFuY2UgQWRkIGEgYiBjID0+IEFkZCAoU3VjYyBh
KSAoUHJlZCBiKSBjOwoJaW5zdGFuY2UgQWRkIGEgYiBjID0+IEFkZCAoUHJlZCBhKSAoU3VjYyBi
KSBjOwoKCWNsYXNzIE5lZ2F0ZSBhIGIgfCBhIC0+IGI7CglpbnN0YW5jZSBOZWdhdGUgWmVybyBa
ZXJvOwoJaW5zdGFuY2UgKE5lZ2F0ZSBhIGIpID0+IE5lZ2F0ZSAoU3VjYyBhKSAoUHJlZCBiKTsK
CWluc3RhbmNlIChOZWdhdGUgYSBiKSA9PiBOZWdhdGUgKFByZWQgYSkgKFN1Y2MgYik7CgoJY2xh
c3MgU3ViIGEgYiBjIHwgYSBiIC0+IGM7CgoJaW5zdGFuY2UgU3ViIFplcm8gWmVybyBaZXJvOwoK
CWluc3RhbmNlIE5lZ2F0ZSBiIGMgPT4gU3ViIFplcm8gKFN1Y2MgYikgKFByZWQgYyk7CglpbnN0
YW5jZSBOZWdhdGUgYiBjID0+IFN1YiBaZXJvIChQcmVkIGIpIChTdWNjIGMpOwoKCWluc3RhbmNl
IFN1YiAoU3VjYyBiKSBaZXJvIChTdWNjIGIpOwoJaW5zdGFuY2UgU3ViIChQcmVkIGIpIFplcm8g
KFByZWQgYik7CgoJaW5zdGFuY2UgU3ViIGEgYiBjID0+IFN1YiAoU3VjYyBhKSAoU3VjYyBiKSBj
OwoJaW5zdGFuY2UgU3ViIGEgYiBjID0+IFN1YiAoUHJlZCBhKSAoUHJlZCBiKSBjOwoKCWluc3Rh
bmNlIFN1YiBhIGIgYyA9PiBTdWIgKFN1Y2MgYSkgKFByZWQgYikgKFN1Y2MgKFN1Y2MgYykpOwoJ
aW5zdGFuY2UgU3ViIGEgYiBjID0+IFN1YiAoUHJlZCBhKSAoU3VjYyBiKSAoUHJlZCAoUHJlZCBj
KSk7CgoJY2xhc3MgQWJzIGEgYiB8IGEgLT4gYjsKCWluc3RhbmNlIEFicyBaZXJvIFplcm87Cglp
bnN0YW5jZSBBYnMgKFN1Y2MgYSkgKFN1Y2MgYSk7CglpbnN0YW5jZSAoQWJzIGEgYikgPT4gQWJz
IChQcmVkIGEpIChTdWNjIGIpOwoKCWNsYXNzIEdDRCBhIGIgZ2NkIHwgYSBiIC0+IGdjZDsKCWlu
c3RhbmNlIEdDRCBaZXJvIGIgYjsKCWluc3RhbmNlIEdDRCAoU3VjYyBhKSBaZXJvIChTdWNjIGEp
OwoJaW5zdGFuY2UKCQkoCgkJU3ViIGEgYiBhbWIsCgkJQWJzIGFtYiBkaWZmLAoJCUlzQXRMZWFz
dCBaZXJvIGFtYiBhYmlnZ2VyLAoJCVBpY2sgYWJpZ2dlciBiIGEgc21hbGxlciwKCQlHQ0QgKFN1
Y2Mgc21hbGxlcikgZGlmZiBnY2QKCQkpCgkJPT4gR0NEIChTdWNjIGEpIChTdWNjIGIpIGdjZDsK
CgktLSBvbmx5IGluc3RhbmNlcyBmb3IgYSBtb2QgYiA9PSAwCgljbGFzcyBEaXZpZGUgYSBiIGMg
fCBhIGIgLT4gYzsKCWluc3RhbmNlCgkJKAoJCU5lZ2F0ZSBhIG5hLAoJCU5lZ2F0ZSBiIG5iLAoJ
CURpdmlkZSBuYSAoU3VjYyBuYikgYwoJCSkKCQk9PiBEaXZpZGUgYSAoUHJlZCBiKSBjOwoJaW5z
dGFuY2UgRGl2aWRlIFplcm8gKFN1Y2MgYikgWmVybzsKCWluc3RhbmNlCgkJKAoJCVN1YiBhIGIg
YW1iLAoJCURpdmlkZSBhbWIgKFN1Y2MgYikgYwoJCSkKCQk9PiBEaXZpZGUgKFN1Y2MgYSkgKFN1
Y2MgYikgKFN1Y2MgYyk7CglpbnN0YW5jZQoJCSgKCQlBZGQgYSBiIGFwYiwKCQlEaXZpZGUgYXBi
IChTdWNjIGIpIGMKCQkpCgkJPT4gRGl2aWRlIChQcmVkIGEpIChTdWNjIGIpIChQcmVkIGMpOwoJ
CglkYXRhIFJhdGlvbmFsVHlwZSBudW0gZGVub207CgkKCWNsYXNzIE1ha2VSYXRpb25hbCBuIGQg
ciB8IG4gZCAtPiByOwoJaW5zdGFuY2UKCQkoCgkJR0NEIG4gZCBnY2QsCgkJRGl2aWRlIG4gZ2Nk
IG51bSwKCQlEaXZpZGUgZCBnY2QgZGVub20KCQkpCgkJPT4gTWFrZVJhdGlvbmFsIG4gZCAoUmF0
aW9uYWxUeXBlIG51bSBkZW5vbSk7Cgl9Cg==
--Emailer_-1223820195--
From mark@chaos.x-philes.com Mon Apr 23 04:19:36 2001
From: mark@chaos.x-philes.com (Mark Carroll)
Date: Sun, 22 Apr 2001 23:19:36 -0400 (EDT)
Subject: Novice question
Message-ID:
Is this a good place for novice questions? I have just started to try to
learn Haskell, and am using Hugs to start with. When I write the
not-very-useful function,
greaterthan 0 _ _ = False
greaterthan _ (x:xs) (y:ys) = x > y
and test it,
Main> greaterthan 2 [3] [4]
False
Main> greaterthan 3 [4] [3]
True
Main> greaterthan 0 [4] [3]
False
Main> greaterthan 0 [] []
ERROR: Unresolved overloading
*** Type : Ord a => Bool
*** Expression : greaterthan 0 [] []
Main>
...I don't understand what the problem is. I'm guessing that the problem
is with the use of > and it not knowing which 'version' of > to use, but
it doesn't need to know because we're not matching with that line anyway.
I hope that didn't sound quite as confused as I am. (-:
Is there anything easy someone can say that will enlighten me as to why
things are as they are?
(I understand that Ord is a set of types and that you can probably only
apply > to things that are in it, and that > is overloaded somehow.)
Thanks.
-- Mark
From Tom.Pledger@peace.com Mon Apr 23 04:41:47 2001
From: Tom.Pledger@peace.com (Tom Pledger)
Date: Mon, 23 Apr 2001 15:41:47 +1200
Subject: Novice question
In-Reply-To:
References:
Message-ID: <15075.42107.571713.994461@waytogo.peace.co.nz>
Mark Carroll writes:
| Is this a good place for novice questions?
Yes, either here or on http://haskell.org/wiki/wiki
| greaterthan 0 _ _ = False
| greaterthan _ (x:xs) (y:ys) = x > y
:
| Main> greaterthan 0 [] []
| ERROR: Unresolved overloading
| *** Type : Ord a => Bool
| *** Expression : greaterthan 0 [] []
|
| Main>
|
| ...I don't understand what the problem is. I'm guessing that the problem
| is with the use of > and it not knowing which 'version' of > to use, but
| it doesn't need to know because we're not matching with that line anyway.
| I hope that didn't sound quite as confused as I am. (-:
Your guess is basically right. The error can be fixed by specifying
`the type of element that the lists do not contain', so to speak.
greaterthan 0 [] ([] :: [()]) -- empty list of ()
greaterthan 0 [] ([] :: [Bool]) -- empty list of Bool
greaterthan 0 [] "" -- empty list of Char
This need for an explicit type signature is quite common in
out-of-context tests at an interpreter's prompt, but rarer in actual
programs.
HTH.
Tom
From fjh@cs.mu.oz.au Mon Apr 23 18:43:44 2001
From: fjh@cs.mu.oz.au (Fergus Henderson)
Date: Tue, 24 Apr 2001 03:43:44 +1000
Subject: Novice question
In-Reply-To:
References:
Message-ID: <20010424034344.A31566@hg.cs.mu.oz.au>
On 22-Apr-2001, Mark Carroll wrote:
> greaterthan 0 _ _ = False
> greaterthan _ (x:xs) (y:ys) = x > y
...
> Main> greaterthan 0 [] []
> ERROR: Unresolved overloading
> *** Type : Ord a => Bool
> *** Expression : greaterthan 0 [] []
>
> ...I don't understand what the problem is. I'm guessing that the problem
> is with the use of > and it not knowing which 'version' of > to use,
Yes.
> but it doesn't need to know because we're not matching with that line anyway.
The type checker doesn't know that.
The type checker only takes into account the types of the arguments,
not their values, so it can't tell when an ambiguity like this
doesn't matter because the ambiguous code won't be executed.
--
Fergus Henderson | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: | -- the last words of T. S. Garp.
From shae@webwitches.com Sun Apr 29 13:54:03 2001
From: shae@webwitches.com (Shae Erisson)
Date: Sun, 29 Apr 2001 15:54:03 +0300
Subject: tutorial and other random bits
Message-ID: <20010429155403O.shae@webwitches.com>
Hi, I've started learning Haskell, but I'm coming from a Python/Java/SQL/etc background.
I've learned a bit of elisp and scheme in my travels, but Haskell is very very different even from those two.
The gentle introduction seems more like a brickbat to me, the best things I've found so far are homework assignments from various CS classes around the world.
I've looked for a good irc channel dedicated to haskell, and not found one. I've also searched for a tutorial that works along the same lines as the Python tutorial, and not found one.
I have lots of complete beginner questions...
Also, it seems the Haskell Wiki has lost many pages again. Would it be possible to use MoinMoin instead of pyWiki?
I looked at the "applications written in Haskell" links, but many of the links are dead.
I have found some sample code by searching google, but I'd really like to find a library of small pieces of demo code showing the various idioms and useful basics. Does such a thing exist?
Thanks,
----
Shae Matijs Erisson - http://www.webwitches.com/~shae/
From khchoi@ruby.kaist.ac.kr Sun Apr 29 14:53:09 2001
From: khchoi@ruby.kaist.ac.kr (Kwanghoon Choi)
Date: Sun, 29 Apr 2001 22:53:09 +0900 (KST)
Subject: tutorial and other random bits
In-Reply-To: <20010429155403O.shae@webwitches.com>
Message-ID:
Hi,
I have an OLD web page entitled "Haskell Programming in the Imaginary World".
The web page contains only several small Haskell programs and it just
reflects my unorganized thoughts and programs. Some of them may not follow
the Haskell 98 definition. So, it may not be the one that you are looking for.
But I had the same opinion as yours when I made the web page.
> I have found some sample code by searching google, but I'd really like
> to find a library of small pieces of demo code showing the
> various idioms and useful basics. Does such a thing exist?
http://pllab.kaist.ac.kr/~khchoi/haskell/
Kwanghoon
On Sun, 29 Apr 2001, Shae Erisson wrote:
> Hi, I've started learning Haskell, but I'm coming from a Python/Java/SQL/etc background.
> I've learned a bit of elisp and scheme in my travels, but Haskell is very very different even from those two.
>
> The gentle introduction seems more like a brickbat to me, the best things I've found so far are homework assignments from various CS classes around the world.
>
> I've looked for a good irc channel dedicated to haskell, and not found one. I've also searched for a tutorial that works along the same lines as the Python tutorial, and not found one.
>
> I have lots of complete beginner questions...
>
> Also, it seems the Haskell Wiki has lost many pages again. Would it be possible to use MoinMoin instead of pyWiki?
>
> I looked at the "applications written in Haskell" links, but many of the links are dead.
> I have found some sample code by searching google, but I'd really like to find a library
> of small pieces of demo code showing the various idioms and useful basics. Does such a thing exist?
> Thanks,
> ----
> Shae Matijs Erisson - http://www.webwitches.com/~shae/
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>