Re: [Haskell-cafe] RE: ANN: System.FilePath 0.9
Andrew Pimlott wrote: On Thu, Jul 27, 2006 at 09:59:37PM +0200, Udo Stenzel wrote: In fact, that's consistent with the current documentation, because * getFileName foo == foo * getFileName foo/ == I have to disagree with that. No, you don't. That's the current behaviour of Neil Mitchell's System.FilePath 0.9 according to the haddockumentation. There isn't much point in disagreeing about observable facts, is there? First of all, is not a filename; Most certainly it isn't. Which is all the more reason not to like the current design. An empty filename just isn't the same as no filename. if you mean that foo/ has no filename, it makes much more sense to use something like a Maybe type. It does very much. In fact, I don't deem getFileName to be an essential function when a simple pattern match would do the same thing. foo/ really doesn't have a file name, as it very explicitly names a directory. Second, foo is just as good a directory as foo/ to the system ...unless you have both (think Reiser4) or you want to create the file (I think, but I'm not sure). However, what's the point in being ambiguous when we can be explicit? Sometimes there is a difference, libraries and tools shouldn't gloss over that without consideration. But if you wish to make the distinction, at least provide an operation that lets me force a path to be treated file-wise or directory-wise. WTF?! A path names either a directory or a file. We might have some operations that accept file names instead of path names. What's there to be treated? Being explicit about the distinction makes any ambiguity go away. Filesystems are ugly. :-) So are microprocessors. We can still have a nice programming language, and we can also have a nice filesystem language. And it is about the slash: foo can be a directory. No, it still isn't. We can distinguish between Directory (but not file, fifo, character or block special) and anything (if in doubt, not directory), which is an essential semantic distinction and not just the accidental presence of a slash (or backslash or colon or whatever $EXOTIC_OS uses). Also, parsing paths _once_ and printing them _once_ but doing everything else by operating on their logical structure makes specifying any intermediate operation a lot easier, if nothing else. If this thread shows anything, then it is that specifying path operations is harder than expected. Udo. -- Structure is _nothing_ if it is all you got. Skeletons _spook_ people if they try to walk around on their own. I really wonder why XML does not. -- Erik Naggum signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] commandline parsing?
I've been using pesco_cmdline for a while now. But I did notice that it doesn't fit my needs.. And it took me quite a while to get to know why I was getting strange typeable errors when specifying the wrong default value or reading the wrong type.. (these errors occur at runtime thus they don't use haskells strength) So I got another crazy idea. Why not see arguments as tokens and use a parser such as parsec? All you would have to do is creating some kind of syntax tree. Consider an example application : mmewcde (my mega executable which can do everything). mmewcde edit file mmewcde mv file file mmewcde mv --target-dir dest folder files mmewcde cp file file mmewcde cp --target-dir dest folder files mmewcde callsox infile options outfile Why not something like tar? mmewcde tar x|c|f|v* ..? Of cause I'll have to write the funtions edit :: String - IO () mv :: String - String - IO () mvDest :: String - [String] - IO () ... ... which have to be called Now I'd like to do this: optionParser = many $ oneOf [ edit, mv, mvDest, cp, cpDest, callsox, tar] optionParserWithHelp = optionParser | printHelp edit = do string edit file - existingFilename launchEditor file mv = [..] mvDest = do string mv string --target-dir td - existingDirectory files - many existingFilename map (movefile td) files [...] printHelp = do oneOf $ map string [-h,--help,--usage] prettyPrint optionParser main = do args - getArgs parseAndExecute optionParserWithHelp prettyPrint might look like this (this will be unncommon ;) mmewcde --help: many edit exitingfile or mv exitingfile file Would this be nice? Does this already exist somehow? perhaps many can even be made nongreedy so that you can specify more than one command at once mmewcde mv --target-dir d f1 f2cp --target-dir d2 f3 f4 ... Does this make sense? I think this would lead to self documenting well mantainable code. Marc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] commandline parsing?
Hi, Have you seen: System.Console.GetOpt http://www.haskell.org/ghc/docs/latest/html/libraries/base/System-Console-GetOpt.html Interestingly Hoogle doesn't seem to index it, but it does exist! (and in fact Hoogle even uses it...) Thanks Neil On 7/29/06, Marc Weber [EMAIL PROTECTED] wrote: I've been using pesco_cmdline for a while now. But I did notice that it doesn't fit my needs.. And it took me quite a while to get to know why I was getting strange typeable errors when specifying the wrong default value or reading the wrong type.. (these errors occur at runtime thus they don't use haskells strength) So I got another crazy idea. Why not see arguments as tokens and use a parser such as parsec? All you would have to do is creating some kind of syntax tree. Consider an example application : mmewcde (my mega executable which can do everything). mmewcde edit file mmewcde mv file file mmewcde mv --target-dir dest folder files mmewcde cp file file mmewcde cp --target-dir dest folder files mmewcde callsox infile options outfile Why not something like tar? mmewcde tar x|c|f|v* ..? Of cause I'll have to write the funtions edit :: String - IO () mv :: String - String - IO () mvDest :: String - [String] - IO () ... ... which have to be called Now I'd like to do this: optionParser = many $ oneOf [ edit, mv, mvDest, cp, cpDest, callsox, tar] optionParserWithHelp = optionParser | printHelp edit = do string edit file - existingFilename launchEditor file mv = [..] mvDest = do string mv string --target-dir td - existingDirectory files - many existingFilename map (movefile td) files [...] printHelp = do oneOf $ map string [-h,--help,--usage] prettyPrint optionParser main = do args - getArgs parseAndExecute optionParserWithHelp prettyPrint might look like this (this will be unncommon ;) mmewcde --help: many edit exitingfile or mv exitingfile file Would this be nice? Does this already exist somehow? perhaps many can even be made nongreedy so that you can specify more than one command at once mmewcde mv --target-dir d f1 f2cp --target-dir d2 f3 f4 ... Does this make sense? I think this would lead to self documenting well mantainable code. Marc ___ 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] Sending Ctrl-C under Windows
Hi, I want to send Ctrl-C to a process opened by runInteractiveCommand, under Windows. I have found System.Posix.Signals, but on Windows none of those methods exist. For further information, the processes I want to send Ctrl-C to are ghci and hugs, so doing something like terminateProcess isn't what i want, because I don't want the process to be terminated, just the current computation. If there is another way to programmatically terminate the computation started by hugs/ghci (but not the process) via runInteractiveCommand, that would be great too. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Serializing Functions and Actions for Distributed Programming
I'm very excited by the ability to pass functions or IO actions between threads of the same program. But I don't see any language or library support for doing so between programs, or between sessions with the same program. OCaml provides a partial solution: http://caml.inria.fr/pub/docs/manual-ocaml/libref/Marshal.html Though all it's really sending is an address and a hash of the binary program. Even SerTH doesn't help with functional types. I seek the knowledge of the Haskell Cafe: is there a reasonable way of addressing this problem? -- Brian T. Sniffen [EMAIL PROTECTED]or[EMAIL PROTECTED] http://www.evenmere.org/~bts ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Serializing Functions and Actions for Distributed Programming
Hi I'm very excited by the ability to pass functions or IO actions between threads of the same program. But I don't see any language or library support for doing so between programs, or between sessions with the same program. OCaml provides a partial solution: I know Tom Shackell has been trying to solve this with Yhc. His work is on trying to pull apart functions, send them over a network connection to an unrelated computer (different architecture, os, continent etc) and put them back together, with lots of communication and other cool stuff. I know there is an API for this in the yhc repo, but I have absolutely no idea how to use it :) I also think this is intended as a low level library, with something easier to use going to be layered on top of it. http://www-users.cs.york.ac.uk/~malcolm/cgi-bin/darcsweb.cgi?r=yhc-devel;a=headblob;f=/src/packages/yhc-base-1.0/YHC/Runtime/API.hs Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Serializing Functions and Actions for Distributed Programming
At Sat, 29 Jul 2006 14:07:51 -0400, Brian Sniffen wrote: I'm very excited by the ability to pass functions or IO actions between threads of the same program. But I don't see any language or library support for doing so between programs, or between sessions with the same program. There is a project, Mobile Haskell, that deals with this a bit. It requires a special version of the GHC compiler -- and I am not sure how publicly available the patches are. There are a few papers on it such as: http://homepages.inf.ed.ac.uk/stg/workshops/TFP/book/DuBois/duboismhaskell/cameraready.pdf j. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Baffled by Disk IO
I have run into a baffling distinction between the behavior of GHCi and the compiled binary from GHC. I suspect it's something pretty stupid on my part. I have the following test program test.hs import Matrix main = let f1 = bRgauss 4 3 f2 = bRgauss 3 2 fu = f1 *. f2 in bsave fumat fu -- The type signature of bsave is -- | save a matrix to a file bsave :: String - m - IO() bsave str z = do k - matindx z withCString str (\x - bmsave x k) and bmsave is a C routine that does a simple write to disk using fprintf. If I compile using GHC and run this as test.exe it does absolutely nothing, no file is actually saved. In fact no file is saved even if I try to print components of fu in the IO monad. Whereas if I load it into GHCi and run main, everything works as expected. Well sort of. Apparently everytime I extract something out of fu and use it in an IO monad it executes all the IO actions in fu, so it's easy to get unwanted behavior with incautious use. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
