[Haskell] ML 2013: last call for presentations

[Daan Leijen]

There are still a few days left to write a short talk proposal 
for the ML workshop 2013! Since there are no official proceedings, 
this is an ideal venue if you are working on a  full submission 
for some other conference but want to talk about the  work early 
on and get useful community feedback.

Hope to see you there,
-- Daan 


ACM SIGPLAN Workshop on ML
Sunday, September 22, 2013, Boston MA
(co-located with ICFP)

http://research.microsoft.com/en-us/um/people/daan/mlworkshop2013
=== 

The ML family of programming languages includes dialects known as
Standard ML, OCaml, and F#.  These languages have inspired a large
amount of computer-science research, both practical and theoretical.
This workshop aims to provide a forum where users, developers and
researchers of ML languages and related technology can interact and
discuss ongoing research, open problems and innovative applications.
  
The ML workshop has adopted an informal model since 2010. It is a 
workshop with presentations selected from submitted abstracts. There 
are no published proceedings, so any contributions may be submitted 
for publication elsewhere. We hope that this format encourages the 
presentation of exciting (if unpolished) research and deliver a lively 
workshop atmosphere.

SCOPE
-

We seek research presentations on topics related to ML, including but
not limited to

  * Applications: case studies, experience reports, pearls, etc.
  * Extensions: higher forms of polymorphism, generic programming,
objects, concurrency, distribution and mobility, semi-structured
data handling, etc.
  * Type systems: inference, effects, overloading, modules, contracts,
specifications and assertions, dynamic typing, error reporting, etc.
  * Implementation: compilers, interpreters, type checkers, partial
evaluators, runtime systems, garbage collectors, etc.
  * Environments: libraries, tools, editors, debuggers, cross-language
interoperability, functional data structures, etc.
  * Semantics: operational, denotational, program equivalence,
parametricity, mechanization, etc.

Three kinds of submissions will be accepted: Research Presentations,
Experience Reports and Demos.

  * Research Presentations: Research presentations should describe new
ideas, experimental results, significant advances in ML-related
projects, or informed positions regarding proposals for
next-generation ML-style languages.  We especially encourage
presentations that describe work in progress, that outline a
future research agenda, or that encourage lively discussion.
These presentations should be structured in a way which can be, at
least in part, of interest to (advanced) users.

  * Experience Reports: Users are invited to submit Experience Reports
about their use of ML languages. These presentations do not need
to contain original research but they should tell an interesting
story to researchers or other advanced users, such as an
innovative or unexpected use of advanced features or a description
of the challenges they are facing or attempting to solve.

  * Demos: Live demonstrations or short tutorials should show new
developments, interesting prototypes, or work in progress, in the
form of tools, libraries, or applications built on or related to
ML.  (Please note that you will need to provide all the hardware
and software required for your demo; the workshop organizers are
only able to provide a projector.)

Each presentation should take 20-25 minutes, except demos, which
should take 10-15 minutes.  The exact time will be decided based on
the number of accepted submissions.


SUBMISSION INSTRUCTIONS
---

Submissions should be at most two pages, in PDF format, and printable
on US Letter or A4 sized paper. Submissions longer than half a page
should include a one-paragraph synopsis suitable for inclusion in the
workshop program.

Submissions must be uploaded to the following website before the
submission deadline (2013-06-21):

  https://www.easychair.org/conferences/?conf=ml2013

For any question concerning the scope of the workshop or the
submission process, please contact the program chair
(daan at microsoft.com).


IMPORTANT DATES
---

  * Friday, June 21 : Submission
  * Monday, July 22 : Notification
  * Sunday, September 22: Workshop


PROGRAM COMMITTEE
-

  Daan Leijen (chair) (Microsoft Research, US) 
  Jesse A. Tov(Harvard University, US) 
  Derek Dreyer(MPI-SWS, Germany) 
  Atsushi Ohori   (Univ. of Tohoku, Japan) 
  Lars Bergstrom  (Univ. of Chicago, US) 
  Jean Yang   (MIT CSAIL, US) 
  Gavin Bierman   (Microsoft Research, Cambridge, UK) 
  Tomas Petricek  (Univ. of Cambridge, UK) 
  Yukiyoshi Kameyama  (Univ. of Tsukuba, Japan) 
  Peter Thiemann  (Univ. of Freiburg, Germany) 


STEERING COMMITTEE

[Haskell] ML workshop 2013: Call for presentations

[Daan Leijen]

ACM SIGPLAN Workshop on ML
Sunday, September 22, 2013, Boston MA
(co-located with ICFP)

http://research.microsoft.com/en-us/um/people/daan/mlworkshop2013
===

The ML family of programming languages includes dialects known as
Standard ML, OCaml, and F#.  These languages have inspired a large
amount of computer-science research, both practical and theoretical.
This workshop aims to provide a forum where users, developers and
researchers of ML languages and related technology can interact and
discuss ongoing research, open problems and innovative applications.

The ML workshop has adopted an informal model since 2010. It is a
workshop with presentations selected from submitted abstracts. There
are no published proceedings, so any contributions may be submitted
for publication elsewhere. We hope that this format encourages the
presentation of exciting (if unpolished) research and deliver a lively
workshop atmosphere.

SCOPE
-

We seek research presentations on topics related to ML, including but
not limited to

  * Applications: case studies, experience reports, pearls, etc.
  * Extensions: higher forms of polymorphism, generic programming,
objects, concurrency, distribution and mobility, semi-structured
data handling, etc.
  * Type systems: inference, effects, overloading, modules, contracts,
specifications and assertions, dynamic typing, error reporting, etc.
  * Implementation: compilers, interpreters, type checkers, partial
evaluators, runtime systems, garbage collectors, etc.
 * Environments: libraries, tools, editors, debuggers, cross-language
interoperability, functional data structures, etc.
  * Semantics: operational, denotational, program equivalence,
parametricity, mechanization, etc.

Three kinds of submissions will be accepted: Research Presentations,
Experience Reports and Demos.

  * Research Presentations: Research presentations should describe new
ideas, experimental results, significant advances in ML-related
projects, or informed positions regarding proposals for
next-generation ML-style languages.  We especially encourage
presentations that describe work in progress, that outline a
future research agenda, or that encourage lively discussion.
These presentations should be structured in a way which can be, at
least in part, of interest to (advanced) users.

  * Experience Reports: Users are invited to submit Experience Reports
about their use of ML languages. These presentations do not need
to contain original research but they should tell an interesting
story to researchers or other advanced users, such as an
innovative or unexpected use of advanced features or a description
of the challenges they are facing or attempting to solve.

  * Demos: Live demonstrations or short tutorials should show new
developments, interesting prototypes, or work in progress, in the
form of tools, libraries, or applications built on or related to
ML.  (Please note that you will need to provide all the hardware
and software required for your demo; the workshop organizers are
only able to provide a projector.)

Each presentation should take 20-25 minutes, except demos, which
should take 10-15 minutes.  The exact time will be decided based on
the number of accepted submissions.


SUBMISSION INSTRUCTIONS
---

Submissions should be at most two pages, in PDF format, and printable
on US Letter or A4 sized paper. Submissions longer than a half a page
should include a one-paragraph synopsis suitable for inclusion in the
workshop program.

Submissions must be uploaded to the following website before the
submission deadline (2013-06-21):

  https://www.easychair.org/conferences/?conf=ml2013

For any question concerning the scope of the workshop or the
submission process, please contact the program chair
(daan at microsoft.com).


IMPORTANT DATES
---

  * Friday, June 21 : Submission
  * Monday, July 22 : Notification
  * Sunday, September 22: Workshop


PROGRAM COMMITTEE
-

  Daan Leijen (chair) (Microsoft Research, US)
  Jesse A. Tov(Harvard University, US)
  Derek Dreyer(MPI-SWS, Germany)
  Atsushi Ohori   (Univ. of Tohoku, Japan)
  Lars Bergstrom  (Univ. of Chicago, US)
  Jean Yang   (MIT CSAIL, US)
  Gavin Bierman   (Microsoft Research, Cambridge, UK)
  Tomas Petricek  (Univ. of Cambridge, UK)
  Yukiyoshi Kameyama  (Univ. of Tsukuba, Japan)
  Peter Thiemann  (Univ. of Freiburg, Germany)


STEERING COMMITTEE
--

  Matthew Fluet   (Rochester Institute of Technology)
  Alain Frisch(LexiFi)
  Jacques Garrigue(Nagoya University)
  Yaron Minsky(Jane Street)
  Greg Morrisett  (Harvard University)
  Andreas Rossberg(chair, Google)
  Chung-chieh Shan(Indiana University

Re: [Haskell] why don't we have const Ptrs?

[Daan Leijen]

Hi David,

> One could pretty easily create a ConstPtr type which one could peek into,
> but not poke to, but then you'd have to explicitely convert a Ptr into a
> ConstPtr when passing it as an argument.  That feels a bit silly.

One way of dealing with constant pointer is to introduce (yet another)
phantom type variable 'r' to pointers:

 data Ptr r a = ...

and introduce a read access hierarchy:

 data Read a
 data Write

A constant pointer has type  "Ptr (Read ()) a"
A normal pointer has type"Ptr (Read Write) a"
At least read pointer"Ptr (Read r) a"
And a 'don't care' pointer   "Ptr r a

 peek :: Ptr (Read r) a -> IO a
 poke :: Ptr (Read Write) a -> a -> IO ()
 alloc:: IO (Ptr (Read Write) a)

So, the type signature for strcat is:

 foreign import strcat :: Ptr (Read Write) CChar -> Ptr (Read a) CChar -> IO ()

And we can derive the "const" attribute too:

 data FooPtr r = FooPtr String (Ptr r Foo)

Since the read-write restrictions of "Ptr" carry over to "FooPtr".

The design can be refined since four kinds of pointers is a bit too much.
We could use for example:

 type Const   = ()
 data Write

and say:

 "Ptr Const a"  == constant pointer
 "Ptr Write a"  == read-write pointer
 "Ptr r a"  == at least readable

And strcat would be:

  foreign import strcat :: Ptr Write CChar -> Ptr r CChar -> IO ()

and we would have:

  constantMalloc :: (Ptr Write a -> IO ()) -> Ptr Const a
  malloc :: Ptr Write a

  peek :: Ptr r a -> IO a
  poke :: Ptr Write a -> a -> IO ()

So, this is another solution, although I am not sure if it is worth the
trouble making the distinction between normal and constant pointers.

All the best,
-- Daan.

David Roundy wrote:

Hello all,

I was thinking this morning as I lay on the floor (where I sleep) about
static typechecking, and how much more wonderful Haskell is than any other
language, when it occurred to me that when working with pointers, Haskell
actually has *less* static typechecking than C or C++.  It was a very
disturbing thought, so much so that I was almost compelled to arise early
to place this question before this learned audience.

Why is it that in C++ I can write

void strcpy(char *dest, const char *src);

but in Haskell I must import this function as


foreign import ccall unsafe "static string.h strcpy"
 strcpy :: Ptr CChar -> Ptr CChar -> IO ()


and lose that wonderful information that the function doesn't modify the
contents of its second argument?

One could pretty easily create a ConstPtr type which one could peek into,
but not poke to, but then you'd have to explicitely convert a Ptr into a
ConstPtr when passing it as an argument.  That feels a bit silly.

One could get around this by introducing a class to get around this


class ReadablePtr p where
   peek :: p a -> IO a
   peekOff ...


and then make both Ptr and ConstPtr instances of this class, but this still
seems like a very hackish solution.

Moreover, I'd like to be able to have const objects quite apart from Ptrs,
such as a const Handle, which I can read from, but cannot write to, or a
const IORef--and we wouldn't want to leave out const ForeignPtrs.  Of
course, even reading affects a Handle's internal state, so one would need
to be explicit about what "const" indicates.  But it seems to me that in
the IO world there are a whole slew of "things that refer to other things"
which could all be grouped together.

And a "const" attribute ought to be derived, so that if I create a data
type


data FooPtr = FooPtr String (Ptr Foo)


one should ideally be able to automatically understand that a const FooPtr
holds a const (Ptr Foo).

One could go further, at least when dealing with Ptrs, and create a way of
handling "restricted" pointers--which we could interpret as a const pointer
to an object that cannot be changed by anyone else either.  One could
safely create restricted pointers with a function of the type


mallocRestrictedPtr :: (Ptr a -> IO ()) -> RestrictedPtr a


which would allow one to ensure at the typechecking level that
RestrictedPtrs point to memory that cannot be modified.  There's still some
unstafety involved, in that you could read out of bounds, but you would
know that apart from that possibility the contents of a RestrictedPtr truly
will never change.

So my question is, how would one implement such an "annotation" extension?
I'd like to be able to pass a (Ptr a) as a (Const (Ptr a)) without an
explicit typecast, since the Const really isn't changing the type of the
pointer, it's just marking it as one that can't be modified.  A function
that accepts a (Const (Ptr a)) should also accept a (Restricted (Ptr
a))--but Restricted pointers are really just pudding, as they only differ
from Const pointers in what optimizations are allowed.  On the other hand,
it's not just compiler optimizations that they would allow, but also
user-code optimizations, which could be much more useful.  They also have
the advantage of making certain unsafe functions safe.

The

Re: [Haskell] Excessive sharing and GHC

[Daan Leijen]

John Meacham wrote:

On Tue, Oct 18, 2005 at 08:31:19AM +0100, Simon Peyton-Jones wrote:

GHC tries not to create space leaks, but does not guarantee not to.  In
particular, the full laziness transformation is so beneficial most of
the time that, even though it can create a space leak GHC still does it
(unless you turn it off with a flag).


I was thinking it would be nice if one could put a pragma on CAFs that
basically made ghc treat them as WHNF so it would float them inward as
far as possible including inside lambdas. in particular, constant
strings that are created (cheaply) from efficient internal
representations should not be held onto in their inefficient form.


What about adding a unit argument? That would do the trick without pragmas.

All the best,
-- Daan


it might even be worth it to have a pragma that made ghc think they
were duplicatable too, so it would float them all the way to each of their
uses, duplicating the expression as necessary just to make sure it is
never held onto more than needed.

John



___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] ANNOUNCE: ghc-src version 0.2.0

[Daan Leijen]

Brian Smith wrote:
I heard that there is some combinator-based Haskell parser that also is 
equivalent to GHC's Happy-based one, and is within 10% of its 
performance. I had thought that I read that GHC might even start using 
it. Does anybody know if the combinator-based one is available?


This work has been done Arthur Baars -- he actually replaced the ghc
parser by his combinator parser and build Ghc + standard libraries
with it which took 10% longer than using the Happy parser. You should
probably contact him to get more information. One interesting thing is
that the combinator parser can use syntax macros and thus extend the
syntax of Haskell at compile time in a type-safe way.

All the best,
-- Daan Leijen.

ps. When you check out Arthur's webpage, be sure to read the
"Typing dynamic typing" article -- it is a great paper!




Thanks,
Brian




___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell


___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] combining IntMaps

[Daan Leijen]

Adrian Hey wrote:

Hello,


Thanks! It's interesting the way your AVL tree library is set up --
there seems to be a much broader degree of functionality than that
provided by Data.Set. But I'm trying to see, is there a significant
difference in the fundamental data structure.


Well Data.Set is based on a different balanced tree type (weight
balanced trees), similar to those used in the Adams paper. I'm
also quite sceptical about the Hedge algorithm, so the AVL library
doesn't use it. It uses divide and conquer, but not quite as Adams
describes it.


Please note that the original mail was about "IntMap" and "IntSet" and these data 
structures use patricia trees and have a much different union algorithm alltogether. 
(a very good one actually -- one of the main reasons to make a special Map and Set 
instance for integers :-) )



But IMO the biggest problem with Data.Set is the inflexible API.
For example..


From Data.Set:

 union :: Ord a => Set a -> Set a -> Set a
 intersect :: Ord a => Set a -> Set a -> Set a


From Data.Tree.AVL:

 genUnion :: (e -> e -> COrdering e) -> AVL e -> AVL e -> AVL e
 genIntersection :: (a -> b -> COrdering c) -> AVL a -> AVL b -> AVL c


You are right, but there is a reason for this: with the Set api I wanted to expose 
only operations that do not violate the notion of a mathematical set: ie. the 
ordering on the elements must be fixed or otherwise the invariants might not hold any 
longer. One way to insure this is by passing an ordering function when constructing a 
set, but a nicer way is to use overloading (since only a single instance can hold for 
the set).


Of course, maybe it is a good idea to make two modules: a 'collection' data type that 
exposes internal operations, and a 'Set' module on top that implements sets and does 
not expose operations that could violate set invariants.


You are right that these considerations do not make as much sense in the context of 
general AVL trees since no guarantee op "Set" functionality is given there. Same 
holds for the IntMap and Map interfaces. (but not for "Bag").


> or is the main point that
> the additional functionality could not have otherwise been provided in
> an efficient way without going into the guts of Data.Set?

Efficiency wise, I think one should only provide functions that ensure that the 
complexity does not get worse -- if one also considers functionality that improves on 
a constant factor (like traversing twice) there is no end to the number of functions 
that can be provided (as one is basically doing deforestation by hand). But this is 
of course just my personal opinion on how to control the size of the API.


All the best,
-- Daan Leijen.


Of course there's no reason why similar functions could not be
provided by Data.Set, but they're not there at present.



or is the main point that
the additional functionality could not have otherwise been provided in
an efficient way without going into the guts of Data.Set?



Yes. This why producing useable libraries like this is so difficult.
There's plenty of reasonable things you just can't do efficiently
with Data.Set. Same is probably true of Data.Tree.AVL of course, but
I'm trying to make it more complete all the time.

Anyway, please try out AVL and let me know if there's anything more
missing.

Regards
--
Adrian Hey

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell


___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] combining IntMaps

[Daan Leijen]

Hi Chad,

Scherrer, Chad wrote:

the sum of the values is zero. My specification is

addMaps :: IntMap Int -> IntMap Int -> IntMap Int
addMaps m = IntMap.filter (/= 0) . IntMap.unionWith (+) m

But I'm not really happy with this because it traverses both maps for 
the union, and then traverses the result to get rid of all the zeros. 
(This function is a performance bottleneck in my current code).


The function is not so bad as it looks at first sight. First of all, the unionWith 
and filter are (somewhat) lazy and it is not the case that an entire map will be 
build before the filter is run. Furthermore, complexity wise, you can not improve the 
function much -- only a constant factor since the map is traversed twice (assuming 
that the compiler does no deforestation).


I do not think that we want families of functions like "filterUnion" etc, but maybe 
it would be good to add an "adjustInsert" function that can insert, delete, or adjust 
a key in the map -- just what you needed to implement the single-traversal algorithm:



I thought I could do something like

addMaps' :: IntMap Int -> IntMap Int -> IntMap Int
addMaps' = IntMap.foldWithKey f
where
f k x = IntMap.update (maybeAdd x) k
maybeAdd x v = let s = v + x in if s == 0 then Nothing else Just s


However, note that "union" might have a much better runtime behaviour than folding 
through one map and looking up values in the other map. Through the "hedge" algorithm 
 it more or less takes unions of sub-trees which, depending on the actual runtime 
structure, generally take much less time. Having said that, one has to be *extremely* 
careful making any performance remarks about functional data structures -- especially 
in a lazy setting. I have been surprised many times by benchmark results that changed 
completely by little changes in how the structure was 'demanded' at runtime. For the 
same reason, I highly suspect that your original 'bottleneck' in the program is 
probably not the "filter . union" call, but somewhere else in the program -- maybe 
even the wrong algorithm? From my experience, it usually doesn't help much to mess 
with the internal representation of data structures in Haskell. Usually there are so 
many factors involved that writing a clear algorithm and thinking hard about it works 
out much better in the long run (together with a handful of seq's and strictness 
annotations :-) )


I hope this helps,
All the best,
 Daan Leijen


But this is no good, because IntMap.update only affects those keys where 
lookup succeeds, so

IntMap.update (maybeAdd 3) 8 IntMap.empty
returns IntMap.empty, rather than a map with 8 -> 3 as I had hoped.

What would you suggest to help addMaps run faster? Do I need to pry open 
the IntMap implementation to do better?


Thanks so much,
Chad Scherrer

PS - I mistakenly crosslisted this to the GHC users list, because I 
didn't realize how the mailing lists were set up. Please excuse my 
noobiness.





___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell


___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Haskell workshop 2005 -- Call for participation.

[Daan Leijen]

 2005 Haskell Workshop
   Tallinn, Estonia, 30 September, 2005
 http://www.cs.uu.nl/~daan/hw2005

Call for participation

-- Important Dates ---

Early registration deadline : July 29
Late registration deadline  : September 2
Haskell workshop: September 30

Registration is available from <http://www.cs.ioc.ee/tfp-icfp-gpce05>.


-- Preliminary Programme -

The preliminary programme is available from the Haskell workshop website at
<http://www.cs.uu.nl/~daan/hw2005> and is appended in plain text to this 
section.

This year, David Roundy gives an invited talk about Darcs: a popular distributed
version control system written Haskell.

  8:45
    Welcome by Daan Leijen

  9:00 - 10:30
Invited talk: Lessons from Darcs
David Roundy

Visual Haskell – A full-featured Haskell development environment
Krasimir Angelov and Simon Marlow

Haskell ready to Dazzle the real world
Martijn M. Schrage, Arjan van IJzendoorn, and Linda C. van der Gaag

  11:00 - 12:30
Dynamic applications from the ground up
Don Stewart and Manuel M. T. Chakravarty

Haskell server pages through dynamic loading
Niklas Broberg

Haskell on a shared-memory multiprocessor
Tim Harris, Simon Marlow, and Simon Peyton Jones

  14:00 - 15:30
Verifying Haskell programs using constructive type theory
Andreas Abel, Marcin Benke, Ana Bove, John Hughes, Ulf Norell

Putting Curry-Howard to work
Tim Sheard

There and Back Again – Arrows for Invertible Programming
Artem Alimarine, Sjaak Smetsers, Arjen van Weelden, Marko van Eekelen,
and Rinus Plasmeijer

  16:00 - 17:15
TypeCase: A design pattern for type-indexed functions
Bruno C. d. S. Oliveira and Jeremy Gibbons

Functional pearl: Polymorphic pattern matching
Richard S. Bird

Tool demonstration: Halfs – the Haskell file system
Isaac Jones

  17:15 - 17:45
Discussion: The future of Haskell


-- The Haskell Workshop --

The Haskell Workshop 2005 is an ACM SIGPLAN sponsored workshop affiliated with
the 2005 International Conference on Functional Programming (ICFP). Previous
Haskell Workshops have been held in La Jolla (1995), Amsterdam (1997), Paris
(1999), Montreal (2000), Firenze (2001), Pittsburgh (2002), Uppsala (2003), and
Snowbird (2004).


-- Scope -

The purpose of the Haskell Workshop is to discuss experience with Haskell, and
future developments for the language.  The scope of the workshop includes all
aspects of the design, semantics, theory, application, implementation, and
teaching of Haskell. Topics of interest include, but are not limited to, the
following:

* Language Design,
with a focus on possible extensions and modifications of Haskell as well as
critical discussions of the status quo;
* Theory,
in the form of a formal treatment of the semantics of the present language
or future extensions, type systems, and foundations for program analysis and
transformation;
* Implementations,
including program analysis and transformation, static and dynamic
compilation for sequential, parallel, and distributed architectures, memory
management as well as foreign function and component interfaces;
* Tools,
in the form of profilers, tracers, debuggers, pre-processors, and so forth;
* Applications, Practice, and Experience,
with Haskell for scientific and symbolic computing, database, multimedia and
Web applications, and so forth as well as general experience with Haskell in
education and industry;
* Functional Pearls,
being elegant, instructive examples of using Haskell.

Papers in the latter two categories need not necessarily report original
research results; they may instead, for example, report practical experience
that will be useful to others, re-usable programming idioms, or elegant new ways
of approaching a problem. The key criterion for such a paper is that it makes a
contribution from which other practitioners can benefit. It is not enough simply
to describe a program!


-- Program committee -

Martin Erwig Oregon State University
John Hughes  Chalmers University of Technology
Mark Jones   OGI School of Science and Engineering at OHSU
Ralf Lämmel  Microsoft Corp.
Daan Leijen  Universiteit Utrecht (Program Chair)
Andres Löh   Universiteit Utrecht
Andrew Moran Galois Connections Inc.
Simon Thompson   University of Kent
Malcolm Wallace  University of York
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Haskell workshop 2005: final call for papers

[Daan Leijen]

Final call for papers, with still two working weeks to go:

 2005 Haskell Workshop
   Tallinn, Estonia, 30 September, 2005
 http://www.cs.uu.nl/~daan/hw2005

 Final Call for papers


 -- Important Dates ---

Submission deadline: June 10
Acceptance notification: July  5
Final version due  : July 19
Haskell workshop   : September 30


-- The Haskell Workshop --

The Haskell Workshop 2005 is an ACM SIGPLAN sponsored workshop affiliated with
the 2005 International Conference on Functional Programming (ICFP). Previous
Haskell Workshops have been held in La Jolla (1995), Amsterdam (1997), Paris
(1999), Montreal (2000), Firenze (2001), Pittsburgh (2002), Uppsala (2003), and
Snowbird (2004).


-- Scope -

The purpose of the Haskell Workshop is to discuss experience with Haskell, and
future developments for the language.  The scope of the workshop includes all
aspects of the design, semantics, theory, application, implementation, and
teaching of Haskell. Topics of interest include, but are not limited to, the
following:

* Language Design,
with a focus on possible extensions and modifications of Haskell as well as
critical discussions of the status quo;
* Theory,
in the form of a formal treatment of the semantics of the present language
or future extensions, type systems, and foundations for program analysis and
transformation;
* Implementations,
including program analysis and transformation, static and dynamic
compilation for sequential, parallel, and distributed architectures, memory
management as well as foreign function and component interfaces;
* Tools,
in the form of profilers, tracers, debuggers, pre-processors, and so forth;
* Applications, Practice, and Experience,
with Haskell for scientific and symbolic computing, database, multimedia and
Web applications, and so forth as well as general experience with Haskell in
education and industry;
* Functional Pearls,
being elegant, instructive examples of using Haskell.

Papers in the latter two categories need not necessarily report original
research results; they may instead, for example, report practical experience
that will be useful to others, re-usable programming idioms, or elegant new ways
of approaching a problem. The key criterion for such a paper is that it makes a
contribution from which other practitioners can benefit. It is not enough simply
to describe a program!

If there is sufficient demand, we will try to organise a time slot for system or
tool demonstrations.  If you are interested in demonstrating a Haskell related
tool or application, please send a brief demo proposal to the program chair
([EMAIL PROTECTED]).


-- Submissions ---

Authors should submit papers in postscript or portable document format (pdf),
formatted for A4 paper, to Daan Leijen ([EMAIL PROTECTED]). The length should be
restricted to 12 pages in standard ACM SIG proceedings format. In particular,
LaTeX users should use the most recent sigplan proceedings style available from
the Haskell workshop web-site. Furthermore, the "abbrv" style should be used for
the bibliography. Accepted papers are published by the ACM and appear in the ACM
digital library.

Each paper should explain its contributions in both general and technical terms,
clearly identifying what has been accomplished, explaining why it is
significant, and comparing it with previous work. Authors should strive to make
the technical content of their papers understandable to a broad audience.


-- Program committee -

Martin Erwig Oregon State University
John Hughes  Chalmers University of Technology
Mark Jones   OGI School of Science and Engineering at OHSU
Ralf Lämmel  Microsoft Corp.
Daan Leijen  Universiteit Utrecht (Program Chair)
Andres Löh   Universiteit Utrecht
Andrew Moran Galois Connections Inc.
Simon Thompson   University of Kent
Malcolm Wallace  University of York
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Using Haddock

[Daan Leijen]

T.A.T.Davie wrote:
Hi,
  I've been trying to get haddock to work, and have successfully produced
However, the files seem to contain no useful information at all, even if I
comment the modules as so:
--| Its a fucking module
module MyModule where
As a gentlemen's tool, Haddock might have been offended by
your artistic depiction of improper virtues within the
enlightning pureness of Haskell ;-)
On the other hand, it could also be that Haddock expects
a space between the comment sign and the bar:
-- | This is a proper haddock comment
Cheers,
-- Daan Leijen.

{-|
  The 'square' function squares an integer.
  It takes one argument, of type 'Int'.
-}
square :: Int -> Int
square x = x * x
(the square example taken from the haddock documentation).  And still I
get no more documentation than:
ContentsIndex
MyModule
Synopsis
Produced by Haddock version 0.6
What on earth is it trying to do?
Bob
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Re: Fixed-length vectors in Haskell, Part 2: Using no extensions

[Daan Leijen]

Ashley Yakeley wrote:

  In article 
<[EMAIL PROTECTED]>,
 David Menendez <[EMAIL PROTECTED]> wrote:
  
  

  data Vec 0   a = Nil
data Vec s v a = Cons a (v a)
  

Some aliases for convenience:


  type Vec 1 = Vec s Vec 0
type Vec 2 = Vec s Vec 1
type Vec 3 = Vec s Vec 2
type Vec 4 = Vec s Vec 3
  

  
  
I don't understand this at all, and neither does GHC.
  

You seem to have lost the underscores :-)
It can be written without underscores as:

 data Vec0 a = Nil
 data VecS v a = Cons a (v a)

 type Vec1 = VecS Vec0
 type Vec2 = VecS Vec1


All the best,
 Daan Leijen

Btw. David: nice example of useful GADT use!




___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] announce: wxHaskell 0.9.4, windows bug fix release

[Daan Leijen]

Announcement: wxHaskell version 0.9.4, update 1
--
<http://wxhaskell.sourceforge.net>
This is a bugfix release of wxHaskell version 0.9.4 for Windows
platforms with GHC 6.4. The interpreter GHCi 6.4 now works with
wxHaskell without problems. Thanks to Sigbjorn Finne for fixing this
bug.
As always, first uninstall before re-installing:
- click on   "wxhaskell-0.9.4\bin\wxhaskell-unregister.bat"
- remove the "wxhaskell-0.9.4" directory
- unzip the new release
- click on   "wxhaskell-0.9.4\bin\wxhaskell-register.bat"
Have fun,
Daan Leijen.
--
wxHaskell is a portable GUI library for Haskell. The goal of the
project is to provide an industrial strength portable GUI library, but
without the burden of developing (and maintaining) one ourselves.
wxHaskell is therefore build on top of wxWidgets -- a comprehensive
C++ library that is portable across all major GUI platforms; including
GTK, Windows, X11, and MacOS X. Furthermore, it is a mature library
(in development since 1992) that supports a wide range of widgets with
native look-and-feel, and it has a very active community (ranked among
the top 25 most active projects on sourceforge).
Since most of the interface is automatically generated from the
wxEiffel binding, the current release of wxHaskell already supports
about 75% of the wxWindows functionality -- about 2900 methods in 500
classes with 1400 constant definitions.
wxHaskell has been build with GHC 6.x on Windows, MacOS X and
Unix systems with GTK. A binary distribution is available for Windows,
Linux (RPM) and MacOS X.
And even if you don't intend to write GUI's yourself, it will be fun
to check out the screenshots at <http://wxhaskell.sourceforge.net>.
--
Version 0.9.4-1
-
Bugfixes:
- Compile the wx library with -fvia-C. This prevents crashes in   
  GHCi-6.4.(Fix is found by Sigbjorn Finne)

Version 0.9.4
-
Backward compatible additions:
- Adapted the configuration, make files, and install scripts to work
 with GHC 6.4.
- Adapted the wxHaskell C-layer to work with wxWidgets 2.6.0
- Made "Object" an instance of Ord
Version 0.9
-
Non backward compatible changes:
- Changed "image" attribute to "picture"
Backward compatible additions:
- Added Multiple OpenGL Canvas example and fixed old example.
- Much improved process support in WXCore.Process. Use
 "processExecAsyncTimed" instead of "processExecASync".
- Full printing support in WXCore.Print
- Added SpintControl events.
- Fixed bug in MultiListBoxes where selections would only be
 added.
- Added "pixelBufferGetPixels" and "pixelBufferSetPixels" and
 according functions for images.
- Added "image" and made it an instance of the "Sized" class
 exported "imageCreateFromPixels" and "imageCreateFromPixelArray"
- Added "drawImage"
- Removed dependency on "readline" package in ghc 6.2.2
- Added "--cache" argument to configure script
Bug fixes:
- fixed "on command" event handlers in submenus.
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] announce: wxHaskell 0.9.4

[Daan Leijen]

Announcement: wxHaskell version 0.9.4
--
<http://wxhaskell.sourceforge.net>
I am pleased to announce a new release of wxHaskell.
This is mostly an update to support GHC 6.4 and it does not contain
any new features. Binary installers are provided for MacOS X, Linux
(RPM), and Windows.
Unfortunately, GHCi-6.4 does not work with wxHaskell. For Windows
platforms I still recommend GHC 6.2.2 since GHCi-6.2.2 works great
with wxHaskell (on Windows).
All the best,
Daan Leijen.
--
wxHaskell is a portable GUI library for Haskell. The goal of the
project is to provide an industrial strength portable GUI library, but
without the burden of developing (and maintaining) one ourselves.
wxHaskell is therefore build on top of wxWidgets -- a comprehensive
C++ library that is portable across all major GUI platforms; including
GTK, Windows, X11, and MacOS X. Furthermore, it is a mature library
(in development since 1992) that supports a wide range of widgets with
native look-and-feel, and it has a very active community (ranked among
the top 25 most active projects on sourceforge).
Since most of the interface is automatically generated from the
wxEiffel binding, the current release of wxHaskell already supports
about 75% of the wxWindows functionality -- about 2900 methods in 500
classes with 1400 constant definitions.
wxHaskell has been build with GHC 6.x on Windows, MacOS X and
Unix systems with GTK. A binary distribution is available for Windows,
Linux (RPM) and MacOS X.
And even if you don't intend to write GUI's yourself, it will be fun
to check out the screenshots at <http://wxhaskell.sourceforge.net>.
--
Version 0.9.4
-
Backward compatible additions:
- Adapted the configuration, make files, and install scripts to work
 with GHC 6.4.
- Adapted the wxHaskell C-layer to work with wxWidgets 2.6.0
- Made "Object" an instance of Ord
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Haskell workshop 2005: second call for papers.

[Daan Leijen]

[I apologize for cross-postings. Please forward to interested colleagues]
2005 Haskell Workshop
 Tallinn, Estonia, 30 September, 2005
  http://www.cs.uu.nl/~daan/hw2005
Second Call for papers
-- Important Dates ---
Submission deadline: June 10
Acceptance notification: July  5
Final version due  : July 19
Haskell workshop   : September 30
-- The Haskell Workshop --
The Haskell Workshop 2005 is an ACM SIGPLAN sponsored workshop 
affiliated with
the 2005 International Conference on Functional Programming (ICFP). Previous
Haskell Workshops have been held in La Jolla (1995), Amsterdam (1997), Paris
(1999), Montreal (2000), Firenze (2001), Pittsburgh (2002), Uppsala 
(2003), and
Snowbird (2004).

-- Scope -
The purpose of the Haskell Workshop is to discuss experience with 
Haskell, and
future developments for the language.  The scope of the workshop 
includes all
aspects of the design, semantics, theory, application, implementation, and
teaching of Haskell. Topics of interest include, but are not limited to, the
following:

* Language Design,
   with a focus on possible extensions and modifications of Haskell as 
well as
   critical discussions of the status quo;
* Theory,
   in the form of a formal treatment of the semantics of the present 
language
   or future extensions, type systems, and foundations for program 
analysis and
   transformation;
* Implementations,
   including program analysis and transformation, static and dynamic
   compilation for sequential, parallel, and distributed architectures, 
memory
   management as well as foreign function and component interfaces;
* Tools,
   in the form of profilers, tracers, debuggers, pre-processors, and so 
forth;
* Applications, Practice, and Experience,
   with Haskell for scientific and symbolic computing, database, 
multimedia and
   Web applications, and so forth as well as general experience with 
Haskell in
   education and industry;
* Functional Pearls,
   being elegant, instructive examples of using Haskell.

Papers in the latter two categories need not necessarily report original
research results; they may instead, for example, report practical experience
that will be useful to others, re-usable programming idioms, or elegant 
new ways
of approaching a problem. The key criterion for such a paper is that it 
makes a
contribution from which other practitioners can benefit. It is not 
enough simply
to describe a program!

If there is sufficient demand, we will try to organise a time slot for 
system or
tool demonstrations.  If you are interested in demonstrating a Haskell 
related
tool or application, please send a brief demo proposal to the program chair
([EMAIL PROTECTED]).

-- Submissions ---
Authors should submit papers in postscript or portable document format 
(pdf),
formatted for A4 paper, to Daan Leijen ([EMAIL PROTECTED]). The length should be
restricted to 12 pages in standard ACM SIG proceedings format. In 
particular,
LaTeX users should use the most recent sigplan proceedings style 
available from
the Haskell workshop web-site. Furthermore, the "abbrv" style should be 
used for
the bibliography. Accepted papers are published by the ACM and appear in 
the ACM
digital library.

Each paper should explain its contributions in both general and 
technical terms,
clearly identifying what has been accomplished, explaining why it is
significant, and comparing it with previous work. Authors should strive 
to make
the technical content of their papers understandable to a broad audience.

-- Program committee -
Martin Erwig Oregon State University
John Hughes  Chalmers University of Technology
Mark Jones   OGI School of Science and Engineering at OHSU
Ralf Lämmel  Microsoft Corp.
Daan Leijen  Universiteit Utrecht (Program Chair)
Andres Löh   Universiteit Utrecht
Andrew Moran Galois Connections Inc.
Simon Thompson   University of Kent
Malcolm Wallace  University of York
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Haskell Workshop 2005: Call for papers

[Daan Leijen]

[I apologize for cross-postings. Please forward to interested colleagues]
2005 Haskell Workshop
 Tallinn, Estonia, 30 September, 2005
  http://www.cs.uu.nl/~daan/hw2005
  Call for papers
-- Important Dates ---
Submission deadline: June 10
Acceptance notification: July  5
Final version due  : July 19
Haskell workshop   : September 30
-- The Haskell Workshop --
The Haskell Workshop 2005 is an ACM SIGPLAN sponsored workshop 
affiliated with
the 2005 International Conference on Functional Programming (ICFP). Previous
Haskell Workshops have been held in La Jolla (1995), Amsterdam (1997), Paris
(1999), Montreal (2000), Firenze (2001), Pittsburgh (2002), Uppsala 
(2003), and
Snowbird (2004).

-- Scope -
The purpose of the Haskell Workshop is to discuss experience with 
Haskell, and
future developments for the language.  The scope of the workshop 
includes all
aspects of the design, semantics, theory, application, implementation, and
teaching of Haskell. Topics of interest include, but are not limited to, the
following:

* Language Design,
   with a focus on possible extensions and modifications of Haskell as 
well as
   critical discussions of the status quo;
* Theory,
   in the form of a formal treatment of the semantics of the present 
language
   or future extensions, type systems, and foundations for program 
analysis and
   transformation;
* Implementations,
   including program analysis and transformation, static and dynamic
   compilation for sequential, parallel, and distributed architectures, 
memory
   management as well as foreign function and component interfaces;
* Tools,
   in the form of profilers, tracers, debuggers, pre-processors, and so 
forth;
* Applications, Practice, and Experience,
   with Haskell for scientific and symbolic computing, database, 
multimedia and
   Web applications, and so forth as well as general experience with 
Haskell in
   education and industry;
* Functional Pearls,
   being elegant, instructive examples of using Haskell.

Papers in the latter two categories need not necessarily report original
research results; they may instead, for example, report practical experience
that will be useful to others, re-usable programming idioms, or elegant 
new ways
of approaching a problem. The key criterion for such a paper is that it 
makes a
contribution from which other practitioners can benefit. It is not 
enough simply
to describe a program!

If there is sufficient demand, we will try to organise a time slot for 
system or
tool demonstrations.  If you are interested in demonstrating a Haskell 
related
tool or application, please send a brief demo proposal to the program chair
([EMAIL PROTECTED]).

-- Submissions ---
Authors should submit papers in postscript or portable document format 
(pdf),
formatted for A4 paper, to Daan Leijen ([EMAIL PROTECTED]). The length should be
restricted to 12 pages in standard ACM SIG proceedings format. In 
particular,
LaTeX users should use the most recent sigplan proceedings style 
available from
the Haskell workshop web-site. Furthermore, the "abbrv" style should be 
used for
the bibliography. Accepted papers are published by the ACM and appear in 
the ACM
digital library.

Each paper should explain its contributions in both general and 
technical terms,
clearly identifying what has been accomplished, explaining why it is
significant, and comparing it with previous work. Authors should strive 
to make
the technical content of their papers understandable to a broad audience.

-- Program committee -
Martin Erwig Oregon State University
John Hughes  Chalmers University of Technology
Mark Jones   OGI School of Science and Engineering at OHSU
Ralf Lämmel  Microsoft Corp.
Daan Leijen  Universiteit Utrecht (Program Chair)
Andres Löh   Universiteit Utrecht
Andrew Moran Galois Connections Inc.
Simon Thompson   University of Kent
Malcolm Wallace  University of York
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] announce: wxhaskell 0.9

[Daan Leijen]

Benjamin Franksen wrote:

  On Friday 25 February 2005 19:14, Daan Leijen wrote:
  
  
Announcement: wxHaskell version 0.9

  
  Could you (or anyone else) please give me a summary on how exactly I have to 
patch the makefile[.lib] so that I can compile this ghc-6.4? I found the 
discussion a bit confusing, because there were so many different issues...
  

Hi Ben,

I am working on a fresh release of wxHaskell that can be used with ghc
6.4. As you know,
there are some issues with the changed dependency output of ghc6.4 that
are not  quite
trivially solved. 

If you can't wait for the new release, try to contact Georg Martius who
has succeeded
compiling it with a pre-release of ghc 6.4.

All the best,
 Daan.


  
Thanx,
Ben
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
  




___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] announce: wxhaskell 0.9

[Daan Leijen]

Announcement: wxHaskell version 0.9
--
<http://wxhaskell.sourceforge.net>
I am pleased to announce a new release of wxHaskell.
This new release has support for the printing and much improved
support for processes and the grid control.
Binary installers are provided for MacOS X, Linux (RPM), and Windows,
for use with ghc 6.2.2.
Have fun,
 Daan Leijen.
--
wxHaskell is a portable GUI library for Haskell. The goal of the
project is to provide an industrial strength portable GUI library, but
without the burden of developing (and maintaining) one ourselves.
wxHaskell is therefore build on top of wxWidgets -- a comprehensive
C++ library that is portable across all major GUI platforms; including
GTK, Windows, X11, and MacOS X. Furthermore, it is a mature library
(in development since 1992) that supports a wide range of widgets with
native look-and-feel, and it has a very active community (ranked among
the top 25 most active projects on sourceforge).
Since most of the interface is automatically generated from the
wxEiffel binding, the current release of wxHaskell already supports
about 75% of the wxWindows functionality -- about 2900 methods in 500
classes with 1400 constant definitions.
wxHaskell has been build with GHC 6.x on Windows, MacOS X and
Unix systems with GTK. A binary distribution is available for Windows,
Linux (RPM) and MacOS X.
And even if you don't intend to write GUI's yourself, it will be fun
to check out the screenshots at <http://wxhaskell.sourceforge.net>.
--
Version 0.9
-
Non backward compatible changes:
- Changed "image" attribute to "picture"
Backward compatible additions:
- Added Multiple OpenGL Canvas example and fixed old example.
- Much improved process support in WXCore.Process. Use
  "processExecAsyncTimed" instead of "processExecASync".
- Full printing support in WXCore.Print
- Added SpintControl events.
- Fixed bug in MultiListBoxes where selections would only be
  added.
- Added "pixelBufferGetPixels" and "pixelBufferSetPixels" and
  according functions for images.
- Added "image" and made it an instance of the "Sized" class
  exported "imageCreateFromPixels" and "imageCreateFromPixelArray"
- Added "drawImage"
- Removed dependency on "readline" package in ghc 6.2.2
- Added "--cache" argument to configure script
Bug fixes:
- fixed "on command" event handlers in submenus.
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Proposal: Allow "\=" for field update in record update syntax

[Daan Leijen]

Benjamin Franksen wrote:
This library class defines the operations on a record:
class RecordField r l t | r l -> t where
  getField :: l -> r -> t
  putField :: l -> t -> r -> r
I have once written a short note about how Haskell'98 records could
be made more useful using a conservative extensions. The suggested
implementation method corresponds quite closely to what you sketch
here. Here is the url:

It should be interesting to read about the different tradeoffs of
extending the current record system, but keep in mind that this is a
just a quick writeup of ideas (and written two years ago!)
-- Daan.
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] A puzzle and an annoying feature

[Daan Leijen]

Lennart Augustsson wrote:
Daan Leijen wrote:
A "closed class" directive however is an explicit specification that
makes the intention of the designer explicit in the program. Since
it would solve the puzzle in a rather elegant and explicit way, I
thought that it was interesting to mention.
Indeed, a closed directive would have been fine.  But it's not really
necessary, the class is obviously closed because of not being exported.
But the type checker doesn't use this fact.
I find it somewhat anomalous that there is one unique way to give types
to my program, but that the type checker refuses to do it. :)
You are right, I feel like that too: one should expect that the type
checker can figure this out, and perhaps it is even really useful.
On the other hand, suppose you decide later to export the
class, and suddenly your code would no longer type check.
The fact that adding an export defintion would lead to a type
error somewhere else in the code might be rather confusing.
(worse! it might be considered inelegant :-)
Personally, I feel that this problem might be better solved by
making a lot of the implicit assumptions (and semantics) of type
classes more explicit, and bring them under user control. Of course,
I do have not have any idea of how this should be done concretely ;-)
(although type class directives might be a step in the right direction?)
-- Daan
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] A puzzle and an annoying feature

[Daan Leijen]

Keean Schupke wrote:
No, closed classes are different, here we are talking about lazy overlap 
resolution, so
if at _call_ time only one instance fits we choose it. Closing a class 
is different.
A "closed class" directive however is an explicit specification that
makes the intention of the designer explicit in the program. Since
it would solve the puzzle in a rather elegant and explicit way, I
thought that it was interesting to mention.
All the best,
 -- Daan.
   Keean.
Daan Leijen wrote:
Lennart Augustsson wrote:
[snip]
So in what sense is this really ambiguous?
I think it would be quite reasonable to allow the Puzzle module
to compile, resolving `a' to be Bool.  I.e., if there is only one
instance that can satisfy a constraint and there is no possibility
of adding instances outside the compiled module, I think resolving the
overloading makes sense.

You may be interested in a recent paper by Bastiaan Heeren and Juriaan
Hage [1] about type class directives. The "closed" directive in that 
paper is more or less implied by your example. Here is a quote from 
the paper:

"The main advantage of a closed type class is that we know the fixed 
set of instances. Using this knowledge, we can influence the type 
inference process. As discussed in the introduction to Section 2, we 
can reject definitions early on (in case the set of instances for a 
certain type class is empty) or improve a type variable to a certain 
type (in case the set of instances is a singleton)."

All the best,
 -- Daan Leijen.
[1] http://www.cs.uu.nl/~bastiaan/papers.html#typeclassdirectives
(to appear in PADL 2005)  

-- Lennart
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] A puzzle and an annoying feature

[Daan Leijen]

Lennart Augustsson wrote:
[snip]
So in what sense is this really ambiguous?
I think it would be quite reasonable to allow the Puzzle module
to compile, resolving `a' to be Bool.  I.e., if there is only one
instance that can satisfy a constraint and there is no possibility
of adding instances outside the compiled module, I think resolving the
overloading makes sense.
You may be interested in a recent paper by Bastiaan Heeren and Juriaan
Hage [1] about type class directives. The "closed" directive in that 
paper is more or less implied by your example. Here is a quote from the 
paper:

"The main advantage of a closed type class is that we know the fixed set 
of instances. Using this knowledge, we can influence the type inference 
process. As discussed in the introduction to Section 2, we can reject 
definitions early on (in case the set of instances for a certain type 
class is empty) or improve a type variable to a certain type (in case 
the set of instances is a singleton)."

All the best,
 -- Daan Leijen.
[1] http://www.cs.uu.nl/~bastiaan/papers.html#typeclassdirectives
(to appear in PADL 2005)

-- Lennart
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Create a List

[Daan Leijen]

Hi Jose,
Jose manuel Hernando Cobeña wrote:
-hello, I need to create a list of Colors, and I like do this:
list_colors <- varGet vColors

color_red  <- checkBox p [text := "Red",  checked := False, on command 
:= do aux red list_colors ]

where
   aux one_color list_colors =
 if (elem one_color list_colors)
 then do
varSet vColors (delete one_color list_colors)
 else do
varSet vColors (red:list_colors)

but the variable vColors no change and I can not create de list of colors.
You should pass the variable to the helper function -- not its value.
ie. this should work better:
...
colorRed <- checkBox p [text := "Red", on command := onRed red vColors]
...
where
  onRed color vColors
= vColors [value :~ \colors -> if (color `elem` colors)
then .. else color:colors]
I hope this helps,
 -- Daan.
ps. It is better to send wxHaskell related questions to
the [EMAIL PROTECTED] mailing list
instead of the Haskell list.
Thanks

Localiza a tus ex compañeros de clase o trabajo. Date de alta gratis 
aquí. 


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] image writing library

[Daan Leijen]

Ketil Malde wrote:
I would like to write an (Array (Int,Int) Int) to a file in some kind
of image format.  I implemented (quick and very dirty) XBM output, 
> [snip]
So, before I start,
does anybody know any other libraries or programs that could be used?
Hi Ketil,
You could use wxHaskell to write (and read) files in many different
formats (like png, bmp, tif, jpg, ico, xbm, etc). If you build from
CVS, you will find the function "imageGetPixelArray" and 
"imageCreateFromPixelArray" in the "Graphics.UI.WXCore.Image" module.

If you use the latest packaged 0.8 release, you will have to do with
the lower level "pixelBufferSet/GetPixel" functions.
Note that if you do not call "start", there is no GUI stuff
involved and you can just use the image conversion functions of 
wxHaskell in a console application.

Not a minimal solution, but maybe good enough for your purposes.
All the best,
 Daan.
ps. In a recent mail to shelarcy in the wxHaskell users mail archive
you can find a program that shows how to use the lower level pixelBuffer 
functions in wxHaskell 0.8:



___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Memo function help

[Daan Leijen]

Tom Hofte wrote:
I want to use the memo function for  implementing a dynamic programming 
algorithm in Haskell.
This is needed to cache intermediate results.
Can anyone tell me where I can find some examples that use the memo 
function or even a tutorial.
Hi Tom,
I like Byron Cook's paper about disposable memo functions:

-- Daan.

 
Thanks,
 
Tom Hofte


MSN Search, for accurate results! click here 



___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Announce: wxHaskell 0.8

[Daan Leijen]

Announcement: wxHaskell version 0.8
--
<http://wxhaskell.sourceforge.net>
I am pleased to announce a new release of wxHaskell. The library is
now 1 year old, and more than 4000 downloads further.
This new release has support for the powerful wxGrid control, managed
resources, and system colors. Futhermore, all object references are
now checked, raising a Haskell exception if they are not valid. The
MacOS X version is much more stable now than the previous release.
Binary installers are provided for MacOS X, Linux (RPM), and Windows.
The webpage has a screenshot of a heap profile viewer for GHC written
in wxHaskell by Wei Tan. There is also a *draft* version of an article
about the design of wxHaskell. I have to submit a final version this
Friday and any comments are very welcome.
All the best,
 Daan Leijen.
--
wxHaskell is a portable GUI library for Haskell. The goal of the
project is to provide an industrial strength portable GUI library, but
without the burden of developing (and maintaining) one ourselves.
wxHaskell is therefore build on top of wxWidgets -- a comprehensive
C++ library that is portable across all major GUI platforms; including
GTK, Windows, X11, and MacOS X. Furthermore, it is a mature library
(in development since 1992) that supports a wide range of widgets with
native look-and-feel, and it has a very active community (ranked among
the top 25 most active projects on sourceforge).
Since most of the interface is automatically generated from the
wxEiffel binding, the current release of wxHaskell already supports
about 75% of the wxWindows functionality -- about 2900 methods in 500
classes with 1400 constant definitions.
wxHaskell has been build with GHC 6.x on Windows, MacOS X and
Unix systems with GTK. A binary distribution is available for Windows,
Linux (RPM) and MacOS X.
And even if you don't intend to write GUI's yourself, it will be fun
to check out the screenshots at <http://wxhaskell.sourceforge.net>.
--
Version 0.8
---
Non backward compatible changes:
- Added wildcards argument to the "fileSaveDialog" function.
- Removed the call to "buttonSetDefault" in the "defaultButton"
  property since GTK seems to enlarge the button in that case.
- Removed alignment argument for text controls
- Removed sorted and labels argument for choice and combo boxes.
- Removed sorted argument for listboxes.
- Added default "stretch" to every toplevel layout, assuring that
  such layout gets at least all available space assigned.
- (un)set "maximize box" when "resizeable" is set.
- Removed default "wxTAB_TRAVERSAL" style on frames (to make the grid
  work correctly).
- Renamed "WXCore.WxcClassTypes" to "WXCore.WxcClassInfo".
Backward compatible additions:
- Added pure "bitmap" and "sound"
- Added "variable" objects (mutable variables)
- Added custom control demo.
- Made "refresh" erase the background too.
- Added "children" attribute for windows.
- Added "border" attribute for windows.
- Added "tabTraversal" attribute for windows.
- Added wxGrid events and demo (samples/wx/Grid.hs).
- Improved signatures for wxGrid.
- Added "changes.txt" file :-)
- Added "HAS_RADIO_MENU_ITEMS" to "isDefined".
- Added support for radio menu items.
- New wxHaskell+HOpenGL sample added to the contributions. Thanks
  to Shelarcy and Sean Seefried.
- Added "Align" and "Wrapped" classes to set alignment
  and wrap mode for text controls.
- Added "Sorted" class to set the sort mode of choice, combo box,
  and listbox controls.
- Added "creation time" attributes that use reflective attributes
  not compositional (and thus not so nice), but very convenient!
- Added "entry" as shorthand for "textEntry"
- Added "SystemColor" and "colorSystem" to get standard system colors.
- Defaulted background color of "Frame"s to Color3DFace (as a Panel).
- Made the definition of "Closure" in "wrappers.h" more liberal to
  support wxOCaml better.
- Added "frameCentre" method
- Huge internal changes: split up wxcClasses in three files and added
  support for managed objects like bitmaps. Also added checks for NULL
  pointers.
Bug fixes:
- HtmlLinkClicked events are now properly generated.
- Fixed bug that crashed wxHaskell when a tree control had the focus
  and a key was pressed. Thanks to Olivier Spier for sending a fix.
- The "item" attribute of a list control always returned the first
  item and disregarded the parameter. Thanks to Olivier Spier for
  sending a fix.

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Announce: wxHaskell 0.8

[Daan Leijen]

Announcement: wxHaskell version 0.8
--
<http://wxhaskell.sourceforge.net>
I am pleased to announce a new release of wxHaskell. The library is
now 1 year old, and more than 4000 downloads further.
This new release has support for the powerful wxGrid control, managed
resources, and system colors. Futhermore, all object references are
now checked, raising a Haskell exception if they are not valid. The
MacOS X version is much more stable now than the previous release.
Binary installers are provided for MacOS X, Linux (RPM), and Windows.
The webpage has a screenshot of a heap profile viewer for GHC written
in wxHaskell by Wei Tan. There is also a *draft* version of an article
about the design of wxHaskell. I have to submit a final version this
Friday and any comments are very welcome.
All the best,
 Daan Leijen.
--
wxHaskell is a portable GUI library for Haskell. The goal of the
project is to provide an industrial strength portable GUI library, but
without the burden of developing (and maintaining) one ourselves.
wxHaskell is therefore build on top of wxWidgets -- a comprehensive
C++ library that is portable across all major GUI platforms; including
GTK, Windows, X11, and MacOS X. Furthermore, it is a mature library
(in development since 1992) that supports a wide range of widgets with
native look-and-feel, and it has a very active community (ranked among
the top 25 most active projects on sourceforge).
Since most of the interface is automatically generated from the
wxEiffel binding, the current release of wxHaskell already supports
about 75% of the wxWindows functionality -- about 2900 methods in 500
classes with 1400 constant definitions.
wxHaskell has been build with GHC 6.x on Windows, MacOS X and
Unix systems with GTK. A binary distribution is available for Windows,
Linux (RPM) and MacOS X.
And even if you don't intend to write GUI's yourself, it will be fun
to check out the screenshots at <http://wxhaskell.sourceforge.net>.
--
Version 0.8
---
Non backward compatible changes:
- Added wildcards argument to the "fileSaveDialog" function.
- Removed the call to "buttonSetDefault" in the "defaultButton"
  property since GTK seems to enlarge the button in that case.
- Removed alignment argument for text controls
- Removed sorted and labels argument for choice and combo boxes.
- Removed sorted argument for listboxes.
- Added default "stretch" to every toplevel layout, assuring that
  such layout gets at least all available space assigned.
- (un)set "maximize box" when "resizeable" is set.
- Removed default "wxTAB_TRAVERSAL" style on frames (to make the grid
  work correctly).
- Renamed "WXCore.WxcClassTypes" to "WXCore.WxcClassInfo".
Backward compatible additions:
- Added pure "bitmap" and "sound"
- Added "variable" objects (mutable variables)
- Added custom control demo.
- Made "refresh" erase the background too.
- Added "children" attribute for windows.
- Added "border" attribute for windows.
- Added "tabTraversal" attribute for windows.
- Added wxGrid events and demo (samples/wx/Grid.hs).
- Improved signatures for wxGrid.
- Added "changes.txt" file :-)
- Added "HAS_RADIO_MENU_ITEMS" to "isDefined".
- Added support for radio menu items.
- New wxHaskell+HOpenGL sample added to the contributions. Thanks
  to Shelarcy and Sean Seefried.
- Added "Align" and "Wrapped" classes to set alignment
  and wrap mode for text controls.
- Added "Sorted" class to set the sort mode of choice, combo box,
  and listbox controls.
- Added "creation time" attributes that use reflective attributes
  not compositional (and thus not so nice), but very convenient!
- Added "entry" as shorthand for "textEntry"
- Added "SystemColor" and "colorSystem" to get standard system colors.
- Defaulted background color of "Frame"s to Color3DFace (as a Panel).
- Made the definition of "Closure" in "wrappers.h" more liberal to
  support wxOCaml better.
- Added "frameCentre" method
- Huge internal changes: split up wxcClasses in three files and added
  support for managed objects like bitmaps. Also added checks for NULL
  pointers.
Bug fixes:
- HtmlLinkClicked events are now properly generated.
- Fixed bug that crashed wxHaskell when a tree control had the focus
  and a key was pressed. Thanks to Olivier Spier for sending a fix.
- The "item" attribute of a list control always returned the first
  item and disregarded the parameter. Thanks to Olivier Spier for
  sending a fix.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Re: Initialisation without unsafePerformIO

[Daan Leijen]

On Fri, 04 Jun 2004 00:35:14 -0700, Ashley Yakeley <[EMAIL PROTECTED]> wrote:
In article <[EMAIL PROTECTED]>,
 John Meacham <[EMAIL PROTECTED]> wrote:
I am a fan of allowing top level declarations of the form:
foo <- newIORef "foo"
which would behave as an initializer, with the semantics being that it
be evaluated at most once before foos first use. (so it could be
implemented via unsafePerformIO or as an init section run before main).
The
{-# NOINLINE foo #-}
foo = unsafePeformIO $ newIORef "foo"
idiom is so common and useful, it should have some compiler support. It
is 'clean' too, since all we are doing is extending the "world" with new
state, but in a much cleaner/safer way then writing to a file or environment
variable or other methods of storing state in the world.
Clean it is not:
foo :: a
foo <- newIORef undefined
writeChar :: Int -> IO ()
writeChar x = writeIORef foo x
readString :: IO String
readString = readIORef foo
cast :: Char -> IO String
cast c = (writeChar c) >> readString
If we check that the type of "foo" is monomorphic,
this is no longer unsafe.
-- Daan.

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Announce: wxHaskell 0.7

[Daan Leijen]

Announcement: wxHaskell version 0.7
--
<http://wxhaskell.sourceforge.net>

This new release contains bug fixes, a few new widget attributes, and
has an improved build system for MacOS X and Linux. Binary installers
are provided for MacOS X, Linux (RPM), and Windows.
The webpage has some nice screenshots now of larger applications that
are written with wxHaskell, and a sample of wxHaskell with HOpenGL.
There is also a Wiki site for wxHaskell now.
All the best,
 Daan.
--
wxHaskell is a portable GUI library for Haskell. The goal of the
project is to provide an industrial strength portable GUI library, but
without the burden of developing (and maintaining) one ourselves.
wxHaskell is therefore build on top of wxWidgets -- a comprehensive
C++ library that is portable across all major GUI platforms; including
GTK, Windows, X11, and MacOS X. Furthermore, it is a mature library
(in development since 1992) that supports a wide range of widgets with
native look-and-feel, and it has a very active community (ranked among
the top 25 most active projects on sourceforge).
Since most of the interface is automatically generated from the
wxEiffel binding, the current release of wxHaskell already supports
about 75% of the wxWindows functionality -- about 2900 methods in 500
classes with 1400 constant definitions.
wxHaskell has been build with GHC 6.x on Windows, MacOS X and
Unix systems with GTK. A binary distribution is available for Windows,
Linux (RPM) and MacOS X.
And even if you don't intend to write GUI's yourself, it will be fun
to check out the screenshots at <http://wxhaskell.sourceforge.net>.
All the best,
  Daan Leijen.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] RFC: DData in hierarchical libraries

[Daan Leijen]

Hi Christian,

(Some have already replied, but I'll say some more about some issues)

On Mon, 08 Mar 2004 12:32:21 +0100, Christian Maeder <[EMAIL PROTECTED]> wrote:

Set.toAscList is not really necessary as it is the same as Set.toList.
Not necessarily: the lists from Set.toList will be equal for equal Set's, but
may be unordered. Use "toAscList" or "toDescList" if you want an ordered variant.
Now, my *implementation* might use "toAscList" for "toList", but that is a separate 
issue.

The functions Set.fromAscList and Set.fromAscDistinctList should be marked as "unsafe"
I think so too, although I like "unchecked" better?

Furthermore, already for Set.fromList I expect it to be linear, if the input list happens to be ascending.
That is not the case yet -- making it linear might be possible but
one has to be very careful about "lost" laziness in that case..
For finite, strict lists, one can of course just check if the list
is ordered in linear time and use "fromAscList" if that is the case.
The same argument about "ordered lists" apply to the Map module. In addition, it would be nice if there were a variant of "Map.keys" that returns a set of keys, since the invariant that the keys are ascending and distinct may easily get lost, if not captured by the Set type.
That seems a good thing. Let's add it.

A straight forward implementation is:

Map.keySet = Set.fromDistinctAscList . Map.keys

The use of "Set.fromDistinctAscList" is safe in this case, but - alas - Map needs to import Set. (But maybe there is even a faster implementation of Map.keySet that exploits the internal representation.)
Yes, we could do that -- but the circular dependency is terrible, and a wrapper 
module
would need to look at the internal representation of Map/Set :-(
-- Daan.

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [wxhaskell-users] Re: [Haskell] Announce: wxHaskell 0.6

[Daan Leijen]

Dear Gour,

On Wed, 3 Mar 2004 12:58:53 +0100, Gour <[EMAIL PROTECTED]> wrote:
(Again), I have one suggestion for wxHaskell: to combine doc & src packages
into one - wxhaskell-x-xx.
The documentation is generated from the source, so there is no need to include it.
Furthermore, the binary releases include documentation nowadays. The doc package
is just provided for those that don't have haddock or don't want to build the
documentation themselves.
I was playing during the 0.30.4 but could not solve sandbox problem since
wxhaskell writes into /usr/lib.
This is easily solved by giving the "--prefix" option to configure. See
the "building" page on the wxHaskell website. (wxhaskell normally installs
whereever you install wxWidgets).
Although having said that, I can't get wxHaskell stuff to link properly
on my Gentoo box at the moment, probably because my OpenGL setup is
rather broken.
You would only get openGL link errors if you build wxWidgets with 
"--with-glcanvas",
leaving out that option will drop support of the openGL canvas and link properly.
There also was a recent post on wxhaskell-users regarding openGL linking with more
recent wxWidget versions that might solve your link problems too.
Thanks for trying wxHaskell,
Sincerely,
 Daan.
ps. Let's take this discussion to "wxhaskell-users".

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] definition of intersperse

[Daan Leijen]

On Tue, 02 Mar 2004 16:59:48 -0800, Iavor S. Diatchki <[EMAIL PROTECTED]> wrote:
i'd like to suggest that the definition of "intersperse" from the List module be made more lazy.
Good thing, I think that library functions should always be as lazy as possible
in their observeable interface (or well documented why they aren't)
intersperse :: a -> [a] -> [a]
intersperse _   []  = []
intersperse sep (x:xs)  = x : rest
  where rest [] = []
rest xs = sep : intersperse sep xs
I don't like the generic name "rest" so much, and the function is not
as efficient as it could be due to too much matching -- what about:
intersperse:: a -> [a] -> [a]
intersperse sep [] = []
intersperse sep (x:xs) = x : prefix sep xs
prefix:: a -> [a] -> [a]
prefix sep [] = []
prefix sep (x:xs) = sep : x : prefix sep xs


-- Daan.

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Announce: wxHaskell 0.6

[Daan Leijen]

Announcement: wxHaskell version 0.6
--
<http://wxhaskell.sourceforge.net>

This new release fixes many bugs, adds basic support for MDI
applications and compiles with the latest CVS snapshots of wxWidgets.
For now, only an installer for windows is provided.
All the best,
 Daan.
News (see the wxHaskell website for more information):
- wxWindows is now called wxWidgets! (and yes, it is due to Microsoft :-)
- wxWidgets runs on mobile phones (Symbian OS).
- Borland Builder-X will ship with wxWidgets as its windowing toolkit.
Updates:
- Support for MDI applications
- Combobox now catches enter keys through "on command"
- Many list-like controls now react on "on select" instead of "on command"
- Attribute "enable" is now called "enabled"
- Resize bugs are fixed,  new "dynamic" layout combinator added
- Repaint bugs are fixed, new "fullRepaintOnResize" attribute added.
- Basic support for unicode fonts (see the screenshots page)
Tested on:
- windowsXP and windows 2000 with ghc 6.2, 6.0.1, and wxMSW 2.4.2
- MacOS X 10.3 (Panther) with ghc 6.2 and wxMAC 2.5.1 (20 feb 2004)
- MacOS X 10.2 (Jaguar) with ghc 6.0.1 and wxMAC 2.4.2
- Red Hat Linux 10 (Fedora) with ghc 6.2
- FreeBSD, with ghc 5.05. and wxGTK 2.4.1
- and wxHaskell has been known to run on other platforms :-)
--
wxHaskell is a portable GUI library for Haskell. The goal of the
project is to provide an industrial strength portable GUI library, but
without the burden of developing (and maintaining) one ourselves.
wxHaskell is therefore build on top of wxWidgets -- a comprehensive
C++ library that is portable across all major GUI platforms; including
GTK, Windows, X11, and MacOS X. Furthermore, it is a mature library
(in development since 1992) that supports a wide range of widgets with
native look-and-feel, and it has a very active community (ranked among
the top 25 most active projects on sourceforge).
Since most of the interface is automatically generated from the
wxEiffel binding, the current release of wxHaskell already supports
about 75% of the wxWindows functionality -- about 2900 methods in 500
classes with 1400 constant definitions.
wxHaskell has been build with GHC 6.x on Windows, MacOS X and
Unix systems with GTK. A binary distribution is available for Windows
and MacOS X.
And even if you don't intend to write GUI's yourself, it will be fun
to check out the screenshots at <http://wxhaskell.sourceforge.net>.
All the best,
  Daan Leijen.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Parsec question: attempted 'notMatching' combinator

[Daan Leijen]

On Wed, 18 Feb 2004 01:11:31 -0500, Andrew Pimlott <[EMAIL PROTECTED]> wrote:
After some pondering and fiddling, a version I like:

notFollowedBy' :: Show a => GenParser tok st a -> GenParser tok st ()
notFollowedBy' p= join $  do a <- try p; return (unexpected (show a))
  <|>
  return (return ())
Great work. Do you think that the library function should
be fixed with this version? (or can you check it in yourself?)
-- Daan.

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Impredicative Types?

[Daan Leijen]

On Tue, 17 Feb 2004 14:40:18 -0800, Ashley Yakeley <[EMAIL PROTECTED]> wrote:
 Ben Rudiak-Gould <[EMAIL PROTECTED]> wrote:

> Bear in mind you can't even write IO (forall t. whatever) in Haskell.

True, but why is this? Is there a deep reason why we can use nested
foralls as the arguments to (->), but not as the arguments to any other
type constructor?
Apparently it makes type-checking Very Very Hard. Simon PJ may have
explained it to me ("impredicative", he called it), but I don't remember
offhand.
Whenever you instantiate type variables with type schemes, you are impredicative.
Impredicative instantiation makes type checking (much) harder -- without extra
constraints, you don't even have principal types. i.e.
choose :: a -> a -> a
choose x y = x
What is the type of "choose id" if your system is impredicative?
Either "forall a. (a -> a) -> (a -> a)"  or "(forall a. a->a) -> (forall a. a->a)"
Note that neither of these types subsumes the other.
This is why MLF adds extra constraints which enables them to give a principle
type to this expression. (namely: forall a. (a >= forall a. a -> a) => a -> a)
Anyway, Ben Rudiak's particular case, namely instantiating arguments of a
type with type schemes, is difficult due to another problem. It is very
hard to know whether an argument to a type is used contra-variantly or co-variantly
(or both, or not at all). This means that we can't do a proper subsumption
check on type schemes. i.e.
data Contra a  = Contra (a -> Int)
data Co a  = Co (Int -> a)
data None a= None
data Both a= Contra (a -> Int) | Co a
In this case it may seem trivial to infer the contra/co variance of the argument
but try this with some type constructors as arguments :-) In a particular case
one can give type rules of course, for example for tuples or the IO monad.
All the best,
 Daan.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Announce: wxhaskell 0.5

[Daan Leijen]

Announcement: wxHaskell version 0.5
--
<http://wxhaskell.sourceforge.net>

This is patch-level release against ghc 6.2, and I also added support
for Html window events.
All the best,
 Daan.
--
wxHaskell is a portable GUI library for Haskell. The goal of the
project is to provide an industrial strength portable GUI library, but
without the burden of developing (and maintaining) one ourselves.
wxHaskell is therefore build on top of wxWindows -- a comprehensive
C++ library that is portable across all major GUI platforms; including
GTK, Windows, X11, and MacOS X. Furthermore, it is a mature library
(in development since 1992) that supports a wide range of widgets with
native look-and-feel, and it has a very active community (ranked among
the top 25 most active projects on sourceforge).
Since most of the interface is automatically generated from the
wxEiffel binding, the current release of wxHaskell already supports
about 75% of the wxWindows functionality -- 2878 methods in 513
classes with 1347 constant definitions.
wxHaskell has been build with GHC 6.x on Windows, MacOS X and
Unix systems with GTK. A binary distribution is available for Windows
and MacOS X.
And even if you don't intend to write GUI's yourself, it will be fun
to check out the screenshots at <http://wxhaskell.sourceforge.net>.
All the best,
  Daan Leijen.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Parsec] Extracting line and column numbers

[Daan Leijen]

What about these?

  sourceColumn :: SourcePos -> Column
  sourceLine :: SourcePos -> Line
These signatures are missing in the source, therefore they are not listed in the documentation generated by haddock.
I'll fix this in the Parsec sources, so the GHC 6.2+ will have it.
Maybe I'll even get around to documenting Parsec with Haddock comments some day...
-- Daan.

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: from array update algorithm to nice Haskell code

[Daan Leijen]

Hi Wolfgang,

I think that you are mixing up worst case bounds O(..) with some specific
case. I guess that you mean by "O(1) elements" a known and constant number
of elements.
I mean a constant maximum number of elements.  An example would be that the
set b is guaranteed to have not more than one element.
Ah, I think I have the gist of your message now. For DData.Set, the
worst case bound for intersect is O(n+m), however, for your particular
case, it will behave as you want. i.e. for an intersection where one
of the sets is empty, it will run in constant time; for an intersection
where one of the sets has one element, it will take at most O(log n) time
(where n is the number of elements in the other set). This is again a
worst case bound: if n is zero (the empty set), it will be a constant
time operation. Even stronger, if you ask for the intersection of two large
sets that have no common elements, the operation will take (log n + log m) time.
Still, in the worst case, where both trees have about the same size and the
same kind of elements, the algorithm will degenerate to O(n+m). (btw. this is not
the case when you would simply iterate over one set and test membership of
the other (= O(m*log n)))
I am not entirely sure if this also holds for Data.Set, but I guess it is
the same. A small issue is that it *does* pay off to swap the arguments if
their size differs (just as in your list example), and I don't know
if Data.Set does that -- you should look in the CVS sources to find out.
If you think that application to the sets with single values happens often,
maybe I should add some special-case code to make this more (absolutely) efficient.
All the best,
 Daan.


However, in the worst case, this will degenerate to some "m" number of
elements, and your function would take O(m*log n) time, i.e. much worse than
O(n+m).
I don't understand this.  If m doesn't depend on any input values but is
really constant then O(m * log n) = O(log n)âregardless of how large m is.
Well, the specification of O(n + m) time does only say that the time is less
than c * (n + m) of some constant c which is no contradiction to an O(log n)
time.  But it leaves the possibility open that the calculation really needs
linear time.
All the best,
  Daan.

[...]
Wolfgang

[1] SchÃning, Theoretische Informatik â kurzgefasst, Spektrum Akademischer
Verlag
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell



___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: from array update algorithm to nice Haskell code

[Daan Leijen]

Now assume that I have a set a with O(n) elements and a set b with O(1)
elements.
You can't have "O(1) elements" ... (A bound like O(..) talks about
the worst case time/space of an operation.)
a `minusSet` b would take O(n) time and so would a `intersect` b.
If I'd use
foldr (flip delFromSet) a (setToList b)
and
[x | x <- setToList b, x `elementOf` a]
instead of a `minusSet` b and a `intersect` b, I would get away with O(log n)
time.
I think that you are mixing up worst case bounds O(..) with some specific case.
I guess that you mean by "O(1) elements" a known and constant number of elements.
However, in the worst case, this will degenerate to some "m" number of
elements, and your function would take O(m*log n) time, i.e. much worse
than O(n+m).
All the best,
 Daan.
Is this true?

Wolfgang

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: Combining distinct-thread state monads?

[Daan Leijen]

Hi Mark,

The state transformer approach seems to have
advantageous in that it provides a framework for
building new monads from old, and accessing the
components.  One disadvantage is that it lacks
symmetry in that one monad is arbitrarily chosen
to sit inside the other.
You may want to read "composing monads" by Mark Jones
and Luc Duponcheel. It specifies precisely what kind
of laws should hold before monads can be composed.
(and indeed, it also shows that not all monads are
symetrical and can be arbitrarily composed!)
<http://www.cse.ogi.edu/~mpj/pubs/composing.html>

All the best,
 Daan Leijen.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: Working haskell/db+hugs set?

[Daan Leijen]

Hi Kyra,

Trying to play with haskell/db, I've found myself being a little bit stuck.

The latest version of hugs haskell/db (as referenced from
http://www.haskell.org/haskellDB/download.html) works with seems to be of
May 1999. I cannot find any references to this version of hugs except
http://www.cs.uu.nl/~daan/download/hugs98may.exe which is broken.
Sorry for causing this inconvenience - maybe I should remove the webpage...
However, haskellDB is fairly old and was also the start of a framework for
typeful database  programming. It uses the TREX extension though that never
has been implemented in GHC and other Haskell systems. Furthermore, Haskell
wasn't as good as it is now with foreign libraries. Therefore, I still provide
the old Hugs 1998 may version just to enable people to play with it.
As Bjorn said, the good news is that people at Chalmers try to update haskellDB for
use in current Haskell's -- probably using functional depencies with repeated
catesian products to emulate TREX-like functionality. Maybe they can provide
you with a prototype version?
All the best,
 Daan.

Is it possible to find somewhere in the net all neccessary components (older
hugs, newer haskelldb, whatever...) to run any haskelldb example?
With best regards
and
Happy New Year!
Kyra

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: from array update algorithm to nice Haskell code

[Daan Leijen]

On Wed, 31 Dec 2003 12:35:23 +0100, Wolfgang Jeltsch <[EMAIL PROTECTED]> wrote:

The documentation of DData.Map states the following as an advantage of
DData.Map over Data.FiniteMap:
It uses the efficient hedge algorithm for both union and difference [...].
Does this mean that the Data.FiniteMap functions for union and difference
don't have an O(n + m) complexity as the DData.Map functions have?
No. Even though a "hedge" algorithm is generally more efficient, it doesn't
change the complexity class -- just the absolute efficiency. According to
measurements done by Stephen Adams, it is about 20% faster (for strict programs).
In my experience, the absolute efficiency is pretty important, especially for
small data sets and Haskell :-), for example, for small data sets, a simple list
is more efficient than a Set data type in many common situations.
Therefore, you will only notice the difference for "hedge" unions when you
use large data sets.
-- Daan.


[...]
Wolfgang

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: from array update algorithm to nice Haskell code

[Daan Leijen]

Hi Wolfgang,

is there some documentation about the complexity of the FiniteMap and Set operations?
My DData library gives some useful links to papers about this subject, also
take a look at the "IntSet" and "IntMap" libraries as they have an interesting
complexity class. Also, all DData functions have their complexity listed in the 
documentation.
See: 

The operations in the "Data.FiniteMap" library in Ghc have the same complexity
of the operations in the "DData.Map" library. The "Data.Set" library in Ghc is
based on the FiniteMap library (and thus has the same complexity)
On Tue, 30 Dec 2003 23:14:05 +0100, Wolfgang Jeltsch <[EMAIL PROTECTED]> wrote:
I have an algorithm which updates one or more arrays in a loop.  The update
operations depend on the (old) contents of the arrays, so I cannot use
accumArray.  I want to implement this algorithm without mutable arrays in
Haskell.  Are there any possibilities to do so efficiently?  Are there some
hints about how to do this?
Storing the incremental changes might be a good options. You can get this
somewhat automatically by using (lazy) balanced trees -- every insertion/update will
only copy the changed 'path' in the tree, giving you a logarithmic copy time
while being persistent (maintaining all old versions).
-- Daan.

Wolfgang

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Why are strings linked lists?

[Daan Leijen]

Hi Graham,
 
> I tried to track that down (for a colleague), but the link at:
>http://www.cs.uu.nl/helium/documentation.html
> to:
>http://www.cs.uu.nl/~daan/papers/lvm.pdf
> is broken, and I can't find any other references.

Sorry for the broken link. The LVM is described in
the last chapter of my thesis which can be found on
my home page (http://www.cs.uu.nl/~daan)

-- Daan.
 
> #g
> 
> 
> 
> Graham Klyne
> For email:
> http://www.ninebynine.org/#Contact
> 
> ___
> Haskell mailing list
> [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
> 
> 


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: set representation question

[Daan Leijen]

Hi Hal,

On Tue, 11 Nov 2003 16:45:56 -0800 (PST), Hal Daume III <[EMAIL PROTECTED]> 
wrote:

i'm looking for a representation for a set of natural numbers.  right 
now, my representation is sorted array, which works well.  *all* i care 
about
is being able to quickly calculate the size of the intersection of two
sets.  these sets are, in general, very sparse, which means that the
intersections tend to be small.
I have a very speedy implementation of "Int" sets based on
big-endian patricia trees in the DData library at:


You can just pull out the "IntSet.hs" and start using it.

One warning though, it is a general implementation and you might
get better performance using a hand-tuned data structure that is
adapted to your problem set (but than, you might not, since I
paid lots of attention to the bit efficiency of the library ;-)
All the best,
 Daan.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Announce: wxHaskell 0.4

[Daan Leijen]

Announcement: wxHaskell version 0.4 
--

<http://wxhaskell.sourceforge.net>

The main addition of this new release is extensive support for ODBC 
database access. This is currently only tested on windows and not yet 
supported on MacOS X. Further additions: many GUI improvements for 
MacOS X, resize issues have been fixed, new functionality to 
manipulate pixel buffers, and support for OpenGL windows (untested yet 
with HOpenGL... we are looking for volunteers :-).

--
wxHaskell is a portable GUI library for Haskell. The goal of the 
project is to provide an industrial strength portable GUI library, but 
without the burden of developing (and maintaining) one ourselves. 

wxHaskell is therefore build on top of wxWindows -- a comprehensive 
C++ library that is portable across all major GUI platforms; including 
GTK, Windows, X11, and MacOS X. Furthermore, it is a mature library 
(in development since 1992) that supports a wide range of widgets with 
native look-and-feel, and it has a very active community (ranked among 
the top 25 most active projects on sourceforge).

Since most of the interface is automatically generated from the 
wxEiffel binding, the current release of wxHaskell supports 
about 85% of the wxWindows functionality -- 2878 methods in 513
classes with 1347 constant definitions.

wxHaskell has been build with GHC 6.01 on Windows, MacOS X and 
Unix systems with GTK. A binary distribution is available for Windows 
and MacOS X. 

And even if you don't intend to write GUI's yourself, it will be fun 
to check out the screenshots at <http://wxhaskell.sourceforge.net>.

All the best,
  dr. :-)  Daan Leijen.

 


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Haskell on the cover of a magazine!

[Daan Leijen]

wxHaskell gets a two-page article in the october edition 
of the popular French PC magazine, L'Informaticien. 

The article is written by Frédéric Mazué, and gives an
overview of wxWindows, wxHaskell, and compares the library 
against F# (the OCaml integration to .NET).

For screenshots of the relevant pages, see:

 http://wxhaskell.sourceforge.net/screenshots.html#linformaticien

Just think of all those thousands of French O'Caml programmers 
that will suddenly start to use Haskell ;-)

All the best,
 Daan Leijen.


"wxHaskell est un outil d'ores et déjà remarquable et d'une 
grande fiabilité. Examinons de plus près ce dont il s'agit."

"En raison de toutes ses qualités, la popularité de Haskell
va donc croissant"


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: implement hash table

[Daan Leijen]

> > [EMAIL PROTECTED] wrote:
> > >
> > > ... hash table in my data structure, can some one tell me how to
implement 
> > > it? I can't find much information about it.
> > >
> > > Thanks a lot
> > >
> > > Rui
> >
> > http://www.haskell.org/ghc/docs/6.0/html/base/Data.HashTable.html
> 
> There is also the FiniteMap data type which may also please you:
> http://www.haskell.org/ghc/docs/6.0/html/base/Data.FiniteMap.html
> 

And maybe a fast integer finite map may please you even more:

http://www.cs.uu.nl/~daan/ddata.html


-- Daan Leijen


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: [GUI] Announce: wxHaskell 0.2

[Daan Leijen]

> Thanks for the release.  0.2 seems to build much better on Linux. :)
> I built an rpm package with ghc-6.0.1 for wxGTK2 and put it at

Thanks! I'll try it out and put it on sourceforge (if that 
is ok with you). I also like your naming scheme, I guess I should
also include the ghc version and processor in the name of binary
releases.  (btw. what does the extra "-2" mean in the version?
(like wxhaskell-ghc6.0.1-0.2-2.i386.rpm)

-- Daan




> 
http://juhp.dyndns.org/jens/haskell/

for now.  They should be available from later

http://haskell.org/~petersen/rpms/wxhaskell/

(current public_html seems to be disabled on haskell.org).

Jens
___
GUI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/gui



___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Announce: wxHaskell 0.2

[Daan Leijen]

Hi Sven,

(I'll reply to the portability issues in a separate mail)

>   * It would be nice if the directory created by unzipping 
> wxhaskell-src-0.2.zip  contained a version number.
> 
>   * It would be even nicer if wxhaskell-doc-0.2.zip unzipped 
> into a *single*  directory.
> 
>   * You need `-package parsec' for linking wxdirect nowadays.

Thanks for the hints. I'll look into it for a future version.
I will not actively support CVS GHC's though -- that will be too much
work :-)

>   * When HelloWorld terminates, it segfaults in wxVariant()'s 
> destructor. I have no idea what's going on here, but I can only repeat
my 
> warnings stated some time ago: Mixing a C++ library with pure C (=
GHC's code) 
> is a highly  delicate, platform/compiler dependent and fragile thing
to do...

I am quite sure that this has nothing to do with C vs. C++ :-)
(I am not linking at all with C++ directly -- instead I am using extern
C
wrappers that are used in a separate dynamic link library with their own
C++ runtime system. This is just like calling any other systems library.
)

The segfault is really weird though -- it might be that you started
"main" twice
from GHCi (a known bug in wxGTK), that your GHC is broken, that you use
an
old GTK, anything really :-(

>   * The package configuration should include linker flags for 
> the path of libwxc.so, otherwise a non-superuser has to fiddle around
with
> LD_LIBRARY_PATH and the like.

I am fairly hesitant here -- this means that I need two different
package
description files -- one for binary installs and one for developer
installs.
I'll look into it, but since I am not a real unix wizard, maybe you can
tell me offline what you exactly need/want.

All the best,
 Daan.


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Announce: wxHaskell 0.2

[Daan Leijen]

Hi Sven,

> the library documentation says: "Portability: 
> portable", but this is not the case at all, wxHaskell uses 
> quite a few extensions (apart from the FFI, which can be 
> considered portable nowadays):

wxHaskell consists of two layers: WXCore and WX.

The WXCore layer is supposed to be totally Haskell98 compatible
(or really easy to make compatible).

The WX layer is a nice haskellized version of the wxWindows
API on top of WXCore that uses extensions.

>   * wxcore/src/Graphics/UI/WXCore/IntMap.hs fiddles around 
> with unboxed values and GHC interna for performance reasons. Is this 
> really necessary?   (Apart from that, it triggers a bug in GHC's new
Lexer :-}

No, it is not. Actually on  you
can
find a Hugs98 and "standard" haskell98 version. I just used this one as
I only
use GHC but it can easily be replaced.

>   * The default declaration of setBitMask in
wx/src/Graphics/UI/WX/Types.hs uses
> a scoped type variable. This could probably be rewritten to
something more
> portable.

Thanks for the hint. I'll remove the type declaration.

>   * wx/src/Graphics/UI/WX/Attributes.hs uses existentially 
> quantified data constructors (:=, :~, ::=, and ::~) for purely 
> aesthetical reasons.

Yes, I am considering changing it to "=:" operators, that look less
nice,
but remove the dependency on rank-2 polymorphism. However, I haven't
removed them yet as 1) not enough people complained, 2) any serious
haskell 
compiler supports "forall" now, and 3) the (:=) operator looks *really*
good, 
and 4) I depend on more devious things already which are harder to
avoid, namely:

>   * Type synonyms in instance heads + complex instance heads are quite
pervasive:

This is a devious thing to do, but totally unavoidable given the way I
model
inheritance with phantom types. I have considered using type classes to
model
the inheritance but that leads to a) other dependencies on extensions,
b) hard
to understand error messages, and c) a much more complex model. (See
Andre Pang's
master thesis for a ingenious way to model full inheritance)

On the other hand, phantom type inheritance is easy *and* using type
synonyms
in instance heads is *very* convenient (a huge improvement compared to
all the
instance declarations I had to write for GIO). (So, I guess I am making
a case for
supporting this extension in future Haskells as it is so useful).

>   * wx/src/Graphics/UI/WX/Classes.hs uses MPTC with 
> functional dependencies.

Hmm, yes, but these could be removed -- they are not very important.

> I don't want to sound too negative, Daan has done an 
> impressive job, but I'm a bit concerned about all this 
> non-portable stuff when we are planning to use wxHaskell as 
> the basis for our GUI efforts.

I share your concerns. However, keep in mind that WXCore is Haskell98 +
FFI,
and that only the nicified abstraction WX uses extensions. That is,
anyone can
build another nicified abstraction that is H98 compatible. However, it
seems that
for "real" libraries, one wants a bit more power.

In the end though, I would like wxHaskell to be an open community effort
and not to
be "daan's" library. In that sense, anyone can change the libraries
interface if
enough people support that. I am not emotionally attached to my design
and will certainly
support people that want to change or fix the library (especially given
my lack
of time to spend on this project :-). 


All the best, and thanks for your comments,
  Daan.

> Cheers,
> S.
> 
> 
> ___
> Haskell mailing list
> [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
> 
> 


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Announce: wxHaskell 0.2

[Daan Leijen]

Announcement: wxHaskell version 0.2 
--

<http://wxhaskell.sourceforge.net>

The new release has (improved) support for tree controls, list 
controls, toolbars, splitter windows, sliders, gauges, and bitmap
buttons. Screenshots of these widgets on different platforms have been
added to the website. Furthermore, there are numerous small bug fixes,
especially for wxGTK. A list of non-compatible changes is attached at 
the end of this mail.

--
wxHaskell is a portable GUI library for Haskell. The goal of the 
project is to provide an industrial strength portable GUI library, but 
without the burden of developing (and maintaining) one ourselves. 

wxHaskell is therefore build on top of wxWindows -- a comprehensive 
C++ library that is portable across all major GUI platforms; including 
GTK, Windows, X11, and MacOS X. Furthermore, it is a mature library 
(in development since 1992) that supports a wide range of widgets with 
native look-and-feel, and it has a very active community (ranked among 
the top 25 most active projects on sourceforge).

Since most of the interface is automatically generated from the 
wxEiffel binding, the current release of wxHaskell already supports 
about 75% of the wxWindows functionality -- 2766 methods in 505
classes with 1279 constant definitions.

wxHaskell has been build with GHC 6.0/6.01 on Windows, MacOS X and 
Unix systems with GTK. A binary distribution is available for Windows 
and MacOS X. 

And even if you don't intend to write GUI's yourself, it will be fun 
to check out the screenshots at <http://wxhaskell.sourceforge.net>.

All the best,
  Daan Leijen.


ps. More funny statistics: the wxWindows libraries have been 
downloaded over a million times at sourceforge! The Python binding to 
wxWindows (wxPython) about 600.000 times, and the Haskell binding
to wxWindows about 100 times :-)


--
Breaking changes to version 0.1:

- Renamed the "WXH" layer to "WXCore". 
  > import Graphics.UI.WXCore
  instead of 
  > import Graphics.UI.WXH

- Changed the interface of menu items a bit. The label and help text 
  is now  supplied via attributes:
  > medit<- menuPane   [text := "&Edit"]
  > mfont<- menuItem medit [text := "&Font...\tCtrl+F"
  >,help := "Set the font"]
 


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Announce: wxHaskell, a portable GUI library.

[Daan Leijen]

> I can't seem to download any files for wxHaskell from 
> sourceforge; this is probably a misconfiguration on their 
> part, but I thought it best to let you know as well.

Thanks for the info. However, it downloads fine for most
people here at the university. Maybe you should try a different
mirror or click at the shown mirror URL directly.

All the best,
  Daan.

ps. If it still doesn't work, send me a notice today and I'll put up
some local copies at my home page. (and maybe you could just
reply to me personally (and/or wxhaskell-users) to reduce traffic 
at the main haskell list.)


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Announce: wxhaskell: macOSX binaries and bugfix.

[Daan Leijen]

Two announcements regarding wxHaskell:


1) I have created a binary release for MacOS X. Installation details can
   be found on the download page.

2) I have fixed a small bug in the configuration script for Linux. The
   source release has been updated. (and I promise I won't do that again
   as I go tomorrow on a holiday for two weeks :-)

All the best,
  Daan.


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Announce: wxHaskell, a portable GUI library.

[Daan Leijen]

Announcement: wxHaskell 0.1
---

<http://wxhaskell.sourceforge.net>

wxHaskell is a new portable GUI library for Haskell. The goal of the 
project is to provide an industrial strength portable GUI library, but 
without the burden of developing (and maintaining) one ourselves. 

wxHaskell is therefore build on top of wxWindows -- a comprehensive 
C++ library that is portable across all major GUI platforms; including 
GTK, Windows, X11, and MacOS X. Furthermore, it is a mature library 
(in development since 1992) that supports a wide range of widgets with 
native look-and-feel, and it has a very active community (ranked among 
the top 25 most active projects on sourceforge).

Since most of the interface is automatically generated from the 
wxEiffel binding, the current release of wxHaskell already supports 
about 75% of the wxWindows functionality -- about 2500 methods in 500 
classes with 1200 constant definitions.

wxHaskell has been build with GHC 6.0 on Windows, MacOS X and Unix 
systems with GTK. A binary distribution is available for Windows (and
we are working on a binary release for MacOS X).

And even if you don't intend to write GUI's yourself, it will be fun 
to check out the screenshots at <http://wxhaskell.sourceforge.net>.

All the best,
  Daan Leijen.


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: C++ class structure mapping

[Daan Leijen]

Dear Abraham,

> Now comes the question of how to map a C++ class hierarchy 
> into haskell. 
> It seems natural to try to map C++ classes into haskell typeclasses;
> however, there are a few issues involved with that.  

You will quickly run into problems when doing that. The most 
important problem is that class instances are implicitly exported
(ie. have a global scope). When different C++ classes implement 
the same methods, you will get unresolvable name clashes in Haskell.

Fortunately, there exists a simple solution to model *single*
inheritance
object models in Haskell. It works with using phantom types where we
encode the inheritance tree in the phantom type variable.

Here is a quick example. Suppose we have the following classes:

 class Window { void Show(); };
 class Frame   : public Window { void SetTitle( const char* title ); };
 class Control : public Window { ... };
 class Button  : publice Control { void SetLabel( const char* label );
};

Every object in Haskell will be represented by a simple "Ptr a". The
phantom type "a" will encode the inheritance relation, that is, for
each class we will create a new "phantom" data type that represents
its class (or its part of the virtual method table).

  type Window a  = Ptr (CWindow a)
  data CWindow a = CWindow

Note that we will never use the "CWindow" constructor and that it
therefore
called a phantom data type. The  "CWindow" type represents the Window
class
by itself, the "a" type variable represents the classes that may extend
it.

  type Frame a  = Window (CFrame a)
  data CFrame a = CFrame

  type Control a = Window (CControl a)
  data CControl a = CControl

  type Button a = Control (CButton a)
  data CButton a = CButton

Ok, now that we have encoded the objects and inheritance relationships,
we
can give the signatures of all the methods:

  frameCreate :: IO (Frame ())
  buttonCreate :: IO (Button ())

  windowShow :: Window a -> IO ()
  frameSetTitle  :: String -> Frame a -> IO ()
  buttonSetTitle :: String -> Button a -> IO ()

The creation function return objects where the type parameter is
instantiated
to unit () -- indeed such function creates exactly a Frame or Button,
but nothing
more. In contrast, a function like "windowShow" has its type parameter
uninstantiated
as it can receive any kind of window (any object that derives from a
window). This
corresponds to the contra-variance rule.

  do b <- buttonCreate
 windowShow b

We can see that the above code does indeed work, the buttonCreate
returns a "Button ()"
that can be passed whenever a "Window a" is expected:

  Button () == Control (CButton ()) == Window (CControl (CButton ())) ==
Window a


Pheew, quite a story. I hope it helps. You can read more about phantom 
types and inheritance in:

  Domain Specific Embedded Compilers, 
  Daan Leijen and Erik Meijer. 2nd USENIX Conference on Domain-Specific
Languages (DSL), Austin, USA, October 1999. 

  Calling Hell from Heaven and Heaven from Hell 
  Sigbjorn Finne, Daan Leijen, Erik Meijer, and Simon Peyton-Jones. 
  Proceedings of the International Conference on Functional Programming
(ICFP), Paris, France, 1999. 

and a recent paper with novel uses of phantom types to encode generic
type constraints:

  James Cheney and Ralf Hinze. Phantom types. (I think it is published
in "the fun of programming" ?)


> I'd like to make a haskell binding for a C++ library.  Most 

I have done this for a upcoming wxHaskell library: a binding to the 
wxWindows GUI library. Just as Alastair, I also think that it is better
to
create (or generate) a C interface to the C++ library first, ie.

extern "C" {
  void object_foo( Object* self, int arg )  
  {
self->foo(arg);
  }
}

Furthermore, you probably need to generate dynamic link libraries
(or shared object files)  to link with GHC as the runtime systems
of C (=GHC) and C++ are incompatible on many platforms.

> First - it seems natural to use template haskell to do the code
> generation.  That way, the library could either write the 

I would advise against this: it is quite experimental and you would
lock yourself into a single implementation. (I have made that mistake
with haskellDB and TREX myself though :-).
Since you will generate code anyway, you probably have no need for
template stuff.

All the best, 
  Daan.




> A 
> separate datatype
> would have to be made for each C++ class to allow it to actually be
> instantiated, which isn't too bad.  However, to allow haskell 
> instances of
> the typeclass to call the old behavior it seems that there'd 
> have to be
> duplicate functions of the ones in the typeclass, i.e.
> 
> class A a where
>   foo :: a -> IO ()
> 
> foo_cpp :: (A a) => a -> IO ()
> 
> That seems

Re: FFI Tutorial / Examples

[Daan Leijen]

On Sun, 09 Mar 2003 22:13:35 -0500, Matthew Donadio <[EMAIL PROTECTED]> wrote:

I may be being a bit dense about this, but I am having some trouble
understanding how to use FFI, especially with respect to interfacing
Haskell lists/arrays to C arrays.
For example, say I have the C functions

void foo (double *input, double *output, int N);
Hi Donadio,

I do this from the top of my head, but it should get you started.
The easiest way to marshal this is to use lists:
foo :: [Double] -> [Double]
foo xs  = unsafePerformIO (fooIO xs)
fooIO :: [Double] -> IO [Double]
fooIO []
 = return [] -- I guess a null array is not supported in foo?
fooIO xs
 = withArray xs $ \cxs ->   -- array of the list (auto deallocated)
   allocaArray n $ \cys ->  -- fresh array of size n (auto deallocated)
   do fooC cxs cys n-- call "foo" in C land
  peekArray n cys   -- unmarshal the values in cys back to a list of 
doubles
 where
   n = length xs
foreign import ccall "foo" fooC :: Ptr Double -> Ptr Double -> Int -> IO ()

If you really want to use Array's, you can convert the lists to arrays
in "foo". Note though that it almost never pays to use Array's in Haskell
unless you really need random access (which is rarely needed in practice).
Hope this helps,
 -- Daan.
btw. If you have the header file of the "foo", you should include it. Say:

 foreign import ccall "Foo.h foo" fooC :: Ptr Double -> Ptr Double -> Int -> IO ()

and use on top of the Haskell file:

 {-# OPTIONS -fvia-C -#include Foo.h #-}

This will check your foreign import signature against the C declaration.

(of course, we should update H/Direct to GHC 5.04 and let it work
better with C header files, and none of this would be needed --
but life is never perfect :-)
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: GUI for Windows

[Daan Leijen]

On Mon, 3 Mar 2003 16:21:22 +0100, <[EMAIL PROTECTED]> wrote:

What User Interface Library would you recommend for use under Windows?
Unfortunately, there is no official GUI library for Haskell yet (but many
people are working toward this goal at the haskell gui mailing list).
At the moment, the best solution on windows (in my opionion) is to use the ObjectIO 
library that ships with GHC 5.04.2. You need to look at some examples to get started 
but it is pretty stable and useable. Unfortunately, it seems though that no one 
actively maintains it...
Another solution could be the HTk library but I have no experience with it.
Fortunately though, people are working on a good portable GUI solution for Haskell so I expect that over a few months the situation will be better.

All the best,
Daan.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: looking for Database Interface in Haskell

[Daan Leijen]

On 03 Mar 2003 13:57:06 +, Steffen Mazanek <[EMAIL PROTECTED]> wrote:

Dear all, we want to access a (MySQL) data base,
running on a linux server, from a Haskell program.

Have a look here:
http://haskell.cs.yale.edu/haskellDB/
A word of warning though from the author :-),
HaskellDB is somewhat outdated at the moment and only works with
TREX supported systems on windows ODBC databases. It is not so hard
to give it a different backend (ie. mySQL) but it is harder to
give it a non-TREX type system -- I have ideas about that though
and I am planning an update after my thesis is finished, but untill that moment, I 
don't think it would fit your particular target very well.
All the best,
 Daan.


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: How to make Parser explicitly "fail"?

[Daan Leijen]

Now I am thinking of writing a Parser for variable. My
thought is:
variable::Parser String
variable = do s<-identifier
if not (s=="define") then return s else
--let parser fail
You forgot to tell which parser library you use. If you
use ParseLib (or Parsec) you can use the monadic zero
function "mzero".
Now, if you are using Parsec, you can also use
"fail :: String -> Parser a" to add some error message.
variable = do s<-identifier
when (s=="define") (fail "define is a keyword")
return s
Or better:

variable = do s<-identifier when (s=="define") (unexpected "keyword")
return s
 "variable"
Or even better, use the standard "identifier" parser from the "ParsecToken" module 
to handle this for you automatically. The
user guide describes this in detail: http://www.cs.uu.nl/~daan/parsec.html
All the best,
Daan.




I will be very happy if there is some mechanism to
implement the "else" branch, for I have thought of it
for long. :)
__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell





___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: Yet another weakly defined bug report

[Daan Leijen]

> These things are always tricky to understand, which is why I recommend
> not using lazy I/O.  File reading is not a pure operation: running out
> of file descriptors is a good counter-example.

Without saying wether I agree with lazy I/O or not, I suggest that
this particular problem may also be due to the runtime implementation:
If one tries to open  a new file but the file descriptors are exhausted,
the runtime system should first trigger a full GC because that might
free up some descriptors -- but maybe GHC is already doing this?

This brings me to another "issue". It would be nice if we can create
foreign pointers with a resource estimate. That is,  a foreign pointer to 
a bitmap might have a high resource estimate. This resource estimate can be 
used by the garbage collector to collect more aggressively if the "foreign" 
resources become filled. I haven't fleshed out a complete design yet,
but it should be somehow possible to express that file-descriptors have
a rather high resource estimate, as they run out after about 200 have been
allocated.

All the best,
Daan.

> Cheers,
> Simon
> ___
> Haskell mailing list
> [EMAIL PROTECTED]
> http://www.haskell.org/mailman/listinfo/haskell
> 
> 
> 

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: FiniteMap performance WITHOUT any copying?

[Daan Leijen]

> Magnus wrote (snipped)
> > Now, Haskell has a garbage collector, so Haskell must know how many
> > pointers there are to all objects in the heap (or?). Then, if a finite map
> > for example only has one single pointer to it, then it ought to be all
> > right to modify the finite map (or whatever datastructure we are
> 
> 
> In fact I don't think GHC does know how many pointers there are to all objects in the
> heap.  That would only be useful if it did GC by reference-counting, which it 
>doesn't.
> Reference counting is in fact rather expensive; 

A possible solution to this could be one-bit reference counting. With this technique,
every pointer to an item is marked as either a unique pointer or a shared pointer.
Normal GC techniques are used to garbage collect the heap but certain operations
can use the uniqueness information to update-in-place. This kind of reference counting
is cheaper since it involves bit-twiddling on the pointers directly instead of 
indirect fields.
However, I think that in the end the price may be too high for the benefits obtained.
It may be applicable however to interpreted systems where these register operations 
come
relatively cheap.

All the best,
Daan.

ps. The remarkable PhD. thesis of William R. Stoye says more about one-bit reference
counts that he uses in his (hardware) SKI machine. Allthough fairly old (1984) it is 
still
a very interesting thesis to read. It is especially fun to read how he already 
describes
very clearly "why functional programming matters", even dwelling on the subject of
functional operating systems.
 ___
> Haskell mailing list
> [EMAIL PROTECTED]
> http://www.haskell.org/mailman/listinfo/haskell
> 
> 

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: FiniteMap performance

[Daan Leijen]

Dear Magnus,

> I wonder what the performance of
> the FiniteMap type is in Haskell. Lookup is of course done in O(log n)
> but is insertion done in O(n) or O(log n)?
...
> If it belongs to O(n), aren't the maps really really useless?
> If it belongs to O(log n), how is this achieved?
>   (my guess is that it is O(n) of course : )

I have once been thinking the same, but you can rest assured,
insert is O(log n)   (for a balanced tree map implementation).

A pure language must indeed copy its values (since it is a new one) but
it can also *share* values that stay the same. In the case of the
balanced tree, the "path" to the inserted node will be copied since they
consist of new and different nodes, but all the subtrees of this path stay
the same and will be shared among all new insertions. It is rather mind-boggling
when you start thinking about how the actual heap looks after a while, but
fortunately, you never have to think about that in Haskell :-) 
(btw. This is really fun to watch if you got a tool like the graphical Hood).

All the best,
Daan.

ps. I have written a fairly extensive (and documented) data structure library 
called DData that has efficient Maps, Sets, Bags etc. Also works well with 
Hugs and other haskell98 compilers. http://www.cs.uu.nl/~daan/ddata.html



> 
> For example, does the function
> 
> addToFM :: Ord key => FiniteMap key elt ->
>   key -> elt  -> FiniteMap key elt
> 
> belong to O(n) or O(log n) (where n is the size of the map) ?
> 
> If it belongs to O(n), aren't the maps really really useless?
> If it belongs to O(log n), how is this achieved?
>   (my guess is that it is O(n) of course : )
> 
> Best regards,
>   Magnus Lindberg
> ___
> Haskell mailing list
> [EMAIL PROTECTED]
> http://www.haskell.org/mailman/listinfo/haskell
> 
> 

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: Bizarre Haskell Problem

[Daan Leijen]

My guess is that you are having an out-of-date .o of .hi file
in your working directory. Clean it up and try again.

All the best,
Daan.

- Original Message -
From: "Matthew Donadio" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, January 27, 2003 10:34 PM
Subject: Bizarre Haskell Problem


> Hi all,
>
> I am currently a having a bizarre Haskell problem, and was wondering if
> anyone had any suggestions.
>
> This is a snippet from a source file:
>
> > foo n = [ a ^* i | i <- [0..(n-2)] ]
> > where i ^* j = (i ^ j) `mod` n
> > a = generator n
>
> > rader :: Array Int (Complex Double) -> Int -> Array Int (Complex Double)
> > rader f n = foo a n -- DEBUG: should be f'
> > where h = listArray (0,n-2) [ f!(a ^* (n-(1+n'))) | n' <- [0..(n-2)] ]
> >   g = listArray (0,n-2) [ w (a ^* n') | n' <- [0..(n-2)] ]
> >   f' = array (0,n-1) ((0, sum [ f!i | i <- [0..(n-1)] ]) : [ (a ^* i, f!0 
>+ sum [ h!j *
g!((i-j)`mod`(n-1)) | j <- [0..(n-2)] ]) | i <- [0..(n-2)] ])
> >   w i = cis (-2 * pi * fromIntegral i / fromIntegral n)
> >   i ^* j = (i ^ j) `mod` n
> > a = generator n
>
> Under hugs and ghc, calling 'foo' and 'rader' with the proper arguments
> will give me different results under certain circumtances.
>
> In rader, n is the number of elements in the array.  If n is < 23, then
> everything is OK.  If n >= 23, then rader returns the wrong result.  The
> bizarre thing is that if I comment out the definitions of h and f' in
> rader, then it returns the correct results.  Hugs also give different
> reduction counts depending on whether h and f' are commented out or
> not.  If I add any more definitions that reference f, then rader
> misbehaves.
>
> What is even more bizarre is that if I copy everything into a separate
> file, then it work for all n.
>
> Any suggestions or hints, other than just use a separate file?  Separate
> files isn't really an option, because the above is simplified a bit, and
> the final version would have mutually recursive modules, which hugs
> can't handle.
>
> Thanks.
>
> --
> Matthew Donadio ([EMAIL PROTECTED])
> ___
> Haskell mailing list
> [EMAIL PROTECTED]
> http://www.haskell.org/mailman/listinfo/haskell
>
>


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: Parsec: No newline after last line and 'many'

[Daan Leijen]

Hi Till,

My guess is that you want to break up a text file into
a list of lines with Parsec. (ie. "lines" functionality).
A text file consists of non-newline characters seperated by
newline characters:

> import Parsec
>
> plines :: Parser [String]
> plines  = (many (noneOf "\n")) `sepBy` newline

You don't need any "try" or "manyTill" here. It seems to 
work on my system but I haven't tested it exhaustively.

> TestLine> parseTest linep ("hi\nTill")
> ["hi","Till"]
> 
> TestLine> parseTest linep ("hi\nTill\n")
> ["hi","Till",""]
> 
> TestLine> parseTest linep ("hi\n\nTill\n")
> ["hi","","Till",""]

I hope this helps, 
All the best,
Daan.


- Original Message - 
From: "Till Doerges" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, April 07, 2002 11:04 PM
Subject: Re: Parsec: No newline after last line and 'many'


> On Sun, Apr 07, 2002 at 07:44:42PM +0200, Till Doerges wrote:
> 
> > Eventually I want to be able to use my parser 'linep' with 'many' on
> > no matter which text-files.
> 
> 'manyTill linep eof' and is what I wanted (looking at my first name, I
> should have gotten that one earlier... ;-)
> 
> Bye -- Till
> ___
> Haskell mailing list
> [EMAIL PROTECTED]
> http://www.haskell.org/mailman/listinfo/haskell
> 
> 


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Haskell puzzles!

[Daan Leijen]

Hi all,

I have put together some interesting Haskell puzzles!
Not many people were able to solve all three puzzles 
so don't be discouraged you don't know all the answers.

Have fun, 
 Daan.

-
- All three puzzles are "Haskell 98"; you can solve 
  them using the Haskell 98 manual and they should be
  implementation independent.

- "equal" means that two evaluated expression denote
  the same semantical value; i.e. when typed on the
  Hugs prompt, I will see the same answer.

- All the answers are at the end of this mail.

-
1) Are e1 and e2 equal?

> f (x:xs) y  = x
> g (x:xs)= \y -> x
>
> e1 = seq (f []) 1
> e2 = seq (g []) 1


-
2) Are e1 and e2 equal? 
   Is one definition preferred over the other?
   (And what about "h x = nfib 30" ?)

> f  = const (nfib 30)
> g  = \x -> nfib 30
>
> e1 = f 1 + f 2
> e2 = g 1 + g 2


-
3) Are e1 and e2 equal?
   And what if I typed them on the Hugs prompt?

> f   = \x -> x + x
> g x = x + x
>
> e1  = f 1.0 + f 2.0
> e2  = g 1.0 + g 2.0


-
Answers at the end of this email.








































Answers:
-
1) 
answer: 
  "e1" equals the value 1, while "e2" is undefined.
   
explanation:
  This is due to the translation of pattern matching.
  The functions are de sugared into:

  > f x' y  = case x' of (x:xs) -> x
  > g x'= case x' of (x:xs) -> (\y -> x)

  Now, the expression "f []" is a partial application
  and thus in weak head normal form while "g []" is
  evaluated and the pattern matching fails.

opinion:
  I think that the pattern matching translation rules
  are wrong here and we shouldn't push the "case" through
  the lambda's. However, the current rules are potentially
  more efficient since all arguments can be collected
  before matching.

-
2)
answer:
  Yes, "e1" and "e2" are equal. However, the "f" definition
  is preferred since it potentially shares the computation 
  of "nfib 30". ("e1" will be almost twice as fast as "e2" 
  on most systems).

explanation:
  The Haskell language is only defined to be "non-strict".
  This means that there are no guarantees about sharing. However,
  all current Haskell systems use lazy semantics. This means
  that both "f" and "g" are caf's. When "g" is evaluated, the
  expression "\x -> nfib 30" is shared and on each call "nfib 30"
  is re-evaluated. When "f" is evaluated, the application node
  "const (nfib 30)" is shared and once it is applied it will be updated
  and "nfib 30" is only evaluated once. Smart compilers like GHC 
  however, will inline definitions like "g" and after common expression
  elimination we also end up with an efficient version. Same would
  hold for a full laziness transformation.

  Note that "h x = nfib 30" behaves exactly like "g" except that it's
  type is more general due to the monomorphism restriction and 
  defaulting:

  > f,g :: a -> Integer
  > h   :: Num b => a -> b

opinion:
  I believe that the operational distinction between both definitions
  is fundamentally important and should be expressible by the user.

-
3) 
answer:
  Yes, "e1" and "e2" are equal (6.0). However, when "e1" and "e2"
  are used outside the scope of "f" and "g", for example when typed
  on the Hugs prompt, "e1" is not well-typed.

explanation:
  The type of "g" is "Num a => a -> a". One would expect the same
  type for "f" but unfortunately, the monomorphism restriction prevents
  this and defaulting tries to resolve the instance. Based on the usage
  of "f", it will default to "Double" and we get the type "Double -> Double"
  for "f". However, if we would use it from the Hugs prompt, there is
  no usage site of "f" and defaulting will resort to the "default defaulting"
  rules and set the type of "f" to "Integer -> Integer" and the expression
  "f 1.0" becomes ill typed -- that is, unless I use a "default" declaration
  in the module, as in:

  > default (Double)

opinion:
  Clearly, as puzzle 2 shows, we want to have a distinction between 
  shared values and functions. So, we need at least to be warned when
  the compiler would add a dictionary argument. I would say that an
  "overloading warning" is more appropriate than a "monomorphism restriction".
  Anyway, the real culprit here is the horrible defaulting mechanism. 
  I believe that defaulting has no place in Haskell modules and should 
  probably only be used on expressions in a top-level interpreter.



___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: Specifying Kinds of Types

[Daan Leijen]

>I'd like to be able to declare the kinds of new types and synonyms, 
>because sometimes Haskell can't infer them.

The kind inferencer normally works quite well
in Haskell. Only when you use phantom types
(ie. unused type variables), you sometimes have to 
guide the kind inferencer -- either with phantom
constructors (ie. unused constructors) or phantom
type defintions in the case of newtypes.

Allthough not described, we used this trick extensively 
in Haskell/DB in order to force phantom types 
into the T-REX kind "Row". (http://www.cs.uu.nl/~daan/papers/dsec.ps)

All the best,
Daan.


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: Strange error in show for datatype

[Daan Leijen]

Simon Peyton-Jones wrote:
> Consider:
> 
> data T a = T1 Int | T2 a
> 
> It's clear that (T1 Int) has no a's in it, not even bottom.  Mark Shields
> and ruminated in the corridor about a kind system to make this apparent.
> That is, T1 would have type
> 
> T1 :: forall a::Pure .  Int -> T a
> 
> Then if we see (forall a::Pure. Show a => )
> we're justified in fixing a to Empty.   

I think that even with this kind system, we can't fix it 'a' to Empty. 
For example, the empty list constructor would get type:

[] :: forall (a::Pure) . [a]

and as Koen showed, we still can't fix the 'a' to Empty.

-- Daan.


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: Strange error in show for datatype

[Daan Leijen]

Koen Cleassen wrote:
> Indeed. And this is a perfect example of the fact that all
> this bottom-dictionary passing does not work. The type of
> the list still matters though:
>
>   Hugs> show ([] :: [Char])
>   "\"\""
>
>   Hugs> show ([] :: [Int])
>   "[]"

Koen is absolutely right.  A fundamental property of type-classes
is that you can *not* assign a meaning to the program independent
of its types. A haskell program is not always typeable when I erase
all type signatures because some programs are inherently ambigious,
like showing the empty list. As Koen shows, by giving a type signature
I can disambiguate the program and it indeed gives quite different
results with different type signatures.

A good discussion about this property of type-classes can be found in:

A Second Look at Overloading, Martin Odersky, Philip Wadler, and Martin
Wehr. In Proceedings, ACM Conference on Functional Programming and Computer
Architecture, La Jolla, CA, June 1995.

All the best,
Daan.





___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

announce: PARSEC

[Daan Leijen]

I am pleased to announce a new release of 
PARSEC, a fast monadic parser library for Haskell.
 
The PARSEC library is written for practice and 
usessome novel techniques to improve its speed and to give good error 
messages. It ships with extensive support libraries and documentation. 
PARSEC is distributedwith GHC but GHC 5.02 unfortunately includes an older 
version.
 
PARSEC can be downloaded from:http://www.cs.uu.nl/people/daan/parsec.html
 
I would like to thank the many(!) people that have 
writtenme with advice and comments that improved the library.
 
Have fun,  Daan Leijen.
 
-New 
features:
 
* The ability to use a seperate lexer. The parsers 
  work on any kind of token stream instead of just  
characters.
 
* A user definable state, very convenient to 
maintain  a symbol table.
 
* A module to parse permutation phrases 
[1].
 
* A parameterized lexical analyser 
module.
 
* New combinators like "sepEndBy"
 
 
 
-[1] 
Arthur Baars, Andres Loh and Doaitse Swierstra    "Parsing 
Permutation Phrases"    Proceedings of the Haskell Workshop 
2001.

RE: Singletons and Reflection

[Daan Leijen]

> If we had implicit parameters then all graphics functions 
> would have types
> (? context :: Context) => (explicit arguments) => IO (result) 
> and the main 
> function would be something like
>do 
>   context <- getContext
>   doBusiness with context=context
> 

The catch is off course that every function with an explicit
type signature:

> explicit arguments -> IO result

needs a new type signature:

>  (?context :: Context) => explicit arguments -> IO result

Here, partial type declarations proposed by Koen Claessen would help.
Those declarations are quite usefull if one plans to use implicit
parameters a lot, allthough they improve flexibility in general. 
i.e. one could write:

... => explicit arguments -> IO result

all the time and add any extra implicit arguments as needed 
without change to existing source code.

All the best,
Daan.

RE: Singletons and Reflection

[Daan Leijen]

> What do folk out there think to the idea of having a std module
> in Haskell which contains dynamic environment info.
> things I mean are
>
> progName :: String
> args:: String
>

Representing the 'args' as a value in haskell is probably not
the right thing to do. For one thing, it is not possible to substitute the
value 'args' with its definition, since it is unknown until load time.

I think that the 'dynamic environment' info is much better represented with
implicit arguments. (already implemented by Jeffrey Lewis in the november
hugs release).
(Implicit Parameters: Dynamic Scoping with Static Types. Jeffrey Lewis, Mark
Shields,
Erik Meijer, John Launchbury:
http://www.cse.ogi.edu/~mbs/pub/implicit.ps.gz )

The type of main would than be:

> main :: (?arguments, ?environment) => IO ()

And we could use these arguments anywhere in the haskell program
(without making everything part of the IO monad)

> numArgs :: (?arguments) => Int
> numArgs  = length (?arguments)

Actually, the H/Direct compiler uses an unsafePerformIO to avoid having to
pass around options through all the compiler. Implicit arguments would help
here too.

All the best,
Daan.

Re: haskell IDE

[Daan Leijen]

> I heard that Visual Haskell is under development.
> Do you know when it is released? It will provide Haskell programmer an
> environment that is similar to Visual J++, Visual Basic, or...?

VisualHaskell is indeed under development. However, due to
licensing issues the release date is "somewhere next year".

VisualHaskell will provide you with integrated interpreter,
editor, project and compiler support; but it will be closer
to VisualC++ than for example VisualBasic (ie. not very visual :-)
(erik meijer 
 
For now, you might want to look at Koen Cleassens integration
with the "nedit" editor. This software can be found on haskell.org
under libraries and tools.

All the best,
Daan.


> Besides, if you know, would you please tell me where we can 
> download Uniform Workbench? 
> (I found the paper about Uniform Workbench only)
> 
> Thank you very much !
> Phan Dung.
> 
> 
> 

Re: Contexts

[Daan Leijen]

> > > (3) OK with GHC, error with Hugs:
> > >
> > > f = \x -> m x
> > > x = f()
> > ...
> > > - Is GHC's treatment of (3) a bug?
> >
> > At first glance it looks a bit that way to me, but
> > I will leave it for the more knowledgable Haskell experts
> > to give you a definitive answer on that one.
>
> IIRC it's a known bug in Hugs, and fixing it would be difficult as it is
an artifact of the
> typechecking algorithm used.
>
> GHC is correct, because f *is* monomorphic: the only use is at type ().
Thus f is given the
>type () -> (), rather than C a => a -> (), and thus no sharing is lost.
However, detecting
> that f is only used at the one type involves sneaky look-ahead.

Are you sure about this ? In my opinion the behaviour of Hugs is correct.
 It is clear that the use of "f" in the definition of "x" is monomorphic but
that doesn't make true that "f" is monomorphic. I might import this module
and use
"f" at different types. In general I can only tell if a certain function is
used at only one
type if I either can see all the program code or if the scope of "f" is
restricted
to for example the current module.

-- Daan.

Re: HaskellScript

[Daan Leijen]

> Hello,
> 
> I'm interested in using HaskellScript. Who can tell me where I can find
> useful infomation about how to use it to build interactive web pages?
> Thanks in advance!

The best place to start is at:
http://www.haskell.org/haskellscript

All the best,
Daan Leijen

> 
> Regards,
> Chen Ping
> 
> 
> 

Re: Licenses and Libraries

[Daan Leijen]

> "Daan Leijen" <[EMAIL PROTECTED]> wrote,
>
> > Sigbjorn Finne has done a lot of work to make sure that H/Direct can
handle
> > any standard and dialect of IDL that is around, including
> > OMG/Corba IDL's.  H/Direct can generate interface code to
> > any C library that is described with IDL (which is
> > normally just adding some attributes to the C header file)
> [...]
> > Secondly, it is quite easy to extend H/Direct to support
> > other protocols (like GNOME).

 "Manuel M. T. Chakravarty" <[EMAIL PROTECTED]> wrote,

> I know that and how H/Direct supports...I don't dare to say
> it...COM and plain C.  However, what I am unclear about is
> how does it support OMG's CORBA IDL?  As you mention in the
> H/Direct paper, COM fixes a language-independent, binary
> interface, but CORBA IDL doesn't do that.  Did you define a
> CORBA language mapping for Haskell?

Hi Manuel,

Unfortunately, there is more than one IDL around, they all look
the same and can basically express the same things.
Fortunately, H/Direct can get its input from both OMG /CORBA and
MS dialect IDL and extract the right semantic information.
In a sense, it doesn't matter in what language you describe your
interface as long as it gives enough information to generate marshalling
code. (that's why it is possible to even use C header files, allthough you
need some heuristics and/or extra directives, as you show in your paper).

We have not defined a CORBA *mapping* however. C and COM are
specific protocols for which we defined a mapping and generate marshall
code.
To *specify* an interface in C or COM, you can use any sort of IDL,
including OMG/CORBA IDL.
(btw. since the 'C' binding is actually a (dynamic or static) library
binding, it
supports also languages like pascal, fortran and many others with standard
calling conventions (cdecl, pascal, stdcall, fastcall,...))

The bad thing is that Corba is not a binary protocol and thus H/Direct needs
a different backend/mapping for each different Corba vendor. Many languages
provide
a Corba binding by providing their own Corba environment and interacting
with other Corba environments via the IIOP (internet) protocol of Corba
which
*is* a binary standard.
(Things are not really that bad since it seems that vendors start to
standarize on
object layout).

> If not, how can you
> support CORBA?  To support GNOME, the next step is to
> support the binary interface defined by ORBit (GNOME's
> Object Request Broker).  I guess that this means tweaking
> the marshaling code generation.  This you think is easy?

Supporting Corba would be a lot harder as said above. One approach could be
to just support one environment, I can't recall the name but there is one
excellent
free implementation around of corba (minicorba  or something ?)

Supporting Orbit however seems quite easy and it would be very cool to have
around, allowing for a comparison between COM and ORBit.
You should contact Sigbjorn Finne on the exact details but if
ORBit looks like COM (which is probably true) than it wouldn't
too much work.

> (I'd be really interested to get some more information about
> this, because, as I mentioned, I am interested in adding
> such support.)

It would be very nice to have someone adding these features to
H/Direct, especially since you are working with big frameworks
like GTK. This would have been a nice test of H/Directs abilities
and in a sense it is disappointing to learn that H/Direct didn't fit
your needs completely. I hope to learn how H/Direct can be improved
to take away the need for yet another FFI, which was our primary motivation
for building H/Direct.

All the best,
Daan.

> All the best,
> Manuel
>

Re: Licenses and Libraries

[Daan Leijen]

> On Mon, 23 Aug 1999, Manuel M. T. Chakravarty wrote:
>
> >   ``C -> Haskell, or Yet Another Interfacing Tool''
> >   http://www.score.is.tsukuba.ac.jp/~chak/papers/Cha99b.html
> >

Thanks for making the paper available, I enjoyed it a lot.

> Bravo!
>
> I fully endorse your main motivations from your paper:
> 1. Simplification by avoidance of special devoted languages
>and doing everything in Haskell instead.
> 2. Trying to make it generic enough, so it is not tied
>up to MS world (I am - as well as you are, far from
>criticising H/Direct: it has it niche, which is fine
>and cool).

As one of the designers of the new FFI and H/Direct, I do want
to say that there is *nothing* MS or COM specific about H/Direct or the FFI
!

Sigbjorn Finne has done a lot of work to make sure that H/Direct can handle
any
standard and dialect of IDL that is around, including OMG/Corba IDL's.
H/Direct can generate interface code to any  C library that is described
with IDL (which is normally just adding some attributes to the C header
file)
This works all fine on Linux or whatever system.

Besides that, H/Direct supports the MS dialect of IDL and can generate COM
interface code. However this is just one part of H/Direct which is
orthogonal
to the C support. Secondly, it is quite easy to extend H/Direct to support
other
protocols (like GNOME).


All the best,
Daan.

Re: Haskell Object

[Daan Leijen]

Hi,

>I'm using HaskellObject inside Visual Basic 6.0. If I create only 1 object
>(or 2 objects that have the same source), no problem happen. But when I
>create 2 objects (different source), Visual Basic 6.0 was crashed.
>
>Do you know why? Would you please reply as soon as possible !


HaskellObject is part of ongoing research. Its first release was just two
weeks ago so it
probably contains some bugs. Its design has already changed somewhat and
my current build runs more objects in differents sources without problems.
I hope to put a new build on the web in a week or two.

All the best, Daan.

ps. HaskellObject is part of a research project at Utrecht.  Please do not
use the Haskell mailing list for questions, but write to us personally.
We are interested in you experiences.

preview of HaskellDB

[Daan Leijen]

Given the recent interest in combining Haskell with (relational)
databases, I decided to put a pre-release of HaskellDB on the web.
HaskellDB is a research project and not yet complete, allthough it is
already possible to execute quite complex database operations.
HaskellDB can be found at:

http://www.haskell.org/haskellDB

HaskellDB is a combinator library for expressing queries and other
operations on relational databases in a type safe and declarative
way. All the queries and operations are completely expressed within
Haskell, no embedded (SQL) commands are needed. This close integration
makes it possible to do arbitrary computations on the database (like
computing the transitive closure) and makes it convenient to combine
HaskellDB with other combinator libraries (like Erik Meijer's CGI
library or John Hughes pretty printer).

All the best,
 Daan Leijen.

Re: Haskell, CORBA and Java (Was: Re: Current state of GUI...)

[Daan Leijen]

>From: Daan Leijen <[EMAIL PROTECTED]>
>
>[...]
>> Allthough we have made a binding now for COM, it would indeed be great
>> if we could also have a CORBA binding; it is of vital importance that
>> Haskell can talk with the outside world and the more languages it knows, the
>> better :-)
>> Since there is a serious lack of programmers, it would be very nice if
>> someone would like to adapt H/Direct and the COM run-time modules to
>> create a CORBA binding on a UNIX system; any volunteers ?
>
>How big an effort would it be?  Do you have any estimate?
>
>Manuel


The actual work of adapting the compiler and changing/creating the run-time
support can probably done in a couple of weeks. However, this implies that
you know *a lot* about CORBA and know *exactly* how to design the Haskell model.
The CORBA spec. is huge and there are many ORB's around. It could take quite
some time before you are familiar enough with it, to know what to do. My guess
is that
it would take at least 4 months with someone who is an expert at haskell and
familiar
with component frameworks.

Anyway, H/Direct is not even officially released yet, and I would highly
recommend it
as a starting point for a CORBA binding.

Cheers,  Daan.

Re: Haskell, CORBA and Java (Was: Re: Current state of GUI...)

[Daan Leijen]

> I am quite unhappy to see these developments (e.g.,
> H/Direct) being based on some proprietary standards, as it
> means that they are rather useless to me.
>

Lets clarify some points:

- H/Direct is a OSF DCE IDL compiler which can not only
  generate COM specific bindings but also for example
  bindings for general C libraries or dynamic libraries
  or some CORBA binding. Thanks to sigbjorn's expertise,
  it is a very modular and adaptable compiler that is freely
  available and it should be pretty easy to add a CORBA
  binding.

- HaskellServer is an interface specification that
  allows other software components to use Haskell
  programs by accessing the interpreter/compiler.
  It has an IDL specification and allthough the only
  implementation now is for COM, nothing prevents you
  from writing an implementation under UNIX with ORBIX !
  (btw. I changed the design a lot the past few weeks,
   and I will update the documentation the coming weeks;
   thereby deleting the COM agains CORBA section, this
   is just my personal view of things and should probably
   not belong in that document.)

- HaskellScript *is* a COM specific piece of software that
  lets Haskell programs be used as a generic scripting language
  for programs like MS Word or Internet explorer; much
  like JavaScript and VBScript. It is COM specific because it
  uses ActiveX interfaces which specify a general infrastructure
  in which components can interact. (ie. drawing, persistance,
  events). However, this work *could* be done just as easy
  for UNIX & CORBA *if* there were standard interfaces for
  implementing a scripting binding.

 [Note that it is ActiveX that makes COM a very attractive
  platform. Because of ActiveX, many ready to use components
  are available, like ADO for accessing databases, IE for
  accessing the internet and DirectAnimation for doing fancy
  animations. Without such an infrastructure, no market for
  reusable components can exist.

(http://www.internetworld.com/print/1997/12/08/software/19971208-critic.html
)
  ]

Allthough we have made a binding now for COM, it would indeed be great
if we could also have a CORBA binding; it is of vital importance that
Haskell can talk with the outside world and the more languages it knows, the
better :-)
Since there is a serious lack of programmers, it would be very nice if
someone would like to adapt H/Direct and the COM run-time modules to
create a CORBA binding on a UNIX system; any volunteers ?

All the best,
  Daan.

Re: Felleisen on Standard Haskell

[Daan Leijen]

Simon writes:

>That's just what I intend to do.  I don't see Std Haskell as a big
>deal, but even little deals are worth completing rather than
>leaving as loose ends... and I'm more optimistic than Paul about
>the usefulness of Std Haskell.  I would be happy to find a name
>that was less grand and final-sounding than 'Standard Haskell' though;
>but more final sounding than 'Haskell 1.5'.


What about "Haskell 98" ?
Sounds more final as 1.5 but less final as a Standard :-)

-- Daan