Java was Re: (no subject)
Have a look at <http://www.mondrian-script.org>
Erik
----- Original Message -----
From: "Chris Angus" <CAngus@Armature.com>
To: <haskell-cafe@haskell.org>
Sent: Friday, November 24, 2000 1:44 AM
Subject: (no subject)
> I was wondering if
> Has anybody had access to a Haskell -> Java compiler/translator.
>
> -----------------------------------------
> Chris Angus
> Armature
> Enterprise House
> 1 Apex View
> Leeds LS11 9BH
> +44 113 2595253
> cangus@armature.com
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
From N.Perry@massey.ac.nz Fri Nov 24 17:05:53 2000
Date: Fri, 24 Nov 2000 18:05:53 +0100
From: Nigel Perry N.Perry@massey.ac.nz
Subject: Haskell --> Java was Re: (no subject)
Sorry folks the Haskell compiler at <http://www.mondrian-script.org>
doesn't produce Java, yet...
Actually the compiler *does* produce Java but it has been turned off
as there is no Haskell Prelude for Java yet, that bit is currently
only for .NET. We'll produce such a Java Prelude when we get the
time, no promises as to when at present - .NET is our first priority
at the moment. (For the technically minded the GHC Prelude is a mix
of Haskell and C, its getting the C stuff converted for JVM/.NET
which takes the time.)
However there is a Mondrian compiler on the site which does produce
Java, so maybe that will do you in the meantime.
At 8:48 am -0800 24/11/00, Erik Meijer wrote:
>Have a look at <http://www.mondrian-script.org>
>
>Erik
>
>----- Original Message -----
>From: "Chris Angus" <CAngus@Armature.com>
>To: <haskell-cafe@haskell.org>
>Sent: Friday, November 24, 2000 1:44 AM
>Subject: (no subject)
>
>
>> I was wondering if
> > Has anybody had access to a Haskell -> Java compiler/translator.
--
--
Dr Nigel Perry Email: N.Perry@massey.ac.nz
IIST Tel: +64 6 350 5799 2477
Massey University Fax: +64 6 350 2259
Palmerston North FTP/WWW: smis-asterix.massey.ac.nz
New Zealand
It makes as much sense to wear a "cycle" style helmet in a car as on a bike...
Choosing to wear one on a bike but not in a car is mere inconsistency.
Refusing to wear one in a car while insisting others do so on a bike
is pure hypocrisy.
Will the new Labour government repeal the National government's hypocrisy,
or will they discriminate against cyclists like their predecessors?
Politics and hypocrisy before safety - the NZ Helmet Law, NZ's Shame
From Doug_Ransom@pml.com Fri Nov 24 17:15:52 2000
Date: Fri, 24 Nov 2000 09:15:52 -0800
From: Doug Ransom Doug_Ransom@pml.com
Subject: Will Haskell be commercialized in the future?
Development tools for OO now are as good as smalltalk-80. I expect the
benefits of FP to be widely adopted in industry by 2020.
XSLT is kind of cool and taking off. Not exactly functional but there is no
destructive assignment.
A lot of the things Haskell excells at (IMO) inferior tools are being used
in place. For example, microsoft has build good XSLT translators and two
new compilers (C#, VB7) in the last couple years. Unfortunately, C#, not
Haskell, will probably be "the" language for the next decade. Fortunately,
C++ will not be the language of the next decade.
> -----Original Message-----
> From: Christian Lescher [mailto:christian@lescher.de]
> Sent: Thursday, November 23, 2000 10:14 PM
> To: haskell-cafe@haskell.org
> Subject: Will Haskell be commercialized in the future?
>
>
> In my opinion there are many more real world problems, that
> can be most
> efficiently solved with functional languages like Haskell, as
> (software)
> industry can think of at the moment; they only know their C/C++, Java,
> etc. but can't even think of the power of functional programming or at
> least don't take languages like Haskell for full. (Of corse, there are
> exceptions to the rule, too.)
>
> What do you think: Will Haskell (the related compilers/tools) be
> "commercialized" in the future?
>
> Christian
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
From christian@lescher.de Fri Nov 24 19:18:55 2000
Date: Fri, 24 Nov 2000 20:18:55 +0100
From: Christian Lescher christian@lescher.de
Subject: Will Haskell be commercialized in the future?
Hi Dave,
> This is probably stating the obvious but...
>
> I'm not sure that impure features are necessary if you are thinking of
> using Haskell as a component language -- a component language
> which is functional -- which will be used for parts of systems where it is
> believed to be appropriate. I'm working on an industrial project in a
> university setting and (once I get this damned PhD written up) will be
> working on an image processing/archiving system. I plan to use Haskell as
> a language to be called from the main C++ code for those algorithms which
> are easy to code in Haskell but not in C++. I doubt that I'll be using
> anything which isn't pure functional (e.g., monads) simply because I can't
> conceive of any problem where using them wouldn't mean the particular
> algorithm wouldn't be better written in C++. I've been criticised
> (possibly rightly :-) ) for saying that part of the reason why functional
> languages aren't more widely used is that people who understand C regard
> them as weird. (This isn't theory--this is what the people I work with say
> to me; I may just work with atypical people :-) ) It seems much more
> likely that they'll become popular if they can enroach from being
> component languages, rather than expecting a full beach-head of whole
> systems being implemented entirely in functional languages.
>
> Of course, I'm wrong about lots of things...
I agree with you concerning the usage of functional languages for industrial
purposes. Of course, C/C++, Java, etc. are more common than Haskell. However,
there are specific "industrial" problems that can be solved much easier when
using a functional language - and in the "real world" that's quite often the
case. However, very often industry people don't see this - because they just
don't know the 'declarative alternative'!
In my opinion, there is a great chance for functional languages in industry,
but currently they are just not popular enough.
I also agree with you that the way of combining the two worlds of functional
and imperative programming and always to use the most suitable language is the
best possible solution. The integration of Haskell with other languages is
already quite good (I think of the FFI and tools like HaskellDirect). This
should be further improved!!, f.e. a support of CORBA would be useful.
However, I think, that also the (existing) impure part of Haskell is needed -
i.e. for interfacing with the outside world.
Christian
From nkallen@uclink4.berkeley.edu Sat Nov 25 02:50:21 2000
Date: Fri, 24 Nov 2000 18:50:21 -0800
From: Nick Kallen nkallen@uclink4.berkeley.edu
Subject: Will Haskell be commercialized in the future?
> XSLT is kind of cool and taking off. Not exactly functional but
> there is no
> destructive assignment.
Having written many thousands of lines of XSLT, it's more than cool: it's
fantastic. That it has no destructive assignment is not at all a point in
its favor (though not one against it since it doesn't need it): XSLT is a
declarative language, it's computational model is based on the notion of
matching a node to a "template" and transforming said node... which makes it
perfect for its domain: transforming XML documents.
...XSLT is a domain specific language, and that is why it is so wonderful;
and also, I hope, an indication of what Programming Languages of the Future
([echo] future, future, ...) will look like... The main obstacle is bringing
DSL's out of esoterica (e.g., Robotics control) and into the mainstream
(e.g., GUI design). I'm optimistic: XML is being used for this purpose
(where 'computation' can be expressed declaratively, i.e., as a document),
for example, in ASP+. Other DSL's, e.g., WebL (Compaq's Web Language) have
had moderate success as well...
As for Ye Olde General Purpose Language, I hope that notion dies... Instead
to be replaced by the Programming in the Large language, which should have
extensive facilities for interacting with DSL's. I, of course, love Haskell
to death, but my vote has to go to the (emerging) ML2000, with its first
class modules, higher-order polymorphism, object types, strict evaluation,
and imperative references...
> A lot of the things Haskell excels at (IMO) inferior tools are being used
> in place. For example, Microsoft has build good XSLT translators and two
> new compilers (C#, VB7) in the last couple years. Unfortunately, C#, not
> Haskell, will probably be "the" language for the next decade.
> Fortunately,
> C++ will not be the language of the next decade.
Time will tell... I'm writing a lot of VB these days. I expect that it would
be a giant bitch to write XMLDOM manipulation stuff in Haskell since the DOM
is so imperative and OOey. (It's not that great in VB, but I'm sure as hell
glad I'm not writing it in Java, if for no other reason than the casting
would be a constant syntactic annoyance.)
--
Of course, I'm designing an XML generation language (aimed at a different
domain than XSLT and XDuce, but with vaguely similar intentions to
XMLambda). And I hope, of course, that this will be "the" language for the
next decade ;). (Notice how I think that the important language for the next
10 years will be an XML processing language)
From phoenix@esther.donga.ac.kr Sat Nov 25 11:54:13 2000
Date: Sat, 25 Nov 2000 20:54:13 +0900
From: Wooseok Yang phoenix@esther.donga.ac.kr
Subject: unsubscribe haskell-cafe
dW5zdWJzY3JpYmUgaGFza2VsbC1jYWZlDQo=
From russell@brainlink.com Mon Nov 27 07:49:37 2000
Date: Mon, 27 Nov 2000 02:49:37 -0500
From: Benjamin L. Russell russell@brainlink.com
Subject: Will Haskell be commercialized in the future?
On Fri, 24 Nov 2000 09:15:52 -0800
Doug Ransom <Doug_Ransom@pml.com> wrote:
>
> [stuff deleted]
>
> A lot of the things Haskell excells at (IMO) inferior
> tools are being used
> in place. For example, microsoft has build good XSLT
> translators and two
> new compilers (C#, VB7) in the last couple years.
> Unfortunately, C#, not
> Haskell, will probably be "the" language for the next
> decade. [stuff deleted]
Just out of curiosity: what makes you so sure about C#? C# has some potential big problems, too: in particular, the ability to declare a portion of the code "unsafe," which can encourage unsafe programming among entrenched C/C++ programmers.
I myself am in no big hurry to master C#. I'd rather use a set of domain-specific languages with interlinked code, rather than a single language that purports to be as general-purpose as C# does.
Benjamin L. Russell
russell@brainlink.com
"Furuike ya! Kawazu tobikomu mizu no oto." --Matsuo Basho
From fjh@cs.mu.oz.au Mon Nov 27 10:01:33 2000
Date: Mon, 27 Nov 2000 21:01:33 +1100
From: Fergus Henderson fjh@cs.mu.oz.au
Subject: Will Haskell be commercialized in the future?
On 27-Nov-2000, Benjamin L. Russell <russell@brainlink.com> wrote:
>
> Just out of curiosity: what makes you so sure about C#?
> C# has some potential big problems, too:
> in particular, the ability to declare a portion of the code "unsafe,"
> which can encourage unsafe programming among entrenched C/C++ programmers.
That is twaddle. "Entrenched" C/C++ programmers will doubtless write
bad code in any other language, just like Real Programmers and Fortran.
The ability to declare a portion of the code as `unsafe' is a feature.
It's like `unsafePerformIO' in Haskell! And also no worse than JNI in
Java. Do you think that Haskell would be better without `unsafePerformIO'?
Static checking and language support for safety are very good things;
I've been a supporter of those for a long long time. But to attack
C# because it offers *optional* escapes from the language-enforced
checking is obtuse.
This is not to say that C# doesn't have any serious problems. It does.
Number one is that it's a proprietry language controlled by Microsoft,
with no implementations on non-Windows platforms. Also the lack of
parametric polymorphism makes it much weaker than languages like
Sather and Eiffel which have been around for many years, not to
mention Pizza and Generic Java. This has lead C# to copy some of
Java's other flaws, such as the awful array type.
C# has plenty of flaws. Please criticize it for its real flaws,
not the imagined ones.
--
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 franka@cs.uu.nl Mon Nov 27 12:22:50 2000
Date: Mon, 27 Nov 2000 13:22:50 +0100
From: Frank Atanassow franka@cs.uu.nl
Subject: Will Haskell be commercialized in the future?
Fergus Henderson wrote (on 27-11-00 21:01 +1100):
> That is twaddle. "Entrenched" C/C++ programmers will doubtless write
> bad code in any other language, just like Real Programmers and Fortran.
> The ability to declare a portion of the code as `unsafe' is a feature.
> It's like `unsafePerformIO' in Haskell! And also no worse than JNI in
> Java. Do you think that Haskell would be better without `unsafePerformIO'?
Without remarking on C#, I just wanted to point out that unsafePerformIO is
not part of the Haskell language...
[BTW, John and Olaf: the new haskell.org front page looks great! The logo is a
big improvement...]
--
Frank Atanassow, Information & Computing Sciences, Utrecht University
Padualaan 14, PO Box 80.089, 3508 TB Utrecht, Netherlands
Tel +31 (030) 253-3261 Fax +31 (030) 251-379
From tweed@compsci.bristol.ac.uk Mon Nov 27 12:42:04 2000
Date: Mon, 27 Nov 2000 12:42:04 +0000 (GMT)
From: D. Tweed tweed@compsci.bristol.ac.uk
Subject: Will Haskell be commercialized in the future?
On Mon, 27 Nov 2000, Frank Atanassow wrote:
> > Java. Do you think that Haskell would be better without `unsafePerformIO'?
>
> Without remarking on C#, I just wanted to point out that unsafePerformIO is
> not part of the Haskell language...
Umm, I hope that everyone in the implementors camps feels unsafePerformIO
is a de facto (if not de jure) part of the haskell libraries. I use it an
awful lot, and ironically not to do `imperative' type things but rather to
deal with the case where files on disk, etc, are static over the entire
program lifetime, so that their value can unambiguously be taken to be
their contents, etc. In some ways it's aesthetically annoying that the
same function name is used for both situations where IO isn't strictly
ordered and you don't care if this means you get different file contents
depending on when the read happens to occur, and when a file is
essentially a `raw string CAF that happens to be on disk rather than
compiled in'.
___cheers,_dave________________________________________________________
www.cs.bris.ac.uk/~tweed/pi.htm|tweed's law: however many computers
email: tweed@cs.bris.ac.uk | you have, half your time is spent
work tel: (0117) 954-5250 | waiting for compilations to finish.
From Doug_Ransom@pml.com Mon Nov 27 17:09:05 2000
Date: Mon, 27 Nov 2000 09:09:05 -0800
From: Doug Ransom Doug_Ransom@pml.com
Subject: Will Haskell be commercialized in the future?
> -----Original Message-----
> From: Benjamin L. Russell [mailto:russell@brainlink.com]
> Sent: Sunday, November 26, 2000 11:50 PM
> To: Doug Ransom; haskell-cafe@haskell.org
> Subject: Re: Will Haskell be commercialized in the future?
>
>
> On Fri, 24 Nov 2000 09:15:52 -0800
> Doug Ransom <Doug_Ransom@pml.com> wrote:
> >
> > [stuff deleted]
> >
> > A lot of the things Haskell excells at (IMO) inferior
> > tools are being used
> > in place. For example, microsoft has build good XSLT
> > translators and two
> > new compilers (C#, VB7) in the last couple years.
> > Unfortunately, C#, not
> > Haskell, will probably be "the" language for the next
> > decade. [stuff deleted]
>
> Just out of curiosity: what makes you so sure about C#? C#
> has some potential big problems, too: in particular, the
> ability to declare a portion of the code "unsafe," which can
> encourage unsafe programming among entrenched C/C++ programmers.
Well, first of all, most C++ programmers really hate C++ and will be happy
to stay in safe mode and move to C#. There were cheers at the Microsoft
Profesional Developers Conference when MS announced garbage collection for
the COM replacement and the safety available with C# and managed C++ code.
C# is a huge improvement over C++.
Why would a C++ programmer want to go into unsafe mode? I guess when they
are writing interfaces to device drives, operating system calls, and legacy
interfaces.
>
> I myself am in no big hurry to master C#. I'd rather use a
> set of domain-specific languages with interlinked code,
> rather than a single language that purports to be as
> general-purpose as C# does.
Well, I would prefer to master Haskell and use that as my general purpose
language. Fat chance since the object models available in the microsoft
common language runtime are designed for impertive programming.
>
> Benjamin L. Russell
> russell@brainlink.com
> "Furuike ya! Kawazu tobikomu mizu no oto." --Matsuo Basho
>
From ahey@iee.org Mon Nov 27 15:56:38 2000
Date: Mon, 27 Nov 2000 15:56:38 +0000 (GMT)
From: Adrian Hey ahey@iee.org
Subject: Will Haskell be commercialized in the future?
On Mon 27 Nov, Fergus Henderson wrote:
> Do you think that Haskell would be better without `unsafePerformIO'?
Well, a sceptic like me is bound to wonder why such a non-function is
provided in a purely functional language. What really worries me is
that the damage isn't localised. If you allow such things you can never be
sure that any function really is a function, without careful scrutiny of all
the code it's dependent on.
> This has lead C# to copy some of
> Java's other flaws, such as the awful array type.
What is wrong with Java and C# arrays? (I have never used either).
Regards
--
Adrian Hey
From mg169780@students.mimuw.edu.pl Mon Nov 27 19:53:05 2000
Date: Mon, 27 Nov 2000 20:53:05 +0100 (CET)
From: Michal Gajda mg169780@students.mimuw.edu.pl
Subject: Will Haskell be commercialized in the future?
On Mon, 27 Nov 2000, Doug Ransom wrote:
> [stuff deleted]
> Well, I would prefer to master Haskell and use that as my general purpose
> language. Fat chance since the object models available in the microsoft
> common language runtime are designed for impertive programming.
I often use Haskell in imperative style(for example writting a toy
interpreter for subset of Tcl language). I noticed that(at
least for student projects) it's more convenient than, say C, in some
respects. I can often abstract out of the irrelevant details, thanks to
HOF and careful use of monads/monad transformers. And the need to
explicitly name imperative state or behaviour may clean up the code and
improve understanding of the problem.
Am I the only one?
Greetings
Michal Gajda
korek@charybda.icm.edu.pl
PS I think that inefficiency of lazy evaluation may be the more important
flaw of Haskell. I know that memory profiler may be used, but it's not so
easy to understand, what it tells. At least for someone else than
compiler-writer or at least hardcore computer-scientist.
From trd@cs.mu.OZ.AU Tue Nov 28 03:52:25 2000
Date: Tue, 28 Nov 2000 14:52:25 +1100
From: Tyson Dowd trd@cs.mu.OZ.AU
Subject: Will Haskell be commercialized in the future?
On 27-Nov-2000, Adrian Hey <ahey@iee.org> wrote:
> On Mon 27 Nov, Fergus Henderson wrote:
> > Do you think that Haskell would be better without `unsafePerformIO'?
>
> Well, a sceptic like me is bound to wonder why such a non-function is
> provided in a purely functional language. What really worries me is
> that the damage isn't localised. If you allow such things you can never be
> sure that any function really is a function, without careful scrutiny of all
> the code it's dependent on.
This is an issue, but it arises in any "pure" language with a foreign
language interface.
I think what would be nice to have is a notion of "trust". Only "trusted"
people can use unsafePerformIO -- of course as the application developer
you can decide who you trust and who you don't trust. It would be
possible to use public key crypto to handle trust (if you were worried
enough to bother). Then you only have to scrutinze uses of
unsafePerformIO that you don't trust.
We have been thinking of adding some support for "safety", "purity" and
"trust" to Mercury for a while, but haven't quite hammered out exactly what
these concepts mean and how they interact (or even whether it is all
worthwhile). The general idea is that you could trust :- promise pure
declarations (which are similar to unsafePerformIO). There are other :-
promise declarations too. To use a :- promise declaration you would
have to trust the author.
--
Tyson Dowd #
# Surreal humour isn't everyone's cup of fur.
trd@cs.mu.oz.au #
http://www.cs.mu.oz.au/~trd #
From nkallen@uclink4.berkeley.edu Tue Nov 28 03:52:44 2000
Date: Mon, 27 Nov 2000 19:52:44 -0800
From: Nick Kallen nkallen@uclink4.berkeley.edu
Subject: Will Haskell be commercialized in the future?
> To use a :- promise declaration you would
> have to trust the author.
It seems like you'd also have to trust the author to write bug-free code
too...
From trd@cs.mu.OZ.AU Tue Nov 28 04:14:09 2000
Date: Tue, 28 Nov 2000 15:14:09 +1100
From: Tyson Dowd trd@cs.mu.OZ.AU
Subject: Will Haskell be commercialized in the future?
On 27-Nov-2000, Nick Kallen <nkallen@uclink4.berkeley.edu> wrote:
> > To use a :- promise declaration you would
> > have to trust the author.
>
> It seems like you'd also have to trust the author to write bug-free code
> too...
I think this is the point. You have to trust them to write pure
interfaces. Generally this will involve them writing bug-free code.
This is the level of trust you usually give to compiler and library
writers. But if people start writing foreign language interface stuff
all over the place, you might want to start exerting some control over
using it unless you are pretty sure it's bug-free (an deliberately
written to be pure).
--
Tyson Dowd #
# Surreal humour isn't everyone's cup of fur.
trd@cs.mu.oz.au #
http://www.cs.mu.oz.au/~trd #
From ashley@semantic.org Tue Nov 28 04:26:50 2000
Date: Mon, 27 Nov 2000 20:26:50 -0800
From: Ashley Yakeley ashley@semantic.org
Subject: Will Haskell be commercialized in the future?
At 2000-11-27 19:52, Tyson Dowd wrote:
>On 27-Nov-2000, Adrian Hey <ahey@iee.org> wrote:
>> On Mon 27 Nov, Fergus Henderson wrote:
>> > Do you think that Haskell would be better without `unsafePerformIO'?
>>
>> Well, a sceptic like me is bound to wonder why such a non-function is
>> provided in a purely functional language. What really worries me is
>> that the damage isn't localised. If you allow such things you can never be
>> sure that any function really is a function, without careful scrutiny of all
>> the code it's dependent on.
>
>This is an issue, but it arises in any "pure" language with a foreign
>language interface.
Not necessarily, the functions just need to be typed correctly. In the
case of a non-safe or imperative function, that's going to be of the
form "a -> IO b" (or "IO a -> IO b" if you prefer the more powerful arrow
model).
No safety needs to be sacrificed.
--
Ashley Yakeley, Seattle WA
From trd@cs.mu.OZ.AU Tue Nov 28 04:54:32 2000
Date: Tue, 28 Nov 2000 15:54:32 +1100
From: Tyson Dowd trd@cs.mu.OZ.AU
Subject: Will Haskell be commercialized in the future?
On 27-Nov-2000, Ashley Yakeley <ashley@semantic.org> wrote:
> >This is an issue, but it arises in any "pure" language with a foreign
> >language interface.
>
> Not necessarily, the functions just need to be typed correctly. In the
> case of a non-safe or imperative function, that's going to be of the
> form "a -> IO b" (or "IO a -> IO b" if you prefer the more powerful arrow
> model).
>
> No safety needs to be sacrificed.
I would agree that no purity (referential transparency) needs to be
sacrificed. The IO monad preserves referential transparency pretty
well.
Safety is another issue. If by safety we mean "memory safe" (cannot
use invalid pointers) then how can the IO monad possibly help?
We can dereference an invalid pointer inside or outside the IO monad --
it doesn't matter, the program still crashes. Surely then we cannot call a
foreign language interface "safe" just because it gives each foreign
function IO types.
Typically both impure (non-referentially transparent) and plain old
unsafe code can be made into pure & safe code by a bit of sequencing
(helped by a monad) and an nice pure wrapper interface (and sometimes
even unsafePerformIO to hide the now unnecessary monads).
But the issue then arises that if you use the IO monad for the sequencing
of raw, potentially unsafe code, how are developers supposed to be able
to tell it apart from safe IO code?
--
Tyson Dowd #
# Surreal humour isn't everyone's cup of fur.
trd@cs.mu.oz.au #
http://www.cs.mu.oz.au/~trd #
From chak@cse.unsw.edu.au Wed Nov 29 05:22:48 2000
Date: Wed, 29 Nov 2000 16:22:48 +1100
From: Manuel M. T. Chakravarty chak@cse.unsw.edu.au
Subject: Will Haskell be commercialized in the future?
Adrian Hey <ahey@iee.org> wrote,
> On Mon 27 Nov, Fergus Henderson wrote:
> > Do you think that Haskell would be better without `unsafePerformIO'?
>
> Well, a sceptic like me is bound to wonder why such a non-function is
> provided in a purely functional language. What really worries me is
> that the damage isn't localised. If you allow such things you can never be
> sure that any function really is a function, without careful scrutiny of all
> the code it's dependent on.
Consider `unsafePerformIO' to be a feature to implement
system libraries and the like. It makes it easier to
implement libraries in Haskell which otherwise partially or
completely would have to be written in another language and,
then, be called from Haskell.
Like with any system library if the system programmer messes
it up (eg, exports a function that isn't really a function),
you are in for some trouble. This is not very different to
you trusting the interpreter or compiler implementer that
what they execute is actually what you wrote.
Cheers,
Manuel
From kurt.wilkin@actfs.co.nz Thu Nov 30 04:11:45 2000
Date: Thu, 30 Nov 2000 17:11:45 +1300
From: Kurt kurt.wilkin@actfs.co.nz
Subject: Type classes diagram?
Has anyone seen a downloadable diagram of the relationships
between all of the Haskell type classes? If so, could you post a
link?
TIA,
Kurt.
From mg169780@students.mimuw.edu.pl Thu Nov 30 04:36:16 2000
Date: Thu, 30 Nov 2000 05:36:16 +0100 (CET)
From: Michal Gajda mg169780@students.mimuw.edu.pl
Subject: Type classes diagram?
On Thu, 30 Nov 2000, Kurt wrote:
> Has anyone seen a downloadable diagram of the relationships
> between all of the Haskell type classes? If so, could you post a
> link?
I think that winhugs generates something like this.
(At least elder versions did it)
Greetings
Michal Gajda
korek@charybda.icm.edu.pl
From khchoi@ruby.kaist.ac.kr Thu Nov 30 04:35:38 2000
Date: Thu, 30 Nov 2000 13:35:38 +0900 (KST)
From: Kwanghoon Choi khchoi@ruby.kaist.ac.kr
Subject: Type classes diagram?
Hi,
Do you mean this diagram in the Haskell98 report?
http://www.haskell.org/onlinereport/basic.html
(6.3 Standard Haskell Classes)
Kwanghoon
On Thu, 30 Nov 2000, Kurt wrote:
> Has anyone seen a downloadable diagram of the relationships
> between all of the Haskell type classes? If so, could you post a
> link?
>
> TIA,
> Kurt.
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
From kurt.wilkin@actfs.co.nz Thu Nov 30 04:54:16 2000
Date: Thu, 30 Nov 2000 17:54:16 +1300
From: Kurt kurt.wilkin@actfs.co.nz
Subject: Type classes diagram?
Thats great, thanks.
PS. Haskell will be commercialised as soon as I can afford to buy an
ad during Superbowl ;-)
(but don't hold your breath.)
Kwanghoon Choi wrote:
>
> Hi,
>
> Do you mean this diagram in the Haskell98 report?
>
> http://www.haskell.org/onlinereport/basic.html
> (6.3 Standard Haskell Classes)
>
> Kwanghoon
>
> On Thu, 30 Nov 2000, Kurt wrote:
>
> > Has anyone
[...]
> > Kurt.
> >
From wohlstad@cs.ucdavis.edu Mon Nov 13 04:12:38 2000
From: wohlstad@cs.ucdavis.edu (Eric Allen Wohlstadter)
Date: Sun, 12 Nov 2000 20:12:38 -0800 (PST)
Subject: List types
Message-ID:
I would like to be able to make a list that contains functions which take
arguments of a certain type 'a'. However I don't know how many 'a'
arguments there are. For example I'd like to be able to make a list of
f,g, and h.
f::a->b
g::a->a->b
h::a->a->a->b
[f,g,h]
Now I could make a function l that takes a list of 'a'.
l::[a]->b
However, I want to be able to curry the a's one at a time.
My solution so far is declare a type Element like this:
data Element a b c d = One a | Two b | Three c | Four d
and then I can make my list like this,
[One f,Two g,Three h]
This gets very ugly. Do you guys have any ideas?
Eric Wohlstadter
UCDavis Software Engineering
From Tom.Pledger@peace.com Mon Nov 13 05:15:39 2000
From: Tom.Pledger@peace.com (Tom Pledger)
Date: Mon, 13 Nov 2000 18:15:39 +1300
Subject: List types
In-Reply-To:
References:
Message-ID: <14863.30971.420810.613511@waytogo.peace.co.nz>
Eric Allen Wohlstadter writes:
> I would like to be able to make a list that contains functions which take
> arguments of a certain type 'a'. However I don't know how many 'a'
> arguments there are. For example I'd like to be able to make a list of
> f,g, and h.
>
> f::a->b
> g::a->a->b
> h::a->a->a->b
> [f,g,h]
>
> Now I could make a function l that takes a list of 'a'.
> l::[a]->b
> However, I want to be able to curry the a's one at a time.
>
> My solution so far is declare a type Element like this:
> data Element a b c d = One a | Two b | Three c | Four d
> and then I can make my list like this,
> [One f,Two g,Three h]
>
> This gets very ugly. Do you guys have any ideas?
>
> Eric Wohlstadter
> UCDavis Software Engineering
Hi.
It looks a lot like a folding task. It would be nice if you could
formulate it the l::[a]->b way, and feed in the arguments in a lazy
list.
Failing that, how about a product of lists, instead of a list of sums?
data Bunch a b =
Bunch {nones :: [b],
ones :: [a->b],
twos :: [a->a->b],
threes :: [a->a->a->b],
fours :: [a->a->a->a->b]}
emptyBunch = Bunch [] [] [] [] []
applyBunch b arg =
Bunch (map ($arg) (ones b))
(map ($arg) (twos b))
(map ($arg) (threes b))
(map ($arg) (fours b))
[]
f x1 = ()
g x1 x2 = ()
h x1 x2 x3 = ()
fgh = emptyBunch {ones=[f], twos=[g], threes=[h]}
test = take 5 (map nones (iterate (\b -> applyBunch b "foo") fgh))
Regards,
Tom
From p.turner@computer.org Mon Nov 13 09:13:07 2000
From: p.turner@computer.org (Scott Turner)
Date: Mon, 13 Nov 2000 04:13:07 -0500
Subject: List types
In-Reply-To:
Message-ID: <3.0.5.32.20001113041307.0101d460@mail.billygoat.org>
You could make a type like this:
data C a b = Raw b | Cooked ( a -> C a b )
ap :: C a b -> a -> C a b
ap (Cooked f) v = f v
cook :: C a (a -> t) -> C a t
cook (Cooked f) = Cooked g
where
g a = cook (f a)
cook (Raw f) = Cooked g
where
g a = Raw (f a)
foo x y z = x <= y && y <= z
f3 = cook $ cook $ cook $ Raw foo
test = f3 `ap` 1 `ap` 2 `ap` 3
Though you could do something similar with a list-based approach.
-- Scott
At 20:12 2000-11-12 -0800, you wrote:
>I would like to be able to make a list that contains functions which take
>arguments of a certain type 'a'. However I don't know how many 'a'
>arguments there are. For example I'd like to be able to make a list of
>f,g, and h.
>
>f::a->b
>g::a->a->b
>h::a->a->a->b
>[f,g,h]
>
>I want to be able to curry the a's one at a time.
--
Scott Turner
p.turner@computer.org http://www.ma.ultranet.com/~pkturner
From john@foo.net Fri Nov 17 00:38:08 2000
From: john@foo.net (John Meacham)
Date: Thu, 16 Nov 2000 16:38:08 -0800
Subject: haskell editor..
Message-ID: <20001116163808.A7272@quetzal.ugcs.caltech.edu>
so while randomly surfing the realm of haskell space I came across the
Alfa Proof assistant. (http://www.cs.chalmers.se/~hallgren/Alfa/) All I
can say is WOW, this thing is fun to play with, (and to think I have
been doing my proofs with pencil and paper all these years).
The interactive editor in particular I found quite enjoyable to use, I
was wondering if someone has ever made or considered making a similar
editor for haskell programs themselves? On first thought it seems that
such a thing should not be too difficult as the type system of haskell
is based on the same theories and haskell programs are similar to
declarative proofs. It seems like an editor of that sort coupled with a
class browser would be a powerful authoring tool.. (and this coming from
a vi user :) )
The other thing that Alfa made me want to try out was programming with
Fudgets. however as far as I can tell Fudgets has bit-rotted away... at
least I have been unable to find a version which compiles with my
prefered setup (ghc 4.08.1)... I was wondering if there is anyone
working on bringing Fudgets up to date? There must be some setup that
can compile it as Alfa still appears to be actively developed, From a
lookover of the sources probably all that would need to be done is to
replace the Xlib layer with one based on FFI so as to be portable to all
the modern platforms and bring the code up to haskell98 compliance...
perhaps somebody has already done this but it is not well publicised or
is there some other reason Fudgets has not been developed recently like
the existence of an accepted better GUI API?
just some random thoughts....
John
--
--------------------------------------------------------------
John Meacham http://www.ugcs.caltech.edu/~john/
California Institute of Technology, Alum. john@foo.net
--------------------------------------------------------------
From xiamin@ghostpriest.rakis.net Fri Nov 17 01:41:00 2000
From: xiamin@ghostpriest.rakis.net (Simon Raahauge DeSantis)
Date: Thu, 16 Nov 2000 20:41:00 -0500
Subject: haskell editor..
In-Reply-To: <20001116163808.A7272@quetzal.ugcs.caltech.edu>; from John Meacham on Thu, Nov 16, 2000 at 04:38:08PM -0800
References: <20001116163808.A7272@quetzal.ugcs.caltech.edu>
Message-ID: <20001116204100.A24143@ghostpriest.rakis.net>
[Stuff about Alfa and Fudgets]
I had Fudgets working just fine on a SunOS 4.1.4 box two years ago with HBC.
I'm by no means a programmer but from playing around with Fudgets I was
incredibly impressed. I've never seen anything quite as cool.
--
-Simon Raahauge DeSantis
From christian@lescher.de Fri Nov 24 06:13:31 2000
From: christian@lescher.de (Christian Lescher)
Date: Fri, 24 Nov 2000 07:13:31 +0100
Subject: Will Haskell be commercialized in the future?
Message-ID: <3A1E070B.C6AD0CE7@lescher.de>
In my opinion there are many more real world problems, that can be most
efficiently solved with functional languages like Haskell, as (software)
industry can think of at the moment; they only know their C/C++, Java,
etc. but can't even think of the power of functional programming or at
least don't take languages like Haskell for full. (Of corse, there are
exceptions to the rule, too.)
What do you think: Will Haskell (the related compilers/tools) be
"commercialized" in the future?
Christian
From chak@cse.unsw.edu.au Fri Nov 24 07:59:56 2000
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Fri, 24 Nov 2000 18:59:56 +1100
Subject: FP & Python
Message-ID: <20001124185956K.chak@cse.unsw.edu.au>
The following article featuring an interview with the
authors of alternative Python implementations might be
interesting to some of you, as it features the use of FP
technology in the context of a popular language:
http://www-4.ibm.com/software/developer/library/l-pyth7.html?open&l=666,t=gr,p=Interviews
Vyper might actually be of interest for Phil's page about
real-world applications of FP.
Cheers,
Manuel
From CAngus@Armature.com Fri Nov 24 09:44:53 2000
From: CAngus@Armature.com (Chris Angus)
Date: Fri, 24 Nov 2000 09:44:53 -0000
Subject: (no subject)
Message-ID: <753866CAB183D211883F0090271F46C204AB8985@COW>
I was wondering if
Has anybody had access to a Haskell -> Java compiler/translator.
-----------------------------------------
Chris Angus
Armature
Enterprise House
1 Apex View
Leeds LS11 9BH
+44 113 2595253
cangus@armature.com
From haskell-cafe@haskell.org"
Message-ID: <8766lditcw.fsf@frown.here>
Christian Lescher writes:
> In my opinion there are many more real world problems, that can be most
> efficiently solved with functional languages like Haskell, as (software)
> industry can think of at the moment; they only know their C/C++, Java,
> etc. but can't even think of the power of functional programming or at
> least don't take languages like Haskell for full. (Of corse, there are
> exceptions to the rule, too.)
>
> What do you think: Will Haskell (the related compilers/tools) be
> "commercialized" in the future?
Let me counter with another question. Do you think people will pay for
it and enough to keep the vendors going?
Regards
Friedrich
From jstok@bluedog.apana.org.au Fri Nov 24 10:39:56 2000
From: jstok@bluedog.apana.org.au (Jason Stokes)
Date: Fri, 24 Nov 2000 21:39:56 +1100
Subject: Will Haskell be commercialized in the future?
References: <3A1E070B.C6AD0CE7@lescher.de>
Message-ID: <3A1E457C.B2387BD0@bluedog.apana.org.au>
Christian Lescher wrote:
>
> In my opinion there are many more real world problems, that can be most
> efficiently solved with functional languages like Haskell, as (software)
> industry can think of at the moment; they only know their C/C++, Java,
> etc. but can't even think of the power of functional programming or at
> least don't take languages like Haskell for full. (Of corse, there are
> exceptions to the rule, too.)
>
> What do you think: Will Haskell (the related compilers/tools) be
> "commercialized" in the future?
I very much doubt that a "pure" Haskell (ie, a pure functional language)
is a marketable proposition, but certainly "impure" functional languages
or languages with heavy functional aspects (ML, Lisp, Erlang etc.) which
retain imperative elements have the potential to break through and start
a resurgence of functional techniques in the commercial world. Before
that happens people must become disillusioned with Java, C, C++ and
other mainstays of the commercial developer, of course.
From tweed@compsci.bristol.ac.uk Fri Nov 24 11:01:42 2000
From: tweed@compsci.bristol.ac.uk (D. Tweed)
Date: Fri, 24 Nov 2000 11:01:42 +0000 (GMT)
Subject: Will Haskell be commercialized in the future?
In-Reply-To: <3A1E457C.B2387BD0@bluedog.apana.org.au>
Message-ID:
On Fri, 24 Nov 2000, Jason Stokes wrote:
> I very much doubt that a "pure" Haskell (ie, a pure functional language)
> is a marketable proposition, but certainly "impure" functional languages
> or languages with heavy functional aspects (ML, Lisp, Erlang etc.) which
> retain imperative elements have the potential to break through and start
> a resurgence of functional techniques in the commercial world. Before
> that happens people must become disillusioned with Java, C, C++ and
> other mainstays of the commercial developer, of course.
This is probably stating the obvious but...
I'm not sure that impure features are necessary if you are thinking of
using Haskell as a component language -- a component language
which is functional -- which will be used for parts of systems where it is
believed to be appropriate. I'm working on an industrial project in a
university setting and (once I get this damned PhD written up) will be
working on an image processing/archiving system. I plan to use Haskell as
a language to be called from the main C++ code for those algorithms which
are easy to code in Haskell but not in C++. I doubt that I'll be using
anything which isn't pure functional (e.g., monads) simply because I can't
conceive of any problem where using them wouldn't mean the particular
algorithm wouldn't be better written in C++. I've been criticised
(possibly rightly :-) ) for saying that part of the reason why functional
languages aren't more widely used is that people who understand C regard
them as weird. (This isn't theory--this is what the people I work with say
to me; I may just work with atypical people :-) ) It seems much more
likely that they'll become popular if they can enroach from being
component languages, rather than expecting a full beach-head of whole
systems being implemented entirely in functional languages.
Of course, I'm wrong about lots of things...
___cheers,_dave________________________________________________________
www.cs.bris.ac.uk/~tweed/pi.htm|tweed's law: however many computers
email: tweed@cs.bris.ac.uk | you have, half your time is spent
work tel: (0117) 954-5250 | waiting for compilations to finish.
From Erik Meijer" Java was Re: (no subject)
References: <753866CAB183D211883F0090271F46C204AB8985@COW>
Message-ID: <001801c05636$6adc5060$411d0041@c486306a>
Have a look at
Erik
----- Original Message -----
From: "Chris Angus"
To:
Sent: Friday, November 24, 2000 1:44 AM
Subject: (no subject)
> I was wondering if
> Has anybody had access to a Haskell -> Java compiler/translator.
>
> -----------------------------------------
> Chris Angus
> Armature
> Enterprise House
> 1 Apex View
> Leeds LS11 9BH
> +44 113 2595253
> cangus@armature.com
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
From N.Perry@massey.ac.nz Fri Nov 24 17:05:53 2000
From: N.Perry@massey.ac.nz (Nigel Perry)
Date: Fri, 24 Nov 2000 18:05:53 +0100
Subject: Haskell --> Java was Re: (no subject)
In-Reply-To: <001801c05636$6adc5060$411d0041@c486306a>
References: <753866CAB183D211883F0090271F46C204AB8985@COW>
<001801c05636$6adc5060$411d0041@c486306a>
Message-ID:
Sorry folks the Haskell compiler at
doesn't produce Java, yet...
Actually the compiler *does* produce Java but it has been turned off
as there is no Haskell Prelude for Java yet, that bit is currently
only for .NET. We'll produce such a Java Prelude when we get the
time, no promises as to when at present - .NET is our first priority
at the moment. (For the technically minded the GHC Prelude is a mix
of Haskell and C, its getting the C stuff converted for JVM/.NET
which takes the time.)
However there is a Mondrian compiler on the site which does produce
Java, so maybe that will do you in the meantime.
At 8:48 am -0800 24/11/00, Erik Meijer wrote:
>Have a look at
>
>Erik
>
>----- Original Message -----
>From: "Chris Angus"
>To:
>Sent: Friday, November 24, 2000 1:44 AM
>Subject: (no subject)
>
>
>> I was wondering if
> > Has anybody had access to a Haskell -> Java compiler/translator.
--
--
Dr Nigel Perry Email: N.Perry@massey.ac.nz
IIST Tel: +64 6 350 5799 2477
Massey University Fax: +64 6 350 2259
Palmerston North FTP/WWW: smis-asterix.massey.ac.nz
New Zealand
It makes as much sense to wear a "cycle" style helmet in a car as on a bike...
Choosing to wear one on a bike but not in a car is mere inconsistency.
Refusing to wear one in a car while insisting others do so on a bike
is pure hypocrisy.
Will the new Labour government repeal the National government's hypocrisy,
or will they discriminate against cyclists like their predecessors?
Politics and hypocrisy before safety - the NZ Helmet Law, NZ's Shame
From Doug_Ransom@pml.com Fri Nov 24 17:15:52 2000
From: Doug_Ransom@pml.com (Doug Ransom)
Date: Fri, 24 Nov 2000 09:15:52 -0800
Subject: Will Haskell be commercialized in the future?
Message-ID: <3233BEE02CB3D4118DBA00A0C99869401D60B1@hermes.pml.com>
Development tools for OO now are as good as smalltalk-80. I expect the
benefits of FP to be widely adopted in industry by 2020.
XSLT is kind of cool and taking off. Not exactly functional but there is no
destructive assignment.
A lot of the things Haskell excells at (IMO) inferior tools are being used
in place. For example, microsoft has build good XSLT translators and two
new compilers (C#, VB7) in the last couple years. Unfortunately, C#, not
Haskell, will probably be "the" language for the next decade. Fortunately,
C++ will not be the language of the next decade.
> -----Original Message-----
> From: Christian Lescher [mailto:christian@lescher.de]
> Sent: Thursday, November 23, 2000 10:14 PM
> To: haskell-cafe@haskell.org
> Subject: Will Haskell be commercialized in the future?
>
>
> In my opinion there are many more real world problems, that
> can be most
> efficiently solved with functional languages like Haskell, as
> (software)
> industry can think of at the moment; they only know their C/C++, Java,
> etc. but can't even think of the power of functional programming or at
> least don't take languages like Haskell for full. (Of corse, there are
> exceptions to the rule, too.)
>
> What do you think: Will Haskell (the related compilers/tools) be
> "commercialized" in the future?
>
> Christian
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
From christian@lescher.de Fri Nov 24 19:18:55 2000
From: christian@lescher.de (Christian Lescher)
Date: Fri, 24 Nov 2000 20:18:55 +0100
Subject: Will Haskell be commercialized in the future?
References:
Message-ID: <3A1EBF1E.69F6F57@lescher.de>
Hi Dave,
> This is probably stating the obvious but...
>
> I'm not sure that impure features are necessary if you are thinking of
> using Haskell as a component language -- a component language
> which is functional -- which will be used for parts of systems where it is
> believed to be appropriate. I'm working on an industrial project in a
> university setting and (once I get this damned PhD written up) will be
> working on an image processing/archiving system. I plan to use Haskell as
> a language to be called from the main C++ code for those algorithms which
> are easy to code in Haskell but not in C++. I doubt that I'll be using
> anything which isn't pure functional (e.g., monads) simply because I can't
> conceive of any problem where using them wouldn't mean the particular
> algorithm wouldn't be better written in C++. I've been criticised
> (possibly rightly :-) ) for saying that part of the reason why functional
> languages aren't more widely used is that people who understand C regard
> them as weird. (This isn't theory--this is what the people I work with say
> to me; I may just work with atypical people :-) ) It seems much more
> likely that they'll become popular if they can enroach from being
> component languages, rather than expecting a full beach-head of whole
> systems being implemented entirely in functional languages.
>
> Of course, I'm wrong about lots of things...
I agree with you concerning the usage of functional languages for industrial
purposes. Of course, C/C++, Java, etc. are more common than Haskell. However,
there are specific "industrial" problems that can be solved much easier when
using a functional language - and in the "real world" that's quite often the
case. However, very often industry people don't see this - because they just
don't know the 'declarative alternative'!
In my opinion, there is a great chance for functional languages in industry,
but currently they are just not popular enough.
I also agree with you that the way of combining the two worlds of functional
and imperative programming and always to use the most suitable language is the
best possible solution. The integration of Haskell with other languages is
already quite good (I think of the FFI and tools like HaskellDirect). This
should be further improved!!, f.e. a support of CORBA would be useful.
However, I think, that also the (existing) impure part of Haskell is needed -
i.e. for interfacing with the outside world.
Christian
From nkallen@uclink4.berkeley.edu Sat Nov 25 02:50:21 2000
From: nkallen@uclink4.berkeley.edu (Nick Kallen)
Date: Fri, 24 Nov 2000 18:50:21 -0800
Subject: Will Haskell be commercialized in the future?
In-Reply-To: <3233BEE02CB3D4118DBA00A0C99869401D60B1@hermes.pml.com>
Message-ID: <000d01c0568a$73d21fc0$0b28c83f@pacbell.net>
> XSLT is kind of cool and taking off. Not exactly functional but
> there is no
> destructive assignment.
Having written many thousands of lines of XSLT, it's more than cool: it's
fantastic. That it has no destructive assignment is not at all a point in
its favor (though not one against it since it doesn't need it): XSLT is a
declarative language, it's computational model is based on the notion of
matching a node to a "template" and transforming said node... which makes it
perfect for its domain: transforming XML documents.
...XSLT is a domain specific language, and that is why it is so wonderful;
and also, I hope, an indication of what Programming Languages of the Future
([echo] future, future, ...) will look like... The main obstacle is bringing
DSL's out of esoterica (e.g., Robotics control) and into the mainstream
(e.g., GUI design). I'm optimistic: XML is being used for this purpose
(where 'computation' can be expressed declaratively, i.e., as a document),
for example, in ASP+. Other DSL's, e.g., WebL (Compaq's Web Language) have
had moderate success as well...
As for Ye Olde General Purpose Language, I hope that notion dies... Instead
to be replaced by the Programming in the Large language, which should have
extensive facilities for interacting with DSL's. I, of course, love Haskell
to death, but my vote has to go to the (emerging) ML2000, with its first
class modules, higher-order polymorphism, object types, strict evaluation,
and imperative references...
> A lot of the things Haskell excels at (IMO) inferior tools are being used
> in place. For example, Microsoft has build good XSLT translators and two
> new compilers (C#, VB7) in the last couple years. Unfortunately, C#, not
> Haskell, will probably be "the" language for the next decade.
> Fortunately,
> C++ will not be the language of the next decade.
Time will tell... I'm writing a lot of VB these days. I expect that it would
be a giant bitch to write XMLDOM manipulation stuff in Haskell since the DOM
is so imperative and OOey. (It's not that great in VB, but I'm sure as hell
glad I'm not writing it in Java, if for no other reason than the casting
would be a constant syntactic annoyance.)
--
Of course, I'm designing an XML generation language (aimed at a different
domain than XSLT and XDuce, but with vaguely similar intentions to
XMLambda). And I hope, of course, that this will be "the" language for the
next decade ;). (Notice how I think that the important language for the next
10 years will be an XML processing language)
From phoenix@esther.donga.ac.kr Sat Nov 25 11:54:13 2000
From: phoenix@esther.donga.ac.kr (Wooseok Yang)
Date: Sat, 25 Nov 2000 20:54:13 +0900
Subject: unsubscribe haskell-cafe
Message-ID: <002f01c056d6$6ea04080$a42573a8@phoenix>
dW5zdWJzY3JpYmUgaGFza2VsbC1jYWZlDQo=
From russell@brainlink.com Mon Nov 27 07:49:37 2000
From: russell@brainlink.com (Benjamin L. Russell)
Date: Mon, 27 Nov 2000 02:49:37 -0500
Subject: Will Haskell be commercialized in the future?
In-Reply-To: <3233BEE02CB3D4118DBA00A0C99869401D60B1@hermes.pml.com>
Message-ID:
On Fri, 24 Nov 2000 09:15:52 -0800
Doug Ransom wrote:
>
> [stuff deleted]
>
> A lot of the things Haskell excells at (IMO) inferior
> tools are being used
> in place. For example, microsoft has build good XSLT
> translators and two
> new compilers (C#, VB7) in the last couple years.
> Unfortunately, C#, not
> Haskell, will probably be "the" language for the next
> decade. [stuff deleted]
Just out of curiosity: what makes you so sure about C#? C# has some potential big problems, too: in particular, the ability to declare a portion of the code "unsafe," which can encourage unsafe programming among entrenched C/C++ programmers.
I myself am in no big hurry to master C#. I'd rather use a set of domain-specific languages with interlinked code, rather than a single language that purports to be as general-purpose as C# does.
Benjamin L. Russell
russell@brainlink.com
"Furuike ya! Kawazu tobikomu mizu no oto." --Matsuo Basho
From fjh@cs.mu.oz.au Mon Nov 27 10:01:33 2000
From: fjh@cs.mu.oz.au (Fergus Henderson)
Date: Mon, 27 Nov 2000 21:01:33 +1100
Subject: Will Haskell be commercialized in the future?
In-Reply-To:
References: <3233BEE02CB3D4118DBA00A0C99869401D60B1@hermes.pml.com>
Message-ID: <20001127210132.A21702@hg.cs.mu.oz.au>
On 27-Nov-2000, Benjamin L. Russell wrote:
>
> Just out of curiosity: what makes you so sure about C#?
> C# has some potential big problems, too:
> in particular, the ability to declare a portion of the code "unsafe,"
> which can encourage unsafe programming among entrenched C/C++ programmers.
That is twaddle. "Entrenched" C/C++ programmers will doubtless write
bad code in any other language, just like Real Programmers and Fortran.
The ability to declare a portion of the code as `unsafe' is a feature.
It's like `unsafePerformIO' in Haskell! And also no worse than JNI in
Java. Do you think that Haskell would be better without `unsafePerformIO'?
Static checking and language support for safety are very good things;
I've been a supporter of those for a long long time. But to attack
C# because it offers *optional* escapes from the language-enforced
checking is obtuse.
This is not to say that C# doesn't have any serious problems. It does.
Number one is that it's a proprietry language controlled by Microsoft,
with no implementations on non-Windows platforms. Also the lack of
parametric polymorphism makes it much weaker than languages like
Sather and Eiffel which have been around for many years, not to
mention Pizza and Generic Java. This has lead C# to copy some of
Java's other flaws, such as the awful array type.
C# has plenty of flaws. Please criticize it for its real flaws,
not the imagined ones.
--
Fergus Henderson | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: | -- the last words of T. S. Garp.
From franka@cs.uu.nl Mon Nov 27 12:22:50 2000
From: franka@cs.uu.nl (Frank Atanassow)
Date: Mon, 27 Nov 2000 13:22:50 +0100
Subject: Will Haskell be commercialized in the future?
In-Reply-To: <20001127210132.A21702@hg.cs.mu.oz.au>; from fjh@cs.mu.oz.au on Mon, Nov 27, 2000 at 09:01:33PM +1100
References: <3233BEE02CB3D4118DBA00A0C99869401D60B1@hermes.pml.com> <20001127210132.A21702@hg.cs.mu.oz.au>
Message-ID: <20001127132250.A10360@cs.uu.nl>
Fergus Henderson wrote (on 27-11-00 21:01 +1100):
> That is twaddle. "Entrenched" C/C++ programmers will doubtless write
> bad code in any other language, just like Real Programmers and Fortran.
> The ability to declare a portion of the code as `unsafe' is a feature.
> It's like `unsafePerformIO' in Haskell! And also no worse than JNI in
> Java. Do you think that Haskell would be better without `unsafePerformIO'?
Without remarking on C#, I just wanted to point out that unsafePerformIO is
not part of the Haskell language...
[BTW, John and Olaf: the new haskell.org front page looks great! The logo is a
big improvement...]
--
Frank Atanassow, Information & Computing Sciences, Utrecht University
Padualaan 14, PO Box 80.089, 3508 TB Utrecht, Netherlands
Tel +31 (030) 253-3261 Fax +31 (030) 251-379
From tweed@compsci.bristol.ac.uk Mon Nov 27 12:42:04 2000
From: tweed@compsci.bristol.ac.uk (D. Tweed)
Date: Mon, 27 Nov 2000 12:42:04 +0000 (GMT)
Subject: Will Haskell be commercialized in the future?
In-Reply-To: <20001127132250.A10360@cs.uu.nl>
Message-ID:
On Mon, 27 Nov 2000, Frank Atanassow wrote:
> > Java. Do you think that Haskell would be better without `unsafePerformIO'?
>
> Without remarking on C#, I just wanted to point out that unsafePerformIO is
> not part of the Haskell language...
Umm, I hope that everyone in the implementors camps feels unsafePerformIO
is a de facto (if not de jure) part of the haskell libraries. I use it an
awful lot, and ironically not to do `imperative' type things but rather to
deal with the case where files on disk, etc, are static over the entire
program lifetime, so that their value can unambiguously be taken to be
their contents, etc. In some ways it's aesthetically annoying that the
same function name is used for both situations where IO isn't strictly
ordered and you don't care if this means you get different file contents
depending on when the read happens to occur, and when a file is
essentially a `raw string CAF that happens to be on disk rather than
compiled in'.
___cheers,_dave________________________________________________________
www.cs.bris.ac.uk/~tweed/pi.htm|tweed's law: however many computers
email: tweed@cs.bris.ac.uk | you have, half your time is spent
work tel: (0117) 954-5250 | waiting for compilations to finish.
From Doug_Ransom@pml.com Mon Nov 27 17:09:05 2000
From: Doug_Ransom@pml.com (Doug Ransom)
Date: Mon, 27 Nov 2000 09:09:05 -0800
Subject: Will Haskell be commercialized in the future?
Message-ID: <3233BEE02CB3D4118DBA00A0C99869401D60BB@hermes.pml.com>
> -----Original Message-----
> From: Benjamin L. Russell [mailto:russell@brainlink.com]
> Sent: Sunday, November 26, 2000 11:50 PM
> To: Doug Ransom; haskell-cafe@haskell.org
> Subject: Re: Will Haskell be commercialized in the future?
>
>
> On Fri, 24 Nov 2000 09:15:52 -0800
> Doug Ransom wrote:
> >
> > [stuff deleted]
> >
> > A lot of the things Haskell excells at (IMO) inferior
> > tools are being used
> > in place. For example, microsoft has build good XSLT
> > translators and two
> > new compilers (C#, VB7) in the last couple years.
> > Unfortunately, C#, not
> > Haskell, will probably be "the" language for the next
> > decade. [stuff deleted]
>
> Just out of curiosity: what makes you so sure about C#? C#
> has some potential big problems, too: in particular, the
> ability to declare a portion of the code "unsafe," which can
> encourage unsafe programming among entrenched C/C++ programmers.
Well, first of all, most C++ programmers really hate C++ and will be happy
to stay in safe mode and move to C#. There were cheers at the Microsoft
Profesional Developers Conference when MS announced garbage collection for
the COM replacement and the safety available with C# and managed C++ code.
C# is a huge improvement over C++.
Why would a C++ programmer want to go into unsafe mode? I guess when they
are writing interfaces to device drives, operating system calls, and legacy
interfaces.
>
> I myself am in no big hurry to master C#. I'd rather use a
> set of domain-specific languages with interlinked code,
> rather than a single language that purports to be as
> general-purpose as C# does.
Well, I would prefer to master Haskell and use that as my general purpose
language. Fat chance since the object models available in the microsoft
common language runtime are designed for impertive programming.
>
> Benjamin L. Russell
> russell@brainlink.com
> "Furuike ya! Kawazu tobikomu mizu no oto." --Matsuo Basho
>
From ahey@iee.org Mon Nov 27 15:56:38 2000
From: ahey@iee.org (Adrian Hey)
Date: Mon, 27 Nov 2000 15:56:38 +0000 (GMT)
Subject: Will Haskell be commercialized in the future?
In-Reply-To: <20001127210132.A21702@hg.cs.mu.oz.au>
Message-ID:
On Mon 27 Nov, Fergus Henderson wrote:
> Do you think that Haskell would be better without `unsafePerformIO'?
Well, a sceptic like me is bound to wonder why such a non-function is
provided in a purely functional language. What really worries me is
that the damage isn't localised. If you allow such things you can never be
sure that any function really is a function, without careful scrutiny of all
the code it's dependent on.
> This has lead C# to copy some of
> Java's other flaws, such as the awful array type.
What is wrong with Java and C# arrays? (I have never used either).
Regards
--
Adrian Hey
From mg169780@students.mimuw.edu.pl Mon Nov 27 19:53:05 2000
From: mg169780@students.mimuw.edu.pl (Michal Gajda)
Date: Mon, 27 Nov 2000 20:53:05 +0100 (CET)
Subject: Will Haskell be commercialized in the future?
In-Reply-To: <3233BEE02CB3D4118DBA00A0C99869401D60BB@hermes.pml.com>
Message-ID:
On Mon, 27 Nov 2000, Doug Ransom wrote:
> [stuff deleted]
> Well, I would prefer to master Haskell and use that as my general purpose
> language. Fat chance since the object models available in the microsoft
> common language runtime are designed for impertive programming.
I often use Haskell in imperative style(for example writting a toy
interpreter for subset of Tcl language). I noticed that(at
least for student projects) it's more convenient than, say C, in some
respects. I can often abstract out of the irrelevant details, thanks to
HOF and careful use of monads/monad transformers. And the need to
explicitly name imperative state or behaviour may clean up the code and
improve understanding of the problem.
Am I the only one?
Greetings
Michal Gajda
korek@charybda.icm.edu.pl
PS I think that inefficiency of lazy evaluation may be the more important
flaw of Haskell. I know that memory profiler may be used, but it's not so
easy to understand, what it tells. At least for someone else than
compiler-writer or at least hardcore computer-scientist.
From trd@cs.mu.OZ.AU Tue Nov 28 03:52:25 2000
From: trd@cs.mu.OZ.AU (Tyson Dowd)
Date: Tue, 28 Nov 2000 14:52:25 +1100
Subject: Will Haskell be commercialized in the future?
In-Reply-To: ; from ahey@iee.org on Mon, Nov 27, 2000 at 03:56:38PM +0000
References: <20001127210132.A21702@hg.cs.mu.oz.au>
Message-ID: <20001128145224.A13347@cs.mu.oz.au>
On 27-Nov-2000, Adrian Hey wrote:
> On Mon 27 Nov, Fergus Henderson wrote:
> > Do you think that Haskell would be better without `unsafePerformIO'?
>
> Well, a sceptic like me is bound to wonder why such a non-function is
> provided in a purely functional language. What really worries me is
> that the damage isn't localised. If you allow such things you can never be
> sure that any function really is a function, without careful scrutiny of all
> the code it's dependent on.
This is an issue, but it arises in any "pure" language with a foreign
language interface.
I think what would be nice to have is a notion of "trust". Only "trusted"
people can use unsafePerformIO -- of course as the application developer
you can decide who you trust and who you don't trust. It would be
possible to use public key crypto to handle trust (if you were worried
enough to bother). Then you only have to scrutinze uses of
unsafePerformIO that you don't trust.
We have been thinking of adding some support for "safety", "purity" and
"trust" to Mercury for a while, but haven't quite hammered out exactly what
these concepts mean and how they interact (or even whether it is all
worthwhile). The general idea is that you could trust :- promise pure
declarations (which are similar to unsafePerformIO). There are other :-
promise declarations too. To use a :- promise declaration you would
have to trust the author.
--
Tyson Dowd #
# Surreal humour isn't everyone's cup of fur.
trd@cs.mu.oz.au #
http://www.cs.mu.oz.au/~trd #
From nkallen@uclink4.berkeley.edu Tue Nov 28 03:52:44 2000
From: nkallen@uclink4.berkeley.edu (Nick Kallen)
Date: Mon, 27 Nov 2000 19:52:44 -0800
Subject: Will Haskell be commercialized in the future?
In-Reply-To: <20001128145224.A13347@cs.mu.oz.au>
Message-ID: <000901c058ee$a9e6a660$0b28c83f@pacbell.net>
> To use a :- promise declaration you would
> have to trust the author.
It seems like you'd also have to trust the author to write bug-free code
too...
From trd@cs.mu.OZ.AU Tue Nov 28 04:14:09 2000
From: trd@cs.mu.OZ.AU (Tyson Dowd)
Date: Tue, 28 Nov 2000 15:14:09 +1100
Subject: Will Haskell be commercialized in the future?
In-Reply-To: <000901c058ee$a9e6a660$0b28c83f@pacbell.net>; from nkallen@uclink4.berkeley.edu on Mon, Nov 27, 2000 at 07:52:44PM -0800
References: <20001128145224.A13347@cs.mu.oz.au> <000901c058ee$a9e6a660$0b28c83f@pacbell.net>
Message-ID: <20001128151409.A14028@cs.mu.oz.au>
On 27-Nov-2000, Nick Kallen wrote:
> > To use a :- promise declaration you would
> > have to trust the author.
>
> It seems like you'd also have to trust the author to write bug-free code
> too...
I think this is the point. You have to trust them to write pure
interfaces. Generally this will involve them writing bug-free code.
This is the level of trust you usually give to compiler and library
writers. But if people start writing foreign language interface stuff
all over the place, you might want to start exerting some control over
using it unless you are pretty sure it's bug-free (an deliberately
written to be pure).
--
Tyson Dowd #
# Surreal humour isn't everyone's cup of fur.
trd@cs.mu.oz.au #
http://www.cs.mu.oz.au/~trd #
From ashley@semantic.org Tue Nov 28 04:26:50 2000
From: ashley@semantic.org (Ashley Yakeley)
Date: Mon, 27 Nov 2000 20:26:50 -0800
Subject: Will Haskell be commercialized in the future?
Message-ID: <200011280426.UAA13901@mail4.halcyon.com>
At 2000-11-27 19:52, Tyson Dowd wrote:
>On 27-Nov-2000, Adrian Hey wrote:
>> On Mon 27 Nov, Fergus Henderson wrote:
>> > Do you think that Haskell would be better without `unsafePerformIO'?
>>
>> Well, a sceptic like me is bound to wonder why such a non-function is
>> provided in a purely functional language. What really worries me is
>> that the damage isn't localised. If you allow such things you can never be
>> sure that any function really is a function, without careful scrutiny of all
>> the code it's dependent on.
>
>This is an issue, but it arises in any "pure" language with a foreign
>language interface.
Not necessarily, the functions just need to be typed correctly. In the
case of a non-safe or imperative function, that's going to be of the
form "a -> IO b" (or "IO a -> IO b" if you prefer the more powerful arrow
model).
No safety needs to be sacrificed.
--
Ashley Yakeley, Seattle WA
From trd@cs.mu.OZ.AU Tue Nov 28 04:54:32 2000
From: trd@cs.mu.OZ.AU (Tyson Dowd)
Date: Tue, 28 Nov 2000 15:54:32 +1100
Subject: Will Haskell be commercialized in the future?
In-Reply-To: <200011280426.UAA13901@mail4.halcyon.com>; from ashley@semantic.org on Mon, Nov 27, 2000 at 08:26:50PM -0800
References: <200011280426.UAA13901@mail4.halcyon.com>
Message-ID: <20001128155432.A14627@cs.mu.oz.au>
On 27-Nov-2000, Ashley Yakeley wrote:
> >This is an issue, but it arises in any "pure" language with a foreign
> >language interface.
>
> Not necessarily, the functions just need to be typed correctly. In the
> case of a non-safe or imperative function, that's going to be of the
> form "a -> IO b" (or "IO a -> IO b" if you prefer the more powerful arrow
> model).
>
> No safety needs to be sacrificed.
I would agree that no purity (referential transparency) needs to be
sacrificed. The IO monad preserves referential transparency pretty
well.
Safety is another issue. If by safety we mean "memory safe" (cannot
use invalid pointers) then how can the IO monad possibly help?
We can dereference an invalid pointer inside or outside the IO monad --
it doesn't matter, the program still crashes. Surely then we cannot call a
foreign language interface "safe" just because it gives each foreign
function IO types.
Typically both impure (non-referentially transparent) and plain old
unsafe code can be made into pure & safe code by a bit of sequencing
(helped by a monad) and an nice pure wrapper interface (and sometimes
even unsafePerformIO to hide the now unnecessary monads).
But the issue then arises that if you use the IO monad for the sequencing
of raw, potentially unsafe code, how are developers supposed to be able
to tell it apart from safe IO code?
--
Tyson Dowd #
# Surreal humour isn't everyone's cup of fur.
trd@cs.mu.oz.au #
http://www.cs.mu.oz.au/~trd #
From chak@cse.unsw.edu.au Wed Nov 29 05:22:48 2000
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Wed, 29 Nov 2000 16:22:48 +1100
Subject: Will Haskell be commercialized in the future?
In-Reply-To:
References: <20001127210132.A21702@hg.cs.mu.oz.au>
Message-ID: <20001129162248R.chak@cse.unsw.edu.au>
Adrian Hey wrote,
> On Mon 27 Nov, Fergus Henderson wrote:
> > Do you think that Haskell would be better without `unsafePerformIO'?
>
> Well, a sceptic like me is bound to wonder why such a non-function is
> provided in a purely functional language. What really worries me is
> that the damage isn't localised. If you allow such things you can never be
> sure that any function really is a function, without careful scrutiny of all
> the code it's dependent on.
Consider `unsafePerformIO' to be a feature to implement
system libraries and the like. It makes it easier to
implement libraries in Haskell which otherwise partially or
completely would have to be written in another language and,
then, be called from Haskell.
Like with any system library if the system programmer messes
it up (eg, exports a function that isn't really a function),
you are in for some trouble. This is not very different to
you trusting the interpreter or compiler implementer that
what they execute is actually what you wrote.
Cheers,
Manuel
From kurt.wilkin@actfs.co.nz Thu Nov 30 04:11:45 2000
From: kurt.wilkin@actfs.co.nz (Kurt)
Date: Thu, 30 Nov 2000 17:11:45 +1300
Subject: Type classes diagram?
Message-ID: <3A25D381.BC05EA3A@actfs.co.nz>
Has anyone seen a downloadable diagram of the relationships
between all of the Haskell type classes? If so, could you post a
link?
TIA,
Kurt.
From mg169780@students.mimuw.edu.pl Thu Nov 30 04:36:16 2000
From: mg169780@students.mimuw.edu.pl (Michal Gajda)
Date: Thu, 30 Nov 2000 05:36:16 +0100 (CET)
Subject: Type classes diagram?
In-Reply-To: <3A25D381.BC05EA3A@actfs.co.nz>
Message-ID:
On Thu, 30 Nov 2000, Kurt wrote:
> Has anyone seen a downloadable diagram of the relationships
> between all of the Haskell type classes? If so, could you post a
> link?
I think that winhugs generates something like this.
(At least elder versions did it)
Greetings
Michal Gajda
korek@charybda.icm.edu.pl
From khchoi@ruby.kaist.ac.kr Thu Nov 30 04:35:38 2000
From: khchoi@ruby.kaist.ac.kr (Kwanghoon Choi)
Date: Thu, 30 Nov 2000 13:35:38 +0900 (KST)
Subject: Type classes diagram?
In-Reply-To: <3A25D381.BC05EA3A@actfs.co.nz>
Message-ID:
Hi,
Do you mean this diagram in the Haskell98 report?
http://www.haskell.org/onlinereport/basic.html
(6.3 Standard Haskell Classes)
Kwanghoon
On Thu, 30 Nov 2000, Kurt wrote:
> Has anyone seen a downloadable diagram of the relationships
> between all of the Haskell type classes? If so, could you post a
> link?
>
> TIA,
> Kurt.
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
From kurt.wilkin@actfs.co.nz Thu Nov 30 04:54:16 2000
From: kurt.wilkin@actfs.co.nz (Kurt)
Date: Thu, 30 Nov 2000 17:54:16 +1300
Subject: Type classes diagram?
References:
Message-ID: <3A25DD78.33E2A4B0@actfs.co.nz>
Thats great, thanks.
PS. Haskell will be commercialised as soon as I can afford to buy an
ad during Superbowl ;-)
(but don't hold your breath.)
Kwanghoon Choi wrote:
>
> Hi,
>
> Do you mean this diagram in the Haskell98 report?
>
> http://www.haskell.org/onlinereport/basic.html
> (6.3 Standard Haskell Classes)
>
> Kwanghoon
>
> On Thu, 30 Nov 2000, Kurt wrote:
>
> > Has anyone
[...]
> > Kurt.
> >