[OT] Re: [Haskell-cafe] Tricks for making low level haskell hacking easier
On 2/10/07, Donald Bruce Stewart [EMAIL PROTECTED] wrote: 1) Use Hscolour to pretty-ifiy the Core so its more parsable: ghc -O Foo.hs -ddump-simpl | HsColour -tty | less -r will colourise the Core, and pipe it into less (which will display the metachars). A screenshot: http://www.cse.unsw.edu.au/~dons/tmp/screen-core.png Just out of curiosity, what window manager is that? Mathieu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [OT] Re: [Haskell-cafe] Tricks for making low level haskell hacking easier
0xbadcode: On 2/10/07, Donald Bruce Stewart [EMAIL PROTECTED] wrote: 1) Use Hscolour to pretty-ifiy the Core so its more parsable: ghc -O Foo.hs -ddump-simpl | HsColour -tty | less -r will colourise the Core, and pipe it into less (which will display the metachars). A screenshot: http://www.cse.unsw.edu.au/~dons/tmp/screen-core.png Just out of curiosity, what window manager is that? That's dwm, the super minimal window manager. Spencer Janssen's actually attempting a rewrite in Haskell though, which should be fun. http://www.suckless.org/wiki/dwm -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [OT] Re: [Haskell-cafe] Tricks for making low level haskell hacking easier
Mathieu Boespflug [EMAIL PROTECTED] writes: On 2/10/07, Donald Bruce Stewart [EMAIL PROTECTED] wrote: metachars). A screenshot: http://www.cse.unsw.edu.au/~dons/tmp/screen-core.png Just out of curiosity, what window manager is that? Mathieu Looks like ratpoison. http://www.nongnu.org/ratpoison/ But give Ion3 a try. You'll love it. http://modeemi.cs.tut.fi/~tuomov/ion/ http://tinyurl.com/25sd9f VVV ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
feature request: indexing Haskell projects (Re: [Haskell-cafe] auto-completion for Vim 7)
[feature request near the end] Hi Neil, Documentation isn't my strong point :) i noticed that you often reply to feature requests by pointing to undocumented tools/features, either already released in secret, or forthcoming. not that it isn't nice to have those tools, but won't you lose track of your software and its capabilities at this rate (not to talk about your customers' confusion)?-) It was originally only intended to be an internal thing for Hoogle, but it does seem generally useful. in spite of the option name, it doesn't seem Hoogle-specific at all, nor does it really fall into the remit of Haddock as annotation processor. i used to think that type info and such could be added to tags-files, but that is also not quite right - tags files can be extended with such info, but they have no room for tags without source code reference. Haddock-ghc might be equipped to provide the information, but do we really want it to become a general information extractor? perhaps this kind of index generation should really be a feature of the Haskell implementation itself; and indeed, there are :browse and :info already. how about an :index command? You can always download hoogle.txt, or perhaps we could supply summary.txt with the HTML output as the documentation? The GHC people would have to be the ones to decide it - Hugs doesn't ship with documentation anyway. separate downloads go out of sync, so tools should be able to rely on info included with releases. as for documentation: one of the nicest features of windows GHC releases is the inclusion of html docs - i use that all the time. of course, Hugs comes with sources instead of docs, so when Hugs was still my main platform, :find was one of my favourite features. My experience with parsing haddock generated HTML is that its painful, and usually wrong. The indexes might be a bit clearer, but parsing out the type signatures and names was a nightmare. yes, it is a hack. and it is more pattern-based extraction than proper parsing. ghc-haddock will fix that. Extracting names from the index will also miss those without type signatures. for the libraries, anything not documented doesn't exist!-) but yes, until it is integrated with GHC, Haddock will not produce complete indices. which brings me back to my point that GHC(i) should produce those indices itself. $ ghc -e :b Data.Char I experimented with this as the means for getting information for Hoogle. It was fine, apart from extracting instances (you needed the instance and the type both to be in scope, which you can't really do, or the instance is missed). yes, if one wants instances, one could use :info class, but doing that automatically for every class becomes tedious quickly. also, the pretty printing really gets in the way of simple-minded post-processing. Hugs used to have a :browse all, but i don't recall what all meant there. so here is a feature request for Haskell implementations: in addition to :browse, :info, :[ce]tags, i'd like to see :index, as a way to dump the symbol table for a Haskell project and libraries (including those not available in source code). the output should include, for every available item: - identifier (unqualified name/symbol) - qualifier (module prefix) - namespace (function/data constructor, type/constructor, class, module,..) - type - package - source reference relative to package top - doc reference relative to package doc top all in an easy-to-process-by-various-tools format (think ide/editor, not usually written in Haskell itself), please?-) thanks, claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANN: HSH 1.2.0
Neil Mitchell wrote: Hi There are a couple of things about that function... First, I did see it, but its description is rather vague on what it does. From the description, it sounds like it is possible that it would not return an absolute path; I read it more as expanding symlinks. If it does indeed return an absolute path, I think that should be stated explicitly for clarity. More fatally it's only implemented on GHC, not for any reason, but because whoever originally implemented it only used GHC! It's explicitly #ifdef'd to do nothing (just a return) on other compilers. I also hate the name. I know plenty of people who wanted the function, but none who ever found it... I note that the deadline for discussion of System.FilePath has now passed (well, a long time ago :-), so it looks like it's going into base. Any final objections before we do this? Regarding canonicalizePath, I'd be perfectly happy to change its name and/or somehow make it more easily discoverable: does anyone want to make a proposal? Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANN: HSH 1.2.0
John Goerzen wrote: On Sat, Mar 03, 2007 at 05:06:16PM +, Paul Moore wrote: On 03/03/07, John Goerzen [EMAIL PROTECTED] wrote: I'm pleased to announce HSH 1.2.0. Since version 1.0.0 was announced a few days ago, there have been some improvements: I've had a little look, and it looks nice. However, as a mainly Windows user, I'd be interested to know - does it work on Windows (alternatively, is portability to Windows a goal)? It might be worth mentioning up front, if it's Unix-only. Presently, it is Unix-only, though it likely would run fine under Cygwin. I am not yet sure if the new System.Process is powerful enough for this. Upon initial examination, I believe that it is not because it lacks support for pipes. I don't know how Windows shells deal with piping, or even if they can. All I know is that DOS used to simulate it with temporary files, lacking any real multitasking. Windows has proper pipes these days, and System.Process.runInteractiveProcess creates pipes for you. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] HDBC Windows binaries with SQLite 3 support
Hallo list, I guess the subject line says it all. Can anybody help me? -- -alex http://www.ventonegro.org/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: HDBC Windows binaries with SQLite 3 support
Hallo list, I guess the subject line says it all. Can anybody help me? My instructions (i made it for myself! provided as is): --- SQLite setup (Windows). --- We'll need sqlite3.h. $ wget http://sqlite.org/sqlite-source-3_3_7.zip Copy sqlite3.h to c:\Programs\ghc\include\ Also sqlite3.dll library is needed. $ wget http://sqlite.org/sqlitedll-3_3_7.zip Put the library into two places! into c:\Programs\ghc - for compilation. into c:\WINDOWS\system32 - for execution. http://quux.org/devel/hdbc/ $ wget http://gopher.quux.org:70/devel/hdbc/hdbc_1.0.1.2.tar.gz; tar -xzf hdbc_1.0.1.2.tar.gz cd hdbc runhaskell Setup.lhs configure --enable-library-profiling runhaskell Setup.lhs build runhaskell Setup.lhs install $ wget http://gopher.quux.org:70/devel/hdbc/hdbc-sqlite3_1.0.1.0.tar.gz; tar -xzf hdbc-sqlite3_1.0.1.0.tar.gz cd hdbc-sqlite3 joe HDBC-sqlite3.cabal -- include-dirs: .,/usr/local/include -- Extra-Lib-Dirs: /usr/local/lib runhaskell Setup.lhs configure --enable-library-profiling runhaskell Setup.lhs build runhaskell Setup.lhs install cd testsrc ghc --make runtests.hs ./runtests ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: New release of regex packages
I would like to announce new versions of the regex-* packages. This announcement covers: Version Package Description 0.83 regex-base-- Type Classes and generic instances 0.90 regex-compat -- Uses regex-posix to provide old API 0.91 regex-dfa -- backend, pure haskell, no submatch capture 0.90 regex-parsec -- backend, pure haskell 0.91 regex-pcre-- backend, links against libpcre 0.91 regex-posix -- backend, links against standard c library 0.92 regex-tdfa-- backend, pure haskell (Posix semantics) 0.91 regex-tre -- backend, links against libtre (currently buggy) These all compile, install, and run a few test correctly. Most notably, I consider regex-tdfa to be of useful quality now. Summary of changes and recommendations: * all packages: ** import Text.Regex.XXX exposes (getVersion_Text_Regex_XXX :: Data.Version) which allows programs to access the current version number of the package ** LICENSE file provided (all are 3 clause BSD except regex-dfa is LGPL) * regex-base: ** BUGFIX: one of the RegexContext instances used tail unsafely ** RegexMaker now has makeRegexM and makeRegexOptsM for better error handling ** Extract has new instances for (Seq Char) and (ByteString.Lazy), as well as the previous [Char] and ByteString instances * all backends: ** Now support [Char], (Seq Char), ByteString, and ByteString.Lazy ** CHANGE: The (=~~) monadic match operators now use makeRegexM and will call 'fail' when a regular expression cannot be parsed. ** CHANGE: (import Text.Regex.BACKEND) now re-exports (module Text.Regex.Base) * regex-dfa: ** BUGFIX: No longer hangs on repeated nullable subpatterns * regex-tdfa: ** New backend in pure haskell that provides true Posix semantics ** Runs with excellent memory usage ** I recommend this backend for Posix extended regular expressions (leftmost longest). * regex-compat: No other changes, still uses regex-posix underneath, not recommended * regex-parsec: No other changes, I recommend regex-tdfa or regex-pcre instead * regex-pcre: No other changes, best provider of Perl's left-biased regular expressions * regex-posix: No other changes, very slow (on OS X the underlying C library is buggy) * regex-tre:No other changes, underlying libtre version 0.7.5 is still buggy Dependencies: All of the above packages have been updated to depend on regex-base=0.80. I have only tested with GHC 6.6 on Mac OS X 10.4.8 (PPC, 32bit). Porting the backends to other Haskell compilers should be possible, though they may not support the polymorphic type class API that regex-base provides. Porting to GHC 6.4 should work once the support for (Seq Char) and ByteString[.Lazy] has been edited or externally obtained. I think only regex-tdfa actually uses bang patterns at the moment, and those could also be removed when porting. Where to get more information and the packages themselves: There is a slowly developing wiki page at http://haskell.org/haskellwiki/Regular_expressions for holding more documentation relating to these packages. I have uploaded tar.gz sources for each of the packages to hackage: http://hackage.haskell.org/packages/hackage.html They are listed under the Text Category: http://hackage.haskell.org/packages/archive/pkg-list.html#cat:Text Development and bug fixes continue in the darcs repositories under http://darcs.haskell.org/packages/regex-unstable/ To checkout one of the above versions with darcs you can use commands like darcs get --partial --tag=0.83 regex-base where the --tag=0.83 may be omitted to get the latest unstable version To install the packages once you have the source: For regex-pcre and regex-tre (and perhaps regex-posix) you might need to edit the end of cabal file to provide Include and Lib directories to the corresponding C library. # Compile Setup.hs for better startup speed ghc --make Setup.hs -o setup # I use my own path and --user .I recommend doing this to avoid overwriting # the global regex-* from GHC 6.6 ./setup configure --enable-library-profiling --prefix=YOUR_PATH --user ./setup build ./setup install Producing haddock documentation may not work and may not be up to date, with the important exception of regex-base. Future Plans: * regex-base: add support for generalized indices instead of the current Int * regex-tdfa: Improve DFA algorithm and further limit memory allocation. Try to improve performance of ByteString.Lazy matching. Cheers, Chris Kuklewicz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: HDBC Windows binaries with SQLite 3 support
Hallo, On 3/5/07, ArtemGr [EMAIL PROTECTED] wrote: My instructions (i made it for myself! provided as is): Worked after some tweaks for my system. It was actually much easier than I thought. Thanks very much! -- -alex http://www.ventonegro.org/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] LGPL libraries
Hallo, Gtk2Hs and HDBC are both LGPL licensed, but aren't they always static linked? Is there a way to use them in closed-source programs? Cheers, -- -alex http://www.ventonegro.org/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lambdabot on Windows?
Thanks for the pointers - I'll give it a whirl. -- Iain Alexander [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell sequence hosting
Hi everyone, I've been hosting sequence.complete.org on my own server for awhile, but have found that I haven't had time to maintain it lately. I'm looking for someone else that might be willing/able to host and maintain it. It's using Drupal on MySQL, though a fairly old version of Drupal at the moment. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANN: HSH 1.2.0
On Mon, Mar 05, 2007 at 01:30:23PM +, Simon Marlow wrote: I don't know how Windows shells deal with piping, or even if they can. All I know is that DOS used to simulate it with temporary files, lacking any real multitasking. Windows has proper pipes these days, and System.Process.runInteractiveProcess creates pipes for you. But it is not suitable for this purpose. It returns Handles, but it doesn't let me specify Handles going in. That means that it is not possible to create a pipe going directly from program A to program B. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] LGPL libraries
On Mon, 2007-03-05 at 14:07 -0300, Alex Queiroz wrote: Hallo, Gtk2Hs and HDBC are both LGPL licensed, but aren't they always static linked? Is there a way to use them in closed-source programs? Well let me put it this way: I'm not going to sue you and I doubt any of the other contributers are either. When we last cleaned up our license story (standardising on LGPL 2.1) we weren't particularly aware of the static linking issue so we didn't include a specific static linking exemption. We could do that now but honestly it's a bit of a hassle since there are several copyright holders. I'm hoping that the issue will be solved by ghc being able to do produce packages as dynamic libs. If you're really worried (but I wouldn't be) then do recall that the static linking thing only requires that the end user be able to relink with a different version that preserves the same ABI. So you don't have to provide source for your closed source app, you'd just need to provide all the .o / .a files you need to link together to produce your final program. So it's a bit of a hassle but it does meet the requirements of the LGPL and allows a closed source app. So, concretely you'd do something like: ghc --make to build all the .o files for your app, ld -r -x them all together into one .o file. Ship that .o file along with any other closed source ghc package .a files and then anyone will be able to use (the right version of) ghc to link them together along with a modified version of the Gtk2Hs .a lib. Of course GHC doesn't make this especially easy especially since it doesn't make preserving ABIs very easy, but fortunately that's not really your problem. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] LGPL libraries
Hallo, On 3/5/07, Duncan Coutts [EMAIL PROTECTED] wrote: If you're really worried (but I wouldn't be) then do recall that the static linking thing only requires that the end user be able to relink with a different version that preserves the same ABI. So you don't have to provide source for your closed source app, you'd just need to provide all the .o / .a files you need to link together to produce your final program. So it's a bit of a hassle but it does meet the requirements of the LGPL and allows a closed source app. Yeah, was pĺanning to send an object file with the application to allow relinking. I was just curious about the LGPL because GHC always links everything statically. Thanks for the thorough answer! Cheers, -- -alex http://www.ventonegro.org/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] auto-completion for Vim 7
Claus, Stephan: I hope you don't mind me having put a link to your work at the
bottom ;)
(link below)
If someone knows of a simple way to generate a function/type list of
the standard modules, I'd love to hear about it. Generating such a
list on the fly each time is probably not an option, as it would be
too slow.
-Stephan
Hi Stephan.
I like your type hints! But I'd suggest using autoloading so that you
don't have to load those 4000+ lines each time you start vim.
I've had another closer look at my scripts I've written same time ago and I did
some profiling: Result: It is quite usable now.
It implements a very simple cached regex based function finding hack
Have a look at my simple installation instructions:
http://mawercer.de/marcweber/
and try echo
vl#dev#haskell#modules_list_cache_jump#ScanModuleForFunctions(getline(0,'$'))
= ===
abc :: Int - String
abc a = show
todo = notime
= ===
results in
{'abc': {'impl': 5, 'type': 4}, 'main': {'impl': 9}, 'todo': {'impl': 7}}
which means abc's type declaration can be found at line 4 and it is
implemented at line 5 ...
Its far from beeing perfect.
Shouldn't be too hard to add type information as well.
feedback welcome
Marc
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] MPTCs and rigid variables
| class Foo a b | a - b | instance Foo Int String | bar :: Foo Int b = b | bar = rargh | There is nothing wrong with this program. I have run into this | problem and I consider it to be a bug/weakness of the type checking | algorithm used by the implementation. | | (I also agree with you that the term rigid variable is rather | confusing because it is an artifact of the type checking algorithm | used by GHC.) Some brief comments a) I agree there is nothing wrong with this program, BUT it can't be translated into System F. That's why GHC rejects it. However, it *can* be translated into System FC (see System F with type equality coercions, on my home page). But doing so requires a new implementation of type inference for functional dependencies, and I have not done that yet. b) While the program is arguably OK, I have yet to see a really convincing application that needs it. Why not write bar :: String? c) I really want to get rid of functional dependencies altogether, in favour of associated types. Thus class Foo a where type Bar a instance Foo Int where type Bar Int = String bar :: Foo a = Bar a bar = rargh This too requires work on type inference, and we're actively working on that. 4. The rigid type variable thing isn't just an implementation question. What *would* you like the error message to say when you write f :: ([a], Int) - Int f (x:xs, y) = x+y Here we unify 'a' with Int, which is wrong. What would a nicer error message say? Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] LGPL libraries
Hi Gtk2Hs and HDBC are both LGPL licensed, but aren't they always static linked? Is there a way to use them in closed-source programs? If you are concerned about static linking, Yhc may offer a solution, since it produces bytecode files, which don't statically link to anything. Of course, it doesn't support either of the above libraries, but if avoiding static links to your number one priority its the best compiler to use :) As others have said though, I wouldn't worry overly about it. The whole concept of static linking being wrong, but dynamic linking being fine, when you can flip between the modes just by changing compiler, is just silly. You don't infringe (or uninfringe) copyright with a command line flag. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] LGPL libraries
On 3/5/07, Neil Mitchell [EMAIL PROTECTED] wrote: As others have said though, I wouldn't worry overly about it. The whole concept of static linking being wrong, but dynamic linking being fine, when you can flip between the modes just by changing compiler, is just silly. You don't infringe (or uninfringe) copyright with a command line flag. I am not a lawyer, but there are a couple of important points getting missed in this thread: (1) Few people have ever claimed that copyright law in the United States made any rational sense. Even so, Americans are subject to it, anybody who uses GPLed software may be subject to it, and given that the general trend is toward international treaties that subject their member nations to the copyright requirements of the nation with the most restrictive intellectual property laws, it may be safe to say that everyone is subject to it. That's just silly isn't a defense. (2) To paraphrase Eben Moglen, the legal basis for copyrighting software in the US is predicated on the notion that certain large numbers can be copyrighted. Thus, if you can infringe copyright by adding one to a large number, it suddenly doesn't seem so absurd that you can infringe copyright by setting a command line flag. (3) The GPL has never been tested in court, so debates about whether or not static linking can result in a GPL violation are ultimately academic, at least insofar as the real question is whether it's prudent for a company to use GPLed libraries in proprietary software (as the real question usually is). If someone is asking about GPL issues in the first place, it's probably because their boss told them our lawyers say we're not allowed to use anything GPLed, and thus trust me, we're not going to sue you isn't the answer they're looking for, even if it's a completely accurate answer. Since there are people reading this list who release their software under various flavors of the GPL, and who thus presumably care that the free software they sweat over will remain free in perpetuity, hopefully this reply isn't entirely off-topic! Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt I haven't got the slightest idea how to change people, but still I keep a long list of prospective candidates just in case I should ever figure it out. --David Sedaris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Pulling a monad out of a functor
Haskellers, Recently, I have come across a couple of situations in which I need to pull a monad out of a functor so to speak. The first time it was needed, I didn't think much of it, but the second time started me thinking whether there is already an existing construct for this. The type signatures I have in mind are: pull :: (Monad m, Functor f) = f (m a) - m (f a) fmapM :: (Monad m, Functor f) = (a - m b) - f a - m (f b) fmapM f = pull . fmap f You may notice that these are already defined for the List functor as 'sequence' and 'mapM'. It seems to me that if this were a class, the implementor would be defining a traversing order by defining pull; in the list case this traversing sequence is clearly defined as head to tail. I am wondering if there is already a construct for this that I am not aware of (a class, a way to defined it using monads and functors that I am not aware of, an idiom)? Is this something that frequently happens for others, or is it a sign a few of my designs have been flawed recently? Bryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] LGPL libraries
(3) The GPL has never been tested in court http://www.fsf.org/news/wallace-vs-fsf note that during this thread there was a note from a contributor to promise to not sue a potentially infriging use. you should be careful of such promises, particularly considering that some fsf licenses include copyright assignment...in which case it will be the fsf enforcing the gpl, not the original authors (which is the specific purpose of the assignment). the fsf has a vested interest in showing that their licenses have teeth, although more in the case of the glp than in the lgpl. http://www.gnu.org/licenses/why-assign.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] LGPL libraries
brad clawsie on 2007-03-05 20:30:24 -0800: (3) The GPL has never been tested in court http://www.fsf.org/news/wallace-vs-fsf note that during this thread there was a note from a contributor to promise to not sue a potentially infriging use. you should be careful of such promises, particularly considering that some fsf licenses include copyright assignment... No FSF licenses include, demand, or require copyright assignment. The FSF encourages developers assign them the copyright to pieces of free software for the reasons enumerated in the link you mentioned, but this assignment is not a requirement for using the GPL or LGPL. Case in point: the Linux kernel. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pulling a monad out of a functor
http://haskell.org/ghc/dist/current/docs/libraries/base/Data-Traversable.html pull is sequence, fmapM is mapM (also see the sequenceA, traverse functions for the more general case of applicative functors vs. monads) Stefan Ah yes, thank you! Saying It seems to me that if this were a class, the implementor would be defining a traversing order by defining pull should have tipped me off to check out the 'Traversable' class before asking (but, having probably only seen that class once or twice before in passing, it was probably too deep in my head for quick retrieval). Bryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
