Re: [Haskell-cafe] real haskell difficulties (at least for me)
On Thu, 2009-01-15 at 09:49 +0300, Eugene Kirpichov wrote: Would be nice if after a failed build cabal asked whether or not to upload its log immediately, and (on the hackage side) this led to an email being sent to the maintainer. It should not be quite that synchronous but yes that's the general idea. Packages can fail to install for many reasons that are not the fault of the package author, for example missing C libraries. Also, I think maintainers would not be pleased to receive 10's of emails per day! :-) I think in practise it will have to be opt-in for package authors/maintainers and it should only send aggregated information (like it appears not to work on windows with ghc-6.8). Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] real haskell difficulties (at least for me)
Well, I thought about these 10's of emails too; probably hackage could send an email when a new broken build arrives but only if there were no 'unresolved' broken builds before this one; or probably an email at the first broken build and a weekly email reminding you've got some unresolved broken builds. As for missing C libraries: could cabal probably integrate with the native package manager (apt/rpm/..) and ask the user whether to invoke it to install these libraries in case they are missing? However, this is not a solution for Windows since there's no native package manager. An easier solution might be to add a (flag-dependent) broken-build-message field to .cabal files, where authors could put useful info to be printed when a build breaks, like, have you installed libpcre? or please see troubleshooting.txt. /me promises to do some cabal tickets from the 'easy ticket list' after the last exam 2009/1/15 Duncan Coutts duncan.cou...@worc.ox.ac.uk: On Thu, 2009-01-15 at 09:49 +0300, Eugene Kirpichov wrote: Would be nice if after a failed build cabal asked whether or not to upload its log immediately, and (on the hackage side) this led to an email being sent to the maintainer. It should not be quite that synchronous but yes that's the general idea. Packages can fail to install for many reasons that are not the fault of the package author, for example missing C libraries. Also, I think maintainers would not be pleased to receive 10's of emails per day! :-) I think in practise it will have to be opt-in for package authors/maintainers and it should only send aggregated information (like it appears not to work on windows with ghc-6.8). Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] some ideas for Haskell', from Python
Artyom Shalkhakov ha scritto: Hi Manlio, Hi Artyom. Note that it seems you have sent this message only to me; I'm sending the reply to both you and the mailing list. 2009/1/14 Manlio Perillo manlio_peri...@libero.it: 2) In Python it is possible to import modules inside a function. In Haskell something like: joinPath' root name = joinPath [root, name] importing System.FilePath (joinPath) I guess you're talking about first-class modules, the ones that might be passed to functions as arguments, returned from functions as a result, loaded at run-time, etc. No, I was not going that far :). I simply was proposing a method to keep imported definitions local to a function. By the way, here is a strange (for me) problem I hit, and made me think about this extension. Suppose a file foo.hs defines: import Control.Monad import System.Posix.Files as PF isDirectory :: FilePath - IO Bool isDirectory path = PF.isDirectory `liftM` PF.getFileStatus path If I try to load the file from ghci I get: Prelude :l foo.hs [1 of 1] Compiling Main ( foo.hs, interpreted ) Ok, modules loaded: Main. *Main isDirectory /var interactive:1:0: Ambiguous occurrence `isDirectory' It could refer to either `Main.isDirectory', defined at foo.hs:6:0 or `PF.isDirectory', imported from System.Posix.Files at foo.hs:2:0-30 [...] Manlio Perillo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] some ideas for Haskell', from Python
Brandon S. Allbery KF8NH ha scritto: [... about Python import local to functions ...] Sometime they are necessary, to avoid circular import problems (but this not a problem with Haskell). ...in theory. In practice GHC needs help with circular imports, and some cycles might be impossible to resolve. This is interesting. Where can I find some examples? Is this explained in the Real World Haskell book? Thanks Manlio Perillo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about System.Posix.Files.fileAccess
Brandon S. Allbery KF8NH ha scritto:
On 2009 Jan 14, at 9:02, Manlio Perillo wrote:
This is of course a personal opinion, but I think the interface of:
fileAccess :: FilePath - Bool - Bool - Bool - IO Bool
http://haskell.org/ghc/docs/latest/html/libraries/unix/System-Posix-Files.html#v:fileAccess
is not very good.
The underlying system call access() is strongly disrecommended, so it's
not really worth a better interface.
I can't see problems with access function.
Of course it is a problem if used incorrectly:
if (access(foo, F_OK) {
fd = open(foo, ...)
}
Manlio Perillo
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: some ideas for Haskell', from Python
Manlio Perillo wrote: import System.Posix.Files as PF Try this: import qualified System.Posix.Files as PF The problem you described should go away. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: hs-dotnet, version 0.3.0
Sigbjorn Finne wrote: the first public release of hs-dotnet is now available Fantastic accomplishment! I can only repeat dons' comment - this could be game-changing. Some obvious questions that come to mind: We see that it is already possible to expose a Haskell function to .NET as a callback. That's exciting! Can we go to the next step and register it as part of an assembly? Is it be possible for a running .NET app to fire up the GHC runtime and call into compiled Haskell? Is it possible at all for a .NET function not to have any side effects? If so, is there any way to label it as such and then call it from Haskell outside of the IO monad? Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] some ideas for Haskell', from Python
1) In a Python string it is available the \U{name} escape, where name is
a character name in the Unicode database.
As an example:
foo = uabc\N{VULGAR FRACTION ONE HALF}
I think you can use quasi quotation of ghc to achieve this ?
Your code would look like this then:
let foo = [$mystr|abc\N{VULGAR FRACTION ONE HALF}]
Sincerly
Marc Weber
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: some ideas for Haskell', from Python
Gleb Alexeyev ha scritto: Manlio Perillo wrote: import System.Posix.Files as PF Try this: import qualified System.Posix.Files as PF The problem you described should go away. Ah, thanks! I really missed the qualified! Manlio Perillo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] real haskell difficulties (at least for me)
Duncan Coutts ha scritto: [...] Do you know buildbot? http://buildbot.net/trac Yeah, it's great for some kinds of projects. For example it's used for ghc. However it is very centralised, synchronous and needs ssh on Windows. What we've implemented is using cabal-install to generate build logs and summary info and to upload that to the hackage server. The advantage is that we should get an order or two magnitude more results than if we used a handful of buildbots. This seems a good idea. However, it is possible for a thirdy part user to submit build logs for a specific platform? In detail: - The package author submit his package, and additional build logs for each platform he have access to - Other users can submit additional build logs for their platform I think, however, that a centralized system has its advantages. As an example, a newly submitted package can be put in a 'incoming queue', and moved to the final destination only if it builds (and tests succeed) on all the supported platforms. [..] Manlio Perillo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] some ideas for Haskell', from Python
2) In Python it is possible to import modules inside a function. In Haskell something like: joinPath' root name = joinPath [root, name] importing System.FilePath (joinPath) In Python importing a module has totally different semantics from importing in Haskell. I runs the initialization code for the module makes the names in that module available to you code. In Haskell modules are just namespace control, and you can always refer to names imported through import X through the syntax X.name. This means that the local import in Python solves two problems 1) making a name available locally. 2) running initialization code only when a specific function is called. Neither of those makes any sense for Haskell as far as I can tell. Immanuel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: hs-dotnet, version 0.3.0
Nice! Maybe efforts could be combined by integrating some of this work: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Salsa which statically types checks all the calls to DOTNET (emulates the C# type system using type families, I found it nifty) On Thu, Jan 15, 2009 at 12:14 PM, Yitzchak Gale g...@sefer.org wrote: Sigbjorn Finne wrote: the first public release of hs-dotnet is now available Fantastic accomplishment! I can only repeat dons' comment - this could be game-changing. Some obvious questions that come to mind: We see that it is already possible to expose a Haskell function to .NET as a callback. That's exciting! Can we go to the next step and register it as part of an assembly? Is it be possible for a running .NET app to fire up the GHC runtime and call into compiled Haskell? Is it possible at all for a .NET function not to have any side effects? If so, is there any way to label it as such and then call it from Haskell outside of the IO monad? Thanks, Yitz ___ 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] real haskell difficulties (at least for me)
On Thu, 2009-01-15 at 12:45 +0100, Manlio Perillo wrote: Duncan Coutts ha scritto: [...] Do you know buildbot? http://buildbot.net/trac Yeah, it's great for some kinds of projects. For example it's used for ghc. However it is very centralised, synchronous and needs ssh on Windows. What we've implemented is using cabal-install to generate build logs and summary info and to upload that to the hackage server. The advantage is that we should get an order or two magnitude more results than if we used a handful of buildbots. This seems a good idea. However, it is possible for a thirdy part user to submit build logs for a specific platform? Yes. In detail: - The package author submit his package, and additional build logs for each platform he have access to - Other users can submit additional build logs for their platform I think, however, that a centralized system has its advantages. As an example, a newly submitted package can be put in a 'incoming queue', and moved to the final destination only if it builds (and tests succeed) on all the supported platforms. What we really want is both. We want to let random users on random platforms submit simple anonymous build reports (no logs). In addition since any client can upload reports we can set up a number of dedicated clients that will build every new package in a chroot and upload non-anonymous detailed build reports with build logs. The only downside compared to a more centralised system is that we do not get to centrally monitor the status of the dedicated build clients. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell and C++ program
Sukit Tretriluxana: I was looking around Stroustrup's website and found a simple program... I wondered how a Haskell program equivalent to it looks like... main = E.catch (interact reverseDouble) (\_ - print format error) toDoubles = map (read::String-Double) For a safe program in Haskell, we would not normally use an unsafe function like read, and then try to rescue it by catching IO exceptions. Instead, we would write the program safely to begin with. Something like this (building on Jonathan's idea): import Data.Maybe (listToMaybe) main = interact reverseDouble reverseDouble = unlines . intro . maybe [format error] (map show . reverse) . mapM (readMaybe :: String - Maybe Double) . takeWhile (/= end) . words where intro l = (read ++ show (length l) ++ elements) : elements in reversed order : l readMaybe :: Read a = String - Maybe a readMaybe = listToMaybe . map fst . reads The function readMaybe returns the pure value Nothing if there is a format error instead of throwing an IO exception. It has been proposed to make it part of the standard libraries - I'm not sure what the status is of that process. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell and C++ program
Jonathan Cast wrote:
reverseDouble =
unlines
. intro
. map show
. reverse
. map (read :: String - Double)
. takeWhile (/= end)
. words
where
intro l =
(read ++ show (length l) ++ elements) :
elements in reversed order :
l
This can be simplified to
... . map show . reverse . map read . ...
= { map f . reverse = reverse . map f }
... . reverse . map show . map read . ...
= { map f . map g = map (f . g) }
... . reverse . map (show . read) . ...
= { show . read = id }
... . reverse . map id . ...
= { map id = id }
... . reverse . ...
In other words,
reverseDouble =
unlines. intro . reverse . takeWhile (/= end) . words
where
intro xs =
(read ++ show (length xs) ++ elements) :
elements in reversed order :
xs
And the doubles disappeared completely. :)
Regards,
H. Apfelmus
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] real haskell difficulties (at least for me)
Eugene Kirpichov ha scritto: Well, I thought about these 10's of emails too; probably hackage could send an email when a new broken build arrives but only if there were no 'unresolved' broken builds before this one; or probably an email at the first broken build and a weekly email reminding you've got some unresolved broken builds. As for missing C libraries: could cabal probably integrate with the native package manager (apt/rpm/..) and ask the user whether to invoke it to install these libraries in case they are missing? I like the idea. An external package database, where for each software we have an Haskell name, with this name mapped to each specific package. However, this is not a solution for Windows since there's no native package manager. For windows an Haskell external package name can be mapped to an URL to a well know Windows installer. [...] Manlio Perillo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] real haskell difficulties (at least for me)
Duncan Coutts ha scritto: [...] This seems a good idea. However, it is possible for a thirdy part user to submit build logs for a specific platform? Yes. Ok, that's great! In detail: - The package author submit his package, and additional build logs for each platform he have access to - Other users can submit additional build logs for their platform I think, however, that a centralized system has its advantages. As an example, a newly submitted package can be put in a 'incoming queue', and moved to the final destination only if it builds (and tests succeed) on all the supported platforms. What we really want is both. We want to let random users on random platforms submit simple anonymous build reports (no logs). In addition since any client can upload reports we can set up a number of dedicated clients that will build every new package in a chroot and upload non-anonymous detailed build reports with build logs. Since nowdays virtual machines are very affordable, it would be nice to have a set of standard virtual system images, preconfigured to run Cabal installation process. So that when I compile a package on my system, Cabal can be instructed to: 1) Start each virtual machine on the system 2) Submit the package to each machine an get the report 3) Stop each virtual machine Is this a feasible task? The only problem is with proprietary operating systems like Windows and Mac OS, where pre-configured systems can not be provided. [...] Manlio Perillo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell and C++ program
Well, your program is not equivalent to the C++ version, since it
doesn't bail on incorrect input.
2009/1/15 Apfelmus, Heinrich apfel...@quantentunnel.de:
Jonathan Cast wrote:
reverseDouble =
unlines
. intro
. map show
. reverse
. map (read :: String - Double)
. takeWhile (/= end)
. words
where
intro l =
(read ++ show (length l) ++ elements) :
elements in reversed order :
l
This can be simplified to
... . map show . reverse . map read . ...
= { map f . reverse = reverse . map f }
... . reverse . map show . map read . ...
= { map f . map g = map (f . g) }
... . reverse . map (show . read) . ...
= { show . read = id }
... . reverse . map id . ...
= { map id = id }
... . reverse . ...
In other words,
reverseDouble =
unlines. intro . reverse . takeWhile (/= end) . words
where
intro xs =
(read ++ show (length xs) ++ elements) :
elements in reversed order :
xs
And the doubles disappeared completely. :)
Regards,
H. Apfelmus
___
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] real haskell difficulties (at least for me)
On Thu, 2009-01-15 at 13:26 +0100, Manlio Perillo wrote: In detail: - The package author submit his package, and additional build logs for each platform he have access to - Other users can submit additional build logs for their platform I think, however, that a centralized system has its advantages. As an example, a newly submitted package can be put in a 'incoming queue', and moved to the final destination only if it builds (and tests succeed) on all the supported platforms. What we really want is both. We want to let random users on random platforms submit simple anonymous build reports (no logs). In addition since any client can upload reports we can set up a number of dedicated clients that will build every new package in a chroot and upload non-anonymous detailed build reports with build logs. Since nowdays virtual machines are very affordable, it would be nice to have a set of standard virtual system images, preconfigured to run Cabal installation process. So that when I compile a package on my system, Cabal can be instructed to: 1) Start each virtual machine on the system 2) Submit the package to each machine an get the report 3) Stop each virtual machine Is this a feasible task? Yes, and the great thing is that anyone could do that. That's the advantage of a decentralised system. It does not require the permission or help of the cabal/hackage hackers to do it. The only problem is with proprietary operating systems like Windows and Mac OS, where pre-configured systems can not be provided. True. The other issue is that perhaps knowing something builds on a clean virtual machine is not quite so useful as knowing it builds on 100's of messy machines in dozens of different configurations. So that's not to say that using dedicated build clients running on virtual machines is not useful, it is. But we don't need lots and lots of those. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] real haskell difficulties (at least for me)
Duncan Coutts wrote: We want to let random users on random platforms submit simple anonymous build reports (no logs)... The only downside compared to a more centralised system is that we do not get to centrally monitor the status of the dedicated build clients. And that we open ourselves up to some serious security concerns - like hostile build reports and DOS. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell and C++ program
Eugene Kirpichov wrote: Well, your program is not equivalent to the C++ version, since it doesn't bail on incorrect input. Oops. That's because my assertion show . read = id is wrong. We only have read . show = id show . read = id (in the less defined than sense) Regards, H. Apfelmus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Type errors, would extensions help?
Hi,
I have this problem trying to define a function
inside a do expression. I tried this small code
to help me check. This works well:
---
import Data.Ratio ;
main = do {
printNumber - let {
print :: (Num n,Show n) = n - IO () ;
print n = do { putStrLn $ show n}
} in return print ;
print (1%5) ;
print 5.0
}
---
However, just removing 'Num n' gives:
Ambiguous type variable `n' in the constraint:
`Show n' arising from a use of `print' at teste.hs:7:16-20
Why is it ambiguous? Since I don't use numeric
functions, 'Num n,Show n' doesn't seem more specific.
Besides that, the real problem I have is a similar
function declared inside a 'let' as
col :: (WidgetClass w) = w-IO Int
col wid = do {...
that, after beeing used with w beeing Table (and
instance WidgetClass Table do exist) refuses beeing
used with DrawingArea (also with instance WidgetClass
DrawingArea), but I wasn't able to simulate that
in a small program, and don't know if it's related
to the case I'm showing.
Thanks for your kindness,
Maurício
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] real haskell difficulties (at least for me)
Yitzchak Gale ha scritto: Duncan Coutts wrote: We want to let random users on random platforms submit simple anonymous build reports (no logs)... The only downside compared to a more centralised system is that we do not get to centrally monitor the status of the dedicated build clients. And that we open ourselves up to some serious security concerns - like hostile build reports and DOS. DOS is always a problem, for every application open to the Internet. As for hostile builds reports, I don't see it as a security concern. -Yitz Manlio Perillo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re: Haskell and C++ program
Hello Eugene,
Thursday, January 15, 2009, 3:27:59 PM, you wrote:
but at least length.map show is eq to length :)
Well, your program is not equivalent to the C++ version, since it
doesn't bail on incorrect input.
2009/1/15 Apfelmus, Heinrich apfel...@quantentunnel.de:
Jonathan Cast wrote:
reverseDouble =
unlines
. intro
. map show
. reverse
. map (read :: String - Double)
. takeWhile (/= end)
. words
where
intro l =
(read ++ show (length l) ++ elements) :
elements in reversed order :
l
This can be simplified to
... . map show . reverse . map read . ...
= { map f . reverse = reverse . map f }
... . reverse . map show . map read . ...
= { map f . map g = map (f . g) }
... . reverse . map (show . read) . ...
= { show . read = id }
... . reverse . map id . ...
= { map id = id }
... . reverse . ...
In other words,
reverseDouble =
unlines. intro . reverse . takeWhile (/= end) . words
where
intro xs =
(read ++ show (length xs) ++ elements) :
elements in reversed order :
xs
And the doubles disappeared completely. :)
Regards,
H. Apfelmus
___
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
--
Best regards,
Bulatmailto:bulat.zigans...@gmail.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re: [Haskell-cafe] walking a directory tree efficiently
Hi, what about avoid the use of the unfold over the tree and construct it directly (e.g. see http://hpaste.org/13919#a3)? I wonder if there is (an easy) possibility to construct the tree lazily so that output start immediately for large trees. best, Massimiliano Gubinelli -- View this message in context: http://www.nabble.com/walking-a-directory-tree-efficiently-tp21446337p21475846.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] real haskell difficulties (at least for me)
On Thu, 2009-01-15 at 14:38 +0200, Yitzchak Gale wrote: Duncan Coutts wrote: We want to let random users on random platforms submit simple anonymous build reports (no logs)... The only downside compared to a more centralised system is that we do not get to centrally monitor the status of the dedicated build clients. And that we open ourselves up to some serious security concerns - like hostile build reports and DOS. Detailed build reports with logs are not anonymous, clients will need an account on hackage (ie username and password). Yes, we could get flooded with anonymous build reports, but they're much smaller and hopefully they'll either be obviously bogus or drowned out by the volume of legit reports. So the information content and reliability of each data item is lower but hopefully the volume makes up for it, so long as we do the statistics carefully. As Manlio says, we're always open to DOS attacks. We just have to make sure we're not more vulnerable than average by doing too much work on the server side compared to the work done by the client (ie the processing of anonymous reports has to be fairly cheap). Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] real haskell difficulties (at least for me)
Duncan Coutts wrote: let random users... submit... build reports... I wrote: ...we open ourselves up to... hostile build reports and DOS. Manlio Perillo wrote: DOS is always a problem, for every application open to the Internet. Yes. But I didn't mean just generic flooding. I meant abusing the effect of build reports to create a DOS. As for hostile builds reports, I don't see it as a security concern. Hostile build reports could effectively remove a package from hackage. Or bless a faulty package, causing problems on other people's systems. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Type errors, would extensions help?
Mauricio wrote:
Hi,
I have this problem trying to define a function
inside a do expression. I tried this small code
to help me check. This works well:
---
import Data.Ratio ;
main = do {
printNumber - let {
print :: (Num n,Show n) = n - IO () ;
print n = do { putStrLn $ show n}
} in return print ;
print (1%5) ;
print 5.0
}
---
I guess you intended to call printNumber in the quoted snippet?
There's a way to use GHC's extensions to do what you want, let me
illustrate with simpler example:
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE ImpredicativeTypes #-}
t1 () = do f - (return id :: IO (forall a. a-a))
return (f foo, f True)
However, I would call this style unnatural and unnecessary. What's wrong
with plain 'let' or 'where' that work without any extensions?
t2 () = do let f = id
return (f foo, f True)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] real haskell difficulties (at least for me)
Duncan Coutts duncan.cou...@worc.ox.ac.uk writes: On Thu, 2009-01-15 at 09:49 +0300, Eugene Kirpichov wrote: Would be nice if after a failed build cabal asked whether or not to upload its log immediately, and (on the hackage side) this led to an email being sent to the maintainer. It should not be quite that synchronous but yes that's the general idea. Perhaps the maintainer should receive a build summary at regular intervals? This would also work as a check whether there is a live maintainer at the other end of the listed maintainer address. (And hopefully be enough of an annoyance on the libraries@ list that people would start looking for maintainers for orphaned packages :-) -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] real haskell difficulties (at least for me)
Duncan Coutts wrote: Detailed build reports with logs are not anonymous, clients will need an account on hackage (ie username and password). Right. If we experience problems with that in the future, we just have to make sure that it won't be too hard to set up captcha. they'll either be obviously bogus Aren't we talking about an automated system? If we don't explicitly design for the possibility of hostile reports, any automated recognition will be trivial to circumvent. or drowned out by the volume of legit reports. Again, if this is automated, it is trivial generate the required volume. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: HLint 1.2
On Sun, 11 Jan 2009, Neil Mitchell wrote: I am pleased to announce HLint version 1.2. HLint is a lint-like tool for Haskell that detects and suggests improvements for your code. HLint is compatible with most GHC extensions, and supports a wide variety of suggestions, and can be extended with additional user suggestions. To install: cabal update cabal install hlint Fails for me, because of the base-4 dependency. - I'm still using GHC-6.8.2. Can HLint suggest view-pattern-free expressions, such that the program also runs on GHC-6.8 ? :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: HLint 1.2
Hi Henning, To install: cabal update cabal install hlint Fails for me, because of the base-4 dependency. - I'm still using GHC-6.8.2. Can HLint suggest view-pattern-free expressions, such that the program also runs on GHC-6.8 ? :-) HLint is written using view-patterns so requires GHC 6.10 to compile it. After you have it compiled its just a standard Haskell binary, so can be run on any Haskell code and will never suggest view-patterns anyway. Alas compiling without GHC 6.10 is not possible, but if you can get a binary from elsewhere it should run on your machine (subject to cabal configure stuff being set appropriately, which I don't understand...). Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Monads aren't evil? I think they are.
Ertugrul Soeylemez wrote: [...] Thank you for your reply, I think I can refine my thoughts. And make them much longer... ;) The elegance I have in mind comes from abstraction, that is when a type takes a meaning on its own, independent of its implementation. Let's take the example of vector graphics again data Graphic empty :: Graphic polygon :: [Point] - Graphic over:: Graphic - Graphic - Graphic All primitives can be explained in terms of our intuition on pictures alone; it is completely unnecessary to know that Graphic is implemented as type Graphics = Window - IO () empty = \w - return () polygon (p:ps) = \w - moveTo p w mapM_ (\p - lineTo p w) ps over g1 g2 = \w - g1 w g2 w Furthermore, this independence is often exemplified by the existence of many different implementations. For instance, Graphics can as well be written as type Graphics = Pixel - Color empty = const Transparent polygon (p:ps) = foldr over empty $ zipWith line (p:ps) ps over g1 g2 = \p - if g1 p == Transparent then g2 p else g1 p Incidentally, this representation also makes a nice formalization of the intuitive notion of pictures, making it possible to verify the correctness of other implementations. Of course, taking it as definition for Graphic would still fall short of the original goal of creating meaning independent of any implementation. But this can be achieved by stating the laws that relate the available operations. For instance, we have g = empty `over` g = g `over` empty (identity element) g `over` (h `over` j) = (g `over` h) `over` j (associativity) g `over` g = g (idempotence) The first two equations say that Graphics is a monoid. Abstraction and equational laws are the cornerstones of functional programming. For more, see also the following classics John Hughes. The Design of a Pretty-printing Library. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.38.8777 Philip Wadler. A prettier printer. http://homepages.inf.ed.ac.uk/wadler/topics/ language-design.html#prettier Richard Bird. A program to solve Sudoku Slides: http://icfp06.cs.uchicago.edu/bird-talk.pdf (From this point of view, the feature of non-pure languages to allow side effects in every function is useless and distracting. Why on earth would I want over to potentially have side effects? That would just invalidate the laws while offering nothing in return.) Often, the monadic solution _is_ the elegant solution. Please don't confuse monads with impure operations. I use the monadic properties of lists, often together with monad transformers, to find elegant solutions. As long as you're not abusing monads to program imperatively, I think, they are an excellent and elegant structure. I do use state monads where there is no more elegant solution than passing state around. It's simply that: you have a structure, which you modify continuously in a complex fashion, such as a neural network or an automaton. Monads are the way to go here, unless you want to do research and find a better way to express this. In the light of the discussion above, the state monad for a particular state is an implementation, not an abstraction. There is no independent meaning in stateful computation with an automaton as state, it is defined by its sole implementation. Sure, it does reduce boilerplate and simplifies the implementation, but it doesn't offer any insights. In other words, passing state is not an abstraction and it's a good idea to consciously exclude it from the design space when searching for a good abstraction. Similar for the other monads, maybe except the nondeterminism monad to some extend. Of course, a good abstraction depends on the problem domain. For automata, in particular finite state automata, I can imagine that the operations on corresponding regular expressions like concatenation, alternation and Kleene star are viable candidates. I have no clue about neural networks. On a side note, not every function that involves state does need the state monad. For instance, an imperative language might accumulate a value with a while-loop and updating a state variable, but in Haskell we simply pass a parameter to the recursive call foldl f z [] = z foldl f z (x:xs) = foldl f (f z x) xs Another example is modifying a value where a simple function of type s - s like insert 1 'a' :: Map k v - Map k v will do the trick. Personally I prefer this: somethingWithRandomsM :: (Monad m, Random a) = m a - Something a over these: somethingWithRandoms1 :: [a] - Something a somethingWithRandoms2 :: RandomGen g = g - Something a Consciously excluding monads and restricting the design space to pure functions is the basic tool of thought for finding such elegant abstractions. [...] You don't need to exclude monads to restrict the design space to pure functions.
Re: [Haskell-cafe] ANN: HLint 1.2
On Thu, 15 Jan 2009, Neil Mitchell wrote: Hi Henning, To install: cabal update cabal install hlint Fails for me, because of the base-4 dependency. - I'm still using GHC-6.8.2. Can HLint suggest view-pattern-free expressions, such that the program also runs on GHC-6.8 ? :-) HLint is written using view-patterns so requires GHC 6.10 to compile it. After you have it compiled its just a standard Haskell binary, so can be run on any Haskell code and will never suggest view-patterns anyway. My question was, whether HLint can help translating HLint to code without view patterns. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: HLint 1.2
Hi My question was, whether HLint can help translating HLint to code without view patterns. Ah, I misunderstood. Yes, it could (in theory), but it can't automatically apply the hints it generates. Upgrading to GHC 6.10 is probably easier :-) Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: hs-dotnet, version 0.3.0
Sigbjorn Finne wrote: Hi, the first public release of hs-dotnet is now available - a pragmatic take on interoperating between Haskell (via GHC) and .NET. For downloads and (some) info, see: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hs-dotnet http://haskell.forkIO.com/dotnet Feedback most welcome, both on what's there and what you would like to see better handled/supported next. Nice! Has there been any effort to support Mono? -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: hs-dotnet, version 0.3.0
On 1/15/2009 06:19, John Goerzen wrote: Sigbjorn Finne wrote: ... Nice! Has there been any effort to support Mono? Only in spirit so far. I'm keen to find the time to do it and if it would directly help people having Mono as a deployment target, even better. thanks --sigbjorn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: hs-dotnet, version 0.3.0
Thanks Yitzchak, I'm thinking and acting on having that available in your quiver have prototyped the ability to do so a couple of times in the past (stand-alone Haskell code as fully fledged .NET classes/assemblies, both the dynamic and static kind.) I didn't want to hold up the initial release to do this right now _and_ would really like to get a better gauge at how important having that piece would be to users looking to use Haskell in a .NET context. There's only so much time it seems, but no shortage of interesting projects to hack on :-) cheers --sigbjorn On 1/15/2009 03:14, Yitzchak Gale wrote: Sigbjorn Finne wrote: the first public release of hs-dotnet is now available Fantastic accomplishment! I can only repeat dons' comment - this could be game-changing. Some obvious questions that come to mind: We see that it is already possible to expose a Haskell function to .NET as a callback. That's exciting! Can we go to the next step and register it as part of an assembly? Is it be possible for a running .NET app to fire up the GHC runtime and call into compiled Haskell? Is it possible at all for a .NET function not to have any side effects? If so, is there any way to label it as such and then call it from Haskell outside of the IO monad? Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: split-0.1.1 (doc bugfix; new functions wordsBy and linesBy)
* fixes a couple Haddock bugs that were preventing the documentation from building on Hackage, and OK, the documentation is really *actually* fixed now. Thanks to Ross Paterson for upgrading haddock on the Hackage build machine! Check out the Haddocky, documentationy goodness: http://hackage.haskell.org/packages/archive/split/0.1.1/doc/html/Data-List-Split.html -Brent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Comments from OCaml Hacker Brian Hurt
Hi folks, Don Stewart noticed this blog post on Haskell by Brian Hurt, an OCaml hacker: http://enfranchisedmind.com/blog/2009/01/15/random-thoughts-on-haskell/ It's a great post, and I encourage people to read it. I'd like to highlight one particular paragraph: One thing that does annoy me about Haskell- naming. Say you've noticed a common pattern, a lot of data structures are similar to the difference list I described above, in that they have an empty state and the ability to append things onto the end. Now, for various reasons, you want to give this pattern a name using on Haskell's tools for expressing common idioms as general patterns (type classes, in this case). What name do you give it? I'd be inclined to call it something like Appendable. But no, Haskell calls this pattern a Monoid. Yep, that's all a monoid is- something with an empty state and the ability to append things to the end. Well, it's a little more general than that, but not much. Simon Peyton Jones once commented that the biggest mistake Haskell made was to call them monads instead of warm, fluffy things. Well, Haskell is exacerbating that mistake. Haskell developers, stop letting the category theorists name things. Please. I beg of you. I'd like to echo that sentiment! He went on to add: If you?re not a category theorists, and you're learning (or thinking of learning) Haskell, don't get scared off by names like monoid or functor. And ignore anyone who starts their explanation with references to category theory- you don't need to know category theory, and I don't think it helps. I'd echo that one too. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
I have replied on his blog, but I'll repeat the gist of it here. Why is there a fear of using existing terminology that is exact? Why do people want to invent new words when there are already existing ones with the exact meaning that you want? If I see Monoid I know what it is, if I didn't know I could just look on Wikipedia. If I see Appendable I can guess what it might be, but exactly what does it mean? -- Lennart On Thu, Jan 15, 2009 at 3:34 PM, John Goerzen jgoer...@complete.org wrote: Hi folks, Don Stewart noticed this blog post on Haskell by Brian Hurt, an OCaml hacker: http://enfranchisedmind.com/blog/2009/01/15/random-thoughts-on-haskell/ It's a great post, and I encourage people to read it. I'd like to highlight one particular paragraph: One thing that does annoy me about Haskell- naming. Say you've noticed a common pattern, a lot of data structures are similar to the difference list I described above, in that they have an empty state and the ability to append things onto the end. Now, for various reasons, you want to give this pattern a name using on Haskell's tools for expressing common idioms as general patterns (type classes, in this case). What name do you give it? I'd be inclined to call it something like Appendable. But no, Haskell calls this pattern a Monoid. Yep, that's all a monoid is- something with an empty state and the ability to append things to the end. Well, it's a little more general than that, but not much. Simon Peyton Jones once commented that the biggest mistake Haskell made was to call them monads instead of warm, fluffy things. Well, Haskell is exacerbating that mistake. Haskell developers, stop letting the category theorists name things. Please. I beg of you. I'd like to echo that sentiment! He went on to add: If you?re not a category theorists, and you're learning (or thinking of learning) Haskell, don't get scared off by names like monoid or functor. And ignore anyone who starts their explanation with references to category theory- you don't need to know category theory, and I don't think it helps. I'd echo that one too. -- John ___ 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: HLint 1.2
On Thu, 15 Jan 2009, Neil Mitchell wrote: Hi My question was, whether HLint can help translating HLint to code without view patterns. Ah, I misunderstood. Yes, it could (in theory), but it can't automatically apply the hints it generates. Upgrading to GHC 6.10 is probably easier :-) Also throwing away Hugs ... (YHC too ?) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
Lennart Augustsson wrote: I have replied on his blog, but I'll repeat the gist of it here. Why is there a fear of using existing terminology that is exact? Why do people want to invent new words when there are already existing ones with the exact meaning that you want? If I see Monoid I know what it is, if I didn't know I could just look on Wikipedia. If I see Appendable I can guess what it might be, but exactly what does it mean? I would suggest that having to look things up slows people down and might distract them from learning other, perhaps more useful, things about the language. 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] Comments from OCaml Hacker Brian Hurt
Lennart Augustsson wrote: I have replied on his blog, but I'll repeat the gist of it here. Why is there a fear of using existing terminology that is exact? Why do people want to invent new words when there are already existing ones with the exact meaning that you want? If I see Monoid I know what it is, if I didn't know I could just look on Wikipedia. If I see Appendable I can guess what it might be, but exactly what does it mean? Picture someone that doesn't yet know Haskell. If I see Appendable I can guess what it might be. If I see monoid, I have no clue whatsoever, because I've never heard of a monoid before. Using existing terminology isn't helpful if the people using the language have never heard of it. Wikipedia's first sentence about monoids is: In abstract algebra, a branch of mathematics, a monoid is an algebraic structure with a single, associative binary operation and an identity element. Which is *not* intuitive to someone that comes from a background in any other programming language. A lot of communities have the not invented here disease -- they don't like to touch things that other people have developed. We seem to have the not named here disease -- we don't want to give things a sensible name for a programming language that is actually useful. Here's another, less egregious, example: isInfixOf. I would have called that function contains or something. Plenty of other languages have functions that do the same thing, and I can't think of one that names it anything like isInfixOf. If you're learning Haskell, which communicates the idea more clearly: * Appendable or * Monoid I can immediately figure out what the first one means. With the second, I could refer to the GHC documentation, which does not describe what a Monoid does. Or read a wikipedia article about a branch of mathematics and try to figure out how it applies to Haskell. The GHC docs for something called Appendable could very easily state that it's a monoid. (And the docs for Monoid ought to spell out what it is in simple terms, not by linking to a 14-year-old paper.) I guess the bottom line question is: who is Haskell for? Category theorists, programmers, or both? I'd love it to be for both, but I've got to admit that Brian has a point that it is trending to the first in some areas. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]
On Jan 10, 2009, at 4:11 PM, Donn Cave wrote: Quoth John A. De Goes j...@n-brain.net: | Take a language like Ruby or Python (or Java, or C#, etc.). The vast | majority of code written in these languages does not get down to the | C level. When I say, vast majority, I'm referring to 99.999%. | That's because the standard libraries provide sufficiently | comprehensive platform-agnostic abstractions to do what most people | need to do. As a result, libraries for these languages are built on | the standard libraries, and do not require native code. Maybe I haven't been paying enough attention, but I see Python and Haskell in about the same position on this, especially in light of how different they are (Haskell's FFI is a lot easier!) Plenty of Python software depends on C library modules and foreign code. The particular examples you mention - DB and UI - are great examples where it's sort of crazy to do otherwise for just the reasons you go on to list. Python has pure interfaces to all the major databases. While it's true there are no native GUI libraries, there are pure Python libraries for just about everything else. Haskell is not yet to this point. The arguments you list in favor of native code are reasonable (though some of them cut both ways - in particular it's a bold assertion that bug fixes and general development are more likely in a Haskell implementation, compared to a widely used C implementation that it parallels.) I don't think it's a bold assertion. If I'm using a Haskell library that wraps a C library, and find a bug in it, my chances of tracking down the bug in C code and submitting a patch to whatever group maintains it are exactly zero. On the other hand, if it's a pure Haskell library, I'll at least take a look. What would you do? But each case has its own merits, and it's perilous to generalize. It would have been absurd for Python to take the approach that Java takes (lacking the major corporate backing), and probably so also for Haskell. (Though Haskell may in the end need it for APIs that involve I/O, the way things seem to be going in GHC.) Safe, composable IO needs to be pushed into the core (ideally, into the standard). And it needs to be powerful enough to handle the different use cases: text parsing, binary data, random IO, and interactive IO. The currently exposed semantics are neither safe nor composable. Regards, John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Thu, Jan 15, 2009 at 4:12 PM, Sittampalam, Ganesh ganesh.sittampa...@credit-suisse.com wrote: Lennart Augustsson wrote: I have replied on his blog, but I'll repeat the gist of it here. Why is there a fear of using existing terminology that is exact? Why do people want to invent new words when there are already existing ones with the exact meaning that you want? If I see Monoid I know what it is, if I didn't know I could just look on Wikipedia. If I see Appendable I can guess what it might be, but exactly what does it mean? I would suggest that having to look things up slows people down and might distract them from learning other, perhaps more useful, things about the language. Exactly. For example, the entry for monoid on Wikipedia starts: In abstract algebra, a branch of mathematics, a monoid is an algebraic structure with a single, associative binary operation and an identity element. I've had some set theory, but most programmers I know have not. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: HLint 1.2
Ah, I misunderstood. Yes, it could (in theory), but it can't automatically apply the hints it generates. Upgrading to GHC 6.10 is probably easier :-) Also throwing away Hugs ... (YHC too ?) Yes :-( I normally develop in Hugs, for a change I wanted to try GHCi. It's also a project that has loads of pattern matching at a fairly complex level, so the benefits offered by view-patterns and pattern-guards were just too hard to pass up. I'm also using SYB and Uniplate on SYB quite extensively. Now we just need Haskell' to standardise the useful bits (pattern guards, rank-2 types, deriving Data) throw away the junk (n+k, monomorphism restriction) and I can write beautiful programs for all Haskell thingies. Thanks Neil PS. I think I threw away Yhc when I imported Data.Map :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]
On Thu, Jan 15, 2009 at 09:17:55AM -0700, John A. De Goes wrote: On Jan 10, 2009, at 4:11 PM, Donn Cave wrote: Maybe I haven't been paying enough attention, but I see Python and Haskell in about the same position on this, especially in light of how different they are (Haskell's FFI is a lot easier!) Plenty of Python software depends on C library modules and foreign code. The particular examples you mention - DB and UI - are great examples where it's sort of crazy to do otherwise for just the reasons you go on to list. Python has pure interfaces to all the major databases. While it's true there are no native GUI libraries, there are pure Python libraries for just about everything else. Haskell is not yet to this point. By pure do you mean containing python code only? I'm looking through a few, and: PostgreSQL - psycopg - C PostgreSQL - pgsql - C PostgreSQL - pygresql - C MySQL - mysqldb - C MS SQL Server - pymssql - C And any interface that uses ODBC will, by necessity, be calling to C, because ODBC is defined as a C API and not a network protocol. Where are all these pure-Python drivers? I don't think it's a bold assertion. If I'm using a Haskell library that wraps a C library, and find a bug in it, my chances of tracking down the bug in C code and submitting a patch to whatever group maintains it are exactly zero. On the other hand, if it's a pure Haskell library, I'll at Why? least take a look. What would you do? You have to balance that against the chances of there being bugs in code that is used by far fewer people. I don't care what language you're talking about -- I'm going to expect the C PostgreSQL library to be less buggy than a pure reimplementation in any other language, and will have less concern about its maintenance and stability in the future. It's a lot of wheel reinvention to try to re-implement a database protocol in n languages instead of do it in 1 and bind to it everywhere else. AFAIK, the only language where that sort of wheel reinvention is popular is Java. But then Java seems to encourage wheel reinvention anyhow ;-) -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
Why do people think that you should be able to understand everything without ever looking things up? I'll get back to my example from the comment on the blog post. If I see 'ghee' in a cook book I'll check what it is (if I don't know). It has a precise meaning and next time I'll know. Inventing a new word for it serves no purpose, but to confuse people. Parts of Computer Science seem to love to invent new words for existing concepts. Again, I think this just confuses people in the long run. Or use existing words in a different way (like 'functor' in C++.) When it comes to 'isInfixOf', I think that is a particularely stupid name. As you point out, there are existing names for this function. I would probably have picked something like isSubstringOf instead of inventing something that is totally non-standard. I'm not saying Haskell always gets naming right, all I want is to reuse words that exist instead of inventing new ones. (And 'monoid' is not category theory, it's very basic (abstract) algebra.) I don't know any category theory, but if someone tells me that blah is an endomorphism I'm happy to call it that, knowing that I have a name that anyone can figure out with just a little effort. -- Lennart On Thu, Jan 15, 2009 at 4:15 PM, John Goerzen jgoer...@complete.org wrote: Lennart Augustsson wrote: I have replied on his blog, but I'll repeat the gist of it here. Why is there a fear of using existing terminology that is exact? Why do people want to invent new words when there are already existing ones with the exact meaning that you want? If I see Monoid I know what it is, if I didn't know I could just look on Wikipedia. If I see Appendable I can guess what it might be, but exactly what does it mean? Picture someone that doesn't yet know Haskell. If I see Appendable I can guess what it might be. If I see monoid, I have no clue whatsoever, because I've never heard of a monoid before. Using existing terminology isn't helpful if the people using the language have never heard of it. Wikipedia's first sentence about monoids is: In abstract algebra, a branch of mathematics, a monoid is an algebraic structure with a single, associative binary operation and an identity element. Which is *not* intuitive to someone that comes from a background in any other programming language. A lot of communities have the not invented here disease -- they don't like to touch things that other people have developed. We seem to have the not named here disease -- we don't want to give things a sensible name for a programming language that is actually useful. Here's another, less egregious, example: isInfixOf. I would have called that function contains or something. Plenty of other languages have functions that do the same thing, and I can't think of one that names it anything like isInfixOf. If you're learning Haskell, which communicates the idea more clearly: * Appendable or * Monoid I can immediately figure out what the first one means. With the second, I could refer to the GHC documentation, which does not describe what a Monoid does. Or read a wikipedia article about a branch of mathematics and try to figure out how it applies to Haskell. The GHC docs for something called Appendable could very easily state that it's a monoid. (And the docs for Monoid ought to spell out what it is in simple terms, not by linking to a 14-year-old paper.) I guess the bottom line question is: who is Haskell for? Category theorists, programmers, or both? I'd love it to be for both, but I've got to admit that Brian has a point that it is trending to the first in some areas. -- John ___ 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] Comments from OCaml Hacker Brian Hurt
Most people don't understand pure functional programming either. Does that mean we should introduce unrestricted side effects in Haskell? -- Lennart On Thu, Jan 15, 2009 at 4:22 PM, Thomas DuBuisson thomas.dubuis...@gmail.com wrote: On Thu, Jan 15, 2009 at 4:12 PM, Sittampalam, Ganesh ganesh.sittampa...@credit-suisse.com wrote: Lennart Augustsson wrote: I have replied on his blog, but I'll repeat the gist of it here. Why is there a fear of using existing terminology that is exact? Why do people want to invent new words when there are already existing ones with the exact meaning that you want? If I see Monoid I know what it is, if I didn't know I could just look on Wikipedia. If I see Appendable I can guess what it might be, but exactly what does it mean? I would suggest that having to look things up slows people down and might distract them from learning other, perhaps more useful, things about the language. Exactly. For example, the entry for monoid on Wikipedia starts: In abstract algebra, a branch of mathematics, a monoid is an algebraic structure with a single, associative binary operation and an identity element. I've had some set theory, but most programmers I know have not. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] real haskell difficulties (at least for me)
There's no point wasting development resources on threats that may never emerge. If attacks become a problem, it can be dealt with then -- when more information on the nature of the threat is available, so a better solution can be developed than now (when there is no information, only speculation). We're not talking about an airline control system here, where waste is more than acceptable if it trivially reduces risk. Regards, John On Jan 15, 2009, at 6:38 AM, Yitzchak Gale wrote: Duncan Coutts wrote: Detailed build reports with logs are not anonymous, clients will need an account on hackage (ie username and password). Right. If we experience problems with that in the future, we just have to make sure that it won't be too hard to set up captcha. they'll either be obviously bogus Aren't we talking about an automated system? If we don't explicitly design for the possibility of hostile reports, any automated recognition will be trivial to circumvent. or drowned out by the volume of legit reports. Again, if this is automated, it is trivial generate the required volume. -Yitz ___ 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] Comments from OCaml Hacker Brian Hurt
Lennart Augustsson wrote: a name that anyone can figure out with just a little effort. I think the problem is that all these pieces of little effort soon mount up. It's not just the cost of looking it up, but also of remembering it the next time and so on. It's fine when you only encounter the occasional unfamiliar term, but a barrage of them all at once can be quite disorienting. 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] Comments from OCaml Hacker Brian Hurt
For what it's worth, many (most/all?) programmers I know in person don't have the slightest clue about Category Theory and they may have known about abstract algebra once upon a time but certainly don't remember any of it now. They usually understand the concepts perfectly well enough but by lay terms or by no particular name at all. Personally, I don't mind it too much if the generic typeclasses are named using extremely accurate terms like Monoid, but saying that someone should then look up the abstract math concept and try to map this to something very concrete and simple such as a string seems like wasted effort. Usually when encountering something like Monoid (if I didn't already know it), I'd look it up in the library docs. The problem I've had with this tactic is twofold: First, the docs for the typeclass usually don't give any practical examples, so sometimes it's hard to be sure that the append in mappend means what you think it means. Second is that there appears to be no way to document an _instance_. It would be really handy if there were even a single line under Instances Monoid ([] a) that explained how the type class was implemented for the list type. As it is, if you know what a Monoid is already, it's easy to figure out how it would be implemented. If you don't, you're either stuck reading a bunch of pages on the generic math term monoid and then finally realizing that it means appendable (and other similar things), or grovelling through the library source code seeing how the instance is implemented. My 2 cents, -Ross On Jan 15, 2009, at 11:36 AM, Lennart Augustsson wrote: Most people don't understand pure functional programming either. Does that mean we should introduce unrestricted side effects in Haskell? -- Lennart On Thu, Jan 15, 2009 at 4:22 PM, Thomas DuBuisson thomas.dubuis...@gmail.com wrote: On Thu, Jan 15, 2009 at 4:12 PM, Sittampalam, Ganesh ganesh.sittampa...@credit-suisse.com wrote: Lennart Augustsson wrote: I have replied on his blog, but I'll repeat the gist of it here. Why is there a fear of using existing terminology that is exact? Why do people want to invent new words when there are already existing ones with the exact meaning that you want? If I see Monoid I know what it is, if I didn't know I could just look on Wikipedia. If I see Appendable I can guess what it might be, but exactly what does it mean? I would suggest that having to look things up slows people down and might distract them from learning other, perhaps more useful, things about the language. Exactly. For example, the entry for monoid on Wikipedia starts: In abstract algebra, a branch of mathematics, a monoid is an algebraic structure with a single, associative binary operation and an identity element. I've had some set theory, but most programmers I know have not. ___ 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] Comments from OCaml Hacker Brian Hurt
If you called your girlfriend Kitten and on a mountain trip she broke her leg would cry/phone for help to treat your Kitten or would you use a stupid high-brow term woman? Or perhaps you would rename Washington Square for My Kitten Square ? There are hundreds programming languages designed by hackers, that is why I have chosen Haskell... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
I won't deny that Haskell has a large number of unfamiliar term if you've only seen Java before. But I don't think that giving them all happy fuzzy names will help people in the long run. -- Lennart On Thu, Jan 15, 2009 at 4:40 PM, Sittampalam, Ganesh ganesh.sittampa...@credit-suisse.com wrote: Lennart Augustsson wrote: a name that anyone can figure out with just a little effort. I think the problem is that all these pieces of little effort soon mount up. It's not just the cost of looking it up, but also of remembering it the next time and so on. It's fine when you only encounter the occasional unfamiliar term, but a barrage of them all at once can be quite disorienting. 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
Lennart Augustsson wrote: Why do people think that you should be able to understand everything without ever looking things up? I don't. But looking things up has to be helpful. In all to many cases, looking things up means clicking the link to someone's old academic paper or some article about abstract math in Wikipedia. It does not answer the questions: * Why is this in Haskell? * Why would I want to use it? * How does it benefit me? * How do I use it in Haskell? If the docs for things like Monoids were more newbie-friendly, I wouldn't gripe about it as much. Though if all we're talking about is naming, I would still maintain that newbie-friendly naming is a win. We can always say HEY MATHEMETICIANS: APPENDABLE MEANS MONOID in the haddock docs ;-) Much as I dislike Java's penchant for 200-character names for things, I'm not sure Monoid is more descriptive than SomeSortOfGenericThingThatYouCanAppendStuffToClassTemplateAbstractInterfaceThingy :-) -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
At the risk of painting my own bikeshed... If you're learning Haskell, which communicates the idea more clearly: * Appendable or * Monoid Would you call function composition (on endofunctions) appending? The join of a monad? A semi-colon (as in sequencing two imperative statements)? How do you append two numbers? Addition, multiplication, or something else entirely? All these operations are monoidal, i.e., are associative and have both left and right identities. If that's exactly what they have in common, why invent a new name? Appendable may carry some intuition, but it is not precise and sometimes quite misleading. I guess the bottom line question is: who is Haskell for? Category theorists, programmers, or both? I'd love it to be for both, but I've got to admit that Brian has a point that it is trending to the first in some areas. One of my grievances about Haskell is the occasional disregard for existing terminology. Stream Fusion is about lazy lists/co-lists, not streams; type families mean something entirely different to type theorists. This kind of misnomer is even more confusing than a name that doesn't mean anything (at least, until you learn more category theory). Wouter This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
By no means do I suggest that Wikipedia should replace Haskell library documentation. I think the libraries should be documented in a mostly stand-alone way (i.e., no references to old papers etc.). In the case of Monoid, a few lines of text is enough to convey the meaning of it and gives an example. -- Lennart On Thu, Jan 15, 2009 at 4:46 PM, Ross Mellgren rmm-hask...@z.odi.ac wrote: For what it's worth, many (most/all?) programmers I know in person don't have the slightest clue about Category Theory and they may have known about abstract algebra once upon a time but certainly don't remember any of it now. They usually understand the concepts perfectly well enough but by lay terms or by no particular name at all. Personally, I don't mind it too much if the generic typeclasses are named using extremely accurate terms like Monoid, but saying that someone should then look up the abstract math concept and try to map this to something very concrete and simple such as a string seems like wasted effort. Usually when encountering something like Monoid (if I didn't already know it), I'd look it up in the library docs. The problem I've had with this tactic is twofold: First, the docs for the typeclass usually don't give any practical examples, so sometimes it's hard to be sure that the append in mappend means what you think it means. Second is that there appears to be no way to document an _instance_. It would be really handy if there were even a single line under Instances Monoid ([] a) that explained how the type class was implemented for the list type. As it is, if you know what a Monoid is already, it's easy to figure out how it would be implemented. If you don't, you're either stuck reading a bunch of pages on the generic math term monoid and then finally realizing that it means appendable (and other similar things), or grovelling through the library source code seeing how the instance is implemented. My 2 cents, -Ross On Jan 15, 2009, at 11:36 AM, Lennart Augustsson wrote: Most people don't understand pure functional programming either. Does that mean we should introduce unrestricted side effects in Haskell? -- Lennart On Thu, Jan 15, 2009 at 4:22 PM, Thomas DuBuisson thomas.dubuis...@gmail.com wrote: On Thu, Jan 15, 2009 at 4:12 PM, Sittampalam, Ganesh ganesh.sittampa...@credit-suisse.com wrote: Lennart Augustsson wrote: I have replied on his blog, but I'll repeat the gist of it here. Why is there a fear of using existing terminology that is exact? Why do people want to invent new words when there are already existing ones with the exact meaning that you want? If I see Monoid I know what it is, if I didn't know I could just look on Wikipedia. If I see Appendable I can guess what it might be, but exactly what does it mean? I would suggest that having to look things up slows people down and might distract them from learning other, perhaps more useful, things about the language. Exactly. For example, the entry for monoid on Wikipedia starts: In abstract algebra, a branch of mathematics, a monoid is an algebraic structure with a single, associative binary operation and an identity element. I've had some set theory, but most programmers I know have not. ___ 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: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]
On Jan 15, 2009, at 9:31 AM, John Goerzen wrote: By pure do you mean containing python code only? I'm looking through a few, and: Search for pure python mysql or pure python postgresql and you'll see at least two implementations. In addition, there are plenty of pure Python databases for those who want and are able to stay strictly within Python. I don't think it's a bold assertion. If I'm using a Haskell library that wraps a C library, and find a bug in it, my chances of tracking down the bug in C code and submitting a patch to whatever group maintains it are exactly zero. On the other hand, if it's a pure Haskell library, I'll at Why? I'm tired of C. I'm not going to use any unpaid time writing or maintaining anything written in C. I assume if C were my favorite language, I'd be hanging around c-cafe instead of haskell-cafe. :-) You have to balance that against the chances of there being bugs in code that is used by far fewer people. That's true. It's a lot of wheel reinvention to try to re-implement a database protocol in n languages instead of do it in 1 and bind to it everywhere else. Why is wheel reinvention a bad thing? A combination of cooperation and competition is best for every endeavor. We have lots of companies in the business of making tires, each trying to outdo the other, but for any given company, they are all united behind the goal of producing the best possible tire. The consumers benefit. AFAIK, the only language where that sort of wheel reinvention is popular is Java. But then Java seems to encourage wheel reinvention anyhow ;-) The Java reinventions look and feel like Java, because they're native implementations. This is even more important in Haskell where the differences between Haskell and C is about as large as you can get. Regards, John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: HLint 1.2
On Thu, 15 Jan 2009, Neil Mitchell wrote: I normally develop in Hugs, for a change I wanted to try GHCi. It's also a project that has loads of pattern matching at a fairly complex level, so the benefits offered by view-patterns and pattern-guards were just too hard to pass up. Are you sure that you can't come up with some nice functions like 'maybe' to replace those view patterns by function calls? Did you really try? I remember the recent discussion on pattern combinators here on Haskell Cafe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
Of course not, the wikipedians would probably have your head for notability guidelines or something ;-) But seriously, I would have saved many hours of my life and probably many future ones if type class instances were documented and showed up in the haddock docs. -Ross On Jan 15, 2009, at 11:53 AM, Lennart Augustsson wrote: By no means do I suggest that Wikipedia should replace Haskell library documentation. I think the libraries should be documented in a mostly stand-alone way (i.e., no references to old papers etc.). In the case of Monoid, a few lines of text is enough to convey the meaning of it and gives an example. -- Lennart On Thu, Jan 15, 2009 at 4:46 PM, Ross Mellgren rmm- hask...@z.odi.ac wrote: For what it's worth, many (most/all?) programmers I know in person don't have the slightest clue about Category Theory and they may have known about abstract algebra once upon a time but certainly don't remember any of it now. They usually understand the concepts perfectly well enough but by lay terms or by no particular name at all. Personally, I don't mind it too much if the generic typeclasses are named using extremely accurate terms like Monoid, but saying that someone should then look up the abstract math concept and try to map this to something very concrete and simple such as a string seems like wasted effort. Usually when encountering something like Monoid (if I didn't already know it), I'd look it up in the library docs. The problem I've had with this tactic is twofold: First, the docs for the typeclass usually don't give any practical examples, so sometimes it's hard to be sure that the append in mappend means what you think it means. Second is that there appears to be no way to document an _instance_. It would be really handy if there were even a single line under Instances Monoid ([] a) that explained how the type class was implemented for the list type. As it is, if you know what a Monoid is already, it's easy to figure out how it would be implemented. If you don't, you're either stuck reading a bunch of pages on the generic math term monoid and then finally realizing that it means appendable (and other similar things), or grovelling through the library source code seeing how the instance is implemented. My 2 cents, -Ross On Jan 15, 2009, at 11:36 AM, Lennart Augustsson wrote: Most people don't understand pure functional programming either. Does that mean we should introduce unrestricted side effects in Haskell? -- Lennart On Thu, Jan 15, 2009 at 4:22 PM, Thomas DuBuisson thomas.dubuis...@gmail.com wrote: On Thu, Jan 15, 2009 at 4:12 PM, Sittampalam, Ganesh ganesh.sittampa...@credit-suisse.com wrote: Lennart Augustsson wrote: I have replied on his blog, but I'll repeat the gist of it here. Why is there a fear of using existing terminology that is exact? Why do people want to invent new words when there are already existing ones with the exact meaning that you want? If I see Monoid I know what it is, if I didn't know I could just look on Wikipedia. If I see Appendable I can guess what it might be, but exactly what does it mean? I would suggest that having to look things up slows people down and might distract them from learning other, perhaps more useful, things about the language. Exactly. For example, the entry for monoid on Wikipedia starts: In abstract algebra, a branch of mathematics, a monoid is an algebraic structure with a single, associative binary operation and an identity element. I've had some set theory, but most programmers I know have not. ___ 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: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Thu, Jan 15, 2009 at 10:46 AM, Ross Mellgren rmm-hask...@z.odi.ac wrote: snip Usually when encountering something like Monoid (if I didn't already know it), I'd look it up in the library docs. The problem I've had with this tactic is twofold: First, the docs for the typeclass usually don't give any practical examples, so sometimes it's hard to be sure that the append in mappend means what you think it means. Second is that there appears to be no way to document an _instance_. It would be really handy if there were even a single line under Instances Monoid ([] a) that explained how the type class was implemented for the list type. As it is, if you know what a Monoid is already, it's easy to figure out how it would be implemented. If you don't, you're either stuck reading a bunch of pages on the generic math term monoid and then finally realizing that it means appendable (and other similar things), or grovelling through the library source code seeing how the instance is implemented. I think you have a good point regarding documentation. Usually what I end up doing is just going into ghci testing out the instances with some trivial cases to make sure I have good intuition for how it's going to work. I don't think this a problem with the term 'monoid' though, but just a very generic problem with documentation. I have to do the same thing to understand an instance of Foldable despite how literal the name is. I don't know if it's very practical, but I like the idea of haddock generating either links to the source of the instance or some kind of expandable block that will show you the literal code. Cheers, Creighton ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
Lennart Augustsson wrote: Most people don't understand pure functional programming either. Does that mean we should introduce unrestricted side effects in Haskell? The key is to introduce concepts to them in terms they can understand. You introduce it one way to experienced abstract mathematicians, and a completely different way to experienced Perl hackers. I wouldn't expect a mathematician to grok Perl, and I wouldn't expect $PERL_HACKER to grok abstract math. People have different backgrounds to draw upon, and we are under-serving one community. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
I think the documentation should be reasonably newbie-friendly too. But that doesn't mean we should call Monoid Appendable. Appendable is just misleading, since Monoid is more general than appending. -- Lennart On Thu, Jan 15, 2009 at 4:51 PM, John Goerzen jgoer...@complete.org wrote: Lennart Augustsson wrote: Why do people think that you should be able to understand everything without ever looking things up? I don't. But looking things up has to be helpful. In all to many cases, looking things up means clicking the link to someone's old academic paper or some article about abstract math in Wikipedia. It does not answer the questions: * Why is this in Haskell? * Why would I want to use it? * How does it benefit me? * How do I use it in Haskell? If the docs for things like Monoids were more newbie-friendly, I wouldn't gripe about it as much. Though if all we're talking about is naming, I would still maintain that newbie-friendly naming is a win. We can always say HEY MATHEMETICIANS: APPENDABLE MEANS MONOID in the haddock docs ;-) Much as I dislike Java's penchant for 200-character names for things, I'm not sure Monoid is more descriptive than SomeSortOfGenericThingThatYouCanAppendStuffToClassTemplateAbstractInterfaceThingy :-) -- John ___ 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: HLint 1.2
Are you sure that you can't come up with some nice functions like 'maybe' to replace those view patterns by function calls? Did you really try? I remember the recent discussion on pattern combinators here on Haskell Cafe. I could, but it would look more ugly - and I want my code to be beautiful :-) For HLint, view-patterns are something I could live without, SYB is something I couldn't live without. SYB makes me GHC only, view-patterns make me GHC 6.10 only. I could port it to GHC 6.8.3, but I don't think its worth the effort, and the complication that would ensue. In general a view-pattern, as used in HLint, can be translated away by: foo (view - RHS) ... = ... foo new_var ... | RHS - view new_var = ... But its more ugly, requires more intermediate variables, isn't as clear and isn't a generally correct translation (but I think it would almost always work in HLint). Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
I'm totally with you on the instance documentation. I wish haddock allowed it. On Thu, Jan 15, 2009 at 4:56 PM, Ross Mellgren rmm-hask...@z.odi.ac wrote: Of course not, the wikipedians would probably have your head for notability guidelines or something ;-) But seriously, I would have saved many hours of my life and probably many future ones if type class instances were documented and showed up in the haddock docs. -Ross ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
John Goerzen jgoer...@complete.org writes: Wikipedia's first sentence about monoids is: In abstract algebra, a branch of mathematics, a monoid is an algebraic structure with a single, associative binary operation and an identity element. Which is *not* intuitive to someone that comes from a background in any other programming language. Instead of Wikipedia, why not try a dictionary? Looking up monoid using dictionary.com: An operator * and a value x form a monoid if * is associative and x is its left and right identity. On the other hand, appendable doesn't seem to be a word, and while you can infer that it means something that can be appended to, that's only half of the story... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] IFL 2009: Call for Papers
Call for Papers IFL 2009 Seton Hall University SOUTH ORANGE, NJ, USA http://tltc.shu.edu/blogs/projects/IFL2009/ The 21st IFL symposium, IFL 2009, will be held for the first time in the USA. The hosting institution is Seton Hall University in South Orange, NJ, USA and the symposium dates are September 23-25, 2009. It is our goal to make IFL a regular event held in the USA. The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2009 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Following the IFL tradition, IFL 2009 will use a post-symposium review process to produce a formal proceedings which we expect to be published by Springer in the Lecture Notes in Computer Science series. All participants in IFL 2009 are invited to submit either a draft paper or and extended abstract describing work to be presented at the symposium. These submissions will be screened by the program committee chair to make sure they are within the scope of IFL and will appear in the draft proceedings distributed at the symposium. Submissions appearing in the draft proceedings are not peer-reviewed publications. After the symposium, authors will be given the opportunity to incorporate the feedback from discussions at the symposium and will be invited to submit a revised full arcticle for the formal review process. These revised submissions will be reviewed by the program committee using prevailing academic standards to select the best articles that will appear in the formal proceedings. TOPICS IFL welcomes submissions describing practical and theoretical as well as submissions describing applications and tools. If you are not sure if your work is appropriate for IFL 2009, please contact the PC chair at ifl2...@shu.edu. Topics of interest include, but are not limited to: language concepts type checking contracts compilation techniques staged compilation runtime function specialization runtime code generation partial evaluation (abstract) interpretation generic programming techniques automatic program generation array processing concurrent/parallel programming concurrent/parallel program execution functional programming and embedded systems functional programming and web applications functional programming and security novel memory management techniques runtime profiling and performance measurements debugging and tracing virtual/abstract machine architectures validation and verification of functional programs tools and programming techniques PAPER SUBMISSIONS Prospective authors are encouraged to submit papers or extended abstracts to be published in the draft proceedings and to present them at the symposium. All contributions must be written in English, conform to the Springer-Verlag LNCS series format and not exceed 16 pages. The draft proceedings will appear as a technical report of the Department of Mathematics and Computer Science of Seton Hall University. IMPORTANT DATES Registration deadline August 15, 2009 Presentation submission deadline August 15, 2009 IFL 2009 SymposiumSeptember 23-25, 2009 Submission for review process deadline November 1, 2009 Notification Accept/Reject December 22, 2009 Camera ready version January 15, 2010 PROGRAM COMMITTEE Peter Achten University of Nijmegen, The Netherlands Jost Berthold Philipps-Universität Marburg, Germany Andrew Butterfield University of Dublin, Ireland Robby Findler Northwestern University, USA Kathleen Fisher ATT Research, USA Cormac Flanagan University of California at Santa Cruz, USA Matthew FlattUniversity of Utah, USA Matthew Fluet Toyota Technological Institute at Chicago, USA Daniel Friedman Indiana University, USA Andy GillUniversity of Kansas, USA Clemens Grelck University of Amsterdam/Hertfordshire, The Netherlands/UK Jurriaan Hage Utrecht University, The Netherlands Ralf Hinze Oxford University, UK Paul Hudak Yale University, USA John HughesChalmers University of Technology, Sweden Patricia JohannUniversity of Strathclyde, UK Yukiyoshi KameyamaUniversity of Tsukuba, Japan Marco T. Morazán (Chair) Seton Hall University, USA Rex PageUniversity of
Re: [Haskell-cafe] Re: Compiling regex-posix-0.93.2 on windows
Hi Chris et al: On Fri, Oct 17, 2008 at 4:33 PM, Chris Kuklewicz hask...@list.mightyreason.com wrote: I am not sure what is going wrong. I have not been using Haskell on windows. I am also copying this reply to haskell-cafe and libaries mailing lists. Does anyone know? I get passed that error on Cygwin by installing it like this: $ cabal update $ cabal install --extra-include-dirs=c:\cygwin\usr\include regex-posix However, when I try using regex-posix, I get: $ ghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude import Text.Regex.Posix Prelude Text.Regex.Posix Hello World =~ W :: String Loading package syb ... linking ... done. Loading package base-3.0.3.0 ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package containers-0.2.0.0 ... linking ... done. Loading package bytestring-0.9.1.4 ... linking ... done. Loading package mtl-1.1.0.2 ... linking ... done. Loading package regex-base-0.93.1 ... linking ... done. Loading package regex-posix-0.93.2 ... linking ... ghci-haskeline.exe: unable to load package `regex-posix-0.93.2' Prelude Text.Regex.Posix :q Leaving GHCi. interactive: C:\Program Files\Haskell\regex-posix-0.93.2\ghc-6.10.1\HSregex-posix-0.93.2.o: unknown symbol `_regerror' Compiling reveals more details: $ cat reg.hs EOF import Text.Regex.Posix test = Hello World! =~ W :: String main = putStrLn test EOF $ ghc --make reg.hs Linking reg.exe ... C:\Program Files\Haskell\regex-posix-0.93.2\ghc-6.10.1/libHSregex-posix-0.93.2.a(Wrap.o):fake:(.text+0xa2f): undefined reference to `regerror' C:\Program Files\Haskell\regex-posix-0.93.2\ghc-6.10.1/libHSregex-posix-0.93.2.a(Wrap.o):fake:(.text+0xa83): undefined reference to `regerror' C:\Program Files\Haskell\regex-posix-0.93.2\ghc-6.10.1/libHSregex-posix-0.93.2.a(Wrap.o):fake:(.text+0xb6b): undefined reference to `regfree' C:\Program Files\Haskell\regex-posix-0.93.2\ghc-6.10.1/libHSregex-posix-0.93.2.a(Wrap.o):fake:(.text+0xd39): undefined reference to `regcomp' C:\Program Files\Haskell\regex-posix-0.93.2\ghc-6.10.1/libHSregex-posix-0.93.2.a(Wrap.o):fake:(.text+0xf8f): undefined reference to `regexec' C:\Program Files\Haskell\regex-posix-0.93.2\ghc-6.10.1/libHSregex-posix-0.93.2.a(Wrap.o):fake:(.text+0x3656): undefined reference to `regexec' C:\Program Files\Haskell\regex-posix-0.93.2\ghc-6.10.1/libHSregex-posix-0.93.2.a(Wrap.o):fake:(.text+0x3aaa): undefined reference to `regexec' C:\Program Files\Haskell\regex-posix-0.93.2\ghc-6.10.1/libHSregex-posix-0.93.2.a(Wrap.o):fake:(.text+0x3e06): undefined reference to `regexec' C:\Program Files\Haskell\regex-posix-0.93.2\ghc-6.10.1/libHSregex-posix-0.93.2.a(Wrap.o):fake:(.text+0x4bcd): undefined reference to `regexec' C:\Program Files\Haskell\regex-posix-0.93.2\ghc-6.10.1/libHSregex-posix-0.93.2.a(Wrap.o):fake:(.text+0x512e): more undefined references to `regexec' follow collect2: ld returned 1 exit status Any ideas? I feel like I'm missing something very simple. Thanks, Paulo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
Ross Mellgren rmm-hask...@z.odi.ac writes: Usually when encountering something like Monoid (if I didn't already know it), I'd look it up in the library docs. The problem I've had with this tactic is twofold: First, the docs for the typeclass usually don't give any practical examples, so sometimes it's hard to be sure that the append in mappend means what you think it means. I second this, many of the docs are sorely lacking examples (and there are of course docs that simply reference a paper, which is usually too long to be helpful in the short term...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Thu, Jan 15, 2009 at 1:44 PM, Wouter Swierstra w...@cs.nott.ac.uk wrote: Would you call function composition (on endofunctions) appending? The join of a monad? A semi-colon (as in sequencing two imperative statements)? How do you append two numbers? Addition, multiplication, or something else entirely? All these operations are monoidal, i.e., are associative and have both left and right identities. If that's exactly what they have in common, why invent a new name? Appendable may carry some intuition, but it is not precise and sometimes quite misleading. I think this highlights an interesting point: Haskell is more abstract than most other languages. While in other languages Appendable might just mean what Brian suggested in his post, something with an empty state and the ability to append things to the end, in Haskell it applies to numbers and everything else that has an associative operator, that is, everything that is a monoid. So Appendable for numbers would be quite wrong; either it would never be used in situations where one wanted to append things to the end (which is limiting), or it would be used in these situations, which would be quite confusing. I think it is much more important to have good documentation about the typeclasses (and everything else in the library). This issue was mentioned recently in a discussion about monads, and the documentation for the Haskell library is quite uninformative. It would be nice if 1) people would not be scared of names like monoid and functor and 2) the documentation clearly stated what these things are, in a programming context, preferably with some examples. I think 2 would mitigate some of the fear mentioned in 1, if newcomers started to experience things like hey, that's one funky-named stuff this monoid thing, but I see here in the documentation that it is quite simple. -- []s, Andrei Formiga ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
Lennart Augustsson lenn...@augustsson.net writes: By no means do I suggest that Wikipedia should replace Haskell library documentation. I think the libraries should be documented in a mostly stand-alone way (i.e., no references to old papers etc.). In the case of Monoid, a few lines of text is enough to convey the meaning of it and gives an example. I don't think references to old papers are a bad thing (they might be good papers), but such references should certainly not be a replacement for a brief explanation and helpful example! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
Lennart Augustsson wrote: I think the documentation should be reasonably newbie-friendly too. But that doesn't mean we should call Monoid Appendable. Appendable is just misleading, since Monoid is more general than appending. Then why does it have a member named 'mappend'? :-) 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] Comments from OCaml Hacker Brian Hurt
jgoerzen: Hi folks, Don Stewart noticed this blog post on Haskell by Brian Hurt, an OCaml hacker: http://enfranchisedmind.com/blog/2009/01/15/random-thoughts-on-haskell/ It's a great post, and I encourage people to read it. I'd like to highlight one particular paragraph: I'd also recommend yesterday's post http://intoverflow.wordpress.com/2009/01/13/why-haskell-is-beyond-ready-for-prime-time/ Why Haskell is beyond ready for prime time For a few other insights. (Notably, the joy of hoogle/hayoo library search) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
Lennart Augustsson wrote: Most people don't understand pure functional programming either. Does that mean we should introduce unrestricted side effects in Haskell? No, just that we should seek to minimise the new stuff they have to get to grips with. 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] Comments from OCaml Hacker Brian Hurt
On Thu, Jan 15, 2009 at 7:34 AM, John Goerzen jgoer...@complete.org quoted: I'd be inclined to call it something like Appendable. But I don't know what Appendable means. Maybe it means class Appendable a where append :: a x - x - a x ie. a container x's lets you can add an x to the end or maybe it means class Appendable a where append :: a - x - a ie. something that you can append anything to or maybe it means class Appendable a where append :: a - a - a so you can append any two elements of the same type together. Why use words that are so vague when there's already word that unambiguously says what the type class looks like? And even worse, why use duplicate terminology to make it even harder to see when mathematicians and computer scientists are talking about the same thing, so widening the divide between two groups of people who have much to share. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
Beats me. As I said, I don't think Haskell gets all the names right. :) On Thu, Jan 15, 2009 at 5:15 PM, Sittampalam, Ganesh ganesh.sittampa...@credit-suisse.com wrote: Lennart Augustsson wrote: I think the documentation should be reasonably newbie-friendly too. But that doesn't mean we should call Monoid Appendable. Appendable is just misleading, since Monoid is more general than appending. Then why does it have a member named 'mappend'? :-) 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
2009/1/15 Lennart Augustsson lenn...@augustsson.net: Why do people think that you should be able to understand everything without ever looking things up? Understand, no, but have an intuition about, very definitely yes. In mathematics (and I speak as someone with a mathematical degree, so if I caricature anyone, please excuse it as failing memory rather than intent!!!) there's a tendency to invent terminology, rather than use natural names, because new names don't have unwanted connotations - it's the need for precision driving things. In programming, the need is for *communication* and as such, using words with natural - if imprecise, and occasionally even (slightly) wrong - connotations is extremely helpful. I'll get back to my example from the comment on the blog post. If I see 'ghee' in a cook book I'll check what it is (if I don't know). If a significant proportion of words require me to look them up, my flow of understanding is lost and I'll either give up, end up with a muddled impression, or take far longer to understand than the recipe merits (and so, I'll probably not use that cook book again). I'm not saying Haskell always gets naming right, all I want is to reuse words that exist instead of inventing new ones. But you seem to be insisting that mathematical terminology is the place to reuse from - whereas, in fact, computing might be a better basis (although computing doesn't insist on the precision that maths needs, so in any that's not precisely what I mean argument, non-mathematical terminology starts off an a disadvantage, even though absolute precision may not be the key requirement). (And 'monoid' is not category theory, it's very basic (abstract) algebra.) Well, I did a MSc course in mathematics, mostly pure maths including algebra, set theory and similar areas, and I never came across the term. Of course, my degree was 25 years ago, so maybe monoid is a term that wasn't invented then ;-)) I don't know any category theory, but if someone tells me that blah is an endomorphism I'm happy to call it that, knowing that I have a name that anyone can figure out with just a little effort. But unless you invest time researching, you can't draw any conclusions from that. If someone tells you it's a mapping, you can infer that it probably maps some things to one another, which gives you a (minimal, imprecise, and possibly wrong in some corner cases, but nevertheless useful) indication of what's going on. Mathematical precision isn't appropriate in all disciplines. Paul. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
Sittampalam, Ganesh wrote: Lennart Augustsson wrote: I think the documentation should be reasonably newbie-friendly too. But that doesn't mean we should call Monoid Appendable. Appendable is just misleading, since Monoid is more general than appending. Then why does it have a member named 'mappend'? :-) That's a mistake - and in fact, it's a good demonstration of why Monoid should not be named something like Appendable - because it misleads people into thinking that the structure is less general than it really is. Anton ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]
- Original Message From: John A. De Goes j...@n-brain.net On Jan 15, 2009, at 9:31 AM, John Goerzen wrote: AFAIK, the only language where that sort of wheel reinvention is popular is Java. But then Java seems to encourage wheel reinvention anyhow ;-) The Java reinventions look and feel like Java, because they're native implementations. This is even more important in Haskell where the differences between Haskell and C is about as large as you can get. The Java reinventions largely exist because of the huge deployment-time benefits you get from pure-Java code (cross-platform portability of compiled (byte) code, dynamic loading of compiled code over a network, etc.). Such reinventions are much less important for Haskell, since the typical deployment model for a Haskell program is much closer to that of a C program than a Java program or even a Python program. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]
On Thu, Jan 15, 2009 at 10:11 AM, Robert Greayer robgrea...@yahoo.comwrote: - Original Message From: John A. De Goes j...@n-brain.net On Jan 15, 2009, at 9:31 AM, John Goerzen wrote: AFAIK, the only language where that sort of wheel reinvention is popular is Java. But then Java seems to encourage wheel reinvention anyhow ;-) The Java reinventions look and feel like Java, because they're native implementations. This is even more important in Haskell where the differences between Haskell and C is about as large as you can get. The Java reinventions largely exist because of the huge deployment-time benefits you get from pure-Java code (cross-platform portability of compiled (byte) code, dynamic loading of compiled code over a network, etc.). Such reinventions are much less important for Haskell, since the typical deployment model for a Haskell program is much closer to that of a C program than a Java program or even a Python program. I think deployment of Haskell is even easier than that of python, in that you don't have to have all the developer packages installed on target machines to have other's benefit from their use in your binary at least with GHC that is. I've often been quite happily surprised what can be done with little in terms of runtime dependencies with Haskell. Dave ___ 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] Comments from OCaml Hacker Brian Hurt
On Thu, Jan 15, 2009 at 11:46 AM, Ross Mellgren rmm-hask...@z.odi.ac wrote: Usually when encountering something like Monoid (if I didn't already know it), I'd look it up in the library docs. The problem I've had with this tactic is twofold: First, the docs for the typeclass usually don't give any practical examples, so sometimes it's hard to be sure that the append in mappend means what you think it means. The documentation for Monoid is embarrassingly brief. The monoid class. A minimal complete definition must supply mempty and mappend, and these should satisfy the monoid laws. It doesn't even list the monoid laws! Second is that there appears to be no way to document an _instance_. It would be really handy if there were even a single line under Instances Monoid ([] a) that explained how the type class was implemented for the list type. As it is, if you know what a Monoid is already, it's easy to figure out how it would be implemented. Not necessarily. Any instance of MonadPlus (or Alternative) has at least two reasonable Monoid instances: (mplus, mzero) and (liftM2 mappend, return mempty). [] uses the first and Maybe uses the second. I recommend not creating direct instances of Monoid for this reason. If you want to use Monoid with Int, you have to use Sum Int or Product Int. -- 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] Arch Haskell News: Jan 11 2009
On Mon, Jan 12, 2009 at 4:00 AM, Don Stewart d...@galois.com wrote: Arch Haskell News: Jan 11 2009 Hey all, welcome to the first Arch Haskell News of 2009. (News about Haskell on the Arch Linux platform). Arch now has 827 Haskell packages in AUR. FWIW I just replaced gentoo[1] on my desktop with arch, at least in part due to this sort of community enthusiasm :) [1] i was going to replace it anyway, but wasn't sure what with martin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] software correctness ... can we in FPL step up to the plate??
http://www.businessweek.com/the_thread/techbeat/archives/2009/01/nsa_dhs_industr.html?link_position=link3 ... I think that http://www.galois.com is already doing as stated in the article/ .. I sincerely think there is a segway for Haskell here with strong and static type checking.. Strong static type checking is a very useful tool, but there's a lot more to securing against the 25 most common errors. For example, you can use the type system to ensure that output encoding is always applied to user-provided data, but you must first be aware of this issue and write libraries that enforce this and make use of these libraries a requirement in applications or application frameworks. Some problems such as cross-site request forgery are best addressed by the application framework, so framework authors must be aware of these issues and implement protections for the issue. This usually involves the use of some cryptographic primitives, and the type system doesn't do anything to make sure you get that right. Security issues are (mostly) a subset of correctness issues. Haskell provides some tools to help you make sure your program is correct, but there are a lot of ways to write incorrect software despite the help these tools provide. These tools are very valuable and should be sold to the wider developer community, but they are no silver bullet. Vasili Tim Newsham http://www.thenewsh.com/~newsham/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
It is rather funny. When we are young kids, we learn weird symbols like A B C a b c 1 2 3 which we accept after a while. Then we get to learn more complex symbols like ! ? + - / and that takes some time to get used to, but eventually, that works too. But Functor, Monoid or Monad, that we cannot accept anymore. Why, because these are not intuitive? Are the symbols above intuitive? When I started learning Haskell I also found it insane that strange terminology was used everywhere... But every time I try to find a better name, the name is too specific for the situation at hand. Just like Appendable is a good name for specific instances of Monoid In F# they renamed Monads to Workflows for the same reason. I find this just as confusing since a Monad has nothing to do with work and maybe a little bit with a single threaded flow... I would have hoped that we could all stick to the same terminology that was invented a long time ago... Since Haskell is mainly for computer scientists, changing all of this to make it more accessible to newcomers might lead to the mistake: if you try to please the whole world, you please nobody. I mainly think the problem is not the name, but the lack of many tiny examples demonstrating typical use cases for each concept. On Thu, Jan 15, 2009 at 7:27 PM, Lennart Augustsson lenn...@augustsson.netwrote: That's very true. But programming is one where mathematical precision is needed, even if you want to call it something else. On Thu, Jan 15, 2009 at 6:04 PM, Paul Moore p.f.mo...@gmail.com wrote: Mathematical precision isn't appropriate in all disciplines. ___ 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: Type errors, would extensions help?
I suggest you start using let in your do blocks; both of these
problems are solvable with let.
Binding with - instead of let makes the type system work harder,
and will generally require type annotations extensions for
polymorphic results. And it's almost never what you want, anyways;
you don't often have an object of type IO (forall a. a - a)
instead of forall a. IO (a - a) and this situation usually means
you should be using let instead.
Here's the Gtk example; the let on mkNotebook is not strictly
necessary but is just showing the concept in more places; I tend to
avoid x - do ... in my code; I feel it means I should be abstracting
more.
main = do
initGUI
j1 - drawingAreaNew
j2 - tableNew 1 1 True
let mkNotebook = do
note - notebookNew
let insertInNoteBook wid texto = do
lb - labelNew Nothing
labelSetMarkup lb texto
notebookAppendPageMenu note wid lb lb
insertInNotebook j1 J1
insertInNotebook j2 J2
return note
notebook - mkNotebook
putStrLn Finish
Also, is there a reason you hate the layout rule and are using
explicit semicolons everywhere?
-- ryan
On Thu, Jan 15, 2009 at 10:46 AM, Mauricio briqueabra...@yahoo.com wrote:
I have this problem trying to define a function
inside a do expression. I tried this small code
to help me check. This works well:
I guess you intended to call printNumber in the quoted snippet?
(...)
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE ImpredicativeTypes #-}
After you pointed my dumb mistake, I was able to build
the first example -- without any of the extensions! Haskell
can be misterious some times.
Strange enough, I can't get the original (and, to my eyes,
equal) problem to work. This is the smallest I could get it
to be:
--- WARNING: wrong use of gtk, just to get an example
---
import Graphics.UI.Gtk ;
main = do {
initGUI ;
j1 - drawingAreaNew ; j2 - tableNew 1 1 True ;
notebook - do {
note - notebookNew ;
insertInNotebook - let {
colocar :: (WidgetClass w) = w - String - IO Int ;
colocar wid texto = do {
lb - labelNew Nothing ;
labelSetMarkup lb texto ;
notebookAppendPageMenu note wid lb lb
} } in return $ colocar ;
insertInNotebook j1 J1 ;
insertInNotebook j2 J2 ;
return note
} ;
putStrLn Finish
}
---
GHC says:
teste.hs:15:21:
Couldn't match expected type `DrawingArea'
against inferred type `Table'
In the first argument of `insertInNotebook', namely `j2'
In a stmt of a 'do' expression: insertInNotebook j2 J2
(...)
but I would like first argument of insert... to be any
instance of WidgetClass, be it Drawing... or Table.
Thanks,
Maurício
___
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] Comments from OCaml Hacker Brian Hurt
John Goerzen wrote: Though if all we're talking about is naming, I would still maintain that newbie-friendly naming is a win. We can always say HEY MATHEMETICIANS: APPENDABLE MEANS MONOID in the haddock docs ;-) This is backwards. The real problem here is that most people coming from other languages aren't used to working with structures as abstract as monoids, and a natural first instinct is to try to un-abstract them, in this case via the suggested renaming. The thought process tends to be something like I didn't have this problem in language X, Haskell must be doing something wrong. This instinct is not appropriate in the Haskell context. (Although as others have noted, the documentation doesn't do much to help guide people through this.) One of the most mind-bogglingly important features of Haskell is that it is actually possible to make effective use of structures such as monoids in real code. In most languages, you wouldn't even try this. But if you're going to create a zoo of abstract structures like monoids, with the aim of being able to use them as very general building blocks, the last thing you should be doing is naming them according to particular applications they have. This goes against the goal of abstracting in the first place, and will ultimately be confusing and misleading. (As I pointed out in another comment, the misleadingly-named 'mappend' is an example of this.) If there's an existing name for the exact structure in question, it makes sense to use that name. If you're unfamiliar with the structure, then you're going to need to learn a name for it anyway - why not learn a name by which it is already known in other contexts? The main counter to the latter question is I want to give it a new name in order to connote an intended use, but unless the connotation in question is as general as the structure being named, this is a mistake. This issue is not unique to structures from abstract algebra category theory. It can arise any time you have a very polymorphic function, for example. It can often make sense to provide a more specifically named and typed alias for a very general function, to make its use more natural and/or constrained in a particular context, e.g.: specificName :: SpecificType1 - SpecificType2 specificName = moreGeneralFunction Similarly, in the case of monoid, we need to be able to do this, at least conceptually: Appendable = Monoid ...possibly with some additional constraints. In other words, HEY PROGRAMMERS: YOU CAN USE MONOID AS AN APPENDABLE THINGY (AMONG OTHER THINGS). This is perhaps an argument for a class alias mechanism, such as the one described at: http://repetae.net/recent/out/classalias.html But in the absence of such a mechanism, we shouldn't succumb to the temptation to confuse abstractions with their applications. Much as I dislike Java's penchant for 200-character names for things, I'm not sure Monoid is more descriptive than SomeSortOfGenericThingThatYouCanAppendStuffToClassTemplateAbstractInterfaceThingy :-) Usable descriptive names for very abstract structures are just not possible in general, except by agreeing on names, which can ultimately come to seem descriptive. For example, there's nothing fundamentally descriptive about the word append. Anton ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]
John Goerzen ha scritto: Python has pure interfaces to all the major databases. While it's true there are no native GUI libraries, there are pure Python libraries for just about everything else. Haskell is not yet to this point. By pure do you mean containing python code only? I'm looking through a few, and: PostgreSQL - psycopg - C PostgreSQL - pgsql - C PostgreSQL - pygresql - C MySQL - mysqldb - C MS SQL Server - pymssql - C And any interface that uses ODBC will, by necessity, be calling to C, because ODBC is defined as a C API and not a network protocol. Where are all these pure-Python drivers? Time ago, I implemented a client for the network protocol used by PostgreSQL: http://hg.mperillo.ath.cx/twisted/pglib/ it covers almost all the protocol features (only extended queries are not supported). It is implemented using Twisted. I would like to reimplement it in Haskell, sometime in the future. I tried to implement the MySQL network protocol, too, but it is a *mess*, so I gave up (and, at that time, there were strange claims about copyright). It is also possible to support MSSQL and Sybase, implementing a client for the TDS (Tabular Data Stream) protocol. TDS, too, is a mess (well, if you compare it with the PostgreSQL protocol), and last time I studied it, the freeTDS project only had a reversed engineered protocol documentation; now Microsoft has made the TDS variant used my MSSQL public: http://msdn.microsoft.com/en-us/library/cc448435.aspx So, in theory, it should not really be a problem to implement native and robust support for PostgreSQL, MySQL, MSSQL and Sybase. One benefit of these implementation would be builtin support to concurrency [1]. For PostgreSQL, a native implementation can be useful to listen notifies. [...] [1] the libpq API *has* support for async API, but it is not complete (and well tested like sync API, IMHO). As an example there is no support for async function call, although The Function Call sub-protocol is a legacy feature that is probably best avoided in new code. Similar results can be accomplished by setting up a prepared statement that does SELECT function($1, ...). The Function Call cycle can then be replaced with Bind/Execute. P.S.: the PostgreSQL protocol is really well designed Regards Manlio Perillo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Type errors, would extensions help?
I have this problem trying to define a function
inside a do expression. I tried this small code
to help me check. This works well:
I guess you intended to call printNumber in the quoted snippet?
(...)
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE ImpredicativeTypes #-}
After you pointed my dumb mistake, I was able to build
the first example -- without any of the extensions! Haskell
can be misterious some times.
Strange enough, I can't get the original (and, to my eyes,
equal) problem to work. This is the smallest I could get it
to be:
--- WARNING: wrong use of gtk, just to get an example
---
import Graphics.UI.Gtk ;
main = do {
initGUI ;
j1 - drawingAreaNew ; j2 - tableNew 1 1 True ;
notebook - do {
note - notebookNew ;
insertInNotebook - let {
colocar :: (WidgetClass w) = w - String - IO Int ;
colocar wid texto = do {
lb - labelNew Nothing ;
labelSetMarkup lb texto ;
notebookAppendPageMenu note wid lb lb
} } in return $ colocar ;
insertInNotebook j1 J1 ;
insertInNotebook j2 J2 ;
return note
} ;
putStrLn Finish
}
---
GHC says:
teste.hs:15:21:
Couldn't match expected type `DrawingArea'
against inferred type `Table'
In the first argument of `insertInNotebook', namely `j2'
In a stmt of a 'do' expression: insertInNotebook j2 J2
(...)
but I would like first argument of insert... to be any
instance of WidgetClass, be it Drawing... or Table.
Thanks,
Maurício
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]
Donn Cave wrote: Quoth Robert Greayer robgrea...@yahoo.com: The Java reinventions largely exist because of the huge deployment-time benefits you get from pure-Java code (cross-platform portability of compiled (byte) code, dynamic loading of compiled code over a network, etc.). Such reinventions are much less important for Haskell, since the typical deployment model for a Haskell program is much closer to that of a C program than a Java program or even a Python program. To me this argument can cut both ways. To come back to the LDAP example, Perl gets exactly this benefit from its natural implementation, compared to Python's interface to C OpenLDAP - you don't have to install OpenLDAP, eliminating a big nuisance for an interface that might have only a trivial role in your application. Perl is more portable in this particular respect, because it can do LDAP on its own. This cuts both (and many) ways. Someone else touched on how Haskell binaries are easier to deploy than Python programs because you don't have to have Python and a runtime set of things on all your machines. That is true. It is also true that Python programs are easier to install than Haskell ones because I can just apt-get install python-whateverIneed on every machine they'll run on, and don't have to worry about compiling them for that architecture. Moreover, I don't have to recompile them when a security bug is found in one of the libraries I use; I just upgrade the library, something that my OS might do for me automatically. Haskell is currently in somewhat of an unfortunate static linking stage. Dynamically-loaded libraries are pretty much the norm in C, as well as in many other languages. But if, say, the ByteString module has a security hole, I can't just upgrade it on a target box; I have to recompile all programs that use it, on all platforms. I have the luxury of not having to work with proprietary dinosaur systems. My package manager will just handle the LDAP stuff for me, whether it's Perl, Python, or Haskell. But to say that the Perl approach is better, or even more portable, I think misses the mark. Does it have the same level of stability and reliability as the C version? Is it as compatible with other servers? As full-featured? Does it get new features added as fast? The answers to all of these may be yes; I don't know. There are legitimate reasons for reimplementing things in other languages. But to return to the very beginning of the thread -- I do not see the simple fact that some Haskell modules have bindings to C underneath the covers as either a plus or a minus to those modules. Haskell code can be written well, or poorly, as can C code. Not using C is no guarantee of quality, and neither is using C. A well-designed FFI binding to a quality C library can turn out very nicely, as can pure Haskell code. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] How to simplify this code?
Dear list members,
I started looking into monadic programming in Haskell and I have some
difficulties to come up with code that is concise, easy to read and
easy on the eyes. In particular I would like to have a function add
with following type signature: JSON a = MyData - String - a -
MyData. MyData holds a JSValue and add should add a key and a value to
this JSON object. here is what I came up with and I am far from
satisfied. Maybe someone can help me to simplify this...
module Test where
import Text.JSON
import Data.Maybe (isJust, fromJust)
import Control.Monad
data MyData = MyData { json :: JSValue } deriving (Read, Show)
jsObj :: JSValue - Maybe (JSObject JSValue)
jsObj (JSObject o) = Just o
jsObj _ = Nothing
add :: JSON a = MyData - String - a - MyData
add m k v = fromJust $ (return $ json m) = jsObj = (return .
fromJSObject) = (return . ((k, showJSON v):)) = (return .
toJSObject) = (return . showJSON) = \js - (return $ m { json = js
})
add2 :: JSON a = MyData - String - a - MyData
add2 m k v = fromJust $ (\js - m { json = js }) `liftM` (showJSON
`liftM` (toJSObject `liftM` (((k, showJSON v):) `liftM` (fromJSObject
`liftM` (jsObj $ json m)
add3 :: JSON a = MyData - String - a - MyData
add3 = undefined -- How to simplify add?
What the code essentially does is that using functions from Text.JSON,
it gets the list of key-value pairs and conses another pair to it
before wrapping it again in the JSValue-Type.
Many thanks,
Levi
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt
John == John Goerzen jgoer...@complete.org writes: John I guess the bottom line question is: who is Haskell for? Category John theorists, programmers, or both? I'd love it to be for both, but John I've got to admit that Brian has a point that it is trending to John the first in some areas. Thank you for so nicely put it together... Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D pgpvadDX8GCob.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
That's very true. But programming is one where mathematical precision is needed, even if you want to call it something else. On Thu, Jan 15, 2009 at 6:04 PM, Paul Moore p.f.mo...@gmail.com wrote: Mathematical precision isn't appropriate in all disciplines. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]
Quoth Robert Greayer robgrea...@yahoo.com: The Java reinventions largely exist because of the huge deployment-time benefits you get from pure-Java code (cross-platform portability of compiled (byte) code, dynamic loading of compiled code over a network, etc.). Such reinventions are much less important for Haskell, since the typical deployment model for a Haskell program is much closer to that of a C program than a Java program or even a Python program. To me this argument can cut both ways. To come back to the LDAP example, Perl gets exactly this benefit from its natural implementation, compared to Python's interface to C OpenLDAP - you don't have to install OpenLDAP, eliminating a big nuisance for an interface that might have only a trivial role in your application. Perl is more portable in this particular respect, because it can do LDAP on its own. In general, I think it may be absurd to make general statements on this. (Though I imagine one generally valid comparison we can make between Java and Haskell libraries, is that Java's development was better funded.) Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Jan 15, 2009, at 1:21 PM, David Menendez wrote: On Thu, Jan 15, 2009 at 11:46 AM, Ross Mellgren rmm- hask...@z.odi.ac wrote: Second is that there appears to be no way to document an _instance_. It would be really handy if there were even a single line under Instances Monoid ([] a) that explained how the type class was implemented for the list type. As it is, if you know what a Monoid is already, it's easy to figure out how it would be implemented. Not necessarily. Any instance of MonadPlus (or Alternative) has at least two reasonable Monoid instances: (mplus, mzero) and (liftM2 mappend, return mempty). [] uses the first and Maybe uses the second. Sorry my brain apparently misfired writing the original email. What I meant to say is that for the Monoid instance on [a] it's fairly easy (knowing what a Monoid is) to figure out how it's implemented, but that's not true for other classes or instances. That is to say, I agree with you, and intended to up front ;-) -Ross ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] real haskell difficulties (at least for me)
On Thu, 2009-01-15 at 14:25 +0100, Ketil Malde wrote: Duncan Coutts duncan.cou...@worc.ox.ac.uk writes: On Thu, 2009-01-15 at 09:49 +0300, Eugene Kirpichov wrote: Would be nice if after a failed build cabal asked whether or not to upload its log immediately, and (on the hackage side) this led to an email being sent to the maintainer. It should not be quite that synchronous but yes that's the general idea. Perhaps the maintainer should receive a build summary at regular intervals? This would also work as a check whether there is a live maintainer at the other end of the listed maintainer address. (And hopefully be enough of an annoyance on the libraries@ list that people would start looking for maintainers for orphaned packages :-) It may well be tempting to plague maintainers until they fix their packages however in practise it will not work. We want a low barrier to entry for packages on hackage and we do not want to annoy package maintainers to the point where they decide to stop using hackage at all. Of course we also want to measure package quality. The approach I've always advocated is to define subsets of hackage that do meet higher quality levels. Be defining such subsets and holding them up as being a good thing in the community then it puts social pressure on maintainers to have their packages in those higher quality subsets. Then to help them do that they may choose to opt-in to various services like receiving a build summary at regular intervals. So it's the same goal but without the stick. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
John Goerzen wrote: Haskell developers, stop letting the category theorists name things. Please. I beg of you. I'd like to echo that sentiment! He went on to add: If you?re not a category theorists, and you're learning (or thinking of learning) Haskell, don't get scared off by names like monoid or functor. And ignore anyone who starts their explanation with references to category theory- you don't need to know category theory, and I don't think it helps. I'd echo that one too. I am constantly shocked and saddened at the Haskell community's attitude here. It seems to boil down to Why should we make it easier to learn Haskell? If people aren't prepaired to learn abstract algebra, category theory, predicate logic and type system theory, why should we bother to help them? So much for the famously helpful Haskell community. I am seriously beginning to wonder if the people using Haskell actually realise what regular programmers do and don't know about. (You may recall my recent straw poll where 80% of the programmer nerds I asked had no clue what a coroutine is or what existential quantification means.) Notice that monoid sounds almost *exactly* like monad. And yet, what you use them for is wildly unrelated. In a similar vein, who here can tell me off the top of their head what the difference between an epimorphism and a hylomorphism is? I've got a brick-thick group theory book sat right next to me and *I* can't even remember! Best of all, if Joe Programmer makes any attempt to look these terms up, the information they get will be almost completely useless for the purposes of writing code or reading somebody else's. I was especially amused by the assertion that existential quantification is a more precise term than type variable hiding. (The former doesn't even tell you that the feature in question is related to the type system! Even the few people in my poll who knew of the term couldn't figure out how it might be related to Haskell. And one guy argued that forall should denote universal rather than existential quantification...) The sad thing is, it's not actually complicated. The documentation just makes it seem like it is! :-( Databases are based on the relational algebra. But that doesn't seem to stop them from coming up with names for things that normal humans can understand without first taking a course in relational algebra. (Does the Oracle user guide state that a relation is simply a subset of the extended Cartesian product of the respective domains of its attributes? No, I don't *think* so! It says Oracle manages tables which are made up of rows... Technically less precise, but vastly easier to comprehend.) Why can't we do the same? If we *must* insist on using the most obscure possible name for everything, can we at least write some documentation that doesn't require a PhD to comprehend?? (Anybody who attempts to argue that monoid is not actually an obscure term has clearly lost contact with the real world.) As somebody else said, it basically comes down to this: Who the hell is Haskell actually for? If it's seriously intended to be used by programmers, things need to change. And if things aren't going to change, then let's all stop pretending that Haskell actually cares about real programmers. Sorry if this sounds like just another clueless rant, but I'm really getting frustrated about all this. Nobody seems to think there's actually a problem here, despite the incontravertible fact that there is... PS. As a small aside... Is the Monoid class actually used *anywhere* in all of Haskell? Surely saying that something is a monoid is so vague as to be unhelpful. The most you can say about almost everything is practically nothing and all that. All it means is that the type in question has a function that happens to take 2 arguments, and this function happens to have an identity value. How is this information useful? Surely what you'd want to know is what that function *does*?! And since a given type can only be a Monoid instance in one way, wouldn't passing the function and its identity in as parameters be simpler anyway? The integers form at least two different monoids AFAIK... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: monad-interleave 0.1
My two favorite functions in Haskell are unsafeInterleaveIO and
unsafeInterleaveST. I'm surprised there isn't a type class for
them. I just fixed this by adding the monad-interleave package to
hackage:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/monad-interleave
The package adds a Control.Monad.Interleave module. Here is the
entirety of the module:
\begin{code}
-- | Monads that have an operation like 'unsafeInterleaveIO'.
class Monad m = MonadInterleave m where
-- | Get the baton from the monad without doing any computation.
unsafeInterleave :: m a - m a
instance MonadInterleave IO where
unsafeInterleave = unsafeInterleaveIO
{-# INLINE unsafeInterleave #-}
instance MonadInterleave (ST s) where
unsafeInterleave = unsafeInterleaveST
{-# INLINE unsafeInterleave #-}
instance MonadInterleave (Lazy.ST s) where
unsafeInterleave = Lazy.unsafeInterleaveST
{-# INLINE unsafeInterleave #-}
\end{code}
Use it if you need it.
Patrick
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
For what it's worth, many (most/all?) programmers I know in person don't have the slightest clue about Category Theory and they may have known about abstract algebra once upon a time but certainly don't remember any of it now. They usually understand the concepts perfectly well enough but by lay terms or by no particular name at all. One of my friend once said ... and by 'programmer' I mean 'category theory specialist'. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt
On Thu, Jan 15, 2009 at 07:46:02PM +, Andrew Coppin wrote: John Goerzen wrote: If we *must* insist on using the most obscure possible name for everything, can we at least write some documentation that doesn't require a PhD to comprehend?? (Anybody who attempts to argue that monoid is not actually an obscure term has clearly lost contact with the real world.) Several people have suggested this, and I think it would go a long way towards solving the problem. The problem is: this documentation can really only be written by those that understand the concepts, understand how they are used practically, and have the time and inclination to submit patches. Experience suggests there may be no such people out there :-) As somebody else said, it basically comes down to this: Who the hell is Haskell actually for? If it's seriously intended to be used by programmers, things need to change. And if things aren't going to change, then let's all stop pretending that Haskell actually cares about real programmers. It might surprise you to see me say this, but I don't see this discussion as necessarily a weakness. I know of no other language community out there that has such a strong participation of both academics and applied users. This is a great strength. And, of course, Haskell's roots are firmly in academia. I think there there is a ton of interest in Haskell from the, ahem, real world programmer types. In fact, it seems to me that's where Haskell's recent growth has been. There are a lot of things showing up on Hackage relating to networking, Unicode encoding, databases, web apps, and the like. The nice thing about Haskell is that you get to put the theory in front of a lot of people that would like to use it to solve immediate programming problems. But they will only use it if you can explain it in terms they understand. There are a number of efforts in that direction: various websites, articles, books, libraries, etc. And I think the efforts are succeeding. But that doesn't mean there is no room for improvement. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
