- Haskell - Haskell.org

Re: [Haskell] Simple IO Regions
by Sean Seefried 19 Jan '06

19 Jan '06

> Dominic Steinitz wrote: >> Can someone give an explanation of how the marks get built up? > > Suppose we have a class TypeEq a b so that the constraint TypeEq holds > whenever a and b are the same. Then the type Int and the type > TypeEq a Int => a > are kind of equivalent, right? The HList library plays many tricks > like that. The idea is that we can replace a definite type with a type > variable subject to some constraint (which we can fix later on). > In some respects, constraints are more convenient: they float, their > order does not matter, their duplicates are automatically > eliminated. Just what we need to build a set... > It ``follows'' then that instead of building the union of types, we > can build the union of constraints. The latter operation is trivial: > the typechecker does that all the time. If we restrict the scope of > the type variable by quantification, the scope of the corresponding > constraint is likewise restricted. The quantification also builds > eigen-variables (which are distinct from anything else) -- so we get > 'gensym' on the type level for free. That is all there is to it... Olge, I found this explanation really useful. I was wondering if you could explain to me what you mean by eigen-variable though? Sean

2 1

Bluespec, Inc. is seeking full-time software engineers
by Ravi Nanavati 18 Jan '06

18 Jan '06

Introduction: Bluespec, Inc. is a hardware design startup based in Waltham, Massachusetts that is building the next generation of Electronic Design Automation (EDA) tools. Bluespec's toolset, which is based on functional programming technology, delivers a high-level design and verification environment to current Verilog and VHDL designers of ASICs and FPGAs. Bluespec is the first high-level synthesis product that accelerates the design cycle and reduces verification costs while retaining the ability to deliver no-compromise hardware. Bluespec's technical team includes the noted programming-language luminaries Rishiyur Nikhil and Joe Stoy. Join Bluespec and be part of what's next in silicon design! For further details, please visit our website: www.bluespec.com Positions: Multiple openings for both entry-level and senior software engineers Roles and responsibilities: - Software engineers have end-to-end ownership of features and components within Bluespec's hardware synthesis and simulation toolset - starting with definition and continuing through architecture, implementation, testing and documentation. - They work directly with customers to resolve their critical technical issues. When necessary, they are also responsible for training new customers on the Bluespec toolset and being a "first contact" for customer support. - Engineers also must develop a strong, customer-focused understanding of Bluespec's product suite. They apply that understanding to developing prototype designs to flesh out new capabilities as well as testing and benchmarking existing features. - Engineers are also expected to be flexible and adapt to changing roles and responsibilities over time as the technical and business needs of the company evolve. Requirements: - BS/MS/Ph.D degree with Computer Science or Electrical Engineering as a major - Strong programming background with a wide variety of languages (languages of specific interest include Haskell, C, Tcl/Tk and Perl) - Functional programming experience strongly preferred - Hardware design experience strongly preferred - Knowledge of Verilog/VHDL/SystemVerilog/SystemC is a plus - Knowledge of current EDA products is a plus - Strong communication, leadership and interpersonal skills - Ability to thrive in a dynamic, rapidly-changing environment - Working knowledge of Linux/UNIX/Windows Where to Apply: Applicants should send resumes to skp(a)bluespec.com (Sathyam Pattanam, VP Engineering) or careers(a)bluespec.com (Human Resources). Principals only - no agencies, please.

1 0

RE: [Haskell] Simple IO Regions
by Simon Peyton-Jones 18 Jan '06

18 Jan '06

I really like the way you use a set of constraints (IN m1 ms, IN m2 ms, IN m3 ms) to maintain the set of marks. Previously I've thought of using a nested tuple type (m1, (m2, (m3 ()))) to maintain the set, but that is far less convenient. Very neat. Why do you need the instance IN () b ? Simon | -----Original Message----- | From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of | oleg(a)pobox.com | Sent: 17 January 2006 10:13 | To: haskell(a)haskell.org | Subject: [Haskell] Simple IO Regions | | | This message shows a very simple implementation of Monadic Regions | (for the particular case of IO and reading the file). The technique | *statically* guarantees that neither a file handle nor any computation | involving the handle can leak outside of the region that created | it. Therefore, the handle can be safely closed (and its resources | disposed of) whenever control leaves the corresponding 'withFile' | block. Many handles can be open simultaneously, the type system | enforces the proper nesting of their regions. The technique has no | run-time overhead and induces no run-time errors. Unlike the previous | implementation of monadic regions, only the basic extensions | (higher-ranked types and one two-parameter type class) are used. No | undecidable instances, no functional dependencies (let alone | overlapping instances) are required. In fact, the implementation uses | only one trivial typeclass and one trivial instance. | | Perhaps such an approach to File IO can be more widely used? It | trivially generalizes to database IO and other kinds of IO. | | The motivation for monadic regions has been best explained by: | | Brandon Moore wrote on Haskell Cafe: | > I'm assuming you understand how the type on runST and the STRef | > operations ensure that, even though you *can* smuggle out an STRef in | > the result from runST, you will never be able to use it again. | > | > The idea was to do the equivalent thing with databases: use fancy types | > to ensure that handle can only be used inside to origination withDB or | > withCursor or whatever, and the bracketing function can release the | > resource on the way out, without worrying about it being used again. | | Benjamin Franksen wrote: | | > I think this is an extremely good idea. I have been very frustrated | > with finalizers because of their limitations (can't rely on them being | > called at all), so have (reluctantly) been using the unsafe bracket | > version. Making it safe via a type system trick is really the way to | > go. | | | Let us start with the tests | | > {-# OPTIONS -fglasgow-exts #-} | > | > module IORegionsTest where | > | > import IORegions -- see below | > | > test0 = withFile "/etc/motd" (const $ return True) | > | > reader q = do | > c1 <- qGetChar q | > c2 <- qGetChar q | > return [c1,c2] | > | > test1 = withFile "/etc/motd" reader | > test1r = runIOM test1 >>= print | | Instead of handles, we have Qs -- marked handles. The are created by | the function withFile and used similar to regular handles. A special | IOM monad is a newtype away from the regular IO. The phantom type | parameter of the IOM monad maintains the marks of the regions. | | *IORegionsTest> :t reader | reader :: (Monad (IOM marks), IORegions.IN mark marks) => | Q mark -> IOM marks [Char] | | the type of the reader shows that it takes a marked handle and yields | a marked IO computation. The constraint IN assures that the | computation must be marked with the mark of the handle. | | If we attempt to leak the handle: | *> test2 = withFile "/tmp/i.hs" (\q -> return q) | | we get | Inferred type is less polymorphic than expected | Quantified type variable `mark' escapes | In the second argument of `withFile', namely `(\ q -> return q)' | | The following is OK: we perform the computation and return its result: | > test3 = withFile "/etc/motd" (\q -> (qGetChar q)) | | If we attempt to return the unperformed computation itself: | *> test4 = withFile "/tmp/i.hs" (\q -> return (qGetChar q)) | | we get | Could not deduce (IORegions.IN mark marks1) | from the context (IORegions.IN mark marks) | arising from use of `qGetChar' at IORegionsTest.h... | | As we said earlier, more than one handle can be at play at the same | time: | | > reader2 q1 q2 = do | > c1 <- qGetChar q1 | > c2 <- qGetChar q2 | > return [c1,c2] | > test5 = withFile "/etc/motd" (\q1 -> | > withFile "/etc/motd" (\q2 -> reader2 q1 q2)) | > | > test5r = runIOM test5 >>= print | | Incidentally, the inferred type of reader2 is | | *IORegionsTest> :t reader2 | reader2 :: (Monad (IOM marks), | IORegions.IN mark1 marks, | IORegions.IN mark marks) => | Q mark -> Q mark1 -> IOM marks [Char] | | Obviously, the resulting computation is marked with the marks of both | argument handles. | | With two handles, we can actually return a handle -- provided we | return an outermost handle from the innermost region (but not the | other way around). For example, the following is wrong | | *> test6 = withFile "/etc/motd" | *> (\q2 -> | *> do | *> q' <- withFile "/etc/motd" (\q -> return q) | *> qGetChar q') | | | but the following is OK: | > test7 = withFile "/etc/motd" | > (\q2 -> | > do | > q' <- withFile "/etc/motd" (\q -> return q2) | > qGetChar q') | | Ditto for the computation: | | The following is the improper leakage and leads to a type error: | | *> test8 = withFile "/etc/motd" | *> (\q2 -> | *> do | *> a <- withFile "/etc/motd" (\q -> return (qGetChar q)) | *> a) | | But the following is fine: | | > test9 = withFile "/etc/motd" | > (\q2 -> | > do | > a <- withFile "/etc/motd" (\q -> return (qGetChar q2)) | > a) | > | > test9r = runIOM test9 >>= print | | | -- The file IORegions.hs follows. | | {-# OPTIONS -fglasgow-exts #-} | | -- Simple IO Regions | | module IORegions (runIOM, qGetChar, withFile, | -- Only types are exported, not their data constructors! | Q, IOM) where | | import Control.Exception | import System.IO | | -- The marked IO monad. The data constructor is not exported. | -- The type 'marks' is purely phantom (and is never instantiated, actually) | newtype IOM marks a = IOM (IO a) deriving Monad | unIOM (IOM x) = x | | -- The marked IO handle. The data constructor is not exported. | newtype Q mark = Q Handle | | -- |IN mark marks| asserts that |mark| is a member of the mark set |marks| | -- The mark set is really a set, and the best of all, it's typechecker | -- that maintains it. We don't need to do anything at all. | class IN a b | instance IN () b | | -- Reading from a marked handle. The mark must be within the marks | -- associated with the IOM monad | qGetChar :: (IN mark marks) => Q mark -> IOM marks Char | qGetChar (Q h) = IOM $ hGetChar h | | -- There must not be an operation to close a marked handle! | -- withFile takes care of opening and closing (and disposing) of | -- handles. | | -- Open the file, add the markset constraint for the duration of the body, | -- and make sure the marked handle does not escape. | -- The marked handle is closed on normal or abnormal exit from the | -- body | -- The type system guarantees the strong lexical scoping of | -- withFile. That is, we can assuredly close all the handles after | -- we leave withFile because we are assured that no computations with | -- marked handles can occur after we leave withFile. | | withFile :: FilePath -> (forall mark. IN mark marks => Q mark -> IOM marks a) | -> IOM marks a | withFile filename proc = | IOM( | bracket | (openFile filename ReadMode) | (hClose) | (\handle -> unIOM $ proc ((Q handle) :: Q ()))) | | -- Running the IOM monad | runIOM :: (forall mark. IOM mark a) -> IO a | runIOM = unIOM | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

4 3

Time Profiling Haskell
by Thomas Davie 18 Jan '06

18 Jan '06

I have a program that I *know* can run faster... I know there's duplicated effort in there somewhere, the question is where. The heap profile reflects exactly what I would expect it to, so I want a reasonably accurate time profile. Is there any way to get such a thing? Thanks Bob

2 1

Haskell Weekly News: January 16, 2006
by dons＠cse.unsw.edu.au 17 Jan '06

17 Jan '06

Haskell Weekly News: January 16, 2006 Greetings, and thanks for reading the 20th issue of HWN, a weekly newsletter for the Haskell community. Each Monday, new editions are posted to [1]the Haskell mailing list and to [2]The Haskell Sequence. [3]RSS is also available. 1. http://www.haskell.org/mailman/listinfo/haskell 2. http://sequence.complete.org/ 3. http://sequence.complete.org/node/feed New Releases * hdbc-odbc. John Goerzen [4]released 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 4. http://article.gmane.org/gmane.comp.lang.haskell.general/13007 Resources and Tools * Haskell Performance Resources. Simon Marlow [5]opened up a [6]wiki page to collect the community wisdom on writing high performance Haskell code. This is particularly relevant given the discussions regarding the language shootout recently, with many interesting techniques proposed. 5. http://article.gmane.org/gmane.comp.lang.haskell.general/13018 6. http://haskell.org/haskellwiki/Haskell_Performance_Resource Discussion * Arrays. Bulat Ziganshin [7]wrote an interesting RFC on the various Haskell array interfaces. 7. http://article.gmane.org/gmane.comp.lang.haskell.general/12992 * Functional Java. Graham Klyne [8]alerted us to [9]FunctionalJ, an open source library for functional programming in Java. This might be useful to those unfortunates trapped on the JVM. Additionally, Bjorn Bringert [10]mentioned a similar library, Higher-Order Java (HOJ), he wrote a few years ago. 8. http://article.gmane.org/gmane.comp.lang.haskell.cafe/10898 9. http://www.theserverside.com/news/thread.tss?thread_id=38430 10. http://article.gmane.org/gmane.comp.lang.haskell.cafe/10900 * Data structures. Duncan Coutts was [11]looking for an efficient data structure to implement a sequence data type with indexed insert/delete/lookup. 11. http://thread.gmane.org/gmane.comp.lang.haskell.general/13073 * Language Shootout, continued. Many entries have been improved on the [12]Computer Language Shootout, and after several years of complaints that micro-benchmarks are meaningless, and that the tests are biased against purely functional languages, it's great to see that [13]Haskell is now ranked 2nd overall. 12. http://shootout.alioth.debian.org/gp4/ 13. http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all Darcs Corner * darcsweb 0.14. Alberto Bertogli [14]released darcsweb 0.14. 14. http://article.gmane.org/gmane.comp.version-control.darcs.user/9207 Quotes of the Week <palomer> grr, sml can't derive Ord <palomer> sml is a pain to use sometimes <palomer> but sometimes it's a joy! <palomer> ugh, I take it back, it's a pain Contributing to HWN You can help us create new editions of this newsletter. Please see the [15]contributing information, send stories to dons -at- cse.unsw.edu.au. The Darcs repository is available at darcs get http://www.cse.unsw.edu.au/~dons/code/hwn 15. http://sequence.complete.org/hwn-contrib

2 2

Call for Papers - GPCE'06
by Emir Pasalic 17 Jan '06

17 Jan '06

Apologies for multiple/overlapping posts. ------------------------------------------------------------------------ -- CALL FOR TECHNICAL PAPERS Fifth International Conference on Generative Programming and Component Engineering (GPCE'06) http://www.gpce.org/06/ October 22-26, 2006 Portland, Oregon (co-located with OOPSLA'06) Sponsored by ACM SIGPLAN, in cooperation with ACM SIGSOFT. Proceedings to be published by ACM Press. ------------------------------------------------------------------------ -- IMPORTANT DATES * Pre-submission: April 30, 2006 * Submission: May 5, 2006, 23:59, Apia time (firm deadline, no extensions) * Notification: June 28, 2005 SCOPE Generative and component approaches are revolutionizing software development similar to how automation and components revolutionized manufacturing. Generative Programming (developing programs that synthesize other programs), Component Engineering (raising the level of modularization and analysis in application design), and Domain-Specific Languages (elevating program specifications to compact domain-specific notations that are easier to write, maintain, and analyze) are key technologies for automating program development. GPCE provides a venue for researchers and practitioners interested in foundational techniques for enhancing the productivity, quality, and time-to-market in software development that stems from deploying standard componentry and automating program generation. In addition to exploring cutting-edge techniques for developing generative and component-based software, our goal is to foster further cross-fertilization between the software engineering research community and the programming languages community. ------------------------------------------------------------------------ -- SUBMISSIONS 10 pages in SIGPLAN proceedings style (sigplanconf.cls) reporting research results and/or experience related to the topics above (PC co-chairs can advise on appropriateness). We particularly encourage original high-quality reports on applying GPCE technologies to real-world problems, relating ideas and concepts from several topics, or bridging the gap between theory and practice. ------------------------------------------------------------------------ -- TOPICS GPCE seeks contributions in software engineering and in programming languages related (but not limited) to: * Generative programming Reuse, meta-programming, partial evaluation, multi-stage and multi-level languages, and step-wise refinement Semantics, type systems, symbolic computation, linking and explicit substitution, in-lining and macros, templates, and program transformation Runtime code generation, compilation, active libraries, synthesis from specifications, development methods, generation of non-code artifacts, formal methods, and reflection * Generative techniques for Product-line architectures Distributed, real-time and embedded systems Model-driven development and architecture * Component-based software engineering Reuse, distributed platforms and middleware, distributed systems, evolution, patterns, development methods, deployment and configuration techniques, and formal methods * Integration of generative and component-based approaches * Domain engineering and domain analysis Domain-specific languages (DSLs) including visual and UML-based DSLs * Separation of concerns Aspect-oriented and feature-oriented programming, Intentional programming and multi-dimensional separation of concerns * Industrial applications Reports on applications of these techniques to real-world problems are especially encouraged, as are submissions that relate ideas and concepts from several of these topics, or bridge the gap between theory and practice. The program committee is happy to advise on the appropriateness of a particular subject. ------------------------------------------------------------------------ -- General Chair Stanislaw Jarzabek (National University of Singapore, Singapore) Program Committee Program Chairs: Douglas Schmidt (Vanderbilt University, USA) Todd Veldhuizen (Indiana University, USA) Program Committee Members: Giuseppe Attardi (University of Pisa, Italy) Elisa Baniassad (Chinese University of Hong Kong, China) Don Batory (University of Texas at Austin, USA) Ira Baxter (Semantic Designs, USA) Shigeru Chiba (Tokyo Institute of Technology, Japan) Charles Consel (INRIA/LaBRI, France) Krzysztof Czarnecki (University of Waterloo, Canada) Aniruddha Gokhale (Vanderbilt University, USA) Jeff Gray (U. of Alabama Birmingham, USA) George Heineman (Worcester Polytechnic Institute, USA) Zhenjiang Hu (University of Tokyo, Japan) H.-Arno Jacobsen (University of Toronto, Canada) Oleg Kiselyov (FNMOC, USA) Fabio Kon (University of São Paolo, Brazil) Karl Lieberherr (Northeastern University, USA) Joe Loyall (BBN Technologies, USA) Mira Mezini (Darmstadt University of Technology, Germany) Torben Æ. Mogensen (DIKU, Denmark) Emir Pasalic (Rice University, USA) Calton Pu (Georgia Tech, USA) Tim Sheard (Portland State University, USA) Yannis Smaragdakis (Georgia Tech, USA) Michael Stal (Siemens, Germany) Peri Tarr (IBM TJ Watson, USA) Peter Thiemann (Freiburg University, Germany) Eelco Visser (Utrecht University, The Netherlands) Workshops/Tutorials chairs: Christa Schwanninger (Siemens, Germany) Arno Jacobsen (University of Toronto, Canada) Publicity chair: Emir Pasalic (Rice University, USA) Steering Committee: Don Batory (University of Texas at Austin, USA) Krzysztof Czarnecki (University of Waterloo, Canada) Ulrich Eisenecker (University of Leipzig, Germany) Stanislaw Jarzabek (National University of Singapore, Singapore) Eugenio Moggi (University of Genoa, Italy) Greg Morrisett (Harvard University, USA) Frank Pfenning (Carnegie Mellon University, USA) Tim Sheard (Portland State University, USA) Yannis Smaragdakis (Georgia Tech, USA) Walid Taha (Rice University, USA) For additional information, clarification, or questions please feel free to contact the Program Committee Co-chairs (Gpce06-chairs-l(a)mailman.rice.edu) ------------------------------------------------------------------------ -- GPCE Tutorials and Workshops GPCE Tutorials, extending over a half or full day, give a deeper or broader insight than conventional lectures. GPCE Workshops provide intensive collaborative environments, where generative and component technologists meet to discuss and resolve challenging problems in the field. Tutorial and workshop proposals are due Mar 18, 2006.

1 0

Haskell DB bindings (was Re: ANN: HDBC (Haskell Database Connectivity)
by Tim Docker 17 Jan '06

17 Jan '06

oleg(a)pobox.com 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

5 5

darcsweb installed
by Simon Marlow 17 Jan '06

17 Jan '06

I have installed darcsweb on darcs.haskell.org. To browse the available darcs repositories, go here: http://darcs.haskell.org/darcsweb It's also available as http://hackage.haskell.org/darcsweb. Note that currently I have omitted GHC, the reason being that the GHC repository is so big that some of the operations on a file (eg. history, annotate) cause darcs to eat up CPU for several minutes on the server. So to avoid the server becoming bogged down with darcs processes I've just omitted the GHC repository for now. Cheers, Simon

2 1

Spring School on "Datatype-generic programming", Call for Participation
by Fermin Reig 17 Jan '06

17 Jan '06

(Apologies for multiple copies) Call for Participation Spring School on Datatype-Generic Programming http://www.cs.nott.ac.uk/ssdgp2006/ University of Nottingham, UK 24-27 April 2006 ************ Background and objectives ************ Generic programming is a thriving research area aimed at making programming more effective by making it more general. This school aims to give participants insights into the applications of datatype-generic programming and the current research challenges in the area. This school is a successor to the Summer School and Workshop on Generic Programming, held in Oxford in August 2002 (lecture notes appeared as volume 2793 of LNCS). ************ Technical programme ************ The lectures will be tutorial-style (as opposed to conference-style) and will be accessible to beginning computing science postgraduates. The scientific programme consists of six courses given by renowned specialists, and a student session. The list of courses is the following: * Thorsten Altenkirch (University of Nottingham): (in collaboration with Conor McBride and Peter Morris) Generic programming with dependent types * Jeremy Gibbons (University of Oxford): Design Patterns as Higher-Order Datatype-Generic Programs * Ralf Hinze (Universitat of Bonn): Generic Programming, Now! (in collaboration with Andres Loeh) * Johan Jeuring (Universiteit Utrecht): Comparing Approaches to Generic Programming (in collaboration with Ralf Hinze and Andres Loeh) * Ralf Laemmel (Microsoft) The next 700 traversal approaches * Tim Sheard (Portland State University): Putting the Curry-Howard Isomorphism to work. Copies of the draft lecture notes will be provided to all participants. The purpose of the student session is to give students an opportunity to present their work and get feedback. Registrants are invited to propose short talks (15-20 min). The selection will be based on abstracts of 150-400 words. ************ Social programme ************ A conference dinner will be organised (attendance at which will be charged seperately). ************ Organisers ************ Roland Backhouse (University of Nottingham) Jeremy Gibbons (University of Oxford) Ralf Hinze (Universitat Bonn) Johan Jeuring (Universiteit Utrecht) Fermin Reig (University of Nottingham) ************ Co-location ************ The Symposium on Trends in Functional Programming (TFP 2006), and the Conference of the Types Project (TYPES 2006) will be held in Nottingham the week before this spring school. ************ Registration and cost ************ To register, send an email to the following address: gp2006(at)cs.nott.ac.uk A small fee will be charged to cover photocopying of the draft proceedings, coffee, etc. ************ Accommodation ************ Participants are expected to arrange their own accommodation. See the school's web site for information about accommodation in the campus and its vicinity. ************ APPSEM ************ This is an APPSEM affiliated event. APPSEM funds can be used to support participants from APPSEM affiliated sites. ************ Further information ************ Web: http://www.cs.nott.ac.uk/ssdgp2006/ Email: gp2006(at)cs.nott.ac.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

1 0

RE: [Haskell] Re: haskell.org Public Domain
by Simon Peyton-Jones 17 Jan '06

17 Jan '06

I'm no expert on licenses, but I'd like to say what I hope we can achieve GOALS A) It should be easy for people to contribute to the Wiki. In particular, it should be easy for multiple people to contribute to a single Wiki page, so that the question "who is the author" has (by design) no clear answer. B) It should be easy to use material taken from the Wiki: i) it should be easy to know what the license is ii) the license should make it easy to use the material To me B(i) suggests that we should avoid a multiplicity of licenses. Having a different license per-page would be bad enough, but the multiple-authorship of a Wiki means that we could end up with different licenses for different bits of the same page. My suggestion would be * One license for the Wiki. If a contributor wants to put up material with a different license, then link to it as Udo suggested. (This also makes it clear that the link is to material that is not to be edited by others, whereas by definition the entire Wiki actively solicits editing by others.) * That license should be maximally permissive. Anything viral defeats B(ii). Preferably even more permissive than BSD (e.g. no obligation to display a copyright notice. Who would the copyright notice be *to*?) I'm not fussy about the details. Just some way of saying "You can do what you like with this material". Simon | -----Original Message----- | From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Wolfgang | Jeltsch | Sent: 10 January 2006 22:30 | To: haskell(a)haskell.org | Subject: Re: [Haskell] Re: haskell.org Public Domain | | Am Dienstag, 10. Januar 2006 23:03 schrieb John Meacham: | > [...] | | > I would say something like 'contributions and any derivations must be | > usable for any purpose by anyone in perpetuity without restriction' so | > that public domain, BSD, or the GHC license are all fine. | | First, the GHC license is a BSD-style license as far as I know. Second, | BSD-style licenses have restrictions. The restriction I remember is that | derivative works have to include the original copyright notice, the | disclaimer, etc. | | If we do as you propose, different licenses could be chosen and the "user" | wouldn't know what the exact licensing terms of this or that article are. I | think, it is better to choose one permissive license for all the content. | | > [...] | | > John | | Best wishes, | Wolfgang | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

15 40