[Haskell] Haskell DB bindings (was Re: ANN: HDBC (Haskell Database Connectivity)

[Tim Docker]

[EMAIL PROTECTED] wrote:

> Incidentally, the difficulty with finalizers was precisely the
> argument for using enumerators rather than cursors in database
> APIs. Takusen has implemented that idea; takusen currently supports
> Sqlite, PostgreSQL and Oracle, has a test suite. Its performance test
> shows that takusen can retrieve 2 million rows from a table without
> running out of memory.

The differences between HDBC and HSQL have been recently discussed.
Where
does Takusen fit into this picture? From the above, it sounds like it
has
quite a different API. Are all 3 of these actively maintained?

As someone who may wish to construct a haskell db binding for a new db,
it's
not clear to which API it should conform. Sometimes choice is a
burden...

Tim

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

[Haskell] Re: ANN: HDBC (Haskell Database Connectivity)

[oleg]

Axel Simon wrote, in response to Keean Schupke
> > dbConnectWith ::  DbName -> (DbHandle -> IO Result) -> Result
> > dbConnectWith name workFn = do
> > handle <- dbConnectTo name
> > workFn handle `finally` dbDisconnect handle
> >
> > In this way you avoid finalizers... and everthing is safe providing you
> > only export the "with" style functions from the library... Here's an
> > example from the library, the connect function:
>
> I suppose you meant to write "result" rather than "Result". This style
> of functions is only safe if the user ensures that DbHandle is never
> returned as part of the result. You should have that in your
> documentation.

It seems using types to enforce the policy that a data base handle
cannot ever `leak' out might be a better idea, in Haskell. It is quite
straight-forward to do so: cf. the design of the ST monad guarantees
that an STRef cannot `leak' out in the result of runST. Monadic
Regions (implemented in Haskell) generalize the idea to multiple
nested regions: a pointer (or any other resource, e.g., a database
cursor) allocated in one region can be used in nested regions but
cannot leak outside of the region that created it (Or, to be more
precise, cannot be used outside -- and so, can be safely deallocated
when the region is exited).

Incidentally, the difficulty with finalizers was precisely the
argument for using enumerators rather than cursors in database
APIs. Takusen has implemented that idea; takusen currently supports
Sqlite, PostgreSQL and Oracle, has a test suite. Its performance test
shows that takusen can retrieve 2 million rows from a table without
running out of memory.
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Re: License for haskell.org content

[Jan-Willem Maessen]

On Jan 9, 2006, at 7:19 AM, Simon Marlow wrote:


Chris Kuklewicz wrote:


==
Conclusion
It is not possible to borrow text from a GFDL'd manual and  
incorporate

it in any free software program whatsoever.  This is not a mere
license incompatibility.  It's not just that the GFDL is incompatible
with this or that free software license: it's that it is  
fundamentally

incompatible with any free software license whatsoever.  So if you
write a new program, and you have no commitments at all about what
license you want to use, saving only that it be a free license, you
cannot include GFDL'd text.
The GNU FDL, as it stands today, does not meet the Debian Free
Software Guidelines.  There are significant problems with the  
license,

as detailed above; and, as such, we cannot accept works licensed unde
the GNU FDL into our distribution.
==
Thus defaulting the FDL for all wiki content, including code, is a  
very bad idea.


I agree - can we please use BSD or public domain?


I concur.  If you work at a largish company, the IP contamination  
worries can be really irritating.  Putting it all in the public  
domain ensures that people like me can read and contribute without  
trouble.


-Jan-Willem Maessen



Cheers,
Simon

___
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] haskell.org Public Domain

[ajb]

G'day all.

Quoting Ashley Yakeley <[EMAIL PROTECTED]>:

> Does anyone have any objections to putting everything in the public
> domain?

No, with the proviso that individual page authors can override that on
the page itself.  There is a disincentive for authors to do this, because
their material may be deleted instead of refactored.  On the other hand,
I can think of some scenarios where this may be necessary, such as an
author republishing material from one of their scientific papers where
the publisher holds an odd copyright.

While I'd prefer public domain, obviously (it's more useful), I don't
think that retaining attribution is an unreasonable request if an author
wants it for whatever reason.  The MediaWiki Way(tm) to do attribution
is not the same as the C2 Way(tm).  It would not involve dragging
signatures unless it's specifically a discussion page.

Would it be possible to manage attribution automatically?

Cheers,
Andrew Bromage
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Re: License for haskell.org content

[ajb]

G'day all.

Quoting Simon Marlow <[EMAIL PROTECTED]>:

> I agree - can we please use BSD or public domain?

Creative Commons "by" might be an appropriate alternative:

http://creativecommons.org/licenses/by/2.5/

Cheers,
Andrew Bromage
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Re: License for haskell.org content

[Jean-Philippe Bernardy]

We could also use multi licensing. A possibility is to have, by
default, everything licensed at the same time under BSD, CC, FDL and
GPL.

(For those who wonder, this suggestion is serious /and/ sarcastic at
the same time)

Cheers,
JP.

On 1/9/06, Ian Lynagh <[EMAIL PROTECTED]> wrote:
> On Sun, Jan 08, 2006 at 10:16:45PM -0800, Ashley Yakeley wrote:
> > In article <[EMAIL PROTECTED]>,
> >  Ian Lynagh <[EMAIL PROTECTED]> wrote:
> >
> > > Why not use the GPL, then?
> > >
> > > FWIW, the GFDL is considered non-free by Debian[1], so that would mean
> > > any documentation or anything derived from the wiki couldn't be packaged
> > > for Debian.
> > >
> > > Apart from the issue of code itself on the wiki, that other people have
> > > already mentioned, presumably you'd also have licence fun if you try to
> > > take surrounding explanatory text to use as haddock docs etc.
> >
> > Let's discuss it on the wiki:
> > 
>
> I don't know if there was a reason you chose my message in particular to
> reply to, but I have no intention of discussing this, or anything else,
> on a wiki.
>
> Incidentally, if anyone's collecting votes/opinions, I'd vote "yes" for
> any of GPL, BSD, PD, and "no" for any other licence I can think of.
>
> (I am unlikely to directly contribute anything to the wiki ATM, though).
>
>
> Thanks
> Ian
>
> ___
> 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] AMAST 2006 2nd Call for Papers

[Varmo Vene]

  SECOND CALL FOR PAPERS

 11th International Conference on
  Algebraic Methodology and Software Technology, AMAST '06

   colocated with MPC '06

Kuressaare, Estonia,  5-8 July 2006
 

http://cs.ioc.ee/mpc-amast06/amast/ 



Background

The major goal of the AMAST conferences is to promote research that
may lead to the setting of software technology on a firm, mathematical
basis. This goal is advanced by a large international cooperation with
contributions from both academia and industry. The virtues of a
software technology developed on a mathematical basis have been
envisioned as being capable of providing software that is (a) correct,
and the correctness can be proved mathematically, (b) safe, so that it
can be used in the implementation of critical systems, (c) portable,
i.e., independent of computing platforms and language generations, and
(d) evolutionary, i.e., it is self-adaptable and evolves with the
problem domain.

The previous conferences were held in Iowa City, Iowa, USA (1989, 1991
and 2000), Twente, The Netherlands (1993), Montreal, Canada (1995),
Munich, Germany (1996), Sydney, Australia (1997), Manaus, Amazonia,
Brazil (1998), Reunion Island, France (2002) and Stirling, UK (2004,
colocated with MPC' 04). The 2006 conference will be held at
Kuressaare, Estonia, colocated with MPC '06. 

The conference series has become widely known for disseminating 
academic and industrial achievements within the broad AMAST areas
of interest. Through these meetings AMAST has attracted an international
following among researchers and practitioners interested in software
technology, programming methodology and their algebraic and logical
foundations.


Important dates

* Submission of abstracts: 27 January 2006
* Submission of full papers: 3 February 2006
* Notification of authors: 17 March 2006
* Camera-ready version: 14 April 2006


Topics

Topics of interest include, but are not limited to, the following:

* Software technology: systems software technology, application
  software technology, concurrent and reactive systems, formal methods
  in industrial software development, formal techniques for software
  requirements/design, evolutionary software/adaptive systems.

* Programming methodology: logic programming, functional programming,
  object paradigms, constraint programming and concurrency, program
  verification and transformation, programming calculi, specification
  languages and tools, formal specification and development case studies.

* Algebraic and logical foundations: logic, category theory, relation
  algebra, computational algebra, algebraic foundations for languages
  and systems, coinduction, theorem proving and logical frameworks for
  reasoning, logics of programs, algebra and coalgebra.

* Systems and tools (for system demonstrations or ordinary papers):
  software development environments, support for correct software
  development, system support for reuse, tools for prototyping, component
  based software development tools, validation and verification, computer
  algebra systems, theorem proving systems.


Submission and publication

Two kinds of submissions are solicited for this conference: technical
papers and system demonstrations.  Papers may report academic or
industrial progress, and papers which deal with both are especially
well-regarded.

Submission is in two stages. Abstracts (plain text) must be submitted by
27 January 2006. Full papers (pdf) adhering to the llncs style and not
longer than 15 pages (6 pages for system demonstrations) must be submitted
by 3 February 2006. The web-based submission system is open. Papers must
report previously unpublished work and not be submitted concurrently to
another conference with refereed proceedings. Accepted papers must be
presented at the conference by one of the authors.

All papers will be refereed by the programme committee, and will be 
judged based on their significance, technical merit, and relevance 
to the conference.

The proceedings of AMAST '06 will be published in the Lecture Notes
in Computer Science series of Springer-Verlag.


Programme Committee

Michael Johnson, Macquarie University (co-chair)
Varmo Vene, University of Tartu (co-chair)
Luís Barbosa, Universidade do Minho
Gilles Barthe, INRIA Sophia-Antipolis
Michel Bidoit, École Normale Supérieure de Cachan
Gregor v. Bochmann, University of Ottawa
Manfred Broy, Technische Universität München
Cristian Calude, University of Auckland
Christine Choppy, Université Paris Nord
Arthur Fleck, University of Iowa
Marcelo Frias, Universidad de Buenos Aires
Nicolas Halbwachs, Université Grenoble I / CNRS
Anne Haxthausen, Technical University of Denmark
Antonia Lopes, Universidade de Lisboa
Michael Mislove, Tulane University
Peter Mosses, University of Wales Swansea
Monica Nesi, Università degli Studi di L'Aquila
Rocco De Nicola, Università degli Studi di Firenze
Ant

Re: [Haskell] Re: haskell.org Public Domain

[Eric Kow]

Whatever the Haskell community end up deciding, I would like to point 
out that the Wikibooks project uses the GFDL.  What would greatly 
simplify us wikibookians using content from the Haskell wiki are 
GFDL-friendly terms, that is, one of:

 public domain
 GFDL
 creative commons [by][sa] - that's up to 4 CC licenses to choose from 
(*)


If anybody suddenly feels inspired to go contribute, please see 
http://en.wikibooks.org/wiki/Programming:Haskell


--eric

(*) the share-alike situtation may be less clear, it seems CC are 
proposing a one-way compatibility with GFDL, but not sure what the news 
on that is)


On 9 janv. 06, at 21:11, Ashley Yakeley wrote:

As long as that's just the default and not required of course.


No, all contributions would be in the public domain.


--
Eric Kow http://www.loria.fr/~kow
PGP Key ID: 08AC04F9 Merci de corriger mon français.

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

[Haskell] Re: New look for haskell.org: MediaWiki

[Ashley Yakeley]

Sebastian Sylvan wrote:


Is there a way to typeset Haskell syntax yet?


Not yet, but someone could write an extension to do that...


--
Ashley Yakeley

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

[Haskell] ANN: hdbc-odbc

[John Goerzen]

I am pleased to be able to announce the first version of hdbc-odbc,
the ODBC backend for HDBC.

With this driver, you can use HDBC to connect to any database for
which ODBC drivers exist, including such databases as MySQL, Oracle,
MS SQL Server, etc.  I have tested it against PostgreSQL and would
appreciate "make test-ghc6" results with more (see
testsrc/SpecificDB.hs for the place to specify your connect string.)

hdbc-odbc is available for download from:

  http://quux.org/devel/hdbc

People interested in development should use the darcs repo:

  darcs get --partial http://darcs.complete.org/hdbc-odbc

-- 
John Goerzen
Author, Foundations of Python Network Programming
http://www.amazon.com/exec/obidos/tg/detail/-/1590593715
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Re: License for haskell.org content

[Ian Lynagh]

On Sun, Jan 08, 2006 at 10:16:45PM -0800, Ashley Yakeley wrote:
> In article <[EMAIL PROTECTED]>,
>  Ian Lynagh <[EMAIL PROTECTED]> wrote:
> 
> > Why not use the GPL, then?
> > 
> > FWIW, the GFDL is considered non-free by Debian[1], so that would mean
> > any documentation or anything derived from the wiki couldn't be packaged
> > for Debian.
> > 
> > Apart from the issue of code itself on the wiki, that other people have
> > already mentioned, presumably you'd also have licence fun if you try to
> > take surrounding explanatory text to use as haddock docs etc.
> 
> Let's discuss it on the wiki:
> 

I don't know if there was a reason you chose my message in particular to
reply to, but I have no intention of discussing this, or anything else,
on a wiki.

Incidentally, if anyone's collecting votes/opinions, I'd vote "yes" for
any of GPL, BSD, PD, and "no" for any other licence I can think of.

(I am unlikely to directly contribute anything to the wiki ATM, though).


Thanks
Ian

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

[Haskell] Re: haskell.org Public Domain

[Ashley Yakeley]

Cale Gibbard wrote:


As long as that's just the default and not required of course.


No, all contributions would be in the public domain.


It
might be nice to at least include some disclaimers of warranty.


Good idea.

--
Ashley Yakeley

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

Re: [Haskell] haskell.org Public Domain

[Glynn Clements]

Ashley Yakeley wrote:

> > Sounds like a stupid idea?  Thought so.  A wiki should be public domain,
> > plain and simple.  (Put contributions with a different license somewhere
> > else and link to them.  No big deal.)
> 
> There seems to be a consensus for public domain both here and on the 
> wiki page.
> 
> 
> Does anyone have any objections to putting everything in the public 
> domain?

Insisting that everything is in the public domain prevents the
inclusion of third-party content, unless either:

a) that content is also in the public domain (which is unusual; even
content which is "freely" redistributable usually has some kind of
restriction, even if it's only an acknowledgement requirement), or

b) you can obtain a specific exemption from its author (assuming that
you can actually identify and locate the author, which isn't always
easy for projects with a long history and many contributors).

-- 
Glynn Clements <[EMAIL PROTECTED]>
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] haskell.org Public Domain

[Cale Gibbard]

On 09/01/06, Ashley Yakeley <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
>  Udo Stenzel <[EMAIL PROTECTED]> wrote:
>
> > Sounds like a stupid idea?  Thought so.  A wiki should be public domain,
> > plain and simple.  (Put contributions with a different license somewhere
> > else and link to them.  No big deal.)
>
> There seems to be a consensus for public domain both here and on the
> wiki page.
> 
>
> Does anyone have any objections to putting everything in the public
> domain?
>

As long as that's just the default and not required of course. It
might be nice to at least include some disclaimers of warranty.

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

[Haskell] MonadPlus vs. Monoid

[Twan van Laarhoven]

I was wondering, in the MonadPlus documentation it says that:
  * mzero is the identity of mplus (and some extra conditions)
  * mplus is an associative operation
While for Monoid we have:
  * mempty is identity of mappend
  * mappend is an associative operation

MonadPlus is of course a 'stronger' assertion. But why is not every 
instance of MonadPlus also an instance of Monoid?


> instance MonadPlus m => Monoid (m a) where
>mempty  = mzero
>mappend = mplus

The only type that is an instance of both is [a]. But I see no reason 
why it there should not be a Monoid instance for other MonadPlus types. 
In particular, an instance for Maybe could be useful with a writer monad 
when you are only interested in the first result.


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

[Haskell] haskell.org Public Domain

[Ashley Yakeley]

In article <[EMAIL PROTECTED]>,
 Udo Stenzel <[EMAIL PROTECTED]> wrote:

> Sounds like a stupid idea?  Thought so.  A wiki should be public domain,
> plain and simple.  (Put contributions with a different license somewhere
> else and link to them.  No big deal.)

There seems to be a consensus for public domain both here and on the 
wiki page.


Does anyone have any objections to putting everything in the public 
domain?

-- 
Ashley Yakeley, Seattle WA

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

Re: [Haskell] New look for haskell.org: MediaWiki (now: Drupal)

[John Peterson]

The reason that MediaWiki was installed on haskell.org is that people
that know how to install and use MediaWiki (Ashley and others)
volunteered to do all the work.  If we want to move up to Drupal we
need someone that is willing to install, maintain, and transfer
content.  If this is something you want to do let me know.  

MediaWiki addresses many of the issues we've had with haskell.org but
it isn't meant to be the only possible way forward.

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

Re: [Haskell] Re: License for haskell.org content

[Udo Stenzel]

Ketil Malde wrote:
> Another option is the Open Publication License, which requires
> acknowledgement (but little else).

...which would mean that whenever you rearrange something inside the
wiki, you'd have to drag signatures around (and god forbid you
accidentally drop a single one).  The only way out would be to assign
copyright of contributions to some central entity, so the attribution
would always be "(C) The Haskell Wiki Foundation" or something.  Anyone
willing to found or find a suitable non-profit organisation?

Sounds like a stupid idea?  Thought so.  A wiki should be public domain,
plain and simple.  (Put contributions with a different license somewhere
else and link to them.  No big deal.)


Udo.
-- 
People with great minds talk about ideas.
People with ordinary minds talk about things.
People with small minds talk about other people.
-- Eleanor Roosevelt


signature.asc
Description: Digital signature
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] New look for haskell.org: MediaWiki

[Gour]

On Sun, 2006-01-08 at 19:52 -0500, John Peterson wrote:

> This isn't a completely "done deal" - there is still time to object to
> the whole thing or make suggestions.  Nothing will be visible to the
> outside world until we make the switch later.  But I believe this will
> result in a much better site and also make life a lot easier for Olaf
> and I.  (And I apologize to everyone that's asked for updates to
> haskell.org recently - I've been avoiding them to concentrate on
> this!).

As far as I understand Simon's proposal, it was not only about 'better'
wiki system and that's why I proposed something like Drupal which offers
more than a wiki (forums, Collaborative Book, Blogger API support,
Content syndication,Web based administration... see
http://drupal.org/features), so I wonder what's wrong with Drupal (or
some other CMS) and/or if having just a wiki is enough?

Sincerely,
Gour



signature.asc
Description: This is a digitally signed message part
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Re: License for haskell.org content

[Ketil Malde]

Simon Marlow <[EMAIL PROTECTED]> writes:

>> Thus defaulting the FDL for all wiki content, including code, is a
>> very bad idea.

> I agree - can we please use BSD or public domain?

Another option is the Open Publication License, which requires
acknowledgement (but little else).  Anyway, I think a point that
should be taken into consideration is that you can usually tighten the
licensing later on, while making it more liberal can be difficult.

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants

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

Re: [Haskell] New look for haskell.org: MediaWiki

[Duncan Coutts]

On Sun, 2006-01-08 at 21:12 -0500, John Peterson wrote:
> >> wiki is under the GNU FDL so the licenses are not necessarily
> >> compatible.
> 
> >As far as I understand, this means that if I see a sample of code on
> >the haskell wiki, and just want to "steal" it for my project, I'm not
> >allowed to, unless I also release my code under the GNU FDL?
> 
> This is something worth debating.  Certainly you can ask the author of
> the code for permission to use it but this is an extra burden.  Would
> be nice to have a special wiki construct to mark content as posessing
> an "extra" license.  The whole license debate should take place as
> soon as possible before we get a lot of content in there.  I'm not
> wedded to the FDL.

I get the impression that media wiki has some support for marking things
with Creative Commons licenses (and perhaps others) os maybe that'd help
(you often see this for images on Wikipedia). If people were posting
snippets from a GPL program then they could be marked as such.

This is somewhat different from what the default should be for small
snippets.

Duncan

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

[Haskell] Re: License for haskell.org content

[Simon Marlow]

Chris Kuklewicz wrote:


==
Conclusion

It is not possible to borrow text from a GFDL'd manual and incorporate
it in any free software program whatsoever.  This is not a mere
license incompatibility.  It's not just that the GFDL is incompatible
with this or that free software license: it's that it is fundamentally
incompatible with any free software license whatsoever.  So if you
write a new program, and you have no commitments at all about what
license you want to use, saving only that it be a free license, you
cannot include GFDL'd text.

The GNU FDL, as it stands today, does not meet the Debian Free
Software Guidelines.  There are significant problems with the license,
as detailed above; and, as such, we cannot accept works licensed unde
the GNU FDL into our distribution.
==

Thus defaulting the FDL for all wiki content, including code, is a very bad 
idea.


I agree - can we please use BSD or public domain?

Cheers,
Simon

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

Re: [Haskell] New look for haskell.org: MediaWiki

[Sebastian Sylvan]

On 1/9/06, John Peterson <[EMAIL PROTECTED]> wrote:
> As everyone has noticed during the "making Haskell more open"
> discussion, MediaWiki was suggested as a better wiki technology for
> haskell.org.  Ashley Yakeley has generously installed MediaWiki and we
> would like to migrate the main pages of haskell.org into this wiki.
> The migration is not complete - only the front page is finished - but
> I'd like to make this public now so that there's time for comments.
> In the end, this will allow anyone to come in and fix up the main
> haskell.org pages - the people, the projects, the help for beginners,
> whatever you want.  Olaf and I will then step back and let the
> community work directly on the entire site without having to bother us
> (a big advantage!).
>
> This will also impact the old Haskell wiki.  Rather than try to
> automatically convert the old wiki to the new one, we're going to ask
> the community to come in and do this for us.  In particular, the new
> wiki is under the GNU FDL so the licenses are not necessarily
> compatible.  We will keep the two wikis going "side by side" for a
> while but in the long term I hope all content migrates to MediaWiki
> (we won't be deprecating the Trac stuff - this will stay as is).
> I believe that MediaWiki is more professional looking and
> has a nice separation of documentation and discussion that MoinMoin
> lacks.  I hope that this will result in better wiki content and a more
> organized site.  Moving content by hand will give us all a chance to
> spruce up the existing content as it moves (and get rid of all the
> ugly CamelCase page names!).
>
> I expect that it will take another week or so for the rest of the
> haskell.org pages to move into the new wiki - at that point we'll
> "flip the switch" and take down the old pages (but not the old wiki
> yet) and change the main page to point into the MediaWiki.  Content
> that isn't being maintained by Olaf and I will stay as before although
> I hope that more and more pages will move into the wiki and we won't
> have to give out accounts to people on haskell.org just to host
> projects.
>
> The new wiki isn't yet visible from the front page but you can find it
> at http://haskell.org/haskellwiki/Haskell
>
> For you style sheet gurus, the style sheet itself is also in the wiki
> at
>
> http://haskell.org/haskellwiki/MediaWiki:Quiet.css
>
> If anyone wants to help move the main pages over, drop me an email and
> I'll coordinate things.
>
> Feel free to start adding stuff to the new wiki.  It won't be visible
> to the outside world immediately but you can get it ready for the
> switch over.
>
> This isn't a completely "done deal" - there is still time to object to
> the whole thing or make suggestions.  Nothing will be visible to the
> outside world until we make the switch later.  But I believe this will
> result in a much better site and also make life a lot easier for Olaf
> and I.  (And I apologize to everyone that's asked for updates to
> haskell.org recently - I've been avoiding them to concentrate on
> this!).
>
> I'm sure some of the MediaWiki settings still need to be tweaked.
> Send me mail if something in the configuration of MediaWiki needs to
> be changed.
>
> A big thanks again to Ashley!
>


Is there a way to typeset Haskell syntax yet?

/S

--
Sebastian Sylvan
+46(0)736-818655
UIN: 44640862
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] New look for haskell.org: MediaWiki

[Sebastian Sylvan]

On 1/9/06, Anders Höckersten <[EMAIL PROTECTED]> wrote:
> sön 2006-01-08 klockan 21:12 -0500 skrev John Peterson:
> > >> wiki is under the GNU FDL so the licenses are not necessarily
> > >> compatible.
> >
> > >As far as I understand, this means that if I see a sample of code on
> > >the haskell wiki, and just want to "steal" it for my project, I'm not
> > >allowed to, unless I also release my code under the GNU FDL?
> >
> > This is something worth debating.  Certainly you can ask the author of
> > the code for permission to use it but this is an extra burden.  Would
> > be nice to have a special wiki construct to mark content as posessing
> > an "extra" license.  The whole license debate should take place as
> > soon as possible before we get a lot of content in there.  I'm not
> > wedded to the FDL.
>
> Hmm, here's a quick suggestion. The wiki currently says:
> "Content is available under GNU Free Documentation License 1.2."
> We change this to:
> "All Haskell source code on this page is released into the public
> domain. All other content is available under GNU Free Documentation
> License 1.2." "Haskell source code" could also be a link to an exact
> definition of what is and what is not to be regarded as Haskell source
> code, but I think that seems a bit over the top.
>
> It might even be reasonable to release everything into the public
> domain. If nothing else, it means we can change the license later if it
> ends up being abused (which I personally believe is a rather low risk
> scenario).
>

Agreed. I don't see a point in having a restrictive license on source code.

Are there any HCI specialists around? I think the web site could do
with some refactoring. I.e. have fewer and more aptly named sections
linked from the front page (do we need both "books and tutorials" as
well as "learning Haskell"?), but I'm not sure exactly how to do it.
If we're making changes anyway, this would be a good time for
significant changes to be implemented. Since the wiki isn't "live" yet
maybe people will feel less "afraid" to make big changes to the front
page without going through a big voting procedure first (it can always
be changed back, and it's not visible from the front page just yet -
so if people don't like it, there's no harm done).

/S

--
Sebastian Sylvan
+46(0)736-818655
UIN: 44640862
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Re: ANN: HDBC (Haskell Database Connectivity)

[Axel Simon]

On Mon, 2006-01-09 at 11:33 +0100, Benjamin Franksen wrote:
> On Monday 09 January 2006 10:03, Axel Simon wrote:
> > On Sun, 2006-01-08 at 14:51 +, Keean Schupke wrote:
> > > My solution to this when developing a database library for my own
> > > use was to define the API
> > > in a bracket notation style, and only provide safe functions. The
> > > idea is that the function obtains the resource, calls a function
> > > passed as an argument, then frees the resource, so all resouces are
> > > guaranteed to be freed in the correct order... for example:
> > >
> > > dbConnectWith ::  DbName -> (DbHandle -> IO Result) -> Result
> > > dbConnectWith name workFn = do
> > > handle <- dbConnectTo name
> > > workFn handle `finally` dbDisconnect handle
> > >
> > > In this way you avoid finalizers... and everthing is safe providing
> > > you only export the "with" style functions from the library...
> > > Here's an example from the library, the connect function:
> >
> > I suppose you meant to write "result" rather than "Result". This
> > style of functions is only safe if the user ensures that DbHandle is
> > never returned as part of the result. You should have that in your
> > documentation.
> 
> I wanted to mention this too, but you were quicker ;)
> 
> > As far as I can tell, the only general solution is to use finalizers
> > and, if you really need to enforce a sequence of finialization,
> > touchForeignPtr. 
> 
> Repeat: touchForeignPtr can NOT be used to enforce finalization order.

Ok, I re-read that thread. I agree. However, it is likely that the
library you're using allows connections to be freed after the database
is freed. If not, you can still all three methods I posted to get around
the problem: Each connection needs to ref the database pointer and deref
that pointer when the finalizer is run. That way, the database is never
dead until all finalizers of all connections are run.

> > A practical issue with touchForeignPtr is that it 
> > cannot be conveniently called from another finalizer, since the
> > latter live in C. 
> 
> What do you mean "live in C"? Can't or shouldn't finalizers be written 
> in Haskell, too?

Well, before ghc 6.0 and the "new FFI", finalizers where Haskell
functions. Since this was tricky to implement, so finalizers are now C
functions. This has other implications, e.g. you can't pass a closure of
several pointers to the C function, the C finalizer will just get the
one pointer it wraps.

Axel.


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

Re: [Haskell] License for haskell.org content

[Chris Kuklewicz]

I have appended the relevant conclusion

Ian Lynagh wrote:
> On Sun, Jan 08, 2006 at 09:31:16PM -0500, John Peterson wrote:
> 
>>I believe the scenario that the FDL addresses is that someone
>>(probably Paul Hudak!) "borrows" massive amounts of stuff from the wiki,
>>adds his own good stuff, and then publishes a nice book or something
>>without having to share his additional contribution.  Some people
>>would like to be sure that their contributions can't be exploited in
>>this manner.
> 
> 
> Why not use the GPL, then?
> 
> FWIW, the GFDL is considered non-free by Debian[1], so that would mean
> any documentation or anything derived from the wiki couldn't be packaged
> for Debian.
> 
> Apart from the issue of code itself on the wiki, that other people have
> already mentioned, presumably you'd also have licence fun if you try to
> take surrounding explanatory text to use as haddock docs etc.
> 
> 
> Thanks
> Ian
> 
> [1] http://people.debian.org/~srivasta/Position_Statement.xhtml
> http://home.twcny.rr.com/nerode/neroden/fdl.html
> 


==
Conclusion

It is not possible to borrow text from a GFDL'd manual and incorporate
it in any free software program whatsoever.  This is not a mere
license incompatibility.  It's not just that the GFDL is incompatible
with this or that free software license: it's that it is fundamentally
incompatible with any free software license whatsoever.  So if you
write a new program, and you have no commitments at all about what
license you want to use, saving only that it be a free license, you
cannot include GFDL'd text.

The GNU FDL, as it stands today, does not meet the Debian Free
Software Guidelines.  There are significant problems with the license,
as detailed above; and, as such, we cannot accept works licensed unde
the GNU FDL into our distribution.
==

Thus defaulting the FDL for all wiki content, including code, is a very bad 
idea.

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

[Haskell] modern arrays library

[Bulat Ziganshin]

Hello

i just published the following text at the
http://haskell.org/haskellwiki/Arrays



Haskell'98 supports just one array constructor type, namely Array (see
http://haskell.org/onlinereport/array.html). It creates immutable
boxed arrays. "Immutable" means that these arrays, like any other pure
functional data structures, have contents fixed at construction time -
you can't modify it, only query. There is a "modification" operations,
but they just return new array and don't modify an original one. This
makes possible using Arrays in pure functional code along with lists.
"Boxed" means that array elements are just ordinary Haskell (lazy)
values, which are evaluated on need, and even can contain bottom
(undefined) value. You can learn how to use these arrays at
http://haskell.org/tutorial/arrays.html and i recommend you to read
this before proceeding to rest of this page

Nowadays three Haskell compilers - GHC, Hugs and NHC - shipped with
the same set of Hierarchical Libraries
(http://www.haskell.org/ghc/docs/latest/html/libraries/index.html),
and these libraries contains new implementation of arrays, which is
backward compatible with the H98 one, but contains far more features.
Suffice to say that these libraries supports 9 types of array
constructors: Array, UArray, IOArray, IOUArray, STArray, STUArray,
DiffArray, DiffUArray and StorableArray. It is no wonder that new
arrays library make so much confusion for haskellers, although
basically it is very simple - it provides only two interfaces, one of
that you already know.

Thus, the first interface, provided by the new arrays library, defined
by type class IArray (which stands for "immutable array" and defined
in module Data.Array.IArray - see
http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Array-IArray.html)
and contains just the same operations that was defined for Array in
H98. The only difference is that now it is a typeclass and there are 4
array type constructors, which implement this interface: Array,
UArray, DiffArray, DiffUArray. We will describe later differences
between them and cases when other types are preferred to use instead
of good old Array. Also note that to use Array type constructor
together with other new array types, you need to import
Data.Array.IArray module instead of Data.Array



> Mutable IO arrays (module Data.Array.IO)

Second interface defined by the type class MArray (which stands for
"mutable array" and defined in module Data.Array.MArray - see
http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Array-MArray.html)
and contains operations to update array elements in-place. Mutable
arrays are very like to IORefs, only containing multiple values. Type
constructors for mutable arrays are IOArray and IOUArray and
operations which create, update and query these arrays all belongs to
IO monad:

import Data.Array.IO
main = do arr <- newArray (1,10) 37 :: IO (IOArray Int Int)
  readArray  arr 1 >>= print
  writeArray arr 1 64
  readArray  arr 1 >>= print

This program creates array of 10 elements with 37 as initial
values. Then it reads and prints first element of array. After that
program modifies first element of array and then reads and prints it
again. Type definition in second line is necessary because our little
program don't allow compiler to determine concrete type of `arr`.



> Mutable arrays in ST monad (module Data.Array.ST)

Just like IORef has more general cousine - STRef, IOArray has more
general version - STArray (and IOUArray dubbed by STUArray). These
array types allows to work with modifiable arrays in state monad:

import Control.Monad.ST
import Data.Array.ST
main = print $ runST
  (do arr <- newArray (1,10) 127 :: ST s (STArray s Int Int)
  a <- readArray arr 1
  writeArray arr 1 216
  b <- readArray arr 1
  return (a,b)
  )
  
Believe you or not, but now you know all that needed to _use_ any
array type. Unless you are interested in speed issues, just use Array,
IOArray and STArray where appropriate. The following topics are almost
exclusively about selecting proper array type to make program run
faster.



> DiffArray (module Data.Array.Diff)

As we already stated, update operation on immutable arrays (IArray)
just creates new copy of array, what is very inefficient, but it is
pure operation what can be used in pure functions. On the other hand,
updates on mutable arrays (MArray) are efficient but can be done only
in monadic code. DiffArray combines the best of both worlds - it
supports interface of IArray and therefore can be used in pure
functional way, but internally used an efficient updating of MArrays.

How that trick works? DiffArray has pure external interface, but
internally it represented as the reference to IOArray.

When the '//' operator is applied to a diff array, its contents
are physically updated in place. The old array silently changes
its representation without changi

Re: [Haskell] Re: ANN: HDBC (Haskell Database Connectivity)

[Benjamin Franksen]

On Monday 09 January 2006 10:03, Axel Simon wrote:
> On Sun, 2006-01-08 at 14:51 +, Keean Schupke wrote:
> > My solution to this when developing a database library for my own
> > use was to define the API
> > in a bracket notation style, and only provide safe functions. The
> > idea is that the function obtains the resource, calls a function
> > passed as an argument, then frees the resource, so all resouces are
> > guaranteed to be freed in the correct order... for example:
> >
> > dbConnectWith ::  DbName -> (DbHandle -> IO Result) -> Result
> > dbConnectWith name workFn = do
> > handle <- dbConnectTo name
> > workFn handle `finally` dbDisconnect handle
> >
> > In this way you avoid finalizers... and everthing is safe providing
> > you only export the "with" style functions from the library...
> > Here's an example from the library, the connect function:
>
> I suppose you meant to write "result" rather than "Result". This
> style of functions is only safe if the user ensures that DbHandle is
> never returned as part of the result. You should have that in your
> documentation.

I wanted to mention this too, but you were quicker ;)

> As far as I can tell, the only general solution is to use finalizers
> and, if you really need to enforce a sequence of finialization,
> touchForeignPtr. 

Repeat: touchForeignPtr can NOT be used to enforce finalization order.

> A practical issue with touchForeignPtr is that it 
> cannot be conveniently called from another finalizer, since the
> latter live in C. 

What do you mean "live in C"? Can't or shouldn't finalizers be written 
in Haskell, too?

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

Re: [Haskell] Re: ANN: HDBC (Haskell Database Connectivity)

[Axel Simon]

Keean et al,

On Sun, 2006-01-08 at 14:51 +, Keean Schupke wrote:
> My solution to this when developing a database library for my own use 
> was to define the API
> in a bracket notation style, and only provide safe functions. The idea 
> is that the function obtains the resource, calls a function passed as an 
> argument, then frees the resource, so all resouces are guaranteed to be 
> freed in the correct order... for example:
> 
> dbConnectWith ::  DbName -> (DbHandle -> IO Result) -> Result
> dbConnectWith name workFn = do
> handle <- dbConnectTo name
> workFn handle `finally` dbDisconnect handle
> 
> In this way you avoid finalizers... and everthing is safe providing you 
> only export the "with" style functions from the library... Here's an 
> example from the library, the connect function:

I suppose you meant to write "result" rather than "Result". This style
of functions is only safe if the user ensures that DbHandle is never
returned as part of the result. You should have that in your
documentation.

As far as I can tell, the only general solution is to use finalizers
and, if you really need to enforce a sequence of finialization,
touchForeignPtr. A practical issue with touchForeignPtr is that it
cannot be conveniently called from another finalizer, since the latter
live in C. I can think of three solutions:

a) You keep all pointers to your database (handles, connections, etc) in
one C structure and keep one ForeignPtr to that. On deallocation, you
call a custom C function that frees all the objects in the C data
structure in the right sequence.

b) You wrap all C data structures in reference-counting objects. On
creation of a connection you increment the reference count of the
database. Each foreign pointer you create will also increment the
reference count. On deallocation of either, the reference count is
decremented and the object freed if it has dropped to zero.

c) In your special case you could wrap the data base in a StablePtr
whenever you create the first connection and subsequently count the
number of connections you create. You free the StablePtr when there are
no more connections.

Solution b) might be impossible to implement if the library itself frees
the pointers without consulting your reference count first. If the
library frees objects without asking you first, but allows some sort of
finalizers, then solution a) makes it possible to at least mark the
object as invalid (which all your Haskell functions would have to
check). Otherwise solution a) is a bit inefficient, especially if your
library calls Haskell functions and passes points to them -- in this
case you need to check if this points is already in your data structure
and insert it if necessary. Solution c) might be the easiest in your
case where the data base always outlives connections and pointers to
connections are never passed to Haskell except when they are created.

Axel.

> Chris Kuklewicz wrote:
> 
> >Benjamin Franksen wrote:
> >  
> >
> >>On Wednesday 04 January 2006 20:13, John Goerzen wrote:
> >>
> >>
> >>
> >>>Well, yes and no.  It would be impossible to garbage collect (and
> >>>thus finalize) any object for which references to it still exist. 
> >>>Statement handles in HDBC maintain references to the database handle
> >>>pointers, either directly or indirectly, so I can't see how it is
> >>>possible for a database handle to be finalized before the statement
> >>>handle in this situation.
> >>>  
> >>>
> >>Hi John,
> >>
> >>I fear it /is/ possible. This is a very unfortunate situation and one I 
> >>had quite some difficulties to understand, when Simon Marlow explained 
> >>it to me.
> >>
> >>The problem is that finalization of the statement handle might be 
> >>delayed indefinitely. The data dependencies between statement and 
> >>connection handle only ensures that whenever the statement handle is 
> >>alive, then too is the connection handle. But it does not say anything 
> >>about what happens in which order after /both/ are dead (garbage). As 
> >>soon as the connection handle to garbage, too, bothe handles can be 
> >>finalized in /any/ order.
> >>
> >>As I pointed out before, this is a very bad thing, because it makes 
> >>finalizers a whole lot less useful than they could be if an order 
> >>between finalizations could be specified (directly or indirectly). The 
> >>arguments against such a solution are mostly: (1) it is difficult to 
> >>implement efficienty and (2) the programmer could accidentally cause 
> >>finalizer deadlocks by specifying circular dependencies.
> >>
> >>Ben
> >>
> >>
> >
> >This is also mentioned in the documentation:
> >
> >http://www.haskell.org/ghc/docs/6.4.1/html/libraries/base/Foreign-ForeignPtr.html#v%3AtouchForeignPtr
> >
> >  
> >
> >>touchForeignPtr :: ForeignPtr a -> IO ()
> >>
> >>This function ensures that the foreign object in question is alive at the 
> >>given place in the sequence of IO actions. In particular withForeignPtr 
> >>does a tou