[Haskell-cafe] Lisp like symbols in haskell
Hello, Has there already been attempts to introduce lisp like symbols in haskell? Thank you Regards J-C ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: hakyll-0.1
Tom Tobin wrote: The 3 clause BSD license is officially a GPL compatible license. See: http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses It is within the terms of the GPL to link GPL code to a bunch of BSD3 code as long as you abide by both the GPL and the BSD3 license. That really just means that BSD3 code can be used in GPL code; you still have to release your own code as GPL if you are including any GPL code. Having said that... I *really* wish Pandoc would switch to a non-copyleft license. The LGPL is still a copyleft license. Do you still have a problem with that? If Pandoc is LGPL, then I think that means we are dealing with an entirely different situation, one in which the library user can choose whatever license he or she likes for his or her own code as long as any modifications to the LGPL'd library itself are released under the LGPL. Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lisp like symbols in haskell
On Tue, 2009-12-08 at 09:21 +0100, jean-christophe mincke wrote: Hello, Has there already been attempts to introduce lisp like symbols in haskell? I'm not sure if this answers your question, but there is an attempt to mix Lisp syntax with Haskell semantics, called Liskell. Description: http://clemens.endorphin.org/ILC07-Liskell-draft.pdf Latest news: http://blog.clemens.endorphin.org/2009/01/liskell-standalone.html Have fun, -- Ariel J. Birnbaum ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: hakyll-0.1
Gregory Crosswhite wrote: I *really* wish Pandoc would switch to a non-copyleft license. The LGPL is still a copyleft license. Do you still have a problem with that? If Pandoc is LGPL, I wasn't suggesting that pandoc was LGPL, I was probing the other posters attitudes to copyleft licenses other than the GPL. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lisp like symbols in haskell
Hi Jean-Christophe There is no mention in the 'History of Haskell' which is probably the most authoritative published reference http://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-haskell/index.htm If someone wanted to introduce symbols, they would presumably have to propose an extension to the type system to handle them - don't symbols in Lisp and Scheme rely on lists being dynamically typed? Best wishes Stephen 2009/12/8 jean-christophe mincke jeanchristophe.min...@gmail.com: Hello, Has there already been attempts to introduce lisp like symbols in haskell? Thank you Regards J-C ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] ANN: hakyll-0.1
Gregory Crosswhite wrote: Tom Tobin wrote: The 3 clause BSD license is officially a GPL compatible license. See: http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses It is within the terms of the GPL to link GPL code to a bunch of BSD3 code as long as you abide by both the GPL and the BSD3 license. That really just means that BSD3 code can be used in GPL code; you still have to release your own code as GPL if you are including any GPL code. The main licence of darcs is GPL, but I've licensed all my contributions to it as BSD3. My view of this is that while darcs as a whole is obviously still GPL, any of my contributions that can be extracted independently can be used in other projects under BSD3. I'd say that with hakyll, the library itself can be under BSD3 but any executable you produce from it at the moment will necessarily be GPL. Not sure if there's any good way to communicate this fact in the metadata, though. Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lisp like symbols in haskell
jean-christophe mincke wrote: Hello, Has there already been attempts to introduce lisp like symbols in haskell? Thank you Regards J-C J-C, Do you mean symbols as in interned strings with an O(1) string comparison method? I would love to have those, but I don't see an easy way to get it without being in the IO or ST monad. Mike ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lisp like symbols in haskell
Aren't symbols made redundant by algebraic data types? On Tue, Dec 8, 2009 at 4:48 PM, Michael Vanier mvanie...@gmail.com wrote: jean-christophe mincke wrote: Hello, Has there already been attempts to introduce lisp like symbols in haskell? Thank you Regards J-C J-C, Do you mean symbols as in interned strings with an O(1) string comparison method? I would love to have those, but I don't see an easy way to get it without being in the IO or ST monad. Mike ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lisp like symbols in haskell
I think stable names can be used where symbols are used in scheme. I think there are better alternatives for different use cases in haskell. For example, symbols are often used to tag values - haskell has pattern matching on constructors. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lisp like symbols in haskell
Probably in the same way integers are made redundant : data Integer = 0 | 1 | 2 | Cheers, Thu 2009/12/8 Lyndon Maydwell maydw...@gmail.com: Aren't symbols made redundant by algebraic data types? On Tue, Dec 8, 2009 at 4:48 PM, Michael Vanier mvanie...@gmail.com wrote: jean-christophe mincke wrote: Hello, Has there already been attempts to introduce lisp like symbols in haskell? Thank you Regards J-C J-C, Do you mean symbols as in interned strings with an O(1) string comparison method? I would love to have those, but I don't see an easy way to get it without being in the IO or ST monad. Mike ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Lisp like symbols in haskell
Hello Michael, Tuesday, December 8, 2009, 11:48:09 AM, you wrote: Do you mean symbols as in interned strings with an O(1) string comparison method? I would love to have those, but I don't see an easy way to get it without being in the IO or ST monad. you could intern IO usage with unsafePerformIO. it's implemented in GHC sources, afair it's FastString type or so -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lisp like symbols in haskell
On Tue, Dec 8, 2009 at 1:48 AM, Michael Vanier mvanie...@gmail.com wrote: Do you mean symbols as in interned strings with an O(1) string comparison method? I would love to have those, but I don't see an easy way to get it without being in the IO or ST monad. data Sym = Sym String Hash fromString :: String - Sym fromString s = Sym s (hash s) instance Eq Sym where Sym _ h == Sym _ h' = h == h' Much as I am uncomfortable with hash-based equality. 1/2^256, despite being very small, is not zero. It is begging for a mysterious failure someday. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: hakyll-0.1
On Tue, Dec 8, 2009 at 8:22 AM, Gregory Crosswhite [..] If Pandoc is LGPL, then I think that means we are dealing with an entirely different situation, one in which the library user can choose whatever license he or she likes for his or her own code as long as any modifications to the LGPL'd library itself are released under the LGPL. As has been discussed a few times before on this list, using LGPL for Haskell modules has its own set of problems when using GHC, due to the current state of linking in that compiler. From what I've read we're on a path to salvation with 6.12, but we're still not at the destination. /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: new installment of failure framework
Michael, Although I like the idea of improving the way that failures are handled in Haskell, I am having trouble seeing any reason to use your framework. If a function is always assumed to succeed given certain pre-conditions, and somewhere along the lines my code discovers that one of these had been violated, then I throw an exception in order to communicate to myself the manner in which I screwed up. If a function might either succeed or fail for a very specific reason, then I use a Maybe because the caller will know exactly what problem is being signaled by Nothing. If a function might fail for one of many reasons and the caller might care about learning more about the problem, then I use an Either so that I can report the details of the problem. In each of the latter two cases, I can already use monads to handle the errors in a relatively convenient manner. In the first case I usually want the program to die right away and let me know where I screwed up, but if for some reason I wanted to continue even given arbitrary unanticipated problems in a particular computation the I use an exception handler. Given that all of the scenarios that I encounter are already handled by the functionality the standard libraries, it is not clear to me what your framework actually offers. I am not writing this to shoot your framework down, but rather to voice my thoughts aloud in order to hear your response to them, since if there is a use scenario that I am missing in which your framework would be ideal then I would be interested in hearing about it. Cheers, Greg On Dec 6, 2009, at 8:58 PM, Michael Snoyman wrote: We'd like to announce the next installment of the Failure Framework. Based on feedback, our main goals in this release is to reduce the number of external dependencies and avoid complications with monad transformer libraries at the core of the framework. We have made the following changes: * Failure is not tied directly to monads anymore. The main typeclass is Failure, which provides the failure function. MonadFailure, ApplicativeFailure and FunctorFailure are provided for convenience. * The Failure typeclass is now located in the failure package, which has no dependencies. All code dealing with transformers and mtl has been factored into control-monad-failure and control-monad-failure-mtl, respectively. In addition, we are simultaneously releasing the following packages: * safe-failure provides safe versions of dangerous, non total functions, such as head, by returning failures. It depends exclusively on failure. * attempt provides a concrete data type for handling extensible exceptions as failures. It depends exclusively on failure. * control-monad-attempt provides a monad transformer for attempt using the transformers library. We do not provide currently an mtl version of this package, but can provide one if there is demand. * control-monad-exception, explicitly typed, checked exceptions with monadic stack traces. Below are the links to the packages just released. Enjoy! http://hackage.haskell.org/package/failure-0.0.0 http://hackage.haskell.org/package/control-monad-failure-0.6.0 http://hackage.haskell.org/package/control-monad-failure-mtl-0.6.0 http://hackage.haskell.org/package/safe-failure-0.4.0 http://hackage.haskell.org/package/attempt-0.2.0 http://hackage.haskell.org/package/control-monad-attempt-0.0.0 http://hackage.haskell.org/package/control-monad-exception-0.8.0 http://hackage.haskell.org/package/control-monad-exception-mtl-0.8.0 http://hackage.haskell.org/package/control-monad-exception-monadsfd-0.8.0 http://hackage.haskell.org/package/control-monad-exception-monadstf-0.8.0 Michael Snoyman, Pepe Iborra, Nicolas Pouillard ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Allowing hyphens in identifiers
Has there been any serious suggestion or attempt to change the syntax of Haskell to allow hyphens in identifiers, much like in Lisp languages? E.g. hello-world would be a valid function name. -- Deniz Dogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lisp like symbols in haskell
Luke Palmer lrpal...@gmail.com writes: data Sym = Sym String Hash fromString :: String - Sym fromString s = Sym s (hash s) instance Eq Sym where Sym _ h == Sym _ h' = h == h' Much as I am uncomfortable with hash-based equality. 1/2^256, despite being very small, is not zero. It is begging for a mysterious failure someday. How about: instance Eq Sym where Sym s h == Sym s' h' = h == h' s == s' So, very fast if the hashes fail to match, only marginally slower than just the string comparison if they are equal. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Allowing hyphens in identifiers
Deniz Dogan deniz.a.m.do...@gmail.com writes: Has there been any serious suggestion or attempt to change the syntax of Haskell to allow hyphens in identifiers, much like in Lisp languages? E.g. hello-world would be a valid function name. I (among others) suggested it right at the beginning when we were first defining the lexical syntax, and have raised the possibility again a couple of times now that unicode hyphens are available, but it wasn't liked at the beginning and hasn't excited much interest since. Why do you want them? -- Jón Fairbairn jon.fairba...@cl.cam.ac.uk http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2009-01-31) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lisp like symbols in haskell
I think lisp like symbols could be quite useful in the context of embedded DSL to create ... well... symbols that can be interpreted as variables in that DSL. I can imagine something such as a small relational DSL i.e Without symbols we have several alternatives: 1. Symbols are written as strings (and possibly automatically lifted to Symbol string if necessary, It is possible for nums I do not know for strings). Moreover the system should be able to tell the difference between a string representing a symbol and a string representing a string value Table_A 'where' Att_Name = Smith 'and' Att_Age 10 2. Using algebraic data type: the syntax looks better but the data type must be declared before. In this case we must know in advance all the attributes and table names (including all the names used in 'rename' relational opération - the 'as' in sql). Table_A 'where' Att_Name = Smith 'and' Att_Age 10 3 If we had symbols. Note lisp like symbols might well be values of some predefined type Symbol. Just like 2,3, 56 are values of the predefined type Integer. Table_A 'where' Att_Name = Smith 'and' Att_Age 10 Here the problem is that the compiler should be able to tell the difference between a symbol and an undefined variable. Lisp solves it by prefixing the symbol with a little '. Smalltalk prefixes it with #. So with unambiguous symbols: 'Table_A 'where' 'Att_Name = Smith 'and' 'Att_Age 10 or #Table_A 'where' #Att_Name = Smith 'and' #Att_Age 10 Regards J-C ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: hakyll-0.1
Gregory Crosswhite gcr...@phys.washington.edu writes: That really just means that BSD3 code can be used in GPL code; you still have to release your own code as GPL if you are including any GPL code. Not quite true: it means that any code your BSD3 library gets used in has to have a GPL-compatible license: http://www.fsf.org/licensing/licenses/gpl-faq.html#IfLibraryIsGPL (this is the approach I've used for Graphalyze since I use Pandoc as a default library for document generation; later on I'm planning on re-doing the document part in which case it will _have_ to use Pandoc and thus I'll re-license the library). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: hakyll-0.1
2009/12/8 Ivan Lazar Miljenovic ivan.miljeno...@gmail.com: Gregory Crosswhite gcr...@phys.washington.edu writes: That really just means that BSD3 code can be used in GPL code; you still have to release your own code as GPL if you are including any GPL code. Not quite true: it means that any code your BSD3 library gets used in has to have a GPL-compatible license: http://www.fsf.org/licensing/licenses/gpl-faq.html#IfLibraryIsGPL (this is the approach I've used for Graphalyze since I use Pandoc as a default library for document generation; later on I'm planning on re-doing the document part in which case it will _have_ to use Pandoc and thus I'll re-license the library). I wonder how APIs are covered. If your code use an API implemented by Pandoc (GPL) and also by another library licensed under, say, BSD3. Why should your code be licensed under GPL ? The only difference would be a build-depends in the .cabal. Has anyone an idea about this ? Cheers, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
2009/12/8 Jon Fairbairn jon.fairba...@cl.cam.ac.uk: Deniz Dogan deniz.a.m.do...@gmail.com writes: Has there been any serious suggestion or attempt to change the syntax of Haskell to allow hyphens in identifiers, much like in Lisp languages? E.g. hello-world would be a valid function name. I (among others) suggested it right at the beginning when we were first defining the lexical syntax, and have raised the possibility again a couple of times now that unicode hyphens are available, but it wasn't liked at the beginning and hasn't excited much interest since. Why do you want them? I just like the standard Lisp naming convention better than camel casing and saw someone on #haskell mentioning it the other day. No biggie though. -- Deniz Dogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: hakyll-0.1
minh thu not...@gmail.com writes: I wonder how APIs are covered. I don't think an API would be covered. The API is the standard way to use something, if copyright licenses cover usage like this, any executable will be a derivative of the operating system and (possibly) the compiler. Why should your code be licensed under GPL? I think your code is covered by whatever license you wish. An aggregate work, on the other hand, would need to be covered by the GPL, and all source code would have to be available under GPL terms. So if you distribute your code linked to or incorporating the GPL library, the whole must conform to the GPL license (source availability and redistributatbility, etc). Your contributions could still be licensed under a different license (e.g. BSD), as long as the licensing doesn't prevent somebody else to pick it up and relicense it under GPL. At least, that's how I understand things. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lisp like symbols in haskell
jeanchristophe.min...@gmail.com wrote: I think lisp like symbols could be quite useful in the context of embedded DSL to create ... well... symbols that can be interpreted as variables in that DSL. Well for such use-case you could use either stable names, or recode them into a state monad- you will get either a global i.e. lisp like unique symbols, or their equivalent within a state context. Or some variation of the code posted previously in this thread. http://www.haskell.org/ghc/docs/6.10.4/html/libraries/base/System-Mem-StableName.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Zumkeller numbers
Am Dienstag 08 Dezember 2009 08:44:52 schrieb Ketil Malde: Richard O'Keefe o...@cs.otago.ac.nz writes: factors n = [m | m - [1..n], mod n m == 0] -- saves about 10% time, seems to give the same result: factors n = [m | m - [1..n `div` 2], mod n m == 0]++[n] Even faster (for large enough n): factors n = mergeAll [if q == d then [d] else [d, q] | d - [1 .. isqrt n] , let (q,r) = n `divMod` d, r == 0] (But checking against primes is even faster, it seems) That's peanuts, the important part is to partition smaller numbers (i.e. (sigma(n)-2*n) vs. sigma(n)). Still faster would be using the fact that if n is Zumkeller and gcd n m = 1, then n*m is Zumkeller, too. -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: binding to C libraries on Windoww
From: Andrew Coppin andrewcop...@btinternet.com John Lato wrote: The only workable approach is to have users specify the locations of these files, which unfortunately requires more sophistication than can be expected of most Windows users (and even some Windows developers). Well, I don't know. It's going to vary from package to package, but most things that have a semi-official Windows version either come as a Windows Installer package (which, one presumes records where it put everything *somewhere* in the Windows registry), or possibly the *developer* package comes as a simple Zip file that you just unzip to wherever you fancy. Just tell the user the URL to grab the Zip file from, unzip it and tell Cabal where the root is now. Shouldn't be too hard. (Famous last words...) Indeed, in theory it would work this way. In practice, not so much. On a related matter, many packagers resort to using configure-style configuration setups to assist with binding to C libraries. Cabal is now sophisticated enough to handle many of these steps (although not all), however packagers may not have had an opportunity to update their build process to remove the dependency on configure. These packages will continue to require cygwin or mingw for the configure step. Ah yes, this is pretty much guaranteed to make stuff not work on Windows. :-) Still, all Unix systems have Automake, configure, etc., so I guess most people don't even think twice before using it. I gather it's supposed to be Cabal's job to figure this stuff out in Haskell land? AFAIK, this is true to an extent. I think that someone like Duncan could explain the role of Cabal better than I can. Of course Cabal was missing much of the necessary functionality until only recently. As an example, the possibility of listing C library dependencies was only added in 1.6 IIRC. One last wrinkle: many distributors of C libraries do not have Windows machines available to test, and (understandably) have little interest in supporting a platform they don't have and aren't familiar with. As a result, many C libraries are not well supported on Windows and require somebody familiar with gnu build tools (i.e. gcc, make, and autoconf) to be usable on Windows *at all*. This means that, as a Haskell developer wanting to use these libs, you need to use gnu build tools because you're not just binding to the library, you're maintaining a Windows port of it. This seems to be kind of the catch-22. Nobody uses Windows, so there isn't much support for Windows, so we don't attract many Windows users... QED. :-} Agreed (by users I presume you mean Haskell developers). I remember that many readers of this list were shocked by the download numbers for the HP, particularly the high number of Windows downloads. I think it goes to show that there is interest among Windows developers, as long as they have the sense that their platform is equally-supported compared to Linux. There are many more potential windows developers than linux developers due to the size of the Windows install base, so good Windows support is one of the easiest ways to expand the audience. C and unix are pretty much designed to work together, and have been for decades, so I think it's reasonable to expect that Windows is the side that needs to adapt to support their model. In other words, Windows needs to become just like Unix. Not going to happen. ;-) Argue about whether this is good or bad amoungst yourselves. But it's not happening. I don't mean that Windows needs to become just like Unix. I mean that if Windows supported a common installation location for .dll's and .h files (and binary packages regularly provided them), much of this difficulty would be easily resolved. It wouldn't be becoming like Unix, it would mean adopting to a C distribution model that Unix happens to share. Regardless, I think I have a better chance of winning the lottery jackpot than seeing MS support this in my lifetime. MS hasn't done so, which means that C developers would need to unacceptably compromise unix support in their packages in order to better support Windows. I don't know about that... Lots of commercial and open-source products are available for Windows and Unix, seemingly without any problem. (GTK, for example...) I don't deny that adding Windows support is _a lot more work_ than adding support for just another Unix, though. This goes back to the catch-22 you listed above, but I wouldn't say Windows support is without any problem. First you need active Windows developers for this. Commercial products have a big advantage here. Second, Windows support means a host of platform-specific bugs to be dealt with in every part of the package. These are in addition to any other bugs that you'd have anyway. FWIW, I had great difficulty in building hCsound on Windows, and my primary development box at the time was WinXP. I did eventually make it work
[Haskell-cafe] The Transient monad
Hi haskell cafe: concerning Stable Names http://www.haskell.org/ghc/docs/6.10.4/html/libraries/base/System-Mem-StableName.html makeStableName :: a - IO (StableName a) I Did not test fully my proposal, and I´m thinking aloud, Just to inpire others and fish some ideas; The IO in makeStableName suggest more side effects than makeStableName really do. But still the call isn't pure. For calls such are makeStableName that gives a different result the FIRST time they are called but return the same result every time in the same session, I suggest to use a Transient monad: makeStableName :: a - Transient (StableName a) The key here is to maintain the programmer aware that it is not pure, but there are no IO and that the results have no meaning from session to session. Instance Monad Transient where Transient x ↠ f = f x return x = Transient x We can Transient`ize IO calls by means of an implicit memoization: liftT:: IO a - Transient a liftT= whatever memoization code liftT2= liftT3= Memorization then is embedded in the monad transformation This may be more elegant than IO plus unsafePerformIO and is more informative for the programmer. The transition form IO to pure can be done in two steps, see below Instead of unsafePerformIO, we can use: unsafePurifyTransient :: Transient a - a unsafePurifyTransient (Transient x) = x for the inherently transient calls A safer version of unsafePerformIO using implicit memoization could be: unsafePerformIOT :: IO a - a unsafePerformIOT = unsafePurifyTransient . liftT unsafePerformIOT guatantee that it returns the same value in the same session. 2009/12/8 Vladimir Zlatanov vl...@dikini.net jeanchristophe.min...@gmail.com wrote: I think lisp like symbols could be quite useful in the context of embedded DSL to create ... well... symbols that can be interpreted as variables in that DSL. Well for such use-case you could use either stable names, or recode them into a state monad- you will get either a global i.e. lisp like unique symbols, or their equivalent within a state context. Or some variation of the code posted previously in this thread. http://www.haskell.org/ghc/docs/6.10.4/html/libraries/base/System-Mem-StableName.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: new installment of failure framework
On Tue, Dec 8, 2009 at 11:51 AM, Gregory Crosswhite gcr...@phys.washington.edu wrote: Michael, Although I like the idea of improving the way that failures are handled in Haskell, I am having trouble seeing any reason to use your framework. If a function is always assumed to succeed given certain pre-conditions, and somewhere along the lines my code discovers that one of these had been violated, then I throw an exception in order to communicate to myself the manner in which I screwed up. If a function might either succeed or fail for a very specific reason, then I use a Maybe because the caller will know exactly what problem is being signaled by Nothing. If a function might fail for one of many reasons and the caller might care about learning more about the problem, then I use an Either so that I can report the details of the problem. In each of the latter two cases, I can already use monads to handle the errors in a relatively convenient manner. In the first case I usually want the program to die right away and let me know where I screwed up, but if for some reason I wanted to continue even given arbitrary unanticipated problems in a particular computation the I use an exception handler. Given that all of the scenarios that I encounter are already handled by the functionality the standard libraries, it is not clear to me what your framework actually offers. I am not writing this to shoot your framework down, but rather to voice my thoughts aloud in order to hear your response to them, since if there is a use scenario that I am missing in which your framework would be ideal then I would be interested in hearing about it. The failure wiki page addresses exactly why Maybe and Either are inadequate solutions in a number of circumstances. Maybe does not allow any information to be attached; that may be fine when you directly call a function, but what if you call a function, which calls another one, and so on and so forth? You would then have two choices: * Ultimately just receive a Nothing and not know why. * At each step of the why, check if it's a Nothing, and then produce some appropriate message to describe it. If you choose option 2, you're admitting that Maybe was not sufficient for your uses any. Regarding Either, there are a number of issues: * There *is* not Monad instance in the base library. Orphan instances lead to major issues, such as not being able to import two modules at the same time because each declares a Monad Either instance. * With Either, you are limited to a single error type (unless you use existential types). * There is no easy way to chain together different types of Eithers (see below). For example, let's say I want to write some code to authenticate a user via OpenID (see the authenticate package). It has to do at least two things: * Download pages by HTTP * Parse the resulting HTML page. I would like to ideally do the following: authenticate = do page - getPage url parsed - parseHtml page checkResult parsed In other words, easily chain things together, and simply let the error types propogate. If the given functions had these signatures: getPage :: (MonadFailure HttpException m, MonadIO m) = String - m String parseHtml :: Failure ParseHtmlException m = String - m HtmlTree checkResult :: Failure AuthenticationException m = HtmlTree - m Identifier Then authenticate would simply subsume all these error types, making it explicit what a client of the libraries needs to be aware of. If clients instead want to look at it as a simple success/failure, I would recommend using the attempt package. If they want to deal with each failure type separately, they could use control-monad-exception. I hope that clears up why this package exists. It was not born of nothing; it is meant to solve real problems in an elegant manner. If you have any questions, please let me know. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: new installment of failure framework
On Dec 8, 2009, at 1:47 PM, Michael Snoyman wrote: For example, let's say I want to write some code to authenticate a user via OpenID (see the authenticate package). It has to do at least two things: * Download pages by HTTP * Parse the resulting HTML page. I would like to ideally do the following: authenticate = do page - getPage url parsed - parseHtml page checkResult parsed In other words, easily chain things together, and simply let the error types propogate. If the given functions had these signatures: getPage :: (MonadFailure HttpException m, MonadIO m) = String - m String parseHtml :: Failure ParseHtmlException m = String - m HtmlTree checkResult :: Failure AuthenticationException m = HtmlTree - m Identifier Then authenticate would simply subsume all these error types, making it explicit what a client of the libraries needs to be aware of. Let me highlight this point. The Maybe, Either,Exception diversity can be a curse instead of a blessing when combining libraries which return errors in different ways. The main goal of the failure framework is to provide an abstract notion of failure, so that libraries can offer interfaces which fail in an abstract way, and the client of the libraries can make the choice of how to manage the failures. Using a similar example (from [1]), consider a program to download a web page and parse it: 1. Network.URI.parseURI returns (Maybe URI). 2. Network.HTTP.simpleHTTP returns (IO (Result Request)), which is basically a broken version of (IO (Either ConnError Request)). 3. Parsec returns (Either ParseError a) So there's no hope that I can write anything like: * do uri - parseURI uriStr *doc - evenSimplerHTTP uri *parsed - parse grammar uriStr doc The Failure package contains functions that help when dealing with this problem, so that we can write something very close: do uri - try $ parseURI uriStr doc - try $ evenSimplerHTTP uri let parsed = try $ parse grammar uriStr doc But more importantly, the abstract notion of Failure enables library authors to write code that will easily combine with other failable code. Thanks, pepe [1] - http://www.randomhacks.net/articles/2007/03/10/haskell-8-ways-to-report-errors___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] diff implementation in haskell
From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Ketil Malde Don Stewart d...@galois.com writes: http://hackage.haskell.org/package/Diff Wherein we can read: | This is an implementation of the O(ND) diff algorithm [...]. It is O(mn) | in space. At first I thought 'N' and 'M' would be the lengths of the lists, and 'D' is the number of differences, but then the space bound doesn't make sense. I tried to find the reference, but Citeseer is down (again. sigh). Anybody know what the bounds really are? I think the space bounds are O(M+N). Section 4b. A Linear Space Refinement concludes with Unfortunately, the input sequences A and B must be kept in memory, implying that a total of O(M+N) space is needed. BTW, there is a minor improvement to this algorithm (claims to be faster, same space usage): http://research.janelia.org/myers/Papers/np_diff.pdf found via: http://scholar.google.com/scholar?q=%22An+O(NP)+Sequence+Comparison+Algo rithm.%22 I thought this paper was easier to understand. Alistair * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Parsec-like parser combinator that handles left recursion?
Hello there, Is there some other parser library, with similar nice API than Parsec, but which somehow handles left-recursive grammars? Ideally if it has at least rudimentary documentation and/or tutorial :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsec-like parser combinator that handles left recursion?
X-Saiga. Regards, John On Dec 8, 2009, at 7:10 AM, Adam Cigánek wrote: Hello there, Is there some other parser library, with similar nice API than Parsec, but which somehow handles left-recursive grammars? Ideally if it has at least rudimentary documentation and/or tutorial :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] SmallCheck design question
Hi, I'm cc'ing the people behind smallcheck, who can give definitive answers. 1. why are the tuple constructors treated differently? I'd expect depth (x,y) = succ $ max (depth x) (depth y) but the succ is missing. I think this was a design choice. Some people would consider: data Foo = Foo a b and data Foo = Foo (a,b) to be roughly the same - in some way the tuple is just to group things up, but it never is any structure by itself, since any structure it has is limited by the type system. But it could have been defined the other way. 2. why depth and not size (= total number of constructors)? it seems that the number of objects (trees) of given depth rises much more drastically than number of trees of given size. That seems harder to generate terms compositionally. To create all terms of depth n+1 you just glue together all terms of depth n, but to create terms of size n+1 you need to glue 1 with n, 2 with n-1 etc. Thanks, Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell job opportunity
I've posted this before but did not get a whole lot of responses, so here it is again: Principal investment firm based in Manhattan is looking for an outstanding software developer to develop and maintain the firm's proprietary valuation models as well as accounting and portfolio management systems. You should have at least a bachelor’s degree in computer science from a top university and impeccable coding style. This is a high-impact, high-visibility job opportunity where successful candidates will be entrusted with a lot of responsibility for products that have a direct effect on the PL of the firm and influences our workflow. This is a very small hedge fund with me being the only developer right now. The next hire will have a very direct say into how this side of our business progresses from here. We are a growth oriented firm that values people who take a craftsman’s pride in their work. We always like to take a contrarian view of things, value experimenting and using often overlooked technologies. That is one of the main reasons why we currently started using Haskell in developing our quantitative models. We are looking for a candidate who shows strong analytical, organizational, and communication skills. Attention to detail is essential, i.e. we fully document everything we do and pay a lot of attention to coding style. The majority of our existing code was written in Java, so you should have at least some experience with Java and related technologies, in order to be able to maintain the existing code. But as I mentioned above, Haskell has now become my choice of language and eventually all of the existing code will have to be re-written in Haskell. Background in accounting is not necessary but is definitely a plus. Please send your CV and cover letter to recruitment at karamaan.com, or reply to this post if you have any questions. Thanks -- View this message in context: http://old.nabble.com/Haskell-job-opportunity-tp26697169p26697169.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell job opportunity
On Tue, Dec 8, 2009 at 11:09 AM, siki ga...@karamaan.com wrote: I've posted this before but did not get a whole lot of responses, so here it is again: [...] You should have at least a bachelor’s degree in computer science from a top university Might I humbly suggest that this is going to severely limit your hiring options? You're looking for the intersection of sets of people who: - Have a BS in computer science (cuts out a fair number of people) - Graduated from a top university (cuts out a *lot* of people) - Is familiar with Java (cuts out some people) - Is skilled with Haskell (a fair bet for many on this mailing list, at least) - Can work in the Manhattan area (cuts out a *lot* of people) I'm not sure how many people *exist* who meet all these criteria. ;-) I'd probably start by dropping your top university requirement, since I don't think it's all that relevant if you find your candidate has the skills you're looking for. You might even find someone who fits yet doesn't have a CompSci BS degree; you can phrase it as a BS in computer science or an equivalent strong background in theoretical computer science or somesuch, as appropriate. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Handles with their IOMode in their type
On 08/12/2009 03:54, Bas van Dijk wrote: Could not get to sleep tonight so I got up and hacked this together: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=13782 Does something like this already exist on hackage: If not, I may turn this into a package and upload it tomorrow. Comments, criticism and patches are welcome. regards, Bas I like this idea. A small observation, though: stdin :: ReadModes ioMode = Handle ioMode stdin = Handle SIO.stdin This allows writing to stdin by choosing ReadWriteMode as the ioMode. I think it would be better to have just stdin :: Handle ReadMode *HandleExplicitIOMode hPutStrLn (stdin :: Handle ReadWriteMode) This shouldn't typecheck! *** Exception: stdin: hPutStr: illegal operation (handle is not open for writing) This also shows another reason for stdin, stdout and stderr to be monomorphic: hGetLine stdin interactive:1:0: Ambiguous type variable `ioMode' in the constraint: `ReadModes ioMode' arising from a use of `hGetLine' at interactive:1:0-13 Probable fix: add a type signature that fixes these type variable(s) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Rebox Package or To Hackage or not to Hackage
Hi List, I've recently had a situation where I used the same pattern quite a bit while reducing and evaluating an AST. I quickly wrapped the operation in a package and stuck it on github. http://github.com/sw17ch/rebox/blob/master/src/Data/Rebox.hs I'm wondering two things: 1) Does any one recognize the pattern I'm using here as something with a different name? 2) Is this worth sticking on Hackage? It's trivial, but we have plenty of trivial concepts on Hackage (and it's not a bad thing). Any feedback would be great. /jve ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: can there be (hash-table using) O(n) version of this (I think currently) n log n algo?
On Sunday 19 July 2009 09:26:14 Heinrich Apfelmus wrote: Thomas Hartman wrote: The code below is, I think, n log n, a few seconds on a million + element list. I wonder if it's possible to get this down to O(N) by using a hashtable implemementation, or other better data structure. -- findsums locates pairs of integers in a list that add up to a wanted sum. findsums :: [Int] - Int - S.Set (Int,Int) findsums xs wanted = snd . foldl' f (S.empty,S.empty) $ xs where f (candidates,successes) next = if S.member (wanted-next) candidates then (candidates, S.insert (next,wanted-next) successes) else (S.insert next candidates,successes) Remember that hash tables are actually O(key length) instead of O(1), so I don't think you can break the log n for really large lists this way since the key length increases as well (unless most elements are equal anyway). Use a trie of hash tables with ~word-sized pieces of key. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] A new form of newtype
Haskell is very nearly a high level language.
One rather unpleasant way in which it lets the
the underlying machine show through is integral types.
Aside from the unbounded Integer type, which is fine,
there are integral types bounded by machine sizes:
Int, size unspecified, Data.Int.Int{8,16,32,64},
and Data.Word.Word{8,16,32,64}.
There are a number of problems with these.
The principal one is that in order to figure out which
size is needed, a programmer must do arithmetic.
I still remember a student's bitter complaint about
being required to find the base 2 logarithm of 32 in
an examination where calculators were forbidden...
I propose a small addition to 'newtype' syntax:
'newtype' id '=' '[' expr {',' expr}... ']'
[deriving-part]
The expressions are Integral expressions made from
constants and suitable Prelude functions. Each Haskell
implementation supports some sublist of the types
[Int1,Word1,Int2,Word2,Int3,Word3,...,Int64,Word64,
...,Int256,Word256,...,Integral, _except
(It's almost interesting that the Natural type missing
from Haskell would go after Integral in this list, and
so would never be used.)
The effect of the declaration would be to make id
a copy of the first type in the list of supported types
that is big enough to include the value of every expression
on the right hand side, except that
minBound = the smallest value on the right hand side
maxBound = the largest value on the right hand side
rather than being the bounds for the underlying type.
The instances that could be derived would include
Bits, Bounded, Data, Enum, Eq, Integral, Ix, Num, Ord,
PrintfArg, Read, Real, Show, Storable, Typable.
I'd actually prefer that the default list of derived
instances be short, but it's hard to draw an arbitrary line,
so the default instances should be the same as the default
instances for Int in the same Haskell system.
Suppose I knew that I had a 2TB disc (I don't, and wish I
did) and wanted to be able to hold not only any file size
but the sums and differences of up to 10,000,000 file sizes.
(There could be one giant file, and all the file sizes
could be the size of that file.)
newtype FileSize = [-1000*2^41,1000*2^41]
I don't see any simple way to get named values into the
expressions defining a new integral type, but the use of cpp
with Haskell has been common practice for a long time, so
#define Tera 2^40
#define Many 1000
newtype FileSize = [-Many*2*Tera,Many*2*Tera]
In this case, FileSize would be a copy of Integer.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Zumkeller numbers
On Dec 8, 2009, at 8:44 PM, Ketil Malde wrote: Richard O'Keefe o...@cs.otago.ac.nz writes: factors n = [m | m - [1..n], mod n m == 0] I should remark that I wasn't *trying* to write fast code. I was trying to code as directly as I could, fully expecting to have to rewrite later. I was pleasantly surprised that it was fast enough for my purposes. The focus of my attention was actually on can this list of numbers be divided into two parts with the same sum, which was to me the novel part. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lisp like symbols in haskell
* jean-christophe mincke: Has there already been attempts to introduce lisp like symbols in haskell? Do you mean something like Objective Caml's polymorphic variants? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rebox Package or To Hackage or not to Hackage
Hi John, I don't know if this is useful for you, but these are instances of Cofunctor's comap. For example if we use TypeCompose package we have: rebox f = unFlip . cofmap f . Flip The rest are also Cofunctors. There are a few options. You can either specify instances or use type combinators from category-extras or TypeCompose packages. Basically (a - a - b) is curried composition of diagonal Functor from Bifunctor (,) and Cofunctor (Flip (-) a) etc. It's interesting to know more about usage of the pattern for AST reduction. Vitaliy On Tue, Dec 8, 2009 at 9:37 PM, John Van Enk vane...@gmail.com wrote: Hi List, I've recently had a situation where I used the same pattern quite a bit while reducing and evaluating an AST. I quickly wrapped the operation in a package and stuck it on github. http://github.com/sw17ch/rebox/blob/master/src/Data/Rebox.hs I'm wondering two things: 1) Does any one recognize the pattern I'm using here as something with a different name? 2) Is this worth sticking on Hackage? It's trivial, but we have plenty of trivial concepts on Hackage (and it's not a bad thing). Any feedback would be great. /jve ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] can there be (hash-table using) O(n) version of this (I think currently) n log n algo?
Any application where multiple updates are done in multiple threads . gain by using a hashTable 2009/7/18 Bulat Ziganshin bulat.zigans...@gmail.com Hello Thomas, Saturday, July 18, 2009, 7:23:10 PM, you wrote: Going back to my original question, I am now looking for a dead simple motivating example for showing the example of using a (good) hashtable over Data.Map spell checking? -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANN: hakyll-0.1
Ketil Malde wrote: minh thu not...@gmail.com writes: Why should your code be licensed under GPL? I think your code is covered by whatever license you wish. An aggregate work, on the other hand, would need to be covered by the GPL, and all source code would have to be available under GPL terms. So if you distribute your code linked to or incorporating the GPL library, the whole must conform to the GPL license (source availability and redistributatbility, etc). Your contributions could still be licensed under a different license (e.g. BSD), as long as the licensing doesn't prevent somebody else to pick it up and relicense it under GPL. At least, that's how I understand things. Right. So hakyll is absolutely fine with a BSD3 license, AFAICS. Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: The Transient monad
+1 Alberto G. Corona wrote: Hi haskell cafe: concerning Stable Names http://www.haskell.org/ghc/docs/6.10.4/html/libraries/base/System-Mem-StableName.html makeStableName :: a - IO (StableName a) I Did not test fully my proposal, and I´m thinking aloud, Just to inpire others and fish some ideas; The IO in makeStableName suggest more side effects than makeStableName really do. But still the call isn't pure. For calls such are makeStableName that gives a different result the FIRST time they are called but return the same result every time in the same session, I suggest to use a Transient monad: makeStableName :: a - Transient (StableName a) The key here is to maintain the programmer aware that it is not pure, but there are no IO and that the results have no meaning from session to session. Instance Monad Transient where Transient x ↠ f = f x return x = Transient x We can Transient`ize IO calls by means of an implicit memoization: liftT:: IO a - Transient a liftT= whatever memoization code liftT2= liftT3= Memorization then is embedded in the monad transformation This may be more elegant than IO plus unsafePerformIO and is more informative for the programmer. The transition form IO to pure can be done in two steps, see below Instead of unsafePerformIO, we can use: unsafePurifyTransient :: Transient a - a unsafePurifyTransient (Transient x) = x for the inherently transient calls A safer version of unsafePerformIO using implicit memoization could be: unsafePerformIOT :: IO a - a unsafePerformIOT = unsafePurifyTransient . liftT unsafePerformIOT guatantee that it returns the same value in the same session. 2009/12/8 Vladimir Zlatanov vl...@dikini.net jeanchristophe.min...@gmail.com wrote: I think lisp like symbols could be quite useful in the context of embedded DSL to create ... well... symbols that can be interpreted as variables in that DSL. Well for such use-case you could use either stable names, or recode them into a state monad- you will get either a global i.e. lisp like unique symbols, or their equivalent within a state context. Or some variation of the code posted previously in this thread. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rebox Package or To Hackage or not to Hackage
Am Dienstag, den 08.12.2009, 23:25 +0200 schrieb Vitaliy Akimov: Hi John, I don't know if this is useful for you, but these are instances of Cofunctor's comap. For example if we use TypeCompose package we have: rebox f = unFlip . cofmap f . Flip The rest are also Cofunctors. There are a few options. You can either specify instances or use type combinators from category-extras or TypeCompose packages. Basically (a - a - b) is curried composition of diagonal Functor from Bifunctor (,) and Cofunctor (Flip (-) a) etc. You can also define them recursively: rebox0 :: (a - b) - c - c rebox0 _ x = x reboxN :: ((a - b) - d - e) - (a - b) - (b - d) - a - e reboxN reboxM un re = reboxM un . re . un rebox1 :: (a - b) - (b - c) - a - c rebox1 = reboxN rebox0 rebox2 :: (a - b) - (b - b - c) - a - a - c rebox2 = reboxN rebox1 rebox3 :: (a - b) - (b - b - b - c) - a - a - a - c rebox3 = reboxN rebox2 rebox4 = reboxN rebox3 rebox5 = reboxN rebox4 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: hakyll-0.1
On Tue, 8 Dec 2009, Tom Tobin wrote: On Tue, Dec 8, 2009 at 3:30 PM, Ben Franksen ben.frank...@online.de wrote: Ketil Malde wrote: Your contributions could still be licensed under a different license (e.g. BSD), as long as the licensing doesn't prevent somebody else to pick it up and relicense it under GPL. At least, that's how I understand things. Right. So hakyll is absolutely fine with a BSD3 license, AFAICS. Seriously, no, this is *totally* wrong reading of the GPL, probably fostered by a misunderstanding of the term GPL-compatible license. GPL-compatible means the compatibly-licensed work can be incorporated into the GPL'd work (the whole of which is GPL'd), *not the other way around*. If you are forming a derivative work based on the GPL'd work, and thus you have to release that derivative work under the GPL. The combination of haykll and pandoc clearly must be GPL. I don't think it automatically follows from that that hakyll taken alone must be GPL. One might argue that the hakyll itself must be a derivative work as it builds on pandoc, but equally there may well be at least some pieces of hakyll that have independent uses; in addition someone might write a API-compatible replacement for pandoc that was BSD3. I would therefore argue for clearly marking the hakyll source as BSD3, so long as there is some way to clearly signal that anything compiled from it will necessarily be GPL. Ganesh ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The Transient monad
Alberto G. Corona wrote: Hi haskell cafe: concerning Stable Names The IO in makeStableName suggest more side effects than makeStableName really do. But still the call isn't pure. For calls such are makeStableName that gives a different result the FIRST time they are called but return the same result every time in the same session, I suggest to use a Transient monad: makeStableName doesn't really give 'the same result every time', though. For example: * let sn x = hashStableName $ makeStableName x * let x = replicate 3 'x' in (,) $ sn x * evaluate x * sn x (18,17) After x is evaluated in this example, its stable name changes. Perhaps instead of Transient we could use a name that makes it more clear what is going on, perhaps ObservingEvaluation. That could also include exception handling, by the way. makeStableName :: a - Transient (StableName a) Why not wrap it up in a class? class Monad m = MonadObservingEvaluation m where -- what should go here? perhaps: liftOE :: ObservingEvaluation a - m a Then we can have makeStableName :: MonadObservingEvaluation m = a - m (StableName a) Which works both in IO and the new monad. Twan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: hakyll-0.1
On Tue, Dec 8, 2009 at 3:46 PM, Tom Tobin korp...@korpios.com wrote: If you are forming a derivative work based on the GPL'd work, and thus you have to release that derivative work under the GPL. Wow, I mangled the syntax on that last sentence. That should read: If you are forming a derivative work based on the GPL'd work, you thus have to release that derivative work under the GPL. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: hakyll-0.1
On Tue, Dec 8, 2009 at 4:46 PM, Tom Tobin korp...@korpios.com wrote: On Tue, Dec 8, 2009 at 3:30 PM, Ben Franksen ben.frank...@online.de wrote: Ketil Malde wrote: Your contributions could still be licensed under a different license (e.g. BSD), as long as the licensing doesn't prevent somebody else to pick it up and relicense it under GPL. At least, that's how I understand things. Right. So hakyll is absolutely fine with a BSD3 license, AFAICS. Seriously, no, this is *totally* wrong reading of the GPL, probably fostered by a misunderstanding of the term GPL-compatible license. GPL-compatible means the compatibly-licensed work can be incorporated into the GPL'd work (the whole of which is GPL'd), *not the other way around*. If you are forming a derivative work based on the GPL'd work, and thus you have to release that derivative work under the GPL. The crux here is that the source code of hakyll, released on hackage, is not a derivative of Pandoc (it contains, as far as I understand it, no Pandoc source code). A compiled executable *is* a derivative of Pandoc, so anyone who *distributes* a compiled executable would need to make *all* the source available under the GPL (including the hakyll source). Since the hakyll package is released under BSD3, this would be allowed (AIUI, IANAL). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: hakyll-0.1
Am I the only one who finds this stuff confusing as hell? On Tue, Dec 8, 2009 at 2:13 PM, Robert Greayer robgrea...@gmail.com wrote: The crux here is that the source code of hakyll, released on hackage, is not a derivative of Pandoc (it contains, as far as I understand it, no Pandoc source code). A compiled executable *is* a derivative of Pandoc, so anyone who *distributes* a compiled executable would need to make *all* the source available under the GPL (including the hakyll source). Since the hakyll package is released under BSD3, this would be allowed (AIUI, IANAL). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Zumkeller numbers
On Dec 9, 2009, at 1:15 AM, Daniel Fischer wrote: Am Dienstag 08 Dezember 2009 08:44:52 schrieb Ketil Malde: Richard O'Keefe o...@cs.otago.ac.nz writes: factors n = [m | m - [1..n], mod n m == 0] -- saves about 10% time, seems to give the same result: factors n = [m | m - [1..n `div` 2], mod n m == 0]++[n] Even faster (for large enough n): factors n = mergeAll [if q == d then [d] else [d, q] | d - [1 .. isqrt n] , let (q,r) = n `divMod` d, r == 0] We can improve on that somewhat: factors 1 = [1] factors n = 1 : candidates 2 4 n [n] where candidates d d2 n hi = if d2 n then let (q,r) = divMod n d in if r == 0 then d : candidates (d+1) (d2+d+d+1) n (q:hi) else candidates (d+1) (d2+d+d+1) nhi else if d2 == n then d:hi else hi This never constructs a cons cell it doesn't mean to keep. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: hakyll-0.1
On Tue, Dec 8, 2009 at 4:13 PM, Robert Greayer robgrea...@gmail.com wrote: On Tue, Dec 8, 2009 at 4:46 PM, Tom Tobin korp...@korpios.com wrote: On Tue, Dec 8, 2009 at 3:30 PM, Ben Franksen ben.frank...@online.de wrote: Ketil Malde wrote: Your contributions could still be licensed under a different license (e.g. BSD), as long as the licensing doesn't prevent somebody else to pick it up and relicense it under GPL. At least, that's how I understand things. Right. So hakyll is absolutely fine with a BSD3 license, AFAICS. Seriously, no, this is *totally* wrong reading of the GPL, probably fostered by a misunderstanding of the term GPL-compatible license. GPL-compatible means the compatibly-licensed work can be incorporated into the GPL'd work (the whole of which is GPL'd), *not the other way around*. If you are forming a derivative work based on the GPL'd work, and thus you have to release that derivative work under the GPL. The crux here is that the source code of hakyll, released on hackage, is not a derivative of Pandoc (it contains, as far as I understand it, no Pandoc source code). A compiled executable *is* a derivative of Pandoc, so anyone who *distributes* a compiled executable would need to make *all* the source available under the GPL (including the hakyll source). Since the hakyll package is released under BSD3, this would be allowed (AIUI, IANAL). IANAL either, but my understanding is that judges take a very dim view of attempts like this to evade the requirements of a license. If a piece of software is built on another piece of software, it doesn't matter if you're looking at source code or a binary. I can write the SFLC and pose a hypothetical situation that captures the gist of what we're talking about, and post the response here, if anyone is interested. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: hakyll-0.1
On Tue, Dec 8, 2009 at 4:17 PM, Warren Henning warren.henn...@gmail.com wrote: Am I the only one who finds this stuff confusing as hell? It *is* confusing as hell, because law is confusing as hell, because it's an interpreted language of sorts — what matters is how judges rule on the law, not just the law as written. Copyleft licenses, contributor license agreements, and other such icky stuff makes me crazy, but it's stuff that has to be at least somewhat understood if you're contributing to open source, IMHO. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: hakyll-0.1
On Tue, Dec 8, 2009 at 5:13 PM, Robert Greayer robgrea...@gmail.com wrote: The crux here is that the source code of hakyll, released on hackage, is not a derivative of Pandoc (it contains, as far as I understand it, no Pandoc source code). A compiled executable *is* a derivative of Pandoc, so anyone who *distributes* a compiled executable would need to make *all* the source available under the GPL (including the hakyll source). Since the hakyll package is released under BSD3, this would be allowed (AIUI, IANAL). Not to belabor the point (I hope), but consider the following situation -- if the current version of Pandoc, 1.2.1, were released under BSD3, not GPL, it would be obvious that the current version of hakyll could be released as BSD3 as well. After said hakyll release, the Pandoc maintainer would be perfectly within his rights to release an API compatible 1.2.2 version of Pandoc, this time licensed under the GPL. People installing hakyll with cabal might now be building a version of hakyll containing both GPL and BSD3 code. This is not under either author's control, and is perfectly allowable. If the person downloading chooses to redistribute the hakyll executable he's built, he must be aware of and comply with his responsibilities under the GPL, but those would be his responsibilities, not those of the original author of hakyll. (AIUI -- IANAL). (If hakyll had been released under a GPL-incompatible license -- EPL, for example -- then the person downloading hakyll and building the executable could *not* distribute the executable he built. He could use it for his own purposes, but not distribute it. This is the implication of GPL incompatibility. As I Understand It.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interactive chatbot
No worries, I'd rather have it twice than not at all :-) Thank you all for the helpful tipps. We ended up knowing a lot more about Haskell. The easiest solution however, was to compile it all into an application - tadaa, deleting works as wished for. Regards, Torsten Am 05.11.2009 um 02:00 schrieb Ben Millwood: Oops, I clicked reply instead of reply to all. Duplicating the message below. I suppose this means someone is going to get two copies of this. Sorry someone! On Thu, Nov 5, 2009 at 12:56 AM, Ben Millwood hask...@benmachine.co.uk wrote: On Wed, Nov 4, 2009 at 10:21 PM, Torsten Otto t-otto-n...@gmx.de wrote: When we read the user's input through t - getLine it is not possible to delete typos before hitting enter and thereby sending the input off to the system (at least in OS X, bash). I didn't find that terribly problematic, but of course it is a bit of a show stopper from their point of view. As people have said it's worth checking what buffering settings you are using (especially note that ghci changes some interesting settings in relation to how input is handled, and compiled code may behave differently), but it might also be worth checking the terminal application's preferences to see if there are settings related to the interpretation of the backspace key that you need to twiddle one way or the other. In particular, if you are finding that pressing delete makes ^H appear on the input line instead of deleting things, or if pressing ctrl-H deletes stuff where the delete key fails to do so, it might be a problem with your terminal rather than with your program. This is only based on what I vaguely remember from faffing with the Mac Terminal application some time ago when it wouldn't co-operate with screen, but it may be worth a look. yours, Ben Millwood ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Zumkeller numbers
And if you use quotRem it's faster (unless you're running on some exotic hardware like NS32K). On Tue, Dec 8, 2009 at 10:19 PM, Richard O'Keefe o...@cs.otago.ac.nz wrote: On Dec 9, 2009, at 1:15 AM, Daniel Fischer wrote: Am Dienstag 08 Dezember 2009 08:44:52 schrieb Ketil Malde: Richard O'Keefe o...@cs.otago.ac.nz writes: factors n = [m | m - [1..n], mod n m == 0] -- saves about 10% time, seems to give the same result: factors n = [m | m - [1..n `div` 2], mod n m == 0]++[n] Even faster (for large enough n): factors n = mergeAll [if q == d then [d] else [d, q] | d - [1 .. isqrt n] , let (q,r) = n `divMod` d, r == 0] We can improve on that somewhat: factors 1 = [1] factors n = 1 : candidates 2 4 n [n] where candidates d d2 n hi = if d2 n then let (q,r) = divMod n d in if r == 0 then d : candidates (d+1) (d2+d+d+1) n (q:hi) else candidates (d+1) (d2+d+d+1) n hi else if d2 == n then d:hi else hi This never constructs a cons cell it doesn't mean to keep. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: hakyll-0.1
Tom Tobin wrote: IANAL either, Ditto! but my understanding is that judges take a very dim view of attempts like this to evade the requirements of a license. I can't see how any judge could possibly come to that conclusion in this case. Studying the terms of the GPL and the BSD3 a lawyer would come to the conclusion that the terms of the GPL are narrower than the terms of the BSD3 but that independently developed code under the BSD3 license can be linked to GPL code as long as the terms of the GPL are followed. For instance, there are many BSD licensed drivers in the GPL licensed Linux kernel. If a piece of software is built on another piece of software, it doesn't matter if you're looking at source code or a binary. The GPL makes this distinction. The GPL says if you distribute a binary from GPL sources you must release the sources as well. It does not however say that if you release sources you must also release binaries. I can write the SFLC and pose a hypothetical situation that captures the gist of what we're talking about, and post the response here, if anyone is interested. I suggest that you put together a question, post it here for comments and when there is some form of concensus pass the question on the the SFLC. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Zumkeller numbers
Am Mittwoch 09 Dezember 2009 00:02:30 schrieb Lennart Augustsson: And if you use quotRem it's faster (unless you're running on some exotic hardware like NS32K). Yes, but Henning Thielemann was busy in the exception vs. error thread, so I didn't want to distract him by using quotRem :D ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: hakyll-0.1
On Tue, Dec 8, 2009 at 4:46 PM, Tom Tobin korp...@korpios.com wrote: The crux here is that the source code of hakyll, released on hackage, is not a derivative of Pandoc (it contains, as far as I understand it, no Pandoc source code). A compiled executable *is* a derivative of Pandoc, so anyone who *distributes* a compiled executable would need to make *all* the source available under the GPL (including the hakyll source). Since the hakyll package is released under BSD3, this would be allowed (AIUI, IANAL). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe To add to this thought: if the author releases hakyll under the BSD3 license, then even though programs using it *presently* must be licensed under the GPL since Pandoc is, if the Pandoc license were one day changed to BSD3, or hakyll patched to use a different BSD3-compatable API, then at that point programs using it could be licensed under BSD3. Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell job opportunity
On Tue, Dec 8, 2009 at 5:54 PM, Tom Tobin korp...@korpios.com wrote: On Tue, Dec 8, 2009 at 11:09 AM, siki ga...@karamaan.com wrote: I've posted this before but did not get a whole lot of responses, so here it is again: [...] You should have at least a bachelor’s degree in computer science from a top university Might I humbly suggest that this is going to severely limit your hiring options? You're looking for the intersection of sets of people who: - Have a BS in computer science (cuts out a fair number of people) - Graduated from a top university (cuts out a *lot* of people) - Is familiar with Java (cuts out some people) - Is skilled with Haskell (a fair bet for many on this mailing list, at least) - Can work in the Manhattan area (cuts out a *lot* of people) - Is looking for a job. Haskell is still exotic enough that it has a disproportionate amount of Giant Brains among its practitioners. Companies tend to want to hang on to these, even in a recession. -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rebox Package or To Hackage or not to Hackage
On Tue, Dec 8, 2009 at 4:25 PM, Vitaliy Akimov vitaliy.aki...@gmail.com wrote: Hi John, I don't know if this is useful for you, but these are instances of Cofunctor's comap. For example if we use TypeCompose package we have: rebox f = unFlip . cofmap f . Flip Alternately, rebox = flip (.) -- Dave Menendez d...@zednenem.com http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: hakyll-0.1
On Tue, Dec 8, 2009 at 5:15 PM, Gregory Crosswhite gcr...@phys.washington.edu wrote: On Tue, Dec 8, 2009 at 4:46 PM, Tom Tobin korp...@korpios.com wrote: The crux here is that the source code of hakyll, released on hackage, is not a derivative of Pandoc (it contains, as far as I understand it, no Pandoc source code). A compiled executable *is* a derivative of Pandoc, so anyone who *distributes* a compiled executable would need to make *all* the source available under the GPL (including the hakyll source). Since the hakyll package is released under BSD3, this would be allowed (AIUI, IANAL). Hm, I didn't write that; I think your quoting is off. ^_^ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: hakyll-0.1
On Tue, Dec 8, 2009 at 4:38 PM, Robert Greayer robgrea...@gmail.com wrote: Not to belabor the point (I hope), but consider the following situation -- if the current version of Pandoc, 1.2.1, were released under BSD3, not GPL, it would be obvious that the current version of hakyll could be released as BSD3 as well. After said hakyll release, the Pandoc maintainer would be perfectly within his rights to release an API compatible 1.2.2 version of Pandoc, this time licensed under the GPL. People installing hakyll with cabal might now be building a version of hakyll containing both GPL and BSD3 code. This is not under either author's control, and is perfectly allowable. If the person downloading chooses to redistribute the hakyll executable he's built, he must be aware of and comply with his responsibilities under the GPL, but those would be his responsibilities, not those of the original author of hakyll. (AIUI -- IANAL). The compatible-API issue is very murky — it does indeed seem weird that creating an API-compatible BSD'd library would magically release users. I've seen other discussions regarding this, and about the sanest conclusion I've drawn is ask your lawyer. :-/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: hakyll-0.1
Tom Tobin korp...@korpios.com writes: Your contributions could still be licensed under a different license (e.g. BSD), as long as the licensing doesn't prevent somebody else to pick it up and relicense it under GPL. Right. So hakyll is absolutely fine with a BSD3 license, AFAICS. Seriously, no, this is *totally* wrong reading of the GPL, probably fostered by a misunderstanding of the term GPL-compatible license. GPL-compatible means the compatibly-licensed work can be incorporated into the GPL'd work You can incorporate all you want, as long as you don't distribute the result. If you are forming a derivative work based on the GPL'd work, and thus you have to release that derivative work under the GPL. Yes, but I understood the situation to be that Hakyll is using Pandoc as a library, accessing its API. If this makes Hakyll a derivative of Pandoc, then anything running on your Linux box must be GPL, as it uses system calls (the API of the GPL'ed kernel). available under the GPL (including the hakyll source). Since the hakyll package is released under BSD3, this would be allowed (AIUI, IANAL). IANAL either, but my understanding is that judges take a very dim view of attempts like this to evade the requirements of a license. I don't consider it an attempt to evade requirements. For all I know, the author of Hakyll wrote it using public documentation, and never even had Pandoc in his possession. Why should he be bound by its copyright license? I've used public specs to write software to parse files generated by proprietary software. My code is GPL, and I think it would be incredibly unreasonable to force me to abide by whatever license the generating software uses. If a piece of software is built on another piece of software, it doesn't matter if you're looking at source code or a binary. The question is if using an API is sufficient to make it a derived work. I can write the SFLC and pose a hypothetical situation that captures the gist of what we're talking about, and post the response here, if anyone is interested. I'm curious, at least. If nobody else wants it, feel free to email me privately. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Re: ANN: hakyll-0.1
On Tue, Dec 8, 2009 at 4:56 PM, Ben Franksen ben.frank...@online.de wrote: On Tue, 8 Dec 2009, Tom Tobin wrote: Seriously, no, this is *totally* wrong reading of the GPL, probably fostered by a misunderstanding of the term GPL-compatible license. GPL-compatible means the compatibly-licensed work can be incorporated into the GPL'd work (the whole of which is GPL'd), *not the other way around*. No. See http://www.fsf.org/licensing/licenses/gpl-faq.html#WhatIsCompatible Quote: What does it mean to say that two licenses are compatible? In order to combine two programs (or substantial parts of them) into a larger work, you need to have permission to use both programs in this way. If the two programs' licenses permit this, they are compatible. If there is no way to satisfy both licenses at once, they are incompatible.[...] That's what compatibility means in general for any set of licenses, yes. and http://www.fsf.org/licensing/licenses/gpl-faq.html#WhatDoesCompatMean What does it mean to say a license is compatible with the GPL? It means that the other license and the GNU GPL are compatible; you can combine code released under the other license with code released under the GNU GPL in one larger program. And, yes — this is what I said. ^_^ Ganesh Sittampalam wrote: One might argue that the hakyll itself must be a derivative work as it builds on pandoc, If this were so, then /all/ of Linux (including all the thousands of programs found on linux distributions) would have to be licensed under GPL, which is clearly not the case. No, it doesn't work that way; merely running a program under GPL'd Linux isn't the same thing. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: hakyll-0.1
On Tue, Dec 8, 2009 at 5:09 PM, Erik de Castro Lopo mle...@mega-nerd.com wrote: Tom Tobin wrote: I can write the SFLC and pose a hypothetical situation that captures the gist of what we're talking about, and post the response here, if anyone is interested. I suggest that you put together a question, post it here for comments and when there is some form of concensus pass the question on the the SFLC. This sounds good to me; I don't think any of us are lawyers, but if we have lawyers available to ask questions for free, let's take advantage of it. I'm thinking something along these lines: Myself and several other members of a mailing list for a particular programming language were recently discussing a situation where a BSD-licensed work required a GPL'd library. The ensuing discussion led to much confusion all around, as we've all read various (different!) things regarding honoring the GPL, and even where we've read the same thing, we took away different conclusions. We came up with a list of questions that would help us understand the matter better, and we were hoping you could help us answer them. The background situation: X is a library distributed under the GPL. Y is another library that uses that library and requires it in order to compile and function. 1) Is there any scenario where Y can be distributed under a non-GPL license (e.g., the BSD)? 2) If so, what would Y's author need to do (or *not* do)? 3) If Y must be released under the GPL under the above scenario, and someone subsequently wrote library Z, an API compatible replacement for X, and released it under the BSD license, would Y's author now be permitted to release Y under the BSD? (Feel free to add more questions, and/or suggest tweaks.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: dbus-core 0.6 and dbus-client 0.2
Hi John,
Very nice work! As it happens, Dafydd Harries and I wrote another native
implementation of the D-Bus protocol, but yours is much more complete,
and the documentation/commentary is ace. A refreshing change from the
daily pain of libdbus and dbus-glib... :-)
I'm looking at modifying Bustle (which draws sequence diagrams of D-Bus
traffic; http://www.willthompson.co.uk/bustle/) to log raw D-Bus
messages to a pcap file, rather than the current custom text format that
includes just the information from the message the UI needs alongside a
timestamp. Then the UI would read the pcap file, and feed the data
through a D-Bus parser before processing it further. Now that there's a
decent D-Bus implementation available, it seems like a good time to have
a crack at this.
However, I can't find a way to feed a bytestring to dbus-core and get
back a ReceivedMessage. Is this deliberately not exposed? While it's
obviously not useful in general, it would be very useful for Bustle.
(The alternative is to construct a fake connection to myself and feed
messages down it, I guess.)
Also, the Haskell bit of Bustle is licensed under the LGPL (v2.1 or
later), but dbus-{core,client} are under the GPL v3. Could you be
convinced to reconsider the licensing of your packages? D-Bus is often
used to allow free and non-free applications to play nicely together,
letting free software be used in situations where it would otherwise be
passed over; while I for one don't plan to write any non-free D-Bus
applications in Haskell any time soon, it'd be nice not to write Haskell
off for such applications.
--
Will
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: hakyll-0.1
Tom Tobin korp...@korpios.com writes: 1) Is there any scenario where Y can be distributed under a non-GPL license (e.g., the BSD)? 2) If so, what would Y's author need to do (or *not* do)? 3) If Y must be released under the GPL under the above scenario, and someone subsequently wrote library Z, an API compatible replacement for X, and released it under the BSD license, would Y's author now be permitted to release Y under the BSD? I wonder: if *using* an API makes a work derived, wouldn't replicating it be equally problematic? (The question stands anyhow, since 'someone' might be the author of the original library, who is clearly not limited by his licensing...) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: hakyll-0.1
Tom Tobin wrote: The background situation: X is a library distributed under the GPL. Y is another library that uses that library and requires it in order to compile and function. You probably also need to bring in application Z which uses library X via library Y, because library Y is not usable by itself. 1) Is there any scenario where Y can be distributed under a non-GPL license (e.g., the BSD)? You need to make sure they know that your are talking about the 3 clause BSD license, the one the FSF calls the Modified BSD license. 2) If so, what would Y's author need to do (or *not* do)? 3) If Y must be released under the GPL under the above scenario, and someone subsequently wrote library Z, an API compatible replacement for X, and released it under the BSD license, would Y's author now be permitted to release Y under the BSD? The author is always allowed to relicense their own work under whatever license they choose. For instance there are libraries released under the GPL which are also available under a commercial use license for use in closed source products. The requirement here is that the library is soley written by the person doing the dual licensing and/or all other contributors have assigned their rights. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: hakyll-0.1
On Tue, Dec 8, 2009 at 6:10 PM, Erik de Castro Lopo mle...@mega-nerd.com wrote: Tom Tobin wrote: The background situation: X is a library distributed under the GPL. Y is another library that uses that library and requires it in order to compile and function. You probably also need to bring in application Z which uses library X via library Y, because library Y is not usable by itself. I think this is implicit in calling something a library; are there any questions where it would come up? 1) Is there any scenario where Y can be distributed under a non-GPL license (e.g., the BSD)? You need to make sure they know that your are talking about the 3 clause BSD license, the one the FSF calls the Modified BSD license. Good point. 3) If Y must be released under the GPL under the above scenario, and someone subsequently wrote library Z, an API compatible replacement for X, and released it under the BSD license, would Y's author now be permitted to release Y under the BSD? The author is always allowed to relicense their own work under whatever license they choose. Well I think that's actually what we're wondering here — under what circumstances is Y's author permitted to choose his license at will? For instance there are libraries released under the GPL which are also available under a commercial use license for use in closed source products. The requirement here is that the library is soley written by the person doing the dual licensing and/or all other contributors have assigned their rights. But those libraries don't, in turn, depend on GPL'd libraries written by different authors. I think the answer to the can Y's author choose the BSD3 for Y question will also answer this for cases where there's a further, different-author GPL dependency involved. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: hakyll-0.1
On Tue, Dec 8, 2009 at 6:21 PM, Tom Tobin korp...@korpios.com wrote: Well I think that's actually what we're wondering here — under what circumstances is Y's author permitted to choose his license at will? I think I phrased this poorly; it's more under what circumstances is Y's author permitted to distribute Y under the terms of a non-GPL license? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: hakyll-0.1
Tom Tobin wrote: I'm thinking something along these lines: The background situation: X is a library distributed under the GPL. Y is another library that uses that library and requires it in order to compile and function. 1) Is there any scenario where Y can be distributed under a non-GPL license (e.g., the BSD)? 2) If so, what would Y's author need to do (or *not* do)? 3) If Y must be released under the GPL under the above scenario, and someone subsequently wrote library Z, an API compatible replacement for X, and released it under the BSD license, would Y's author now be permitted to release Y under the BSD? (Feel free to add more questions, and/or suggest tweaks.) Based on the discussion so far, I think you need to distinguish between distributing source and distributing binaries. For example: Background: X is a library distributed under GPL. Y is another library which calls external functions in the API of X. Assume X and Y have different authors. 1. Can the author of Y legally distribute the *source* of Y under a non-GPL licence (BSD3, Modified BSD, etc), assuming such source is distributed without any binaries, and is distributed separately from X? 2. etc. Question 1 covers the situation at hand, and keeps the initial line of questioning simple and specific. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: hakyll-0.1
On Tue, Dec 8, 2009 at 6:25 PM, Matthew Brecknell matt...@brecknell.net wrote: Based on the discussion so far, I think you need to distinguish between distributing source and distributing binaries. For example: Background: X is a library distributed under GPL. Y is another library which calls external functions in the API of X. Assume X and Y have different authors. 1. Can the author of Y legally distribute the *source* of Y under a non-GPL licence (BSD3, Modified BSD, etc), assuming such source is distributed without any binaries, and is distributed separately from X? I think you're right — this cuts right to the heart of the main difference in understanding so far. Question 2 can be If the answer to 1 is no, is there *any* circumstance under which the author of Y can distribute the source of Y under a non-GPL license? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: hakyll-0.1
Apologies, Robert, for you getting this twice: I forgot to CC the list as well. Robert Greayer robgrea...@gmail.com writes: The crux here is that the source code of hakyll, released on hackage, is not a derivative of Pandoc (it contains, as far as I understand it, no Pandoc source code). A compiled executable *is* a derivative of Pandoc, so anyone who *distributes* a compiled executable would need to make *all* the source available under the GPL (including the hakyll source). Since the hakyll package is released under BSD3, this would be allowed (AIUI, IANAL). That is my understanding as well: http://www.fsf.org/licensing/licenses/gpl-faq.html#IfLibraryIsGPL , | If a library is released under the GPL (not the LGPL), does that mean | that any program which uses it has to be under the GPL or a | GPL-compatible license? | | Yes, because the program as it is actually run includes the library. ` Thus, it means your program using Pandoc can be BSD3; but it can never be used in a proprietary program. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: dbus-core 0.6 and dbus-client 0.2
On Tue, Dec 8, 2009 at 16:00, Will Thompson w...@willthompson.co.uk wrote:
However, I can't find a way to feed a bytestring to dbus-core and get
back a ReceivedMessage. Is this deliberately not exposed? While it's
obviously not useful in general, it would be very useful for Bustle.
(The alternative is to construct a fake connection to myself and feed
messages down it, I guess.)
It's not exposed at the moment, because I didn't want to commit to a
public API until I knew it was going to work. When I get home tonight,
I'll add it to the API.
Aside from message marshal/unmarshal, are there any other bits of the
protocol which would be helpful to expose?
Also, the Haskell bit of Bustle is licensed under the LGPL (v2.1 or
later), but dbus-{core,client} are under the GPL v3. Could you be
convinced to reconsider the licensing of your packages? D-Bus is often
used to allow free and non-free applications to play nicely together,
letting free software be used in situations where it would otherwise be
passed over; while I for one don't plan to write any non-free D-Bus
applications in Haskell any time soon, it'd be nice not to write Haskell
off for such applications.
The following bit is just me being a free-software hippy, so take it
with a grain of salt, but:
There's already a DBus package for Haskell under the BSD 3-clause
license at http://hackage.haskell.org/package/DBus. It's a bit
awkward to use, because it's a binding to libdbus, but it exists.
dbus-core and -client offer developers ease of use in exchange for the
developers granting rights to their users.
Additionally, as far as I know, the teams porting DBus to Windows and
OS X haven't released anything stable / usable yet -- if somebody's
using DBus, it's probably on Linux, FreeBSD, etc. If any developers
want to develop proprietary software 1) for Linux/BSD 2) in Haskell 3)
using D-Bus, I'm sure both of them will take a break from rolling that
boulder uphill to ask about relicensing.
If it really is an issue -- ie, you'd be willing to use a
less-featured library to avoid the GPL -- then please reply and I'll
re-license. I don't want to negatively impact anybody else working on
free software. But I'd rather keep the license as strong as possible
until somebody actually needs it to be weakened.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A new form of newtype
What would these types be used for? If your students are complaining about having to perform logarithms to store integers, inform them of the Integer type. The existing sized types -- Word/Int [8, 16, 32, 64] -- are useful primarily because they match up with standard integral data types in other languages. They're great for FFI, (un)marshaling via ByteString, and occasional low-level code. In contrast, there is (to my knowledge) no machine with 42-bit integers, so there's no point to defining such intermediate types. In your FileSize example, it would be much easier to simply use: newtype FileSize = FileSize Integer since then your code will cope nicely when everybody upgrades to PB disks in a few years. If you need particular bounds, create your own instance of Bounded. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] How to understand such a `case` ?
findHelper (x:xs) = do -- not lazy, but that's not really important here filex - fileExists (file x) filex' - fileExists (file' x) case () of _ | filex - return $ Just $ file x | filex'- return $ Just $ file' x | otherwise - findHelper xs file x = foldl1 joinFileName (x ++ [helper]) file' x = (file x) ++ (getConfig exe_ext) Sincerely! - fac n = foldr (*) 1 [1..n] -- View this message in context: http://old.nabble.com/How-to-understand-such-a-%60case%60---tp26703526p26703526.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to understand such a `case` ?
Sorry; forgot to CC the list That case is equivalent to: if filex then return $ Just $ file x else if filex' then return $ Just $ file' x else findHelper xs The specific syntax being used is called a pattern guard: http://www.haskell.org/haskellwiki/Pattern_guard On Tue, Dec 8, 2009 at 16:59, zaxis z_a...@163.com wrote: findHelper (x:xs) = do -- not lazy, but that's not really important here filex - fileExists (file x) filex' - fileExists (file' x) case () of _ | filex - return $ Just $ file x | filex' - return $ Just $ file' x | otherwise - findHelper xs file x = foldl1 joinFileName (x ++ [helper]) file' x = (file x) ++ (getConfig exe_ext) Sincerely! - fac n = foldr (*) 1 [1..n] -- View this message in context: http://old.nabble.com/How-to-understand-such-a-%60case%60---tp26703526p26703526.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell job opportunity
On Tue, Dec 8, 2009 at 6:54 PM, Tom Tobin korp...@korpios.com wrote: On Tue, Dec 8, 2009 at 11:09 AM, siki ga...@karamaan.com wrote: You should have at least a bachelor’s degree in computer science from a top university Might I humbly suggest that this is going to severely limit your hiring options? You're looking for the intersection of sets of people who: - Have a BS in computer science (cuts out a fair number of people) - Graduated from a top university (cuts out a *lot* of people) - Is familiar with Java (cuts out some people) - Is skilled with Haskell (a fair bet for many on this mailing list, at least) We hired a technician by trade with no engineering or computer science degree, but who happened to show an unique aptitude and interest for learning a wide variety of programming languages. Though he had no prior experience with Haskell, or functional programming for that matter, in a few months he became a very proficient Haskell developer. I've also experienced many engineers with advanced degrees from prominent schools who have had tremendous difficulty understanding the language -- and the benefits -- of Haskell. I'm starting to believe people are either wired for it, or they are not. - Can work in the Manhattan area (cuts out a *lot* of people) My boss has said that the relative time zone is just as good as co-location. So I'd like to put a call out for resumes, which would help me build a case for opening reqs in the US -- and Canada and Central and South America for that matter. We need people interest in: - hybrid vehicles - electro-hydraulics - feedback control systems - safety-critical, hard real-time embedded - compiler design - formal methods - and of course, functional languages We use Haskell for many tools and Atom for embedded code and verification (http://hackage.haskell.org/package/atom). http://www.eaton.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to understand such a `case` ?
thanks for your quick answer ! Then what's the advantage using such a `case` not using `if` statement given by you ? For me, the `if` statement is more clear . jmillikin wrote: Sorry; forgot to CC the list That case is equivalent to: if filex then return $ Just $ file x else if filex' then return $ Just $ file' x else findHelper xs The specific syntax being used is called a pattern guard: http://www.haskell.org/haskellwiki/Pattern_guard On Tue, Dec 8, 2009 at 16:59, zaxis z_a...@163.com wrote: findHelper (x:xs) = do -- not lazy, but that's not really important here filex - fileExists (file x) filex' - fileExists (file' x) case () of _ | filex - return $ Just $ file x | filex' - return $ Just $ file' x | otherwise - findHelper xs file x = foldl1 joinFileName (x ++ [helper]) file' x = (file x) ++ (getConfig exe_ext) Sincerely! - fac n = foldr (*) 1 [1..n] -- View this message in context: http://old.nabble.com/How-to-understand-such-a-%60case%60---tp26703526p26703526.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe - fac n = foldr (*) 1 [1..n] -- View this message in context: http://old.nabble.com/How-to-understand-such-a-%60case%60---tp26703526p26703743.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to understand such a `case` ?
Am Mittwoch 09 Dezember 2009 01:59:21 schrieb zaxis: findHelper (x:xs) = do -- not lazy, but that's not really important here filex - fileExists (file x) filex' - fileExists (file' x) case () of _ | filex - return $ Just $ file x | filex'- return $ Just $ file' x | otherwise - findHelper xs Such a 'case' is a typographically more pleasant way to test multiple alternatives than a nested if-then-else chain. With an if-then-else chain, the code would wander to the right and be less easily followed. Using a case () of _ | condition1 - thing1 | condition2 - thing2 | condition3 - thing3 ... you can nicely align all possibilities. Since the 'case' here is extraneous to the code logic and serves only aesthetic ends, such a practice may be frowned upon. file x = foldl1 joinFileName (x ++ [helper]) file' x = (file x) ++ (getConfig exe_ext) Sincerely! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to understand such a `case` ?
Am Mittwoch 09 Dezember 2009 02:26:11 schrieb zaxis: thanks for your quick answer ! Then what's the advantage using such a `case` not using `if` statement given by you ? For me, the `if` statement is more clear . Once you have a lot of possibilities to check, if-then-else cascades become rather unreadable. However, it might then be advisable to rethink your code, perhaps introduce a choice combinator. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: hakyll-0.1
On Tue, Dec 8, 2009 at 7:38 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Apologies, Robert, for you getting this twice: I forgot to CC the list as well. Robert Greayer robgrea...@gmail.com writes: The crux here is that the source code of hakyll, released on hackage, is not a derivative of Pandoc (it contains, as far as I understand it, no Pandoc source code). A compiled executable *is* a derivative of Pandoc, so anyone who *distributes* a compiled executable would need to make *all* the source available under the GPL (including the hakyll source). Since the hakyll package is released under BSD3, this would be allowed (AIUI, IANAL). That is my understanding as well: http://www.fsf.org/licensing/licenses/gpl-faq.html#IfLibraryIsGPL , | If a library is released under the GPL (not the LGPL), does that mean | that any program which uses it has to be under the GPL or a | GPL-compatible license? | | Yes, because the program as it is actually run includes the library. ` Thus, it means your program using Pandoc can be BSD3; but it can never be used in a proprietary program. There's another FAQ on GNU site that, I think, addresses the Pandoc/Hakyll situation directly: http://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL You have a GPL'ed program that I'd like to link with my code to build a proprietary program. Does the fact that I link with your program mean I have to GPL my program? Not exactly. It means you must release your program under a license compatible with the GPL (more precisely, compatible with one or more GPL versions accepted by all the rest of the code in the combination that you link). The combination itself is then available under those GPL versions. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: dbus-core 0.6 and dbus-client 0.2
0.7 released -- exposes the DBus.Wire module, which contains functions for marshaling and unmarshaling messages. Also supports detecting invalid UTF-8 when parsing (previously, it'd just error out). No other significant changes. https://dl.dropbox.com/u/1947532/dbus-core_0.7/index.html https://dl.dropbox.com/u/1947532/dbus-core_0.7.pdf It's difficult to know in advance how many bytes will be needed from the socket, so unmarshalMessage is written to pull them from a monad. If you're using it within pure code, you'll want to use Data.Binary.Get (or similar) to implement your parser: - import qualified Data.Binary.Get as G import qualified Data.ByteString.Lazy as BL bytes = BL.pack [1, 2, 3, 4, 5...] getBytes = G.getLazyByteString . fromIntegral received = G.runGet (unmarshalMessage getBytes) bytes - ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A new form of newtype
On Dec 9, 2009, at 1:58 PM, John Millikin wrote:
What would these types be used for? If your students are complaining
about having to perform logarithms to store integers, inform them of
the Integer type.
I mentioned one student who couldn't compute log 32 *himself*
2
to point out that people are bad at arithmetic . As my later
example made clear, base 2 logarithms are not the only calculations
one may need to perform.
I would want to use these types practically any time that I
want to choose bounded integer types for my own purposes.
The existing sized types -- Word/Int [8, 16, 32, 64] -- are useful
primarily because they match up with standard integral data types in
other languages. They're great for FFI, (un)marshaling via ByteString,
and occasional low-level code.
Well, no.
If you want to match up with Java's byte, short, int, or long,
then yes, Int8, Int16, Int32, or Int64 are a good match.
If you want to interface with C, you really really ought to be
using
Data.Foreign.{CChar,CSChar,CUChar,CShort,CUShort,CInt,CUInt,CLong,
CULong,CPtrdiff,CSize,CWchar,CSigAomic,CLLong,CULLong,CIntPtr,
CUintPtr,CIntMax,CUintMax,CTime} or Foreign.C.Error.Errno,
or System.Posix.Types.{you can read the list yourself}
and you may well find yourself wishing for others.
_These_ are the 'standard integral data types' in C,
and they exist precisely because the programmer has
no other portable way of specifying them.
MacOS X gives me library support for integers up to 1024 bits;
if I want to interface to those, what do I do? Never mind not getting
what I ask for, as things standard I can't even _ask_.
People are now writing EDSLs using Haskell to generate code for
all sorts of interesting things. What if you want to use Haskell
as a host for an EDSL targeted at a 24-bit DSP?
In contrast, there is (to my knowledge) no machine with 42-bit
integers, so there's no point to defining such intermediate types.
There may not be MACHINES with 42-bit integers,
but that doesn't mean there aren't PROBLEMS that need them.
This whole idea of let the machine dictate the sizes is
precisely what I'm complaining of.
The Mac OS X library, as I noted above, has
/System/Library/Frameworks/Accelerate.framework/Frameworks/\
vecLib.framework/Headers/vBigNum.h
vS128 vS256 vS512 vS1024 signed
vU128 vU256 vU512 vU1024 unsigned
and I'm pretty sure the hardware doesn't do 1024 bit integers
directly.
In your FileSize example, it would be much easier to simply use:
newtype FileSize = FileSize Integer
sure it would, BUT IT WOULDN'T BE BOUNDED. By this argument,
the Haskell type 'Int' should not exist; except for using
System.* and Foreign.* interface types we should not be using
bounded integers at all.
since then your code will cope nicely when everybody upgrades to PB
disks in a few years. If you need particular bounds, create your own
instance of Bounded.
Sorry, but creating instances of Bounded is what a compiler is for.
If I don't write it, I won't wrong it.
Put together Data.Int, Data.Word, Foreign.*, System.*, and Haskell
_already_ has oodles of integral newtypes. All I'm asking for is
a human-oriented way of doing more of the same. If wanting a
human-oriented way of doing things were unreasonable, we would be
unreasonable to use Haskell, wouldn't we?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: hakyll-0.1
On Tue, Dec 8, 2009 at 8:19 PM, Robert Greayer robgrea...@gmail.com wrote: There's another FAQ on GNU site that, I think, addresses the Pandoc/Hakyll situation directly: http://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL You have a GPL'ed program that I'd like to link with my code to build a proprietary program. Does the fact that I link with your program mean I have to GPL my program? Not exactly. It means you must release your program under a license compatible with the GPL (more precisely, compatible with one or more GPL versions accepted by all the rest of the code in the combination that you link). The combination itself is then available under those GPL versions. I'll confess to not being sure what exactly this means; this seems to imply that if you never distribute the GPL'd code itself, you're fine. In temporary lieu of posing questions explicitly to the SFLC, I dug up a copy of _Intellectual Property and Open Source_ by Foobar (and published by O'Reilly), and found this (from an entire chapter — Chapter 12 — about the GPL): Nevertheless, there is a persistent issue that won’t go away—whether linking programs together creates a derivative work. If linking creates a derivative work, the GPL applies to the linked program; otherwise, the GPL doesn’t apply. ... In legal practice, this arises as a common concern of clients just getting into open source. This question is usually phrased as either, 'Can I load and use a GPL-licensed library without applying the GPL to my application?' or, 'Do I have to apply the GPL to my plug-in for a particular program if that program is licensed under the GPL?' ... I won’t keep you in suspense; the short answer is that we don’t know. It then goes on with the long answer, which is honestly confusing as hell. There's even a question in the FAQ that goes like this: Q: That is different than the official GPL FAQ! Why? A: The GPL FAQ was written in inexact language, and gives the impression that the rules regarding derivative works may have greater reach than current copyright law allows. The FSF has repeatedly stated, however, that they believe in copyright minimalism and that the GPL should not be interpreted to extend beyond the reach of copyright. And the final answer is best: Q: Can I depend on the answers in this QA to keep me out of trouble? A: No. This is our best understanding of copyright law as it stands right now, but it could change tomorrow—and nobody really knows until these questions are resolved in a court of law. Oh dear Ceiling Cat, I have *no* idea at this point. Much of the FAQ deals with distributing *binaries*, though, not source alone. I'd still like to get a (somewhat?) straight answer from the SFLC folks, though. If it turns out that Hakyll *is* okay to be BSD3 licensed so long as neither any binary nor the GPL'd work's source is distributed under non-GPL terms, well ... I'll say that the meaning of BSD licensed will have become much less reliable, since it means you actually have to trace the genealogy of the libraries you use *all* the way back in order to understand the situation for certain. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: hakyll-0.1
On Tue, Dec 8, 2009 at 11:19 PM, Tom Tobin korp...@korpios.com wrote: In temporary lieu of posing questions explicitly to the SFLC, I dug up a copy of _Intellectual Property and Open Source_ by Foobar ::facepalm:: I wrote Foobar as a placeholder as I was typing, and never replaced it. The author's name is Van Lindberg. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
