x86_64 dynamic / PIC
I'm trying to get GHC 8.6.3 running on 64-bit Haiku, cross compiling from 32-bit Haiku. (UNIX-like OS, gcc 7.) The build died when it started trying link up 64 bit .dyn_o, with ld.bfd: utils/hsc2hs/dist-install/build/Main.dyn_o: relocation R_X86_64_PC32 can not be used when making a shared object; recompile with -fPIC But it appears to me that gcc is already configured to use -fPIC with cc1. (Both 32 bit and 64 bit cross-compiler.) And so is ghc-stage1. So I suspect the suggested remedy isn't going to get me very far. Anyone have an idea how to proceed? thanks! Donn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: GHC 8.8.1 and cabal-install version
> What operating system are you on? is it possible for you to use one of the > binaries from http://downloads.haskell.org/~cabal/cabal-install-3.0.0.0/ in > the meantime? It's Haiku, not exactly one of the major operating systems. I'm not in any hurry, I suppose I'll just let it rest and check back later to see if things have improved. It's too bad 8.8.1 breaks so much stuff, but I guess one gets used to that. Donn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] [ANNOUNCE] GHC 8.8.1 and cabal-install version
> https://www.haskell.org/ghc/blog/20190825-ghc-8.8.1-released.html says > > cabal-install users should note that cabal-install-3.0 or later is > required for use with GHC 8.8. I'm not the most sophisticated user of cabal-install ever, but it appears to me that 8.8.1 can't build 3.0.0.0? depends on base >= 4.8 && < 4.13, where 8.8.1 installs base-4.13.0.0. I'm working with cabal-install-3.0.0.0.tar.gz . It looks like it might be possible to up some of the dependencies, like HTTP to 4000.3.14, but I suppose there's a reason why cabal-install itself isn't there yet. Donn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Thread behavior in 7.8.3
Quoth Michael Jones m...@proclivis.com, ... 5) What does -V0 do that makes a problem program run? Well, there's that SIGVTALRM barrage, you may remember we went over that mid-August. I expect there are other effects. Donn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 'import ccall unsafe' and parallelism
I'm no judge of what's true about safe and unsafe, but this account of the system has at least to my ear the ring of authenticity: http://blog.melding-monads.com/2011/10/24/concurrency-and-foreign-functions-in-the-glasgow-haskell-compiler/ The FFI section is short and readable. With respect to whether unsafe does or does not block other threads, I can never penetrate the verbiage about capabilities to know for sure what to expect in practice, but when I checked, in practice, unsafe blocks other threads. I use safe to avoid this. Donn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Odd FFI behavior
[ ... re -V0 ] Thanks, this solved the problem. I would like to know more about what the signals are doing, and what am I giving up by disabling them? My hope is I can then go back to the dll expert and ask why this is causing their library a problem and try to see if they can solve the problem from their end, etc. I'm disgracefully ignorant about that. When I've been forced to run this way, it doesn't seem to do any very obvious immediate harm to the application at all, but I could be missing long term effects. The problem with the library might be easy to fix, and in principle it's sure worth looking into - while the GHC runtime delivers signals on an exceptionally massive scale, there are plenty of normal UNIX applications that use signals, maybe timers just like this for example, and it's easy to set up a similar test environment using setitimer(2) to provide the signal bombardment. (I believe GHC actually uses SIGVTALRM rather than SIGALRM, but don't think it will make any difference.) But realistically, in the end sometimes we can't get a fix for it, so it's interesting to know how -V0 works out as a work-around. I hope you will keep us posted. Donn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Odd FFI behavior
... Because the failures are not general in that they target one particular value, and seem to be affected by time, it makes me wonder if there is some subtle Haskell run time issue. Like, could the garbage collector be interacting with things? Does anyone have an idea what kind of things to look for? Sure - not that I have worked out in any detail how this would do what you're seeing, but it's easy to do and often enough works. Compile with RTS options enabled and invoke with RTS option -V0. That will disable the runtime internal timer, which uses signals. The flood of signals from this source can interrupt functions that aren't really designed to deal with that, because in a more normal context they don't have to. Donn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Errors in non-monadic code
jabolo...@google.com, MIME-Version: 1.0 Content-type: text/plain; charset=UTF-8 In-Reply-To: CAKFCL4VfY-Dz3Xo9ZUZ_SmfRQ2nLGDLbovU=suf1-ssnqvs...@mail.gmail.com References: CAKFCL4VfY-Dz3Xo9ZUZ_SmfRQ2nLGDLbovU=suf1-ssnqvs...@mail.gmail.com quoth Brandon Allbery, Even in IO, exceptions should be reserved for truly exceptional conditions (of the program cannot safely continue variety), not merely for error checking when this can be described as a normal flow of evaluation. Exceptions are not simply alternative flow of control, even in procedural languages; they are *disruptions* of flow of control. I think that would be debatable, especially as applied to procedural languages in general. It's very common to use exceptions in routine flow of control in Python programs, if I remember right. Meanwhile, the Haskell library in my opinion somewhat weakens your case by making ordinary conditions into exceptions, for example end-of-file. In the end it's a large grey area. Ideally, what the program has to do, or whether it can even continue at all, is determined by the program using information reported by the function that encounters the error. If there's a good reason why exceptions should be used only when the program won't be able to continue, it must be that the language's exception handling facililty isn't very robust. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative name for return
quoth Richard A. O'Keefe, ... If you're familiar with *English* rather than, say, the C family of programming languages, return isn't _that_ bad, there is certainly nothing about the word that suggests providing a value. The RFC822 headers of your email suggest that you use a Macintosh computer, so apart from the apparently disputable question of whether you're familiar with English, you have the same online dictionary as mine. Second definition: give, put, or send (something) back to a place or person, with examples she returned his kiss, usage from tennis and football, verdicts, etc. Third definition: yield or make a profit, fourth (re)elect a person or party. Return is all about providing a value, in English. When a term like return is used in a computer programming language in a sense that confounds any prior expectation based on English or other programming languages, that's the opposite of intuitive. It is what it is, and it's silly to talk about changing it at this point, but that doesn't mean that we have to turn the notion of intuitive on its head. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative name for return
quoth Richard A. O'Keefe Check the OED. Most of its meaning are about _turning back_, _resuming_, _reverting_. Yielding or making a profit is not at all about providing a value, but about money going out AND COMING BACK. It's the coming back part that makes it a return. Yes. Return means 'go/come back'; used transitively, it means 'go/come back with _'. value occurs twice in OED 'return, v.1, in neither case referring to providing a value. But of course, the word value as we use it is specific to our application, i.e. it's computer jargon, with an English meaning that's more like thing, object, datum. Wouldn't look for value to convey this meaning in an OED definition of return. In all of the senses, the underlying idea is not provision of a value, but going, turning, or bending back. [Which is actually what the Haskell return fails to do.] What goes/turns/bends back? When used intransitively, the subject; used transitively, the object, our value. I'll give you the COBOL example, it's no better the Haskell return. FORTRAN makes a good deal more sense for an English speaker but uses indirect object semantically - RETURN 2 means return to the second alternate return specified by the caller. (I never used that feature, so don't take my word for it, check your manual before using it!) Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: Non-recursive let
quoth David Thomas davidleotho...@gmail.com, It strikes me as unlikely static analysis would be confused by shadowing. Not to mention that the example only created two expressions of type IO Fd? (I.e., no file descriptors were opened, let alone leaked.) But in any case, I would have guessed that the idea here is that much more than a few examples and counter-examples will be needed to validate something like `shadowing is bad.' If the assertion isn't too simplistic, the examples sure will be. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Non-recursive let [Was: GHC bug? Let with guardsloops]
quoth Alberto G. Corona, Let is recursive because, unlike in the case of other languages, variables are not locations for storing values, but the expressions on the right side of the equality themselves. And obviously it is not possible for a variable-expression to be two expressions at the same time. The recursiveness is buildt-in. It comes from its pure nature. I'm surprised that it would come down to purity. It looks to me like simply a question of scope. I had to write an example program to see what actually happens, because with me it isn't intuitive at all that the name bound to an expression would be visible from within the expression itself. I suppose this is considered by some to be a feature, obviously to others it's a bug. I've gone to some trouble to dig up an nhc98 install (but can't seem to find one among my computers and GHC 7 won't build the source thanks to library re-orgs etc.) Because, I vaguely recall that nhc98's rules were different here? Anyone in a position to prove me wrong? thanks, Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Non-recursive let [Was: GHC bug? Let with guardsloops]
quoth Andreas Abel andreas.a...@ifi.lmu.de, ... I would doubt that nhc98 would interpret let xs = 0 : xs differently than ghc if it implemented anything close to the Haskell 98 standard. What I (so vaguely) remember was a compile error, for some reuse of an identifier where GHC permitted it. I suppose you're right, anyway, probably something else - maybe unambiguous nested shadowing? let x = t + 1 in let y = x in let x = y + 1 in x GHC allows this, and of course there's no recursion. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] createProcess interferes with sockets?
quoth Evan Laforge qdun...@gmail.com, ... and it still waits for the subprocess to complete. Actually, it looks like it's the client's hGetContents, since hGetChar comes back immediately. I guess that's understandable, but even hGetLine blocks. In the version I was looking at, if I change the server's output {-- IO.hPutStr hdl response --} to response\n, it works. Otherwise hGetLine will still be polling for the newline that will never come. System.IO doesn't seem to have a hRead :: Int - IO String, I guess you have to go down to the POSIX fd level, or read char-by-char. In the present case I believe we'd be talking about Network.Socket.ByteString.recv. With a POSIX device like a pipe, then System.Posix.IO.fdRead. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] createProcess interferes with sockets?
quoth Evan Laforge qdun...@gmail.com, ... Oh I see, because the subprocess inherits the socket connection. That makes sense, though it's tricky. Tricky tricky unix. Why does fork() have to be so complicated? Well, it's very elegant really. It's one of the tools UNIX gives you to decompose a task into discrete modules, programs running in separate processes - but inheriting file descriptors and other common environmental stuff. And in some respects should feel familiar to a Haskell programmer - can't modify parent's environment, etc. For me, moral in the story should be that buffered I/O is not robust, for a socket device or anything like it (UNIX pipe, whatever.) That isn't about UNIX, it's just inevitable. Maybe your client is really going to need the timely EOF anyway, but the immediate problem was that the server wrote to the socket and the client couldn't see it. Because the client read is buffered. Not robust. Some programmers are so wedded to the buffered language platform I/O functions that they'll find a way to defeat the buffering or work around it. That can be nonperformant where the semantics of the read depend on buffering, like getLine; don't know what would happen with hGetContents. The path that makes sense to me is low level I/O (read/recv) that simply returns what's there, up to the specified limit. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] createProcess interferes with sockets?
Quoth Evan Laforge qdun...@gmail.com, sleep = Process.createProcess (Process.proc sleep [5]) sleep = Process.createProcess ((Process.proc sleep [5]) {Process.close_fds = True}) - Because the client uses buffered I/O (hGetContents in this case, but hGet-anything would be the same), it doesn't see the server response until a) buffer full, or b) end of file (server closes connection.) - The server does close the connection, but after the sleep process has forked off with a copy of the connection fd. If it doesn't close that fd explicitly, it holds it open until process exit (5 seconds.) Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Overloading
On Mar 13, 2013, at 12:54 AM, Richard A. O'Keefe o...@cs.otago.ac.nz wrote: The interesting challenge here is that we should have Date + Period - Date Date - Period - Date Period + Date - Date Period - Date - ILLEGAL Period + Period - DeriodPeriod - Period - Period Date + Date - ILLEGAL Date - Date - Date and _also_ (remember we are trying to beat C++ here) Int +/- Int - Int. I think I would also want Period * Int - Period Period * Period - ILLEGAL Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Overloading
Peter Caspers pcaspers1...@gmail.com, data Month = January | ... ok, I will try to change my code in that direction. The idea is clear. To whatever extent these algebraic data types do map to integer values for your purposes, you can implement that by making Month an instance of Enum. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Question about forkIO
Quoth C K Kashyap ckkash...@gmail.com, ... Say I have a haskell function 'f' that does a forkIO and starts an action a. I create a DLL of this haskell code and inovke f from C. Can I expect the a to continue to run once f has returned to C? Once control returns to f's caller, outside of the Haskell runtime, then there isn't any way to dispatch IO threads - that's done by the runtime, so it can happen only while executing in the runtime. I am not a forkIO expert, that's just how it appears to me from my limited understanding of how they work. For extra credit - do the old IO threads resume if you call 'f' again, so you'd have more each time? (I don't know!) Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to return a network connection to C
Quoth C K Kashyap ckkash...@gmail.com, I am using http://hackage.haskell.org/package/connection. So I create network connection in Haskell getConnection :: IO Connection I'd like this connection to be returned to C so that subsequent calls from C can send in the connection handle. According to the documentation, he doesn't export enough of the Connection type to access the handle inside, and there appears to be no function provided to do that either. So it looks to me like you'd have to 1) make the connection by hand with Network.Socket.connect etc., 2) get the Socket fd, 3) make a Handle from the Socket, 4) pass that to connectFromHandle, and 5) use the fd with your C function. Note that the socket connection itself, represented by the fd that you return to C, will simply transmit data back and forth without modification. Specifically without SSL encryption. If you need SSL encryption in both Haskell and C, it would probably be simpler to implement the I/O in C and call it from Haskell. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to return a network connection to C
Quoth C K Kashyap ckkash...@gmail.com, Hey Donn ... when you say, implement the IO in C, you also imply implementing the SSL stuff too right? Yes, if you need encrypted I/O from C. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is a Haskell way to implement flags?
Quoth Branimir Maksimovic bm...@hotmail.com, In C usual way is to set some bit in integer variable by shifting or oring, and than check flag integer variable by anding with particular flag value. What is Haskell way? Of course you may do the very same thing, if you like. I think if there's only one of these for the entire program, most Haskell programmers would use a Boolean value, as the space you save with a single bit is of too little consequence to bother with bit twiddling in Haskell. The various flags that belong together might be housed in a `record'. Or, in some contexts a list of an algebraic type might be useful - like, if elem FlagDebug flags, or if any (flip elem flags) [FlagDebug, FlagVerbose] Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FunPtr to C function with #arguments determined atruntime?
Quoth Ryan Newton rrnew...@gmail.com, The scenario is pretty simple. I generate C code at runtime. I compile it to a .so. I know how many arguments it expects (but only at runtime), and I get a FunPtr back from 'dlsym'. How do I call it? I was hoping there would be some Raw lower level FFI layer that I could use to invoke a C function without automagic marshaling and all the other goodness provided by the normal foreign import mechanism. I feel that I might be confused about the problem, but since I don't see anyone direct answers -- in order to call a FunPtr, you can use foreign import ccall dynamic, to create a regular function. As described in the library documentation for Foreign.Ptr, which I bet you've seen, so you know this. You can cast the FunPtr to whatever type you like, so you can call the function with an argument list different from its initial declaration. There are two types of support you don't get, as I see it: 1) Haskell isn't going to make it really super convenient to use a variably typed function, and 2) there's the argument promotion issue mentioned in the document you cited. On that second point, however you go about this, you'll need to thoroughly understand what that means, but it won't strictly prevent you from calling this function, just puts you on notice that the FFI is blind to the argument types and will make default assumptions, so your C function needs to support that. On the first point, of course that's how Haskell is - and from a design point of view, if you're writing C code to be called from Haskell, wouldn't there be better ways to accommodate variable inputs than the argument list? Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FunPtr to C function with #arguments determined atruntime?
Quoth Ryan Newton rrnew...@gmail.com, ... Anyway, in this case it wasn't *too *painful to just generate a bunch of extra boilerplate C functions for (1) creating a data structure to hold the arguments, (2) loading them in one at a time, and (3) deallocating the structure when the call is done. Yuck. But no extra dependencies. If I understand you right, that's a better direction in my view - and when I've done stuff like this I've allocated and marshalled the data structure from the Haskell side fairly painlessly with Foreign.Storable(poke) etc., and the .hsc preprocessor macros for struct access (#poke, etc.) Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ifdef based on which OS you're on
As counterpoint to Vincent Hanquez' note about the certificate store on MacOS Windows, I'd like to cast some doubt on the notion that you can reliably find the cert store here on Linux or the *BSDs. So, if my experience with platforms like that is any guide, you'd rather not hard code this value in any case. I suppose that means application needs a configuration file. #else SSL.contextSetCADirectory ctx /etc/ssl/certs SSL.contextSetVerificationMode ctx $ SSL.VerifyPeer True True Nothing #endif On the bright side, a configuration file makes operational parameters like this very transparent for a sys admin who needs to work with it but wasn't in on the original install. Assuming the config file is easy to find in the first place. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FFI - Approaches to C/C++
Quoth Casey Basichis caseybasic...@gmail.com, ... I am using several other C++ libraries for which there are no existing bindings and no Haskell alternative packages that are even remotely close. Are you suggesting it would be better to write all my own FFI bindings for all the needed libraries? Everything I read suggests that Haskells strengths are in transformation and that interaction is not its strong suit. I've done it, for my own amusement - wrapped a C++ graphics toolkit and used it to write a couple small applications. Most of us would probably object to your transformation/interaction evaluation as presented above ... but it depends on your motivations. In my case, I simply wanted to use Haskell, and in fact I started with a model like yours where the UI was simply written in C++. There were some very cumbersome things about that arrangement though, so I was happy to integrate Haskell into the UI as soon as it became possible. On the other hand ... I'd be lying if I said the Haskell code is cleaner, or really advantageous in any compelling way if we're just talking about the UI. It has its moments - Haskell is always going to pull a few things off pretty well, in a UI or whatever - but of course, this particular UI API is specifically more suited to C++, than Haskell. So given that one can write good, clean code in C++, too, the question is whether Haskell is so vastly advantageous for such applications that it compensates for the sketchy binding. It isn't, I think. Whereupon we come to your original question. Personally, I would just work with the model that's natural to your API. If it's a C++ OO 3D graphics library, then go OO, for the very same reasons discussed above. FP may in principle have all the virtues mentioned in that article, and it's good to be on the lookout for ways you can deploy some of that in a C++ program, but when it comes time to use that OO API, it's what you've got. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How can I avoid buffered reads?
Quoth Brandon Allbery allber...@gmail.com, On Thu, Dec 6, 2012 at 3:24 PM, Tristan Seligmann mithra...@mithrandi.netwrote: On 29 Nov 2012 12:27 PM, Leon Smith leon.p.sm...@gmail.com wrote: System.Posix.IO and Foreign.This appears to work, but for better or worse, it is using blocking calls to the read system call and is not integrated with GHC's IO manager. This shouldn't be an issue for my purposes, but I suppose it's worth pointing out. Reading from an fd corresponding to an actual file is always blocking. select() will always indicate that the fd is ready for reading and writing, and I think epoll() will refuse to operate on the fd at all. This; it's a longstanding gripe among those of us who use network filesystems heavily, since it's entirely possible those reads *will* block... but the usual architecture of Unix-like kernel filesystem code doesn't provide any way to see it or do anything about it. A wretched state of affairs indeed, but is that the same problem? While I guess /dev/urandom isn't supposed to block, so it would look about the same to select(2) either way, /dev/random is select-able, true? If GHC IO is using blocking I/O on everything opened by name, on the assumption it's talking to a filesystem, then that looks to me like GHC's error, not UNIX's. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Blocking IO FIFOs
From Jason Dusek jason.du...@gmail.com, ... If I could somehow arrange to detect EOF when /tmp/exitpipe is closed, then I might as well redirect 1 and 2 to FIFOs and wait for them to EOF, collecting the output. However, all of my experiments suggest that there is simply no way in Haskell to detect the closing of the write end of a FIFO. With `openFileBlocking', one can detect when a FIFO is *opened*; but not when it is closed. It looks to me like our colleague in another followup may have it working in an example. I have run into some trouble myself, with an example program demonstrating the approach I proposed. With a pre-existing named pipe, that I would just keep using, for whatever reason it worked the first time, failed the second, and so forth, working every other time. If the test program created the named pipe, it failed every time. There are probably reasons for all this, but I haven't looked very hard. That was using withFile. If I use POSIX I/O, it works fine. So it looks to me like there is indeed a way in Haskell to detect a closed FIFO, it just may not be Haskell I/O without a lot more work ironing out the possible causes of failure. I believe that doesn't need to be a problem for you, though, because 1) your application is by nature exclusive to POSIX platforms, and 2) you need the named pipe only to detect command process exit, and you can still apply Haskell I/O to the more interesting data that accumulates in the command output disk file. And there may be an answer for my problems with Haskell I/O. Could be as simple as using openFileBlocking, which apparently isn't supported in the ghc I'm using. Could have something to do with the fine points of named pipes - for example, I believe you're supposed to open them O_RDWR in situations you'd think would call for O_READONLY. (Though the latter worked for me with POSIX I/O.) While I'm here ... I share the concern expressed in an earlier followup about the outputs from bash in runInteractiveProcess. This looks like a feature of runInteractiveProcess that makes it intrinsically something like a code smell. input-only and output-only processes are commonly used and fairly tractable, where input-output processes are unusual and and fragile, so it's an unfortunate convenience. I think the idea is that you'd use createProcess specifying only the input redirection. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Blocking IO FIFOs
Quoth Jason Dusek jason.du...@gmail.com, ... For my application, it's important to be able to run multiple queries against the same Bash session. Waiting for Bash to shut down is thus not a viable way to finalize the response. You could redirect to disk files and also use a pipe to wait for exit. I suppose you redirect I/O for individual queries by applying shell redirections to the command? So like this, uname -a /tmp/cmd1 2 /tmp/cmd2 7 /tmp/exitpipe ... then read from /tmp/exitpipe, ignore empty result and read command outputs from the disk files. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Getting PID of a child process
Quoth Jason Dusek jason.du...@gmail.com, Using `System.Process.runInteractiveProcess', I can start a process and get a handle to it: runInteractiveProcess :: FilePath - [String] - Maybe FilePath - Maybe [(String, String)] - IO (Handle, Handle, Handle, ProcessHandle) For diagnostic purposes, I'd like to print the PID of the process attached to this handle -- how best to do that? There's a good chance this isn't the best way, but it seems to work: import System.Process import System.Process.Internals (ProcessHandle__(..), PHANDLE, withProcessHandle) -- for use with withProcessHandle getPID :: ProcessHandle__ - IO (ProcessHandle__, Maybe PHANDLE) getPID h@(OpenHandle t) = return (h, Just t) getPID h@(ClosedHandle t) = return (h, Nothing) main = do (h0, h1, h2, hp) - runInteractiveProcess /bin/date [] Nothing Nothing mp - withProcessHandle hp $ getPID print mp Seems like more scaffolding than this application really ought to require. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] forkProcess, forkIO, and multithreaded runtime
Since we're talking about forkIO here - not forkOS - is it possible to control the use of OS threads to avoid this problem? As I understand it, the problem is with real OS threads. A program running entirely in multiple `green' threads will fork to the same set of threads in the same state, creating no problem with internal state. I'm guessing this is why he sees the problem at 9 threads - maybe the runtime picks up another OS thread at that point. Of course one could link the unthreaded RTS, and that will cause everything, including runtime gc etc., to run in the parent thread, true? And there are some runtime options to control number of threads scheduled. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Issue building ghc on NetBSD/amd64
Quoth lhagan lhaga...@gmail.com, Just tried changing the flag in build.mk, but I get the same error. Also, I'm pretty sure I need the --enable-hc-boot flag. Without it, I get: configure: error: GHC is required unless bootstrapping from .hc files. Unless I've missed a whole lot of progress on this matter, it's going to be much more work than just getting the flags right. Several years ago, I managed to build 6.8, by starting with an OpenBSD port of 6.6 as an hc donor, and of course building 6.6 on NetBSD, and then using 6.6 to build 6.8. There's a great deal of debugging and patching that needs to be done in the process, some of it already done for i386 and some novel to amd64. I presented it to the NetBSD Haskell maintainer, but obviously it's a low priority - I think in the intervening years, you're the second person to mention it. If that individual (whose identity I can't recall at the moment) has a working NetBSD/amd64 port at this time, of any version, that would be extremely helpful; unfortunately I don't, I think my amd64 hardware is defunct. (I don't think I got the interpreter working, by the way, and that also usually means no haddock, etc.) Today, you'd be obliged to follow the same course, but probably would have to build one or two intermediate GHC versions as I doubt that 6.6 could build the current version. I understand the current version is not able to be bootstrapped from hc files at all. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] createProcess running non-existent programs
Quoth Alexander Kjeldaas alexander.kjeld...@gmail.com, See access(2) ... a classic code smell in UNIX programming, for the same reasons. We can solve this problem in an efficient way that works well, and equally well, on any POSIX platform that supports F_CLOEXEC on pipes, and I can't think of anything that doesn't. The appended code is the basic gist of it. This was not invented by the Python world, but as suggested it's one of the things that we'd get from a review of their subprocess module. Donn spawn file cmd env = do (e0, e1) - pipe fcntlSetFlag e1 F_CLOEXEC t - fork (fex e0 e1) close e1 rx - readFd e0 256 if null rx then return t else ioerr (chrToErrType rx) file where fex e0 e1 = do close e0 catch (execve file cmd env) (\ e - writeFd e1 (errToChr e : ioeGetErrorString e)) ioerr (e, s) file = ioError (mkIOError e s Nothing (Just file)) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] createProcess running non-existent programs
Quoth Evan Laforge qdun...@gmail.com, ... ... or at least make sure the haskell version doesn't suffer from problems fixed in the python one. Exactly. This morning I'm reading suggested solutions that would work only some of the time, or on only some platforms, which wouldn't be satisfactory in the long run. Though speaking of platforms, I guess one large headache would be what to do about Microsoft operating systems. Given the unusual nature of these functions (I mean, what operating-system-independent command are you going to invoke, anyway?), maybe it would be OK for the more elaborate support functions to be POSIX / Windows specific. At the level where people are redirecting the output FD and not the error FD, etc. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] createProcess running non-existent programs
Quoth Brandon Allbery allber...@gmail.com, On Mon, Aug 13, 2012 at 10:23 AM, Donn Cave d...@avvanta.com wrote: Though speaking of platforms, I guess one large headache would be what to do about Microsoft operating systems. Given the unusual Microsoft provides APIs that work as is for this, by my understanding; it's the POSIX fork/exec model that makes life difficult. Or interesting, anyway. I wasn't thinking of the `exception in child' problem here, so much as more generally, how much is a fully cross-platform API worth, in a situation where the eventual application of the API is inherently unlikely to be of a cross platform nature. The Python version goes to some length, but can't fully resolve the inconsistencies. That's OK if someone wants to go to the trouble, but if I'm right about inherent platform dependence, it runs the risk of being more irritating than helpful! Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do vs. pattern matching
On Sat, Aug 4, 2012 at 7:05 AM, Alexander Solla alex.so...@gmail.com wrote: On Fri, Aug 3, 2012 at 11:34 PM, Matthew wonderzom...@gmail.com wrote: ... With do notation, I can write something like this: do foo - callFoo x bar - callBar x return (baz) ... The short answer is to write a one liner using (=) and (), unless you need to bind more than one value to a variable. In that case, you should use an applicative interface, if available and otherwise possible, and finally do-notation. But the longer answer would be, it depends! Right? The `do' notation is clear and easy to follow; it's low maintenance - even if you have nothing to bind right now, if that comes up in the future, it will drop right into that `do' block; it's classic Haskell that doesn't need any explaining to (hardly) anyone. Maybe it's your last choice, maybe it's my first. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Call to arms: lambda-case is stuck and needsyour help
Quoth Cale Gibbard: Personally I don't see why everyone appears to prefer the syntax with \ in it over just the obvious case section syntax which was originally proposed. case of { ... } ... Does anyone else agree? Yes. I don't see this as an `anonymous function' in any special sense, only inasmuch as the workaround in its absence involves one. I.e., if I for some reason had been compelled to write \ a - hPutStrLn stdout a ... that wouldn't make hPutStrLn stdout an anonymous function in my book. Neither is `case of ...' an anonymous function, or functions. Donn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Call to arms: lambda-case is stuck and needsyourhelp
Quoth Wolfgang Jeltsch g9ks1...@acme.softbase.org, ... What is an anonymous function? A function that has no name, that is, a function that is not assigned to an identifier. So (+ 1), \x - x + 1, and any lambda case are all anonymous functions. All right, that more general definition works for me. It doesn't take much away from my point, though - in any case, clarity doesn't demand that we use \ for all these things, only for \ x - x + 1. Donn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Call to arms: lambda-case is stuck and needs your help
I think it's very helpful if lambdas start with a lambda, which to me suggests \case. I'd be interested to hear that explained a little further. To me it isn't obvious that `case of' is `a lambda', but it's obvious enough what it is and how it works (or would work) - it's `case' with type a - b instead of just b ... and really the backslash just seems to confuse the issue. I don't remember it from discussions of this proposal in years past. ... But you presumably do not want \proc, because proc is the lambda. I also wondered if `case of' could be equally well generalized to allow for `proc of', but I would certainly have no idea. Donn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Call to arms: lambda-case is stuck and needs your help
The `multi-clause lambda' seems more elegant, if the syntactical problems could be worked out. I mean, unnamed functions are thus just like named functions, something that you'd probably think to try just as soon as you needed the feature. I don't understand the issues well enough with the layout rules to comment on Tyson Whitehead's ideas about that, and for the same reason this may be a useless idea, but what if each clause were introduced by \, would that clarify the column structure, or does indented block structure require a less-indented `layout herald'? f = \ (Just a) (Just b) | a 0 || b 0 - Nothing \ (Just a) (Just b) - Just (a * b) \ _ _ - Nothing Donn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Martin Odersky on What's wrong with Monads
To be fair, while it's great that Functor et al. are available to help solve problems like that with a Tree data structure, in the present context it mostly shows that a trivial example was used to illustrate the problem. Unless I'm missing how this generic fold functionality solves the more general problem. Quoth Alberto G. Corona, ... There is no such problem in imperative languages, which work ever in an hardwired IO monad. Or to look at it from the other direction, the problem with Haskell is that it allows the programmer to write non-IO functions. To the extent that's a real problem, the solution would obviously be to exercise some restraint with the pure code and write more in the IO monad. If you will humor me, we understand that this code is equally satisfactory from a mathematical perspective and there's no crime in it. But does it help with the `flags problem?' Suppose that functions f and g both have IO types; f calls g, and g has optional behavior depending on some IO value computed previously, the flag. The way I understand it, I can accomplish this without passing the flag around: with an IORef. What's less clear to me is whether Haskell really supports the module level accessible IORef value I need. Also known as top level mutable state. Is the NOINLINE pragma I've been using with GHC, really a sound and reliable practice that we're reasonably confident will be supported by other compilers? It feels to me like I'm pulling a weird trick, to do something that's trivial in other programming languages. Maybe that's part of the problem, that imperative programming receives something a little short of full support in Haskell, inasmuch as basic features like top level mutable state require relatively arcane incantations. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell integration with C/C++ (GSOC)
Quoth Anthony Cowley acow...@seas.upenn.edu, ... I think this is a consequence of line buffering rather than a bug. If you write your own increment function in Haskell, you get the same behavior. If you `hSetBuffering stdout NoBuffering` before your `putStr` call, you should get the behavior you wanted. Though if you must do one or the other, I think hFlush makes as much sense. I think his perspective may be that the C stdio library appears to recognize that a TTY read is an occasion to flush stdout. If you already know better, there are ways to solve this problem - flush, change buffering, or use stderr instead of stdout. If you weren't expecting it, though, Haskell might by comparison seem a little retarded. Maybe it isn't a bug. As things stand, it is quite a hassle to use a Haskell library of any complexity called from C. And Haskell is slightly handicapped in this application, if it still doesn't support any good mechanism for top level mutable state (Cf. http://www.haskell.org/haskellwiki/Top_level_mutable_state ) I wonder if the fact that we recognize these problems but haven't been super-motivated to solve them, suggests that there hasn't really been that much call for stand alone Haskell libraries? (The proposal seems to say that C++ programmers could jump at this opportunity because they've been wanting to use Haskell but were afraid of the IO Monad?) Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] thread killed
On Wed, Apr 4, 2012 at 6:37 AM, tsuraan tsur...@gmail.com wrote: What sorts of things can cause a thread to get an asynchronous thread killed exception? I've been seeing rare, inexplicable thread killed messages in my Snap handlers for a long time, but they aren't from Snap's timeout code. This is a long shot, but it's easy to test - turn off GHC's RTS timer, +RTS -V0 -RTS. That removes a source of SIGALRM interrupts. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Theoretical question: are side effects necessary?
Quoth Jeff Shaw shawj...@msu.edu, ... I'm thinking that side effects are really only necessary because Haskell programs expect to mutate the state of a computer outside of the haskell program. I'm not a computer scientist, but in English, side effect is an effect that accompanies some other effect. E.g., you may take an antihistamine to relieve hay fever, and experience a side effect of drowsiness. Let's call the first an `intended effect'? Then in the matter of the computer outside the Haskell program - which is intended effect, and which is side effect? I'd have said, side effects would be like memory paging, deferred resource access for other processes, etc.? Some programs might leave behind temporary files ... I hope the answer is not that in computer science we regard all effects as side effects because the ideal computer program simply exists without consequence. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Theoretical question: are side effects necessary?
Quoth Chris Smith cdsm...@gmail.com, ... The answer is that side effects has become something of a figure of speech, and now has a specialized meaning in programming languages. When we're talking about different uses of the word function in programming languages, side effects refer to any effect other than evaluating to some result when applied to some argument. For example, in languages like C, printf takes some arguments, and returns an int. When viewed as just a function, that's all there is to it; functions exist to take arguments and produce return values. I'm surprised by the use of function as a unit. I would have expected expression or something, but maybe that isn't semantically interesting as long as one can't exist independent of the other. ... But C extends the definition of a function to include additional effects, like making Hello world appear on a nearby computer screen. Because those effects are aside from the taking of arguments and returning of values that functions exist to do, they are side effects... even though in the specific case of printf, the effect is the main goal and everyone ignores the return value, still for functions in general, any effects outside of producing a resulting value from its arguments are side effects. If that's so, it's unfortunate. It would have been more profitable to confine the application of this term (side effect) to the context of the program, where it 1) makes sense in English, and 2) applies to a programming device that has always been of some interest. I have a little trouble defending this point of view because there's some overlap, inasmuch as the program may also retrieve values via external I/O. And Haskell provides writeIORef/readIORef as a convenient way to demonstrate that as a technical side effect without resorting to actual I/O. Still, the use of I/O and similar techniques to create a side effect are interesting as such, and my point is that if we call every I/O a side effect, the term loses its value as a way to describe this programming feature. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Theoretical question: are side effects necessary?
Quoth KC kc1...@gmail.com, On Fri, Mar 16, 2012 at 7:44 PM, Jerzy Karczmarczuk jerzy.karczmarc...@unicaen.fr wrote: ... but the question of purity of a program - in my opinion - concerns the program, and nothing else. You might be thinking of software engineering purity. Or software engineers might be thinking of purity in the same way. I personally hope I think of purity in a way that's of some practical use in terms of Haskell programs, and I would hope software engineers in general would do likewise. From that perspective, it seems to me that M. Karczmarczuk is on pretty solid ground. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: How to work around GHC bug
Quoth Volker Wysk p...@volker-wysk.de, ... I'll report this as a bug in the GHC Trac. But for now, I need to work around the problem somehow. The encoders in GHC.IO.Encoding all work on buffers. How do I recode the command line, in order to get proper Unicode strings? Data.Text might work for you. I'm not guaranteeing that you'll get a proper Unicode string out of this, but you'll get a String with one (LATIN-1) value per character: import qualified Data.ByteString.Char8 as P import Data.Text.Encoding (decodeUtf8) import qualified Data.Text as T let arghs = [\195\164] let args = map (T.unpack . decodeUtf8 . P.pack) arghs Donn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Preventing leaked open file descriptors whencatching exceptions
Quoth Bryan O'Sullivan b...@serpentine.com, On Tue, Feb 21, 2012 at 8:16 AM, Ryan Newton rrnew...@gmail.com wrote: FYI, lsof confirms that there are indeed many many open connections to the same FIFO: Like all of the lowest-level I/O functions, openFD just gives you back an integer, and the Fd type has no notion that there's an underlying system resource associated with it. It's your responsibility to manage it (i.e. clean up manually when catching an exception). What's more - if I understood the hypothesis correctly, that the exception occurs during openFd - that fails to return an Fd because the open(2) system call fails to return one, so it would presumably be an OS level bug if there's really an open file descriptor left from this. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stable pointers: use of cast to/from Ptr
Quoth =?ISO-8859-1?Q?Yves_Par=E8s?= yves.pa...@gmail.com, You mean I have to use a type like StablePtr (IORef Stuff)? Because there I can only peek (deRefStablePtr) the pointer, not poke it. I take it I should return to C a StablePtr to the new value if I don't want to use IORefs... Yes ... Or else I have to use regular Ptrs with Foreign.Marshall.Alloc.malloc yes! Both of these are good ways, to do different things. In your initial message, you asked about a foreign function modifying a value in storage accessible from Haskell - that's regular Ptr. Either way, read or write, communication with the foreign layer is through Ptr, not StablePtr. StablePtr is for Haskell expressions, which would be totally inscrutable to the foreign function anyway, and which naturally do not expect to be modified, so yes, a new value shall be attached to a new StablePtr. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stable pointers: use of cast to/from Ptr
Quoth Yves Pares, ... If StablePtrs cannot have their pointed value modified (either C or Haskell-side), that mostly limits their interest, doesn't it? I'm not sure I follow what's happening in the two cases you mention, but in case it helps, I use StablePtr as a way to smuggle Haskell values through a non-Haskell layer. On the other side, they are just things - not really pointers, so while void* is all right as long as it's the right size, it is a little misleading. Tag might be a better word. castStablePtrToPtr doesn't change that - you still get a tag, not a memory address. I can think of no use for it, unless you want to call a function that happens to use a Ptr () without expecting it to point somewhere in the memory address sense. Since they're Haskell values, it would be perverse to modify them. I just want them back, in a Haskell function dispatched by the other layer. If I want to pass data per se to the other side, I have to marshal it to be readable CInts and such, and then pass it as a Ptr. And/or if the data is to be modified by the other side, same deal, I have to un-marshal it back into Haskell. I actually use them with a C++ layer, where of course the dispatch happens through C++ object member functions. That allows me to map Haskell functions to the C++ API in a C++ derived class that just maintains a table of the actual Haskell `member functions', and a StablePtr for the actual Haskell data. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
Quoth Evan Laforge qdun...@gmail.com, ... The non-composing non-abstract updates are what bug me, and make me scatter about tons of 'modifyThis' functions, both for composability and to protect from field renames. So ... at the risk of stating the obvious, is it fair to say the root of this problem is at least the lack of `first class' update syntax? For example, in a better world you could write stuff like modifyConfig :: (Config - a) - (a - a) - Config - Config modifyConfig fr fv a = a { fr = fv (fr a) } upTempo config = modifyConfig tempo (+ 20) config ... but today you get `fr' is not a (visible) constructor field name So you need a modifyConfigTempo, etc. - when even the above is inconveniently specific, as we'd rather have modifyRecord :: RecordType r = (r - a) - (a - a) - r - r I'm not saying modifyRecord (+ 20) tempo config would be the ideal syntax for everyone who's been dreaming of records improvement, just trying to get at the underlying problem with minimal syntactic distractions. Nested structure doesn't look like a special problem - modifyRecord innerRecord (modifyRecord inInField (+ 20)) outRecord An operator with some infixing doesn't seem to buy a lot - (innerRecord \{} (inInField \{} (+ 20))) outRecord ... but better might be possible without sacrificing composability. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution -record update
Quoth AntC anthony_clay...@clear.net.nz, ... No, Donn, it's not the lack of syntax, it's the lack of semantics for first- class (polymorphic) record update. And there's very little that's obvious. Ah, you're right, I certainly shouldn't have used the word syntax there. But just to be clear on the point, I wonder if you could expand on what you mean by polymorphic above. I mean, when I wrote modifyRecord :: RecordType r = (a - a) - (r - a) - r - r ... while this does obviously represent a polymorphic function, if I write data Config { tempo :: Int, ...} f = modifyRecord tempo (+20) ... then f has type Config - Config, it isn't polymorphic. I am however vaguely aware that some parties to the Record Question would like to make record fields themselves polymorphic, so that 'tempo' could be defined for multiple record types and 'f' would, I suppose, have a type like RecordThatHasTempo r = r - r Maybe that's semantically more like overloading, but in any case, it isn't strictly necessary in order to support first class updates, true? Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
Quoth Evan Laforge qdun...@gmail.com, On Thu, Feb 9, 2012 at 12:49 PM, Donn Cave d...@avvanta.com wrote: ... For example, in a better world you could write stuff like modifyConfig :: (Config - a) - (a - a) - Config - Config modifyConfig fr fv a = a { fr = fv (fr a) } upTempo config = modifyConfig tempo (+ 20) config I think lenses already do better than this, since not only are they more concise than the above (once you've resigned yourself to a few TH splices), they aren't restricted to being only record fields. How more concise? Because =# is more concise than `modifyRecord', etc., or is there some real economy of expression I missed out on? Asking because, honestly I didn't get your earlier example - setTempo :: Config - Config setTempo y = Config.deflt#Config.tempo =# y ... something's missing, I thought - but maybe it's conciser than I can reckon with! The rest - the functions that look like fields, the enforcing invariants, etc. - are cool as lens features, but for Haskell records in general it seems like something that would call for a lot of discussion. Compared to first class record update, where it's easy to see how close to broken the current situation is. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution -record update
Quoth AntC anthony_clay...@clear.net.nz, Donn Cave donn at avvanta.com writes: ... The narrow issue we're trying to address is namespacing, and specifically name clashes: two different records with the same named field. ... Now in return for me answering that, please answer the questions in my earlier post about what limitations on update you'd like: * record-type changing? * Higher-ranked fields? * How many forall'd variables? * Constrained forall'd variables? All right, but it won't be a very interesting answer; partly because I personally do not find the name clash issue per se as compelling as some - I mean, it can be a nuisance for sure, but it isn't broken the way update per se is broken - and partly because, as best as I can make out, I have never dreamed of using any of those four features. So I hope someone with more invested in the problem will chime in! Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
Quoth AntC anthony_clay...@clear.net.nz, ... It was a surprise to me that dot without spaces around is still legal syntax for function composition. It isn't even unusual. You can find stuff like fromIntegral.ord in packages downloaded to build cabal-install for example. It graphically appeals to the notion of a function composed of several functions, so the programmers in question will likely not even be repentant! It's hard to imagine this all going anywhere, really, without some way around the code breakage. Maybe a different separator, like record\field, that really doesn't occur in infix like that. Are all pseudo- or virtual or calculated 'fields'. (Or if not fields, then attributes or properties.) I presume you're not suggesting we have both a function `area' and a pseudo- field `.area'? Well - there's no conflict between those two names, if `.area' is an identifier that starts with a dot. But virtual or calculated fields would presumably not be supported. Depends on whether it's legal to define a function `.area', or `.' spelling is allowed only for declared record fields. Personally I think the latter would be the right choice there - left of the dot must be a record value, right of the dot must be a field declared for that record. I understand this is not the direction you're going. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
Quoth AntC anthony_clay...@clear.net.nz, ... We're on the slippery slope! Where will it end? And now that I've found it, I so love: customer.lastName.tail.head.toUpper-- Yay! ... compared to present practice, with where dot is function composition only - (toUpper.head.tail.lastName) customer So two competing meanings of ., where one is literally the reverse of the other. Of course we won't be able to spell composition without spaces any more, so technically the backwards and forward sense of . are distinct, but it seems kind of unfortunate anyway. ... If you'll consider an idea from the peanut gallery ... for me, the dot notation for fields may as well be spelling as an operator - that is, customer.lastName deploys a field named .lastName. If someone modified Haskell to allow postfix notation from this perspective, when compiler sees customer.lastName, it would look for an identifier .lastName, so it would work only where the fields are so declared: data Customer = Customer { .lastName :: String, .firstName :: String } Without explicit dot nomenclature (as per current practice), only normal function application syntax would be supported (as per current practice.) Unspaced composition (fromInteger.ord) would still be broken, I suppose, but the error (Not in scope: `.ord') would at least be pretty obvious. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
Quoth AntC anthony_clay...@clear.net.nz, ... My proposal is that field selection functions be just ordinary functions, and dot notation be just function application(tight-binding). Then: object.fieldfuncmethod == fieldfuncmethod object (Subject to the tight binding for the dot.) And one-sided dot application is pointless (! errk I mean 'without purpose', no different to writing the bare object or bare fieldfuncmethod). That's interesting! The wiki page on SORF (Simple Overloaded Record Fields, http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields) has some language that, as I interpreted it, meant that Has/Get syntactic sugar depended on the dot, so it's indispensable. Your proposal actually has some similar language but, I see you don't mean it that way. That's great news for anyone who's really dying to get somewhere with records, if it means that the functionality could in principle be introduced independently of changes to the interpretation of . that would break a lot of code. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
Quoth Steve Horne sh006d3...@blueyonder.co.uk, On 30/01/2012 07:09, Donn Cave wrote: ((separate . crack . .smallEnd) egg).yolk (f egg).yolk where f = separate . crack . .smallEnd Scary - that .smallEnd worries me. It's like a field is being referenced with some magical context from nowhere. Obviously I need to read that full proposal. As I said: (assuming for the sake of discussion a functional dot notation .field = \ r - r.field) By that, I meant to say that I just made that up. I am sure that various proposals have made some notational provision for `\ r - r.field', but it may or may not be `.field', I don't recall. But that's all the magic there is to it. Either you have a notational shorthand for it, or you're obliged to write out `\ r - r.field' Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Exceeding OS limits for simultaneous socketconnections
Quoth Marc Weber marco-owe...@gmx.de, ... - replace getContents conn by something strict and close the handle yourself? (not sure about this.) That's an easy one to try, right? Just force evaluation of the getContents return value, in getMsg. If lazy I/O is the culprit here, it wouldn't be the first time. But that will only reduce the magnitude of the problem (albeit perhaps vastly reduce), and as you say, the more reliable solution is to limit the number of concurrent accepts, and concurrent open-and-sends. It isn't like socket I/O really benefits from unlimited concurrency, as all the data is still serially pushed through a wire; you just need enough concurrent peer connections to keep the interface busy. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell Cafe] strict version of Haskell - doesit exist?
Quoth Richard O'Keefe o...@cs.otago.ac.nz, ... On the other hand, a designed-to-be-strict language-and-libraries with close-to-Haskell *syntax* would be nice. I recently described F# as combining the beauty of Caml with the functional purity of C# -- both of course are like the snakes of Ireland. Ouch, the beauty of Caml, tsk. I guess it may not have been a very lively project of late, but the Timber language, a descendant of O'Haskell, is supposed to be strict, I suppose because they were using it in real time controllers. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
On 28/01/2012 13:00, Paul R wrote: ... All this dot syntax magic frankly frightens me. Haskell, as a pure functionnal language, requires (and allows !) a programming style that just does not mix well with object oriented practices. Stretching the syntax to have the dot feel a-bit-but-not-really like object oriented programming, mainly to have IDE autocompletion on some cases, does not make much sens. In the glasgow-haskell-users discussion, it has been pointed out (to little apparent effect) that the current notation for access by field name, `field record', is naturally functional and is easier to read for a functionally trained eye than a postfix `record.field' alternative. It isn't so much of an issue for OO programmers because the languages are also procedural and the expressions tend to be simpler. In a language like Haskell, an expression could switch back and forth several times between pre-fix (functional) and post-fix (dot) notation. Like, `yolk (separate (crack (largeEnd egg)))' becomes `(separate (crack (egg.smallEnd))).yolk' That elementary example doesn't give me much trouble, but it sure doesn't seem to be much of an improvement in notational elegance. See how natural the transformation with function composition - yolk (separate (crack (largeEnd egg))) yolk ((separate . crack . largeEnd) egg) yolk (f egg) where f = separate . crack . largeEnd ... compared to the re-shuffing necessary with post-fix dot notation (assuming for the sake of discussion a functional dot notation .field = \ r - r.field) (separate (crack (egg.smallEnd))).yolk ((separate . crack . .smallEnd) egg).yolk (f egg).yolk where f = separate . crack . .smallEnd Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] named pipe interface
Quoth Serge D. Mechveliani mech...@botik.ru, By openFile you, probably, mean openFd. Yes, sorry! Another point is the number of open files, for a long loop. ... toA_IO = openFd toA WriteOnly Nothing defaultFileFlags ... When applying axiomIO in a loop of 9000 strings, it breaks: too many open files. I do not understand why it is so, because toA_IO and fromA_IO are global constants (I have not any experience with `do'). toA_IO is a global constant of type IO Fd, not Fd. You now see the importance of this distinction - the action actually transpires at toA - toA_IO, and each time that executes, you get a new file descriptor. Anyway, I have changed this to toA = unsafePerformIO toA_IO fromA = unsafePerformIO fromA_IO ... (I need to understand further whether my usage of unsafePerformIO really damages the project). It's actually similar to the way some libraries initialize global values, but there are some additional complexities and it isn't clear to me that it's all guaranteed to work anyway. You can read much more about this here: http://www.haskell.org/haskellwiki/Top_level_mutable_state I'm no expert in this, but they're sure here on haskell-cafe, so if you want to take this up, you might start a new topic here, something like global initialization with unsafePerformIO, describe what you're doing and explain why you can't just pass the open file descriptors as function parameters. ... Indeed. Initially, I tried C - C, and used fgets, fputs, fflush. And it did not work, it required to open/close files inside a loop; I failed with attempts. Again, do not understand, why (do they wait till the buffer is full?). I don't know. When I was younger, I used to track these problems down and try to explain in detail why buffered I/O is a bad bet with pipes, sockets etc. I don't think anyone listened. I think I am going to experiment with I am old, so listen to me and see if it works any better. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] named pipe interface
Quoth Serge D. Mechveliani mech...@botik.ru, [ ... why in Haskell instead of FFI ... ] Because it is a direct and the simplest approach. Why does one need a foreign language, if all the needed functions are in the standard Haskell library? The GHC Haskell library makes some compromises with normal I/O functionality for the sake of its runtime thread system. As difficult as named pipes can be in any case, they can be even trickier in GHC Haskell for this reason. I didn't suggest an FFI approach myself, in my previous follow-up, only because if you haven't worked with the FFI it's a significant initial investment, but I believe it's what I would do. (If I were somehow compelled to used named pipes.) Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] named pipe interface
Quoth Serge D. Mechveliani mech...@botik.ru, ... Initially, I did the example by the Foreign Function Interface for C. But then, I thought But this is unnatural! Use plainly the standard Haskell IO, it has everything. So, your advice is return to FFI ? Well, it turns out that the I/O system functions in System.Posix.IO may work for your purposes. I was able to get your example to work with these functions, which correspond to open(2), read(2), write(2). I would also use these functions in C, as you did in your C program. Haskell I/O functions like hGetLine are analogous to C library I/O like fgets(3) - in particular, they're buffered, and I would guess that's why they don't work for you here. Specifically, openFile toA WriteOnly Nothing defaultFileFlags openFile fromA ReadOnly Nothing defaultFileFlags fdWrite toA str (str, len) - fdRead fromA 64 return str Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Composition operator [was: Re: Records in Haskell]
Quoth Evan Laforge qdun...@gmail.com, ... ... Groups that are reluctant to make formatting changes for fear of confusing revision history are really going to hate that one. I think a lively discussion would also be possible over whether exotic characters are suitable at all. But this is a more or less academic discussion, taking place on ghc-users, nominally out of view of the general Haskell community, right? So I don't need to intrude with mundane objections of that nature. Donn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Composition operator [was: Re: Records in Haskell]
Quoth Greg Weber g...@gregweber.info, On Thu, Jan 12, 2012 at 6:23 PM, Malcolm Wallace malcolm.wall...@me.comwrote: So, who is up for proposing centred dot as the new record-field syntax? We don't need to make this change overnight. The new records system will be turned on by an extension. If you use the new records system, then you will be forced to place spaces around the dot composition operator, or use the unicode dot or an alternative operator. The point seems pretty well taken. If many programmers will actually want the records extension, then they'll want to use it without breaking their code, and the above proposal would help with that. Changing the compose notation to some other character would break practically all Haskell code, so it's hard to take that seriously. Spaces or unicode would be the worst idea yet, but hopefully that isn't what you meant. Donn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Composition operator [was: Re: Records in Haskell]
Quoth Brandon Allbery allber...@gmail.com, On Thu, Jan 12, 2012 at 17:14, Donn Cave d...@avvanta.com wrote: Spaces or unicode would be the worst idea yet, but hopefully that isn't what you meant. Thing is, I think the spaces idea is considered acceptable because it's *already there*. Take a look at how GHC decides whether (.) is the composition operator or a module qualification. Sure, but I mean: given that f . g continues to be composition, but a record notation takes over the unspaced dot, breaking an existing f.g ... ... what is the rationale for an additional unicode dot? That's why I more or less assume that wasn't what he meant, that both . and unicode dot would be supported at the same time for composition, but rather just that one or the other would be chosen. Donn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Composition operator [was: Re: Records in Haskell]
Quoth Brandon Allbery allber...@gmail.com, ... Seems obvious to me: on the one hand, there should be a plain-ASCII version of any Unicode symbol; on the other, the ASCII version has shortcomings the Unicode one doesn't (namely the existing conflict between use as composition and use as module and now record qualifier). So, the Unicode one requires support but avoids weird parse issues. OK. To me, the first hand is all you need - if there should be a plain-ASCII version of any Unicode symbol anyway, then you can avoid some trouble by just recognizing that you don't need Unicode symbols (let alone with different parsing rules.) Donn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] How to terminate the process group of aprocesscreated with createProcess?
Quoth Brandon Allbery allber...@gmail.com, On Thu, Jan 12, 2012 at 06:56, André Scholz andre.sch...@uni-bremen.dewrote: gid - createProcessGroup pid but i get the error message: createProcessGroup: permission denied the documentation for terminateProcess is incorrect and should not mention process groups Right - and terminateProcess should _not_ be fixed to work like the documentation says! I think it's just a point of confusion over how the shell works - in fact, process groups are normally created by the shell, but only when it's serving as the top level interactive shell. In any case, I would not mix System.Process and System.Posix.Process. I'd probably use the latter, but that's because it's closer to what I'm used to as a Unix/SVID/POSIX programmer. Same here, and in any case I don't expect there's any way to do this with System.Process, i.e., portably on non-UNIX platforms. In the System.Posix.Process variant, you get to use fork directly: spawn :: String - [String] - IO ProcessID spawn exe cmd = forkProcess $ executeFile exe False cmd Nothing To set the process group, spawnpg exe cmd = forkProcess $ do getProcessID = joinProcessGroup -- equivalent to setpgrp() executeFile exe False cmd Nothing ... to terminate the process group, signalProcessGroup sigTERM pid ... and wait for the spawned process getProcessStatus True False pid When you're running Haskell in the child fork like this, you could run afoul of runtime thread support, and depending on your situation it might make sense to move the fork/setpgrp/exec out into a C function to avoid that. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] named pipe interface
Quoth Serge D. Mechveliani mech...@botik.ru, (I wonder: is this for beginn...@haskell.org ?) No, not really! As already mentioned, the use of UnsafePerformIO goes a little beyond what I think is its intended purpose, and I think you might have better luck here with a test program that illustrates the problem and doesn't depend on that. But while you're looking into that ... you might be interested to know that there's a problem with named pipes in GHC (beyond the problems that afflict anyone who tries to work with named pipes.) GHC I/O routinely sets file descriptors to non-blocking, unlike the IO libraries for C and other languages, and this could add to your troubles with named pipes. You can read up on that and possibly find clues to the present problem. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to terminate the process group of a processcreated with createProcess?
Quoth Brandon Allbery allber...@gmail.com, ... terminateProcess passes on the semantics of kill(2); on SVID-compliant (and I think POSIX.1-compliant) systems, the negative of the process group leader's process ID is used to signal the process group. Note that you may need to arrange for your initial child process to invoke setpgrp() to insure that the parent program is not part of the process group. ... and that stuff can be found in System.Posix.Process. Support for POSIX killpg can be found in System.Posix.Signals, by the way in case you think that would make your intention more transparent. However I'm unclear as to the situation you are encountering, as your example does not appear to be spawning an intermediate process. I missed that at first myself -- he actually invokes time sleep 60. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
Quoth Steve Horne sh006d3...@blueyonder.co.uk, On 30/12/2011 10:41, Bardur Arantsson wrote: This doesn't sound right to me. To me, a side effect is something which happens as a (intended or unintended) consequence of something else. An effect which you want to happen (e.g. by calling a procedure, or letting the GHC runtime interpreting an IO Int) is just an effect. Trouble is, whether it sounds right doesn't really matter - that's just an artifact of the meaning you're most familiar with. Any specialist field has it's own jargon, including old words given new related-but-different meanings. It may help to recall that the point of Haskell is to write computer programs, and by extension the point of discussing its properties and semantics. Mostly we intend to refine our understanding of those properties and semantics; sometimes we may hope to actually improve them by questioning things that haven't been, but perhaps could be, rigorously defined. (That's how I read some of Conal Elliott's recent posts, for example - but of course, it's still a legitimate question: does it matter, if we only want to write programs?) That's why we use terms in a sense that apply meaningfully to computer programming languages in general and Haskell in particular. To do otherwise - for example to insist on a definition of pure that could not even in principle apply to any useful programming language, or a definition of side effect that would have to apply every time a program does anything - seems to me like an inane waste of time, to put it mildly. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
Quoth Steve Horne sh006d3...@blueyonder.co.uk, On 29/12/2011 08:48, Heinrich Apfelmus wrote: ... Well, it's a matter of terminology: impure /= has side effects. The ability of a language to describe side effects is not tied to its (im)purity. Again, purity refers to the semantics of functions (at run-time): given the same argument, will a function always return the same result? The answer to this question solely decides whether the language is pure or impure. Note that this depends on the meaning of function within that language. In C, side-effects are part of the semantics of functions, so it's an impure language. In Haskell, on the other hand, functions will always return the same result, so the language is pure. You could say that side effects have been moved from functions to some other type (namely IO) in Haskell. ... Anyway, if you're using IO actions, your code is not referentially transparent and is therefore impure - by your own definition of impure. Causing side-effects may not be pedantically the issue, but the mix of causing and reacting to them - ie interacting with the outside - clearly means that some of your function results are dependent on what's happening outside your program. That includes side-effects outside your program yet caused by program program. No, code can be referential transparent and pure and at the same time use IO actions. In order to understand that, you need to untangle the notion you describe above as function result from Haskell function value. We can talk endlessly about what your external/execution results might be for some IO action, but at the formulaic level of a Haskell program it's a simple function value, e.g., IO Int. Again, this is nothing new - it's clear from SPJs Tackling the Awkward Squad that this is what the IO monad is meant for, and if it's evil then at least it's controlled evil. IO is not evil. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
Quoth Gregg Reynolds d...@mobileink.com, On Wed, Dec 28, 2011 at 2:44 PM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: The beauty of the IO monad is that it doesn't change anything about purity. Applying the function bar :: Int - IO Int to the value 2 will always give the same result: bar 2 = bar (1+1) = bar (5-3) Strictly speaking, that doesn't sound right. Look again at the sentence you trimmed off the end: Of course, the point is that this result is an *IO action* of type IO Int, it's not the Int you would get when executing this action. I believe that more or less points to the key to this discussion. If it didn't make sense to you, or didn't seem relevant to the question of pure functions, then it would be worth while to think more about it. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Windows: openFile gives permission deniedwhenfilein use
Quoth Antoine Latter aslat...@gmail.com, ... Would this program then loop: append fromFilePath toFilePath = do str - readFile fromFile writeFile toFile str if 'from' and 'to' where the same file? Currently the locking prevents this. Do you mean, locking makes that work, or just makes it fail in a different way? Anyway, I think that's an example that would have the same issues without hGetContents - that is, any way you set out to overwrite a file by modifying its contents, you have the same problem. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
Quoth Steve Horne sh006d3...@blueyonder.co.uk, On 29/12/2011 18:41, Chris Smith wrote: ... On Thu, 2011-12-29 at 10:04 -0800, Donn Cave wrote: We can talk endlessly about what your external/execution results might be for some IO action, but at the formulaic level of a Haskell program it's a simple function value, e.g., IO Int. Not to nitpick, but I'm unsure what you might mean by function value there. An (IO Int) is not a function value: there is no function involved at all. I think the word function is causing some confusion, so I'll avoid calling things functions when they aren't. Except that it *is* a function value. He's right, I should have omitted function, I just meant value. I think the rest of what came out when he entered tutorial mode should be very helpful, if there's anything left that remains to be clarified about how Haskell manages to be a pure functional language. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Windows: openFile gives permission denied whenfilein use
Quoth Antoine Latter aslat...@gmail.com, ... http://www.haskell.org/pipermail/libraries/2011-October/016978.html ... wherein Ian Lynagh proposed to remove this feature and let the programmer enforce locking or not, as in other programming languages' base I/O libraries. This met with enthusiastic universal support, so whatever the Report may say, it looks to me like the GHC libraries will eventually not do this. Wouldn't this lead to 'getContents' and friends being much less safe than they already are? Or would we have to do something at the GHC runtime level of things to add locking? Interesting question. I tend to steer clear of that function, rather than try to keep track of all the things that can go wrong with it! but I would guess, the effect is the same on any I/O strategy that executes the same way: e.g. if you were to read pieces of the file iteratively you would be similarly exposed to the possibility of concurrent modifications. That risk may be less obvious with getContents if you take the naive view that it returns the contents of the file in the same way that normal I/O operations return data, but then you will eventually be punished for that naivety anyway! Are you aware of some possible special issue with getContents? Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Windows: openFile gives permission denied whenfile in use
Quoth Andrew Coppin andrewcop...@btinternet.com, On 29/12/2011 04:29 AM, Antoine Latter wrote: ... This bug and its discussion is similar, but not identical: http://hackage.haskell.org/trac/ghc/ticket/4363 This one has been rumbling on for ages. As others have said, the Report demands that locking occur, which is probably a mistake. The rationale that followed may have been a little sketchy, but apparently everyone agrees with with the point. I see the ticket led to a discussion on the libraries list - http://www.haskell.org/pipermail/libraries/2011-October/016978.html ... wherein Ian Lynagh proposed to remove this feature and let the programmer enforce locking or not, as in other programming languages' base I/O libraries. This met with enthusiastic universal support, so whatever the Report may say, it looks to me like the GHC libraries will eventually not do this. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
Quoth Gregg Reynolds d...@mobileink.com, .. A minor point maybe, but germane to the original post (I hope). It isn't - I mean, I'm not really sure what your point is, but the example really returns the same IO value, not just one of the same type. Consider an example with implementation: wint :: Int - IO Int wint a = let s = show a in do putStr s return (length s) Now the expression wint 994 is a value of type IO Int, and any instance of that expression is the same value - an action is not the same as the action's result. You can use this value in pure Haskell expressions with confidence. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Records in Haskell
Quoth Greg Weber g...@gregweber.info, ... Many of the built-in record proposals seem more ambitious (create a new record from an existing one, generalize in some other direction). More power or generalization could be very useful, but it can wait for later - Haskell's records are glaringly bad because they lack name-spacing. I think one of the problems being faced with improving records is a false choice between a quick but hacky library desugaring or a major Extensible records built into the compiler. What I am proposing is that (unless someone proposes a great desugaring solution) we make it the immediate goal to have records built into the compiler, but done in the simplest (perhaps least Extensible) way that just accomplishes name-spacing. It's sure easy to imagine something like that happening, in principle, but ... are you saying that extensibility specifically has been a major issue? Could be, I haven't been paying so much attention. Wouldn't extensibility more or less come along with row polymorphism? I mean, my understanding of the term is that an expression that instantiates a particular record field, can incorporate a record lacking that field, which seems to me to be implicit in row polymorphism anyway. I would think row polymorphism is a must-have. If you're interested in looking at old, Haskell-related record systems, also see O'Haskell. Donn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
Quoth Greg Weber g...@gregweber.info, On Wed, Dec 28, 2011 at 2:12 PM, Donn Cave d...@avvanta.com wrote: ... I would think row polymorphism is a must-have. Perhaps if you want *extensible* records. If you would like to make some progress with records in the near future rather than keeping records in limbo, I think we really need to give up for the moment on any higher form of abstraction than straight-forward name-spacing. No, to be clear on that, I haven't given much thought to extensibility per se, I was thinking row polymorphism is a valuable feature on its own, and extensibility just seemed to me to be an implicit side benefit. In principle, a less is more approach to language features appeals to me a lot, but not to the point where we just preemptively give up on any higher form of abstraction. Given the potential for backwards incompatibility, you'd want to have something pretty good to show for it. Donn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] If you'd design a Haskell-like language, what would you do different?
Quoth Hans Aberg, ... For example, I set one entry so that typing x |- a becomes x ⦠a, the TeX \mapsto, in Unicode ⦠RIGHTWARDS ARROW FROM BAR U+21A6. It might be tedious to make a lot of entries, though, but something to start with. Something to finish me with, too. I wouldn't be able to do much in a programming world that used glyphs like that. My vision isn't perfect, but I think it's within a fairly normal range, and it isn't good enough to decode a lot of hieroglyphics at normal font size at reading speed. The ASCII limit of 100 or so normal characters may be a barrier to expression, but it's a boost to comprehension. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to get Cabal to spit out a .a library suitable for linking into C/Objective-C
Sorry about the belated response, but this shouldn't be a problem since it isn't going to be very helpful anyway! I've managed to follow the process described on this page: http://www.haskell.org/haskellwiki/Using_Haskell_in_an_Xcode_Cocoa_project to link Haskell code to a non-Haskell main program, via Xcode. You've probably already seen this, it's mostly about a few iterations of trial and error linking, to get the list of GHC library dependencies, which is what you need whether you're using Xcode or not. If you really need a single library with your code and all those dependencies, that may be technically feasible, though awfully tedious. The only clear problem I encountered while experimenting with it is that GHC run time options need ghc -rtsopts, so they're unavailable if your program isn't built by ghc. I believe I worked around that with a special rtsmain.o, could probably recover the details if that's of interest. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] terminateProcess leaves zombie processes around
Quoth Felipe Almeida Lessa felipe.le...@gmail.com, On Wed, Dec 7, 2011 at 1:19 PM, Brandon Allbery allber...@gmail.com wrote: They *do* terminate; a zombie is a dead process waiting for its parent to reap it with waitForProcess. There's also some POSIX stuff you can do to have them auto-reaped, but doing that correctly and portably is somewhat painful. But zombie processes do consume a row in the process table, right? If so, then it's bad to have them around. Correct. As noted above, clean up with waitForProcess to release this resource. If it's more convenient, that could be done up front, by forking twice and waiting for the intermediate process. One possibly convenient way to do that might be something like runCommand eprover . Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to get a file path to the program invoked?
Quoth wren ng thornton w...@freegeek.org, There was a discussion about this recently over on libraries@, IIRC. The short answer is that, at present, there is no function to give you $0. We'd like to add such a function, but it's not been done yet. Part of the problem is that, as Alexey says, the first element of argv is just whatever is passed to exec, which is not guaranteed to be a complete path, a canonical path, or any other specific thing we'd desire. It's not at all straightforward to determine the actual location of the executable, especially not in a platform-independent manner. argv[0] can't be trusted, scanning through $PATH isn't guaranteed to find it (and even if you find something of the right name, it's not guaranteed to be the correct executable), etc etc. This isn't your problem, though. I mean, if the proposed function is to return the path to the executable file, then indeed you have a big problem with argv[0]. argv[0] can be anything - or nothing (it can be a null string.) But if we've turned to the question of whether to return argv[0], that's much simpler: you don't need to consider why a programmer might want it. It's appalling to think that library developers would withhold access to standard POSIX 1003.1 features while they decide whether they approve of them. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: IO in the middle
I think you're talking about RPC, Remote Procedure Call. A search for that term turns up http://www.haskell.org/haskellwiki/HaXR For things like this, it would make sense to subscribe to haskell-cafe, and post questions there - it's a much more active list that's devoted to ideas about Haskell in general, as opposed to specific quirks of the GHC implementation. Donn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Can't establish subprocess communication
As mentioned by the first person to follow up, you need to set line buffering in the copier program. It's filling up its buffer while you write small lines to it - unlike the test run at the terminal prompt, where it's connected to a TTY device and therefore behaved differently. In a situation where you can confidently say your software will only ever be run in a POSIX environment, I like to use the Posix functions directly, because a buffered Handle on a pipe is nothing but extra trouble, and similarly the convenient wrapping of the POSIX API seems to cause more trouble than it's worth. Did your first attempt fail because the file name was not a complete path? Do that on purpose and see if runInteractiveProcess gives you a useful error message. Engineer some other kind of problem into your copier program, and see what happens to the error message ... oh, rats, it looks like runInteractiveProcess puts unit 2 on another pipe, when you might have worked better for you to leave it the way it was. (This kind of thing is what we call a user friendly API, which is why we say with friends like that, who needs enemies!) Here's how the start process function could be written - import System.Posix.IO import System.Posix.Process startproc = do ip - createPipe op - createPipe pid - forkProcess $ do forRead ip = onStdUnit 0 forWrite op = onStdUnit 1 executeFile ./copier False [] Nothing to - forWrite ip from - forWrite op return (to, from, pid) where forRead (i, o) = closeFd o return i forWrite (i, o) = closeFd i return o onStdUnit i fd = do dupTo fd i closeFd fd -- and then for I/O to the file descriptors (remember to supply -- explicit newlines, if the other process is line buffered, e.g. boo\n, -- But if the other process also uses Posix.readFd, it isn't buffered -- at all, so you don't need newlines. cat is in the latter category, -- but most command line applications are in the former, like, say, awk.) sendrecv to from s = do forkIO $ fdWrite to s return () (v, _) - fdRead from 1024 putStrLn (recvd: ++ show v) -- try it Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Getting started on Mac OSX
Quoth hstenstrom h.stenst...@gmail.com, I have a book on Haskell, and I've downloaded and installed Haskell Platform for Mac OS X. What do I do now? XCode is a requirement, and I have it, but I don't know how to run it. To begin with, I want to test small examples from the book, using ghc or ghci. I have read file:///Library/Haskell/doc/start.html. - Where is the software I've just installed? - How is ghci started? Or the platform, whatever that is? The location of the software is covered in /Library/Haskell/doc/start.html. The key point is that the executables - like ghci - are in your path via /usr/bin. What they mean by should be available in any shell, is that when you run Terminal, you can just type ghci at the prompt. Terminal may be hiding in Applications/Utilities. Apple clearly underestimates the value of this application for its users, but you won't - you're going to be using Terminal a lot, for GHC. You need XCode only because GHC needs its compiler and libraries, you won't use XCode directly yourself just to run examples from the book. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: behaviour change in getDirectoryContents in GHC 7.2?
Quoth John Millikin jmilli...@gmail.com, ... One is to give low-level access, using abstractions as close to the real API as possible. In this model, unix would provide functions like [[ rename :: ByteString - ByteString - IO () ]], and I would know that it's not going to do anything weird to the parameters. I like that a lot. In the PEP I see the phrase in the same way that the C interfaces can ignore the encoding - and the above low level access seems to belong to that same non-problematic category. Donn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] control-c only caught once -- bug?
Quoth Brian Johnson brianjohnsonhaskellc...@gmail.com, ... On further thought, there is something sensible here: the RTS might crash while trying to exit. I propose, for POSIX environments, the following change to SIGINT handling: * SIGINT is transformed into UserInterrupt during normal program execution * Once the RTS is committed to exiting, it resets the signal handler for SIGINT so that any additional control-c causes an immediate exit The picture I get from the commentary (below) is that we're talking about shutting down, one way or another - either gracefully, or if that isn't making satisfactory progress, abruptly on the second ^C. Because the user entered a keyboard interrupt, and the program hasn't installed a signal handler for it. If you have your own shutdown procedure that you want to have happen at that time, then it would make sense to me to catch this exception for that purpose. If you want to handle keyboard interrupts, throughout the lifetime of the program process, then you should handle the signals. If the SIGINT handler described below is too confusing, then I would solve that problem by simply removing it. Programs written in other languages simply abort on unhandled signals, and I'm a little skeptical that there's any reliable way to improve on that. We're just teaching people to press ctrlC twice if it's a Haskell program. Donn From http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Signals: When the interrupt signal is received, the default behaviour of the runtime is to attempt to shut down the Haskell program gracefully. It does this by calling interruptStgRts() in rts/Schedule.chttp://hackage.haskell.org/trac/ghc/browser/rts/Schedule.c (see Commentary/Rts/Scheduler#ShuttingDownhttp://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Scheduler#ShuttingDown). If a second interrupt signal is received, then we terminate the process immediately; this is just in case the normal shutdown procedure failed or hung for some reason, the user is always able to stop the process with two control-C keystrokes ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] control-c only caught once -- bug?
brianjohnsonhaskellc...@gmail.com wrote: The second time I press control-c, it isn't caught -- the program exits instead. Why? I don't know why. Same behavior on my platform (Haiku.) While I imagine someone intimately acquainted with RTS signal handling might be able to explain it, I think the real problem is that Control.Exception.Catch isn't a real signal handler. For example, your program doesn't catch SIGHUP, or SIGALRM, or probably anything but SIGINT. The SIGINT handler looks like more of a quirk of the RTS, than a feature whose behavior you should depend on in great detail. I can use System.Posix.Signals.installHandler to catch ctrlC (SIGINT) in a repeatable way, on MacOS X, so that's working as it should. If you want it to return control to the user interface, that's going to take some work - for all I know, there may be some way to hook a signal handler up with Control.Exception.catch. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] instance Enum Double considered notentirelygreat?
Quoth Chris Smith cdsm...@gmail.com, ... So that's what this is about: do we think of Float as an approximate real number type, or as an exact type with specific values. If the latter, then of course you exclude the value that's larger than the upper range. If the former, then using comparison operators like '' implies a proof obligation that the result of the computation remains stable (loosely speaking, the function continuous) at that boundary despite small rounding error in either direction. In that case, creating a language feature where, in the *normal* case of listing the last value you expect in the list, 0.3 (as an approximate real number) is excluded from this list just because of technicalities about the representation is an un-useful implementation, to say the least, and makes it far more difficult to satisfy that proof obligation. It doesn't appear to me to be a technicality about the representation - the value we're talking about excluding is not just represented as greater than 0.3, it is greater than 0.3 when applied in computations. For example you can subtract 0.3 and get a nonzero value (5.55e-17.) Isn't the problem here with ranges really that they're computed in a way that doesn't work for FP? I mean, when I specify [0.1,0.2..0.5], I really do mean to include 0.5 among those values, as you surmise - so I imply a computation that actually produces that value, i.e., 0.5::Double. The disappointment with iterative addition is not that its fifth value [should be] omitted because it's technically greater, it's that range generation via iterative addition does not yield the values I specified. In other words, a range is a shorthand expression, where the correct value is the one that would have resulted from evaluating the corresponding list of constant expressions. If we don't know how to generate that list correctly for Double, then I suppose range shouldn't be supported, but I thinking I'm seeing hints that we may indeed know how to do this? (I sure don't! though of course for a specific case it can be easy, e.g., (map (/ 10.0) [1..5]).) Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] instance Enum Double considerednotentirelygreat?
Quoth Chris Smith cdsm...@gmail.com, ... I certainly don't agree that wanting the exact value from a floating point type is a reasonable expectation. The *only* way to recover those results is to do the math with the decimal or rational values instead of floating point numbers. You'll get the rounding error from floating point regardless of how you do the computation, because the interval just isn't really 0.1. The difference between those numbers is larger than 0.1, and when you step by that interval, you won't hit 0.5. You may have misunderstand - you're right, it isn't reasonable to expect `exact values' out of 0.1, 0.2, 0.3, etc., in the sense of the values classically denoted by those terms on paper. But I believe they do have specific values of type Double, and it isn't unreasonable to expect the range to produce those values and not some approximation that may have been convenient to compute. I think it's more than reasonable to expect [0.1,0.2..0.5] == [0.1,0.2,0.3,0.4,0.5] and that would make everyone happy, wouldn't it? If it's expensive to compute, hopefully people won't write code that makes intensive use of Double range generation. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] instance Enum Double considered not entirelygreat?
Quoth Richard O'Keefe o...@cs.otago.ac.nz, [ ... re Why would you write an upper bound of 0.3 on a list if you don't expect that to be included in the result? ] Because upper bounds are *UPPER BOUNDS* and are NOT as a rule included in the result. If you write [0,2..9] you - DO expect 0 in the result - DON'T expect 9 in the result - would be outraged if 10 were in the result. Pardon the questions from the gallery, but ... I can sure see that 0.3 shouldn't be included in the result by overshooting the limit (i.e., 0.30004), and the above expectations about [0,2..9] are obvious enough, but now I have to ask about [0,2..8] - would you not expect 8 in the result? Or is it not an upper bound? Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] instance Enum Double considered not entirelygreat?
Quoth Chris Smith cdsm...@gmail.com, ... As for Enum, if someone were to want a type class to represent an enumeration of all the values of a type, then such a thing is reasonable to want. Maybe you can even reasonably wish it were called Enum. But it would be the *wrong* thing to use as a desugaring for list range notation. List ranges are very unlikely to be useful or even meaningful for most such enumerations (what is [ Red, Green .. LightPurple]?); and conversely, as we've seen in this thread, list ranges *are* useful in situations where they are not a suitable way of enumerating all values of a type. It isn't a life or death requirement, but I have dealt with enum values that are ordered and that could usefully be represented in a range. Even your example -- given a set of hues, it's sensible to order them following the spectrum, so [Cyan .. YellowGreen] might represent the hues in the set that are at all in the green range. I'm frankly using Enum as an equivalent to C enum, symbolic integers, where the range is more or less implicit as by default the integer values are [0..]. While I (vaguely) understand that Haskell's Enum is different, the C idiom should at least testify that there's some practical value in the notion of a range of Enum, or something like it. Though not with floating point values, of course. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] efficient chop
Quoth Ivan Lazar Miljenovic ivan.miljeno...@gmail.com, Why the extra case for go? The otherwise guard can be part of the second case... I noticed that myself, so I thought let's see if it's just a matter of style that comes out the same after compilation ... ... and after a few minutes fooling around with that, I'm none the wiser. I could not, within the time allotted, make out what's going on in the -fvia-C .hc files. I guess the way to answer questions like this is to apply the function in question to massive amounts of data and infer the answer from resulting performance? Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Trouble with readProcess
Quoth Charles-Pierre Astolfi c...@crans.org, readProcess cmd [opt1,opt2] seems to execute the following: $ cmd opt1 opt2 That is usually fine, but I'm using an external program that doesn't understand the quotes, so I need to execute instead: $ cmd opt1 opt2 How should I do that? I think your analysis is wrong. I don't know what to suggest, though if you follow up you probably should mention what platform you're running on. Maybe you could devise a simple test program that illustrates the problem? Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Trouble with readProcess
Quoth Charles-Pierre Astolfi c...@crans.org, I've found my mistake: I was calling readProcess cmd [-p -t] instead of readProcess cmd [-p,-t] That would do it. Not sure what are the semantics of quotation in this case, though. And I'm pretty sure my analysis is wrong because of that :) The principle isn't complicated. In UNIX, anyway, quotes are for the shell - $ cmd a b is a string interpreted by the shell as a UNIX command (path, [args]). If an argument contains white space or something it needs to be quoted, and the shell supports all kinds of ways to do that. Of course it uses the quotes, the executed command doesn't see them. But when a Haskell process function's command takes a list of args, we infer that there isn't any shell interpretation, so no quotes. If you want a shell command, for example because you want a pipeline or something, then you may invoke the shell yourself, like readProcess /bin/sh [-c, cmd -p -t] Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] State of play with Haskell-Cocoa (Objective-C)bindings?
Quoth Luke Evans l...@eversosoft.com, I'm planning to start an Objective-C/Cocoa project and would like to write it in Haskell as much as possible. Of course, I can contrive to split the project into app logic (Haskell) and UI (Objective-C) with some sort of minimal interface between them; possibly just plain old C FFI. However, I would like an interface that's as 'automatic' as possible - one that preferably means that I don't have to spend a lot of time maintaining a somewhat heavy-weight special interface layer as I grow my code on both sides of the divide. Preferably the suture line is as far over on the Objective-C side as possible, so that I can write pretty much everything in Haskell. Now, I see a couple of references to some options: - HOC seems very close to what I'm looking for, but the project looks pretty 'dormant'. - I see some mention of an Objective-C FFI, but am uncertain if this is in any current build of GHC. Are there any other options up anyone's sleeves? Anybody working on something interesting I could play with? You've probably seen this already and it didn't qualify as something interesting, but http://www.haskell.org/haskellwiki/Using_Haskell_in_an_Xcode_Cocoa_project still works as of MacOS 10.6 and GHC 7.0.3. No extra libraries or tools needed - you just wrangle your Haskell .o files and all the attendant Haskell libraries into the Xcode project, give Interface Builder Objective C stubs to work with, and call out to Haskell with C FFI. I have done only one program this way, with a very simple interface, not enough to have any real idea how painful it's going to be. (Actually it didn't work with -threaded, and because GHC doesn't do the linking I couldn't figure out how to exercise the new option to allow +RTS options, but it seems to be fine without -threaded.) Until recently, I was concerned about being able to use GC on the Objective-C side, but with Apple's new ARC memory management model, that's no longer an issue. Most Haskell-ObjC bindings that already exist are surely designed for Retain-Release, which I assume is not disrupted by ARC as this is just RR at runtime. I don't know - I'm using standard (C) FFI out of the box, and both languages must support foreign C libraries that manage their own memory, so I perhaps erroneously have not been worrying about it. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] XCode Dependency for HP on Mac - old XCodeversions
Quoth Clive Brettingham-Moore hask...@brettingham-moore.net, To get XCode on my 10.6 machine, I... I had quite a hunt recently to find the most recent XCode for my not-so-recent mac... so I'll share what I found: Were you able to look on your install CD? Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe