Re: [Haskell-cafe] (Un)termination of overloading resolution
On Tue, Feb 21, 2006 at 07:13:17PM -0800, [EMAIL PROTECTED] wrote: > I'm afraid that may still be insufficient, as the following > counter-example shows. It causes GHC 6.4.1 to loop in the typechecking > phase. I haven't checked the latest GHC. The HEAD is more cautious: F.hs:12:0: Variable occurs more often in a constraint than in the instance head in the constraint: E m a b (Use -fallow-undecidable-instances to permit this) In the instance declaration for `Foo m (a -> ())' This is required for all instances. GHC 6.4 relaxed it in the presence of FDs on the classes in the context, but as you've shown that is dangerous. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Array interface refactoring
Hello Alson, Tuesday, February 21, 2006, 11:33:49 PM, you wrote: AK> As a Haskell new-ish-bie, the various Array interfaces AK> seem a bit inconsistent and make learning/using arrays AK> complicated. I *do* understand how to use arrays in AK> Haskell, but I think that the interface could be AK> cleaned up. sorry, but i think that you don't understand the whole situation. btw, are you read http://haskell.org/haskellwiki/Arrays ? AK> Examples of current confusions: AK> IArray and Array are dupes (obvious); Array is a type constructor, while IArray is a class AK> listArray for IArray, but newListArray for MArrays; AK> "!" for IArray, but readArray for MArrays. they have different types (!) :: IArray -> Ix -> Element readArray :: MArray -> Ix -> IO Element can you unify these two operations - one monadic and one pure to common type signature? AK> Proposal: I would propose the following for Haskell': AK> "Array" is the interface for arrays; drop IArray; AK> "MArray" is the interface for arrays in monads (IO, AK> ST, etc); and these two interfaces should support operations with the same names but different types? :) i partially agree with your other suggestions -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] page renaming on the Haskell Wiki
Wolfgang, [Switching to haskell-cafe] Re: [1] http://www.mail-archive.com/haskell@haskell.org/msg18352.html [2] http://www.mail-archive.com/haskell@haskell.org/msg18356.html [3] http://www.w3.org/Provider/Style/URI Wolfgang Jeltsch wrote (in [2]): > On the other hand, I think that the above W3C article is far too extreme. It > tells you that stability is the most important thing concerning URIs. I will pursue this a little further, because I think that getting the web presence right is very important to maintaining an online community. It may be that we must agree to disagree, but based on my experience of using the web, stability of URIs *is* the most important thing (after content, of course). I have been using the W3C web site now for many years, and the inconsistencies you mention have never been a problem for me -- indeed, I hadn't even noticed them until you mentioned them. Why is this? I hypothesize that it is because, when the Web is used effectively, it is really quite rare to enter a URI manually. Instead, one uses various index pages, RSS feeds, search tools and so on to find a URI, and then simply click on it. Many URIs are never seen by human eye, but placed behind descriptive links. W3C themselves use URIs very intensively in transient communications, and their mailing system is set up to facilitate this (see their x-archived-at mail headers). A result of this is that the email archives, together with the web site pages, form a tightly interlinked collection of documents and comments that can be, and are, frequently cross-referenced rather than reinvented. But, for this to work, once a link has been placed in a document, feed, archive or whatever, it is crucially important that it continues to work for as long as the information it references is of interest to people. Without this, all the devices we use to find our way around the web simply fail -- not all at once, but over time. Even with every intent to maintain stability, this happens, but if you allow that URI stability is somehow less important than other conveniences, then I think all hope is lost for information continuing to be accessible. As for the difficulty of designing a consistent URI naming scheme for all time, the W3C position explicitly recognizes this, and this is why they recommend incorporating dates near the the root of the URI path. That way, fashions can change without requiring that pages published using older conventions be removed. How to do this in a wiki, I'm not sure, though I don't take that to mean we shouldn't try. I think the mediawiki mechanism you mention is reasonable if not ideal, though this would clearly be overwhelmed if page-renaming were to become the norm. There are, as you indicate, other technical concerns. But I still think they are more easily solved that the problems that arise by failing to maintain URI stability. Best regards, #g -- Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: haskell programming guidelines
Donald Bruce Stewart wrote: Perhas you'd like to put up a Style page on thew new Haskell wiki, perhaps under the Idioms category? I cannot promise it, but I'll try. If someone else is willing to do it, I would support this. Rob Dockins wrote: I understood that part of the guidelines as a pleading for Maybe. Humm. Well clearly I read it the opposite way. I suppose that means that whatever technique is being recommended should be put forth with more clarity ;-) done (use Maybe or another Monad) Andrew Bromage wrote: So, for example, f (g (h x)) can be expressed well as: f . g $ h x -- only use if you need to distinguish h f . g . h $ x-- better I see this differently. Expressions may be succinct! I find "$" and "." similar enough for non-obfuscation. But I collect cases where "$" does not work (i.e. for the kind #). Bad would be cases where "$" works differently than (reasonably) expected. John Meacham wrote: f x = ... y ... where Just y = Map.lookup x theMap now if the lookup fails you automatically get an error message pointing to the exact line number of the failure. or if the failure message of the routine is more important than the source location you can do f x = ... y ... where Identity y = Map.lookup x theMap These are potential runtime errors, that may be not so obvious to see in the source (ie. for user defined types) and even the compiler (ghc) does not emit a warning. Thanks for all your comments Christian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: haskell programming guidelines
On Wed, Feb 22, 2006 at 01:14:41PM +0100, Christian Maeder wrote: > John Meacham wrote: > >f x = ... y ... where > >Just y = Map.lookup x theMap > > > >now if the lookup fails you automatically get an error message pointing > >to the exact line number of the failure. or if the failure message of > >the routine is more important than the source location you can do > > > >f x = ... y ... where > >Identity y = Map.lookup x theMap > > These are potential runtime errors, that may be not so obvious to see in > the source (ie. for user defined types) and even the compiler (ghc) does > not emit a warning. Indeed, that is the entire point of the construct. ghc definitly should not emit a warning in this case as it is what lazy pattern matching is for. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] page renaming on the Haskell Wiki
Hello Graham, Wednesday, February 22, 2006, 12:57:39 PM, you wrote: GK> How to do this in a wiki, I'm not sure, though I don't take that to mean we GK> shouldn't try. I think the mediawiki mechanism you mention is reasonable if not GK> ideal, though this would clearly be overwhelmed if page-renaming were to become GK> the norm. my 2c is what new wiki is just two months old and we should refactor it now extensively to make it useable in the future. for example, i think that all libraries should be under Library or Libraries root and so on. we started with filling up the pages, now we had enough contents to see what the structure will serve better -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: standard poll/select interface
Hello John, Wednesday, February 22, 2006, 3:32:34 AM, you wrote: >> I agree that a generic select/poll interface would be nice. If it was >> in terms of Handles though, that's not useful for implementing the I/O >> library. If it was in terms of FDs, that's not portable - we'd need a >> separate one for Windows. How would you design it? JM> Yeah, this is why I have held off on a specific design until we get a JM> better idea of what the new IO library will look like. I am thinking it JM> will have to involve some abstract event source type with primitive JM> routines for creating this type from things like handles,fds, or JM> anything else we might want to wait on. so it is system-extendable in JM> that sense in that implementations can just provide new event source JM> creation primitives. i don't think that we need some fixed interface. it can be just parameterized: type ReadBuf h = h -> Ptr () -> Int -> IO Int type WriteBuf h = h -> Ptr () -> Int -> IO () so Unix implementations will use FD, Windows implementation will work with Handle and all will be happy :) JM> The other advantage of this sort of thing is that you would want things JM> like the X11 library to be able to provide an event source for when an JM> X11 event is ready to be read so you can seamlessly integrate your X11 JM> loop into your main one. you don't need to have the same interface for the X11 and files async operations. The library can export "ReadBuf FD", "WriteBuf FD" and "X11Op" implementations and you will use each one in appropriate place. JM> The X11 library would create such an event source from the underlying JM> socket but just return the abstract event source so the implementation JM> can change (perhaps when using a shared memory based system like D11 for JM> instance) without affecting how the user uses the library in a portable JM> way. JM> I will try to come up with something concrete for us to look at that we JM> can modify as the rest of the IO library congeals. as i already said, this IO library will not emerge by itself :) there is my library which use Stream class so it can accept any form of async library. there is a lib by Marcin Kowalczyk. and there is Einar's Alt-Network lib which already implements 2 async methods. so what we need is to convert Einar's work to single interface and make a Stream interface around this. the later will be better accomplished by me, but i don't know whether he planned to work on former. i can also do it, but without any testing because i still don't have any Unix installed :) Streams library by itself is now unix-compilable, thanks to Peter Simons -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re: standard poll/select interface
Hello Donn, Wednesday, February 22, 2006, 4:23:28 AM, you wrote: DC> Could an application reasonably choose between several dispatching DC> systems? For example, I'm working on a Macintosh here, where instead DC> of X11 Apple provides its NextStep based GUI with its own apparently DC> fairly well defined event system. I don't know that system very well, DC> but a MacOS Haskell GUI application would probably want to look in DC> that direction for event integration. Meanwhile, I might want to DC> work with kqueue, on the same platform, because it supports filesystem DC> events along with the usual select stuff. this depends not of John's design of this low-level lib, but on design of higher-level libs that will use it. just for example - Streams lib will allow to switch this manager even at runtime -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: standard poll/select interface
On Wed, Feb 22, 2006 at 03:28:26PM +0300, [EMAIL PROTECTED] wrote: > JM> Yeah, this is why I have held off on a specific design until we get a > JM> better idea of what the new IO library will look like. I am thinking it > JM> will have to involve some abstract event source type with primitive > JM> routines for creating this type from things like handles,fds, or > JM> anything else we might want to wait on. so it is system-extendable in > JM> that sense in that implementations can just provide new event source > JM> creation primitives. > > i don't think that we need some fixed interface. it can be just > parameterized: > > type ReadBuf h = h -> Ptr () -> Int -> IO Int > type WriteBuf h = h -> Ptr () -> Int -> IO () > > so Unix implementations will use FD, Windows implementation will work > with Handle and all will be happy :) I think you misunderstand, the poll interface will need to accept a _set_ of events to wait for. This is independent of the buffer interface and lower level than async IO (for the traditional definition of async IO). Not all event sources will necessarily be FDs on unix or handles on windows, if say a haskell RTS integrates with a systems built in event loop (such as the OSX example mentioned in another email). > JM> The other advantage of this sort of thing is that you would want things > JM> like the X11 library to be able to provide an event source for when an > JM> X11 event is ready to be read so you can seamlessly integrate your X11 > JM> loop into your main one. > > you don't need to have the same interface for the X11 and files async > operations. The library can export "ReadBuf FD", "WriteBuf FD" and > "X11Op" implementations and you will use each one in appropriate > place. You can't treat them as independent types at the poll site, since you need to wait on a set of events from potentially different types of sources. > JM> The X11 library would create such an event source from the underlying > JM> socket but just return the abstract event source so the implementation > JM> can change (perhaps when using a shared memory based system like D11 for > JM> instance) without affecting how the user uses the library in a portable > JM> way. > > JM> I will try to come up with something concrete for us to look at that we > JM> can modify as the rest of the IO library congeals. > > as i already said, this IO library will not emerge by itself :) there > is my library which use Stream class so it can accept any form of > async library. there is a lib by Marcin Kowalczyk. and there is > Einar's Alt-Network lib which already implements 2 async methods. so > what we need is to convert Einar's work to single interface and make a > Stream interface around this. the later will be better accomplished by > me, but i don't know whether he planned to work on former. i can also > do it, but without any testing because i still don't have any Unix > installed :) Streams library by itself is now unix-compilable, thanks > to Peter Simons I am not quite sure what you mean by this. the poll/select interface will be lower level than your Streams library and fairly independent. The async methods I have seen have been non-blocking based and tend to be system dependent, which is different than what the poll/select interface is about. the poll/select interface is about providing the mininimum functionality to allow _portable_ async applications and libraries to be written. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: getChar + System.Cmd.system + threads causes hangups
Donn Cave wrote: On Tue, 21 Feb 2006, Simon Marlow wrote: The reason for the deadlock is because getChar is holding a lock on stdin, and System.Cmd.system needs to access the stdin Handle in order to know which file descriptor to dup as stdin in the child process (the stdin Handle isn't always FD 0, because of hDuplicateTo). I was puzzled by this; from a quick review of the source, it seems that this is because system calls runProcessPosix, which has optional arguments for (stdin, stdout, stderr) for the child process, and when value is Nothing the parent's stdin etc. are used instead. That last part doesn't seem right to me, so if it's awkward to implement, I hope you will consider the possibility that no one needs it. The default value for fd 0 should be fd 0. A process that intends to change the default input stream on this level where the same stream should be inherited by children, can open or dup another file onto fd 0. Conversely, if a program contrives to change stdin to something besides fd 0, I would have assumed the intent was to avoid any affect on child processes. That's certainly a reasonable point of view. Currently the semantics are such that you can say h <- openFile "out" WriteMode hDuplicateTo h stdout system "echo \"hello\"" and the output from the echo command will go to the file "out". I'm perfectly willing to accept that supporting this behaviour is of limited usefulness, and even if you need it then you can call system the long way using runProcess. Anyone else have any opinions on this? Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Emulating bash pipe/ process lib
Hello Simon, Tuesday, February 21, 2006, 4:05:57 PM, you wrote: >> i'm not very interested to do something fascinating in this area. it >> seems that it is enough to do >> >> 1) non-blocking read of the entire buffer on input >> 2) flush buffer at each '\n' at output >> >> that should be enough to implement LineBuffering for everyone except >> purists? and for the NoBuffering the same except for flushing after >> each output operation? SM> Yes, exactly. This is almost what GHC's System.IO currently does, SM> except that for NoBuffering we have a fixed buffer size of 1 byte. It SM> would be safe to have a larger buffer size for NoBuffering read handles, SM> but I didn't recognise that when I wrote it. btw, this makes NoBuffering mode unusable for some tasks. Donn Cave wrote about this here: ... > when i think how to implementat LineBuffering, i decided that it is > the only possible way - read byte a time and see for a '\n'. i don't > know how System.IO implemented but i think that it should do the same Don't know - I see that Simon M followed up with an explanation that I think confirms my impression that LineBuffering is indistinguishable from BlockBuffering, for input. I assume it's only there for the sake of output, where it does make a difference. Only NoBuffering is interoperable with select. > DC> Since POSIX read(2) already supports exactly the functions you need for > DC> unbuffered I/O, it's simpler, easier and more efficient to leave the whole > DC> business right there at the file descriptor level. > > can you please describe that read(2) does that is better than reading > char-at-a-time? It returns whatever available data, as long as it's more than 0 bytes and less than the caller-supplied limit. This is the only read operation that works with select (including char-at-a-time, as a special case where the caller-supplied limit is 1.) > DC> I'm sure you can make > DC> a non-buffering buffer layer work on top of the file descriptor, but what > DC> makes it worth the trouble? > > if you don't have I/O library that implements what you need, it is > indeed simpler to use lower I/O directly. if you have I/O library that > does that you need, it is easier to write: > > (hIn, hOut) <- createUnixPipe > vPutStrLn hOut "hello" > s <- vGetLine hIn > > i'm writing such lib now, so i'm interested to know what i need to > do so that it will work ok. It won't! I mean, we can use it the same way as the ordinary Handle in the original example, but we know in principle, if you call vGetLine, it may block regardless of whether select reports input data, because select can't tell you whether there's a full line of input. So you don't have anything to worry about here - this is not your problem. I only wanted to point out that for select-based I/O event multiplexing, we will continue to need file descriptors and system level POSIX I/O, and that the need for this can occur in such ordinary, mundane applications as reading stdout and stderr in parallel. Donn Cave, [EMAIL PROTECTED] -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Emulating bash pipe/ process lib
Bulat Ziganshin wrote: Tuesday, February 21, 2006, 4:05:57 PM, you wrote: i'm not very interested to do something fascinating in this area. it seems that it is enough to do 1) non-blocking read of the entire buffer on input 2) flush buffer at each '\n' at output that should be enough to implement LineBuffering for everyone except purists? and for the NoBuffering the same except for flushing after each output operation? SM> Yes, exactly. This is almost what GHC's System.IO currently does, SM> except that for NoBuffering we have a fixed buffer size of 1 byte. It SM> would be safe to have a larger buffer size for NoBuffering read handles, SM> but I didn't recognise that when I wrote it. btw, this makes NoBuffering mode unusable for some tasks. Donn Cave wrote about this here: Someone is confused here, probably me. Could you elaborate on what you're referring to by "this", and "unusable for some tasks"? Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: Hashtable woes
On 21 February 2006 17:21, Chris Kuklewicz wrote: > From the shooutout itself: > > http://shootout.alioth.debian.org/gp4/benchmark.php?test=knucleotide&lan g=ghc&id=3 > > and > > http://shootout.alioth.debian.org/gp4/benchmark.php?test=knucleotide&lan g=ghc&id=2 > > (I forget the exact different between them) > > From the wiki (the Current Entry): > > http://haskell.org/hawiki/KnucleotideEntry#head-dfcdad61d34153143175bb9f 8237d87fe0813092 Thanks... sorry for being a bit dim, but how do I make this test run for longer? I downloaded the example input. The prog doesn't seem to take an argument, although the shootout suggests it should be given a parameter of 25. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re: standard poll/select interface
Hello John, Wednesday, February 22, 2006, 5:11:04 PM, you wrote: it seems that we don't understand each other. let's be concrete: my library reads and writes files. it uses read/write/recv/send to do this in blocking manner. now i want to have another operations what will have the SAME INTERFACES but internally use something like poll in order to allow Haskell RTS support i/o overlapping with "user threads". agree? these async operations should had the same interface as blocked ones, but that is impossible for Windows, so i propose to had slightly more general interfaces: type ReadBuf h = h -> Ptr () -> Int -> IO Int type WriteBuf h = h -> Ptr () -> Int -> IO () these are functions which my library will call, all other drom my viewpoint are internal details of this async lib. i don't know (i really don't know) how to build this list of events and how to manage it. the same is for X11 library - async lib just should provide alternative implementation of some operations and don't require from the user of async lib to manage eventlist. it seems like you want to define something more low-level, but i'm as i/o library author will be happy just to call some non-blocking equivalents of read/write provided by async lib. and it seems that i'm not competent enough to discuss details of its internal implementation ;) on the other side, you don't need to wait while some i/o library will be make standard. anyway such library will need non-blocking implementations of read() and write(), so this is the high-level interface that async lib should implement. agree? >> JM> Yeah, this is why I have held off on a specific design until we get a >> JM> better idea of what the new IO library will look like. I am thinking it >> JM> will have to involve some abstract event source type with primitive >> JM> routines for creating this type from things like handles,fds, or >> JM> anything else we might want to wait on. so it is system-extendable in >> JM> that sense in that implementations can just provide new event source >> JM> creation primitives. >> >> i don't think that we need some fixed interface. it can be just >> parameterized: >> >> type ReadBuf h = h -> Ptr () -> Int -> IO Int >> type WriteBuf h = h -> Ptr () -> Int -> IO () >> >> so Unix implementations will use FD, Windows implementation will work >> with Handle and all will be happy :) JM> I think you misunderstand, the poll interface will need to accept a JM> _set_ of events to wait for. This is independent of the buffer interface JM> and lower level than async IO (for the traditional definition of async JM> IO). Not all event sources will necessarily be FDs on unix or handles on JM> windows, if say a haskell RTS integrates with a systems built in event JM> loop (such as the OSX example mentioned in another email). >> JM> The other advantage of this sort of thing is that you would want things >> JM> like the X11 library to be able to provide an event source for when an >> JM> X11 event is ready to be read so you can seamlessly integrate your X11 >> JM> loop into your main one. >> >> you don't need to have the same interface for the X11 and files async >> operations. The library can export "ReadBuf FD", "WriteBuf FD" and >> "X11Op" implementations and you will use each one in appropriate >> place. JM> You can't treat them as independent types at the poll site, since you JM> need to wait on a set of events from potentially different types of JM> sources. >> JM> The X11 library would create such an event source from the underlying >> JM> socket but just return the abstract event source so the implementation >> JM> can change (perhaps when using a shared memory based system like D11 for >> JM> instance) without affecting how the user uses the library in a portable >> JM> way. >> >> JM> I will try to come up with something concrete for us to look at that we >> JM> can modify as the rest of the IO library congeals. >> >> as i already said, this IO library will not emerge by itself :) there >> is my library which use Stream class so it can accept any form of >> async library. there is a lib by Marcin Kowalczyk. and there is >> Einar's Alt-Network lib which already implements 2 async methods. so >> what we need is to convert Einar's work to single interface and make a >> Stream interface around this. the later will be better accomplished by >> me, but i don't know whether he planned to work on former. i can also >> do it, but without any testing because i still don't have any Unix >> installed :) Streams library by itself is now unix-compilable, thanks >> to Peter Simons JM> I am not quite sure what you mean by this. the poll/select interface JM> will be lower level than your Streams library and fairly independent. JM> The async methods I have seen have been non-blocking based and tend to JM> be system dependent, which is different than what the poll/select JM> interface is about. the poll/select interface is about providing the JM> mininimum funct
[Haskell-cafe] Re: [Haskell] page renaming on the Haskell Wiki
Am Mittwoch, 22. Februar 2006 10:57 schrieb Graham Klyne: > [...] Hello Graham, thank you for your answer. > I have been using the W3C web site now for many years, and the > inconsistencies you mention have never been a problem for me -- indeed, I > hadn't even noticed them until you mentioned them. > > Why is this? I hypothesize that it is because, when the Web is used > effectively, it is really quite rare to enter a URI manually. Instead, one > uses various index pages, RSS feeds, search tools and so on to find a URI, > and then simply click on it. Many URIs are never seen by human eye, but > placed behind descriptive links. I'm not convinced. Many other people might not notice improper URIs or might not care about them. But I do care! URIs are text and shall be human-readable and human-understandable. (I think, this view is also backed by the W3C.) Normally, every URI can be seen—at least in the browser window. Nowadays, people might have gotten used to cryptic URIs like http://www.amazon.de/exec/obidos/tg/browse/-/301128/028-9225198-9779755? site-redirect=de so that they don't think of a URI as something a human should be able to understand. But I'm sure that this is not what the inventors of URIs (or URLs) had in mind. And users should be provided with URIs which are as easy to remember and as sensible as possible, in my opinion, so that they have the ability to also enter them into their browsers by hand. How often can you see publications on paper which say something like: To learn more, first go to http://www.our-institution.org/, then click on the link "departments", then on the link "our department" and finally on the link "great new project". I think, it is far better to just say: To learn more, go to http://www.our-institution.org/departments/ours/great-new-project In the past, URIs became mostly something that only the computer is expected to deal with, not the human. I'm very much opposed to this and are therefore a fan of nice URIs. ;-) > W3C themselves use URIs very intensively in transient communications, and > their mailing system is set up to facilitate this (see their x-archived-at > mail headers). A result of this is that the email archives, together with > the web site pages, form a tightly interlinked collection of documents and > comments that can be, and are, frequently cross-referenced rather than > reinvented. > > But, for this to work, once a link has been placed in a document, feed, > archive or whatever, it is crucially important that it continues to work > for as long as the information it references is of interest to people. > Without this, all the devices we use to find our way around the web simply > fail -- not all at once, but over time. Even with every intent to maintain > stability, this happens, but if you allow that URI stability is somehow > less important than other conveniences, then I think all hope is lost for > information continuing to be accessible. Of course, stable URIs have a lot of advantages so URI stability is not something that should be ignored. But it should be weighed against other (important) things. I think that URI stability shouldn't always have the final word. > As for the difficulty of designing a consistent URI naming scheme for all > time, the W3C position explicitly recognizes this, and this is why they > recommend incorporating dates near the the root of the URI path. That way, > fashions can change without requiring that pages published using older > conventions be removed. Of course, this naming scheme isn't really consistent, since the naming schemes you use inside the "name spaces" of different years might (and probably will) differ. > How to do this in a wiki, I'm not sure, though I don't take that to mean we > shouldn't try. I think the mediawiki mechanism you mention is reasonable > if not ideal, though this would clearly be overwhelmed if page-renaming > were to become the norm. There are, as you indicate, other technical > concerns. But I still think they are more easily solved that the problems > that arise by failing to maintain URI stability. The fact that we are dealing with a wiki here makes retaining URI stability especially difficult. You don't have a webmaster allocating URIs. Since the key point of a wiki is that everyone can edit, more wrong things are made at first which have to be corrected later. I want to add another point which is maybe the most important argument for being open to renamings. In the wiki, the page title affects not only the URI but it's also part of the page. It's the human-readable title you see as a part of the article. So this title *has to* be meaningful and sensible. And if this title doesn't fit into some kind of guideline for titles or is not well chosen in another regard then it is just wrong and has to be corrected. Don't misunderstand me. You have a
Re: [Haskell-cafe] Re: [Haskell] page renaming on the Haskell Wiki
Am Mittwoch, 22. Februar 2006 13:00 schrieb [EMAIL PROTECTED]: > [...] > for example, i think that all libraries should be under Library or Libraries > root and so on. we started with filling up the pages, now we had enough > contents to see what the structure will serve better Be careful. A title is not a path name. I think, using hierarchy is good in cases like "GHC/Documentation" since the page is strictly about documentation *for GHC*. So it is clear what the ancestor page should be (GHC). The non-hierarchical title "GHC documentation" would contain the "GHC" anyway and the hierarchical title has more structure. But "Libraries/Edison" seems not like a good idea to me. The more structure you add, the higher is the probability that your structure will not fit future needs. If we want to minimize the reasons for page renamings in the future, we should tend to use "flat names", i.e., names with little or no hierarchical information. If we develop software, we also don't know the right design right from the start. (And therefore we need something better than CVS since CVS doesn't support moving of files and directories. ;-) ) Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hashtable woes
On 2/22/06, Simon Marlow <[EMAIL PROTECTED]> wrote: > On 21 February 2006 17:21, Chris Kuklewicz wrote: > > > From the shooutout itself: > > > > > http://shootout.alioth.debian.org/gp4/benchmark.php?test=knucleotide&lan > g=ghc&id=3 > > > > and > > > > > http://shootout.alioth.debian.org/gp4/benchmark.php?test=knucleotide&lan > g=ghc&id=2 > > > > (I forget the exact different between them) > > > > From the wiki (the Current Entry): > > > > > http://haskell.org/hawiki/KnucleotideEntry#head-dfcdad61d34153143175bb9f > 8237d87fe0813092 > > Thanks... sorry for being a bit dim, but how do I make this test run for > longer? I downloaded the example input. The prog doesn't seem to take > an argument, although the shootout suggests it should be given a > parameter of 25. > I think you need to run the Fasta benchmark with N=25 to generate the input file for this benchmark... /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: haskell programming guidelines
G'day all. Quoting Christian Maeder <[EMAIL PROTECTED]>: > I see this differently. Expressions may be succinct! I find "$" and "." > similar enough for non-obfuscation. But they're _not_ similar! Compare this notation: f . g . h $ x with the one you suggested: f $ g $ h $ x Advantages of the first one: - Encourages the idea that there is function composition going on. Function composition is one of the features of functional programming, so this should be highly encouraged. - Protects your code against the day when the committee realises that ($) has the wrong associativity. (It's the opposite of what you'd expect, since normal function application is left-associative.) Disadvantages: - None whatsoever. It's just as succinct and uses just as many parentheses. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hashtable woes
"Sebastian Sylvan" <[EMAIL PROTECTED]> writes: > I think you need to run the Fasta benchmark with N=25 to > generate the input file for this benchmark... I made the file available at http://www.ii.uib.no/~ketil/knuc.input -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
