Re: [Haskell-cafe] Modules and files
G'day all. Quoting Jerzy Karczmarczuk <[EMAIL PROTECTED]>: > Question of perspective... In Pascal, Modula, Python, Clean, > you name it, modules and files were always 1 - 1. A C++ class is basically an instantiable module. In C++, you can implement more than one module in a file, and you can implement a single module in multiple files. > Somehow > this is considered more 'clean', isn't it? It's usually considered good design practice in languages with modules to have one module responsible for one thing. Sometimes this is not possible, for example, if a module is responsible for implementing a major internal abstraction (e.g. "Core" in GHC, "database" in a database server etc). In that situation, it makes sense to distribute implementation of a module across more than one file. In Haskell, of course, you can do this by re-exporting symbols from imported modules; the Prelude is a case in point. Similarly, if a module is considered "private", such as with nested modules (or nested classes in C++), it is arguably cleaner to implement them privately lest someone else import them and use them. This usually means within the module which uses it, i.e., more than one module per file. > What's the problem with editing and displaying multiple files? This reminds me of a previous discussion of tab stops for some reason. I feel like saying "here's a nickel, kid... buy yourself a decent text editor", but that's a bit rude. More nicely: It's not the programming language's job to take up the slack where your specific text editor is lagging, especially when I can name about half a dozen editors off the top of my head which can handle multiple files perfectly well. > I believe that our 21st century should finally forsake the old > concept of file, as we see it now. A module is an entry in a > database. Be careful, lest you end up with a multiple maintenance problem. The reason why text files haven't gone the way of punched cards yet is that they're uniform and simple, and they're easy from a management point of view (one text file is one work assignment to a programmer in a team). > We have already separate 'interface files'... ...which are automatically generated. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] readEitherChan
I'd like a function that blocks until data is available on one of two channels and then returns that data wrapped in an Either. Here is my naive implementation: readEitherChan::Chan a -> Chan b -> Either a b readEitherChan a b = do var <- newEmptyMVar forkIO (readChan a >>= putMVar var . Left) forkIO (readChan b >>= putMVar var . Right) val <- readMVar return val eitherChan a b left right = readEitherChan a b >>= either left right But creating an MVar and starting two threads feels like a lot of overhead for a simple operation. Is there a better way or is forkIO so efficient that I shouldn't care? -Alex- _ S. Alexander Jacobson mailto:[EMAIL PROTECTED] tel:917-770-6565 http://alexjacobson.com ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] EuroHaskell 2004 pictures
The EuroHaskell 2004 Conference was great fun. Shae Erisson gave a Haskell tutorial, Jeremy Bobbio gave a talk about hOp, and John Hughes gave a talk/tutorial about Arrows. Code was written, pizza was purchased, most attendees claimed to enjoy themselves. A social event for programmers may be an oxymoron, but it was nice to get so many Haskellers in the same room. Until you've experienced the range of jokes and puns that can come from a CS Student Pub named "The Monad" you haven't plumbed the depths of FP humor. Anders Carlsson has pictures on his website: http://ridley.csbnet.se/gallery/eurohaskell Some of my favorites are the signs: http://ridley.csbnet.se/gallery/eurohaskell/p1010059 - (this is a bathroom / watercloset / toilet, insert your local term) http://ridley.csbnet.se/gallery/eurohaskell/p1010052 and of course the unicycle pictures: http://ridley.csbnet.se/gallery/eurohaskell/p1010026 http://ridley.csbnet.se/gallery/eurohaskell/p1010047 Tune in next year for EuroHaskell 2005! -- Shae Matijs Erisson - Programmer - http://www.ScannedInAvian.org/ "I will, as we say in rock 'n' roll, run until the wheels come off, because I love what I do." -- David Crosby ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] forkIO preemption
On 07 June 2004 22:59, S. Alexander Jacobson wrote: > When you forkIO and one of the threads blocks > (e.g. on a socket or a readchan), do execution > automatically resume on other threads and does the > blocked thread consume timeslices while it is > blocked? In GHC: yes, no. > In other words, is there any performance > penalty in setting timeslices very large in a > server app (where all I care about is throughput)? No. But there probably isn't much to gain either. Cheers, Simon ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Modules and files
Jon Fairbairn wrote: On 2004-06-14 at 15:59PDT "Iavor S. Diatchki" wrote: according to the report there should be no connection between modules and files, and one should be able to have multiple modules in a file, and even a single module in multiple files. however none of the implementations support that, so in effect there is 1-1 correspondence between modules and files. the reason for this is that it provides an easy way for the implementation to find the modules. But surely it's also a significant discouragement to those who would write small modules, and therefore a Bad Thing, at least until editing and displaying multiple files is made sufficiently easy? Question of perspective... In Pascal, Modula, Python, Clean, you name it, modules and files were always 1 - 1. Somehow this is considered more 'clean', isn't it? What's the problem with editing and displaying multiple files? There are even such systems as Matlab, where each *function* is put into a separate file, and the directory management of the underlying operating system becomes a part of the dynamic loading mechanism... [I find it a bit annoying, but I won't fight against them...]. I believe that our 21st century should finally forsake the old concept of file, as we see it now. A module is an entry in a database. Even standard text documents, because of hyper-links, multi- format, multi-part collections, etc., merit -perhaps - to be regarded not as "files", but as more structured entities... We have already separate 'interface files'... We should use more frequently multi-level editors. We know, anyway, that it is *good* to have some interaction between the editor and the compiler for the debugging... Jerzy Karczmarczuk ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Modules and files
On 2004-06-14 at 15:59PDT "Iavor S. Diatchki" wrote: > according to the report there should be no connection > between modules and files, and one should be able to have > multiple modules in a file, and even a single module in > multiple files. however none of the implementations > support that, so in effect there is 1-1 correspondence > between modules and files. > the reason for this is that it provides an easy way for > the implementation to find the modules. But surely it's also a significant discouragement to those who would write small modules, and therefore a Bad Thing, at least until editing and displaying multiple files is made sufficiently easy? Jón -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
