Re: [Haskell-cafe] Re: layout problem
On Thursday 17 November 2005 03:44, Cale Gibbard wrote: On 16/11/05, Stefan Monnier [EMAIL PROTECTED] wrote: Indeed! I always use braces and semicolons with do-notation. You are free to do so too! Nothing requires you to use layout. Indeed, you can freely mix the two. I would not recommend braces and semicolons, because these allow a bad layout (easy to parse for a compiler, but hard to read for a human), unless you invest the time to make a tidy layout despite the braces and semicolons. (So why not only make a tidy layout?) Unless you use a simplistic text editor, the braces and semi-colons allow the text editor to do the layout for you. While I find the layout notation attractively clean, I find the redundancy of autolayout+braces+semicolons to save me from a lot of trouble. If your editor is a little smarter still, it can do the Haskell layout without braces automatically too. The emacs mode helps with this. Yi/hIDE should be able to do it perfectly once it's in a generally usable state. :) Hmm, how would your super intelligent text editor layout the ambigous example of the OP? Well, never mind: either way might be the wrong one, depending on what the program is /supposed/ to do. Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Reducing # of context switches
On 17 November 2005 00:17, Joel Reymont wrote: The latest GHC docs mention that the -C option takes a seconds value whereas prior docs mention microseconds. Which is it? Also, do I pass +RTS -Cxxx or is it just -C? It is in seconds, eg. +RTS -C0.5 for switches every half a second. I've just fixed and cleaned up the docs a bit. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] layout problem
On 16 November 2005 17:15, Christian Maeder wrote: Simon Peyton-Jones wrote: Indeed! I always use braces and semicolons with do-notation. You are free to do so too! Nothing requires you to use layout. Indeed, you can freely mix the two. I would not recommend braces and semicolons, because these allow a bad layout (easy to parse for a compiler, but hard to read for a human), unless you invest the time to make a tidy layout despite the braces and semicolons. (So why not only make a tidy layout?) Surely, a different layout may change your semantics (in rare cases). A missplaced _ - error ... case usually causes a pattern warning. liftIOTrap io = do mx - liftIO (do x - io return (return x) `catchError` (\e - return (throwError (fromIOError e I'ld rather avoid the infix `catchError' and write: liftIO $ catchError (do ... ) $ \e - I generally prefer to use the handle variants rather than catch: liftIO $ handle my_handler $ do x - io return (return x) where my_handler e = return (throwError (fromIOError e)) Don't be afraid to name things if it makes your code easier to read. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: layout problem
Benjamin Franksen wrote: If your editor is a little smarter still, it can do the Haskell layout without braces automatically too. The emacs mode helps with this. Yi/hIDE should be able to do it perfectly once it's in a generally usable state. :) Hmm, how would your super intelligent text editor layout the ambigous example of the OP? Well, never mind: either way might be the wrong one, depending on what the program is /supposed/ to do. It would alternate between them as you push TAB, of course. -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: layout problem
On Wed, 16 Nov 2005, Cale Gibbard wrote: If your editor is a little smarter still, it can do the Haskell layout without braces automatically too. The emacs mode helps with this. Yi/hIDE should be able to do it perfectly once it's in a generally usable state. :) The one I'm looking forward to is an editor that'll de-layout code and show me the resulting braces and semicolons (albeit highlighted differently to ones I put there myself). -- [EMAIL PROTECTED] Society does not owe people jobs. Society owes it to itself to find people jobs. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Project postmortem
Folks, I have done a lot of experiments over the past few weeks and came to a few interesting conclusions. First some background, then issues, solutions and conclusions. I wrote a test harness for a poker server that understands the different binary packets and can send and receive them. The harness launches each script in a separate unbound thread that connects to the server via TCP and does its work. The main goals of the project were: easy scripting, very high number of connections from the harness (a few thousand) and running on Windows. I develop on Mac OSX but have a Windows machine for testing and to run the poker server. Another key goal was to support the server encryption. SSL encryption is done in a wierd way that requires attaching read/write OpenSSL BIOs to the SSL descriptor so that SSL encrypts to/from memory. Encrypted chunks are then taken from the BIOs and sent as payload in servver packets. Overall, I probably spent about 4 weeks writing the server and about 2 more weeks grappling with the various issues. The issues centered around 1) the program trashing memory like no tomorrow, 2) intermittent crashes on Windows and 3) not being able to launch a high number of connections on Windows before crashing. I significantly improved trashing of memory by switching to plain Haskell structures from nested lists of wxHaskell-style properties (attr := value). Intermittent crashes were harder to troubleshoot, specially given that things were running smoothly on Mac OSX. Stack traces pointed into libcrypto (part of OpenSSL) and thus to the BIOs that I was allocating. I guesses that OpenSSL was maxing out some resources and closed the leak by explicitly freeing the SSL descriptor which freed the associated BIO structures. Then things got wierder as my program started crashing in a different place entirely with stack traces like this: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x3139322e 0x0027c174 in s8j1_info () (gdb) where #0 0x0027c174 in s8j1_info () #1 0x0021c9f4 in StgRunIsImplementedInAssembler () at StgCRun.c:576 #2 0x0021cdc4 in schedule (mainThread=0x1100360, initialCapability=0x308548) at Schedule.c:932 #3 0x0021dd6c in waitThread_ (m=0x1100360, initialCapability=0x0) at Schedule.c:2156 #4 0x0021dc50 in scheduleWaitThread (tso=0x13c, ret=0x0, initialCapability=0x0) at Schedule.c:2050 #5 0x00219548 in rts_evalLazyIO (p=0x29b47c, ret=0x0) at RtsAPI.c:459 #6 0x001e4768 in main (argc=2262116, argv=0x308548) at Main.c:104 I took waitThread_ as a clue and started digging deeper. Whenever I connect to the server or send a command I wait for X seconds and if not connected or desired command is not received I throw an exception which fails the script. I implemented the timeout combinator a couple of different ways, including that in the Asynchronous Exceptions paper but it did not help. I think the issue has to do with killing threads that are using FFI. Although I'm killing threads that call the Haskell connectTo, hGetBuf, etc. I think it's still FFI. I disposed of timeouts entirely, leaving connectTo as it is and using hWaitForInput on my socket handle to simulate timeouts. This improved things tremendously and I'm now able to run a few thousands of unbound script threads on Windows with OpenSSL FFI and everything. Memory usage is still higher than I would have liked and crashes in OpenSSL still happen when the number of threads/memory usage is really high so there's still room for improvement. I should probably go back to using a foreign finalizer (SSL_free) on the SSL descriptors rather than freeing them explicitly as the freeing does not happen if a script fails mid-way. I'm quite satisfied with my first Haskell project. I love Haskell and will continue hacking away with it. This list is invaluable in the depth of offered help whereas #haskell (IRC) is invaluable when speed matters. I'm quite amazed at the things I have been able to do, the expressiveness of Haskell and the clean looks. Clean looks can be deceptive, though, as they can hide code of amazing complexity. Fundeps, existential types, HList take a while to grasp. Also, I feel somewhat like a pioneer and I definitely got more than a fair share of arrows in my back. I had GHC run out of memory during compilation (fixed by SPJ), had it quit midway during compilation with an error about generated extents being too large in assembler code. I had GHC crash at runtime with an error like fromJust not returning Just, this could not be happening!. Yesterday's error topped them all: internal error: update_fwd: unknown/strange object 0 Please report this as a bug to glasgow-haskell-bugs@haskell.org, or http://www.sourceforge.net/projects/ghc/ I think I got this when using +RTS -C0 -c. Overall, the experience with Haskell has
Re: [Haskell-cafe] Spurious program crashes
On Nov 17, 2005, at 1:44 PM, Sebastian Sylvan wrote: Are you sure it's safe to kill a thread which has already been killed? It seems so from the docs. Why do you fork off the killing of the threads? Why not just run them in sequence? Someone said that they read somewhere that killThread can block. I'm not gonna point any fingers at musasabi ;-). Also, I'd recommend refactoring the code a bit, write a function parIO which runs IO computations in parallell and then define timeout in terms of that. I did this by stealing the timeout/either combinators from the Asynchronous Exceptions paper. It did not help a single bit. Joel -- http://wagerlabs.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Spurious program crashes
On 11/17/05, Joel Reymont [EMAIL PROTECTED] wrote: On Nov 17, 2005, at 1:44 PM, Sebastian Sylvan wrote: Are you sure it's safe to kill a thread which has already been killed? It seems so from the docs. Why do you fork off the killing of the threads? Why not just run them in sequence? Someone said that they read somewhere that killThread can block. I'm not gonna point any fingers at musasabi ;-). Also, I'd recommend refactoring the code a bit, write a function parIO which runs IO computations in parallell and then define timeout in terms of that. I did this by stealing the timeout/either combinators from the Asynchronous Exceptions paper. It did not help a single bit. This is somewhat frustrating for me because I had a very similar (if not the exact same) issue when writing some test applications for an FMOD binding. However, all that source code (and so much more) was lost due to a hard disk failure. I am now struggling to remember what was the cause, and how I solved. What I do remember is that the timeout and parIO functions in the concurrent programming papers I found were NOT correct. killThread did NOT behave as expected when I killed an already killed thread. I tried multiple tricks here (including some which required recursive do-notation) to try to get the parIO function to only kill the *other* thread. This could be done by having the two spawned threads take their computations in an MVar along with the threadID of the other thread. something like: parIO f1 f2 = do m - newEmptyMVar -- result Mvar mf1 - newEmptyMVar -- MVar for f1 mf2 - newEmptyMVar -- MVar for f2 -- fork worker threads t1 - forkIO (child m mf1) t2 - forkIO (child m mf2) -- pass computations and threadID to worker threads putMVar mf1 (t2, f1) putMVar mf2 (t1, f2) -- return result takeMVar m where child m mf = do (tid, f) - takeMVar mf x - f putMVar m x killThread tid timeout t f = threadDelay (round (t * 1e6)) `parIO` f As I remember another solution I came up with was to wrap the child function body in a catch statement. The child function was just a helper function that ran a computation and put its result in an MVar. I *think* the problem *may* have been that when an FFI function got ThreadKilled exception asynchrounously that got bubbled up to the parIO thread for some reason. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Spurious program crashes
Maybe one of the Simons can comment on this. I distinctly remember trying the mdo approach to kill the other thread and getting burned by that. Don't know why I forgot to mention it. On Nov 17, 2005, at 2:03 PM, Sebastian Sylvan wrote: What I do remember is that the timeout and parIO functions in the concurrent programming papers I found were NOT correct. killThread did NOT behave as expected when I killed an already killed thread. I tried multiple tricks here (including some which required recursive do-notation) to try to get the parIO function to only kill the *other* thread. This could be done by having the two spawned threads take their computations in an MVar along with the threadID of the other thread. -- http://wagerlabs.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Spurious program crashes
On 16 November 2005 17:38, Joel Reymont wrote: I'm getting crashes like this and I cannot figure out what the problem is. I'm launching a bunch of threads that connect to a server via TCP and exchange packets. I am running operations like connect and receive in a timeout function that launches two threads and uses an MVar to figure out who's done first. The timeout function then kills the two threads. Any ideas what could be causing this? I feel like a Haskell guinea pig these days :-). I don't see any reason why you should be getting crashes here, but this is a delicate area (async exceptions + FFI). It's possible there's a bug, but as usual we need to reproduce the symptoms here. Can you help with a repro case? Regarding the behaviour of killThread, I believe the version in GHC is slightly different from the version described in the Asynchronous Exceptions paper, in particular the GHC version blocks until the exception has been delivered to the target thread (use another forkIO to get the fully async version). Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Spurious program crashes
I will work on the repro case over the weekend. Getting this to work correctly is crucial to the future of Haskell, I think. Without this working correctly there's a slim chance of Haskell being used successfully used for high-performance networking apps. On Nov 17, 2005, at 3:00 PM, Simon Marlow wrote: I don't see any reason why you should be getting crashes here, but this is a delicate area (async exceptions + FFI). It's possible there's a bug, but as usual we need to reproduce the symptoms here. Can you help with a repro case? -- http://wagerlabs.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ReaderT and concurrency
In http://www.eecs.harvard.edu/~ccshan/prepose/prepose.pdf Oleg and I survey the approaches that others have mentioned and propose a new technique that is particularly relevant in concurrent programs. Ken -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig If debugging is the process of removing bugs, then programming must be the process of putting them in. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Spurious program crashes
Actually, this has just become crucial for me. In my using of hWaitForInput I missed that it blocks all other threads if no input is available :-(. Arghh! I still need timeouts. On Nov 17, 2005, at 3:00 PM, Simon Marlow wrote: Regarding the behaviour of killThread, I believe the version in GHC is slightly different from the version described in the Asynchronous Exceptions paper, in particular the GHC version blocks until the exception has been delivered to the target thread (use another forkIO to get the fully async version). -- http://wagerlabs.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Darcs and the Google Base
This may be just funny, but... As the Google Base went live yesterday (11/16/2005), I tried to add the information about my HSFFIG project to the Base. As the Base allows to define arbitrary attributes (labels) for each item, I added the two of Web URL type: CABAL and DARCS holding urls for the project Cabal file and the Darcs repo respectively. I was turned down on excessive capitalization of these labels. I made them into Cabal and Darcs. The former was accepted. the latter was turned down again as misspelled. I wrote an exemption request explaining that Darcs is not a misspelling. However, it's been more than a whole day since my attempt, it hasn't been resolved. Interestingly, my item was published after I removed the Darcs label, but shortly after I resubmitted the exemption request for Darcs the item disappeared. -- Dimitry Golubovsky Anywhere on the Web ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
I second this motion! I rather like Simon's proposal. On Nov 17, 2005, at 5:00 PM, Fraser Wilson wrote: Yeah, I thought you might have tried that at some point :-) I like http://research.microsoft.com/~simonpj/Haskell/records.html cheers, Fraser. On 11/17/05, Joel Reymont [EMAIL PROTECTED] wrote: Don't get me started, please :-). I tried making each field a separate class but then needed to compose records of difference field instances which led to HList which led to GHC eating up all my memory and crashing, etc. I can see where you are going but if I have 250 records with shared fields then that's a whole lot of extra boiler plate code to marshall between the functions with prefixes to the class method implementations. The road to hell is paved with good intentions ;-). Thanks for the tip, though. On Nov 17, 2005, at 2:12 PM, Fraser Wilson wrote: To solve this problem I just made them all instances of a class with a gameId function. Still, not ideal. -- http://wagerlabs.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
Isn't there a potential for confusion with function composition (f . g)? That being said, I like this idea (I just need to think it through a bit).Joel Reymont [EMAIL PROTECTED] wrote: I second this motion! I rather like Simon's proposal.On Nov 17, 2005, at 5:00 PM, Fraser Wilson wrote: Yeah, I thought you might have tried that at some point :-) I like http://research.microsoft.com/~simonpj/Haskell/records.html cheers, Fraser. ===Gregory Woodhouse [EMAIL PROTECTED] "Interaction is the mind-body problem of computing." --Philip Wadler ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On 11/17/05, Greg Woodhouse [EMAIL PROTECTED] wrote: Isn't there a potential for confusion with function composition (f . g)? That being said, I like this idea (I just need to think it through a bit). I've been wanting this for ages. It's SO much better than the current horribly broken records we have. There could be confusion with function composition, but there's no ambiguity (compositon have spaces around the dot, while record accessors do not). Personally I think that the dot is way to good of a symbol to be wasted on function composition. I mean, how often do you really use function composition in a way which doesn't obfuscate your code? I use ($) way more often than (.). Some people do use it more often than I do, but I find that in most cases except simple pipelined functions it only makes the code harder to read. I'd rather function composition was left out of the prelude alltogether (or defined as (#) or something). Anyway. The current records system is a wart. Joel Reymont [EMAIL PROTECTED] wrote: I second this motion! I rather like Simon's proposal. On Nov 17, 2005, at 5:00 PM, Fraser Wilson wrote: Yeah, I thought you might have tried that at some point :-) I like http://research.microsoft.com/~simonpj/Haskell/records.html cheers, Fraser. === Gregory Woodhouse [EMAIL PROTECTED] Interaction is the mind-body problem of computing. --Philip Wadler ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
Sebastian Sylvan wrote: Personally I think that the dot is way to good of a symbol to be wasted on function composition. I mean, how often do you really use function composition in a way which doesn't obfuscate your code? I use ($) way more often than (.). Some people do use it more often than I I found it useful to use (mainly for debugging purposes) mapM (putStrLn . show) some list if I want to print its elements each on a new line. -- Dimitry Golubovsky Anywhere on the Web ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
So it sounds to me that momentum is building behind Simon PJ's proposal and that we are finally getting somewhere! Now, when can we actually get this in GHC? On Nov 17, 2005, at 5:56 PM, Sebastian Sylvan wrote: I've been wanting this for ages. It's SO much better than the current horribly broken records we have. -- http://wagerlabs.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
Would the record system describe at http://lambda-the-ultimate.org/node/view/1119 also be convertable into System Fw, GHC's existing, strongly-typeed intermediate language. ? On Thu, November 17, 2005 17:56, Sebastian Sylvan said: On 11/17/05, Greg Woodhouse [EMAIL PROTECTED] wrote: Isn't there a potential for confusion with function composition (f . g)? That being said, I like this idea (I just need to think it through a bit). I've been wanting this for ages. It's SO much better than the current horribly broken records we have. There could be confusion with function composition, but there's no ambiguity (compositon have spaces around the dot, while record accessors do not). Personally I think that the dot is way to good of a symbol to be wasted on function composition. I mean, how often do you really use function composition in a way which doesn't obfuscate your code? I use ($) way more often than (.). Some people do use it more often than I do, but I find that in most cases except simple pipelined functions it only makes the code harder to read. I'd rather function composition was left out of the prelude alltogether (or defined as (#) or something). Anyway. The current records system is a wart. Joel Reymont [EMAIL PROTECTED] wrote: I second this motion! I rather like Simon's proposal. On Nov 17, 2005, at 5:00 PM, Fraser Wilson wrote: Yeah, I thought you might have tried that at some point :-) I like http://research.microsoft.com/~simonpj/Haskell/records.html cheers, Fraser. == Gregory Woodhouse [EMAIL PROTECTED] Interaction is the mind-body problem of computing. --Philip Wadler ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
Sebastian Sylvan wrote: Personally I think that the dot is way to good of a symbol to be wasted on function composition. I mean, how often do you really use function composition in a way which doesn't obfuscate your code? I use ($) way more often than (.). Some people do use it more often than I Function composition is a very important and fundamental operation on functions, and I use it all the time. Haskell is supposed to be a functional language. I'd vote against any motion to make it less convenient. Of course, it really shouldn't be (.) but a small circle centred on the line, which isn't on ordinary keyboards. (°) looks closer, but is much less convenient to type. (I need to type Compose 0 ^ in order to get that character.) Spelling it as (.) really is the best easy-to-type approximation. - Cale ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On 11/17/05, Greg Woodhouse [EMAIL PROTECTED] wrote:
Isn't there a potential for confusion with function composition (f . g)?
Perhaps, but I always have spaces on either side when it's function composition. Isn't there already an ambiguity?
-- I bet there's a quicker way to do this ...
module M where data M a = M a deriving (Show)
data T a = T a deriving (Show)
module M.T where f = (+1)
import M
import qualified M.T
f = (*2)
v1 = M . T . f $ 5
v2 = M.T.f $ 5
main = do { print v1; print v2; return () }
Fraser.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: layout problem
On Thursday 17 November 2005 11:42, Ketil Malde wrote: Benjamin Franksen wrote: If your editor is a little smarter still, it can do the Haskell layout without braces automatically too. The emacs mode helps with this. Yi/hIDE should be able to do it perfectly once it's in a generally usable state. :) Hmm, how would your super intelligent text editor layout the ambigous example of the OP? Well, never mind: either way might be the wrong one, depending on what the program is /supposed/ to do. It would alternate between them as you push TAB, of course. Nice solution. Not fool-proof either: you need to know beforehand when to try and ush TAB a second time; but probably ok. Ideal would be a pop-up menu presenting all possible choices; the difficult part being how to represent the choices so that one can easily find out which corresponds to what one wants, and still manage to keep them to less than a screenful of code ;-) Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On 2005-11-17 at 13:21EST Cale Gibbard wrote: Sebastian Sylvan wrote: Personally I think that the dot is way to good of a symbol to be wasted on function composition. I mean, how often do you really use function composition in a way which doesn't obfuscate your code? I use ($) way more often than (.). Some people do use it more often than I Function composition is a very important and fundamental operation on functions, and I use it all the time. Haskell is supposed to be a functional language. I'd vote against any motion to make it less convenient. Hear hear. Of course, it really shouldn't be (.) but a small circle centred on the line, which isn't on ordinary keyboards. (°) looks closer, but is much less convenient to type. (I need to type Compose 0 ^ in order to get that character.) Spelling it as (.) really is the best easy-to-type approximation. Ought to be ∘, unicode 0x2218, but without defining some keyboard macros, that's even harder to type. On the other hand, I could define ctrl-. as (ucs-insert 2218), and then it would be no harder to type than . -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On Thursday 17 November 2005 19:21, Cale Gibbard wrote: Sebastian Sylvan wrote: Personally I think that the dot is way to good of a symbol to be wasted on function composition. I mean, how often do you really use function composition in a way which doesn't obfuscate your code? I use ($) way more often than (.). Some people do use it more often than I Function composition is a very important and fundamental operation on functions, and I use it all the time. Haskell is supposed to be a functional language. I'd vote against any motion to make it less convenient. Of course, it really shouldn't be (.) but a small circle centred on the line, which isn't on ordinary keyboards. (°) looks closer, but is much less convenient to type. (I need to type Compose 0 ^ in order to get that character.) Spelling it as (.) really is the best easy-to-type approximation. Yes, yes, yes. I'd rather use a different operator for record selection. For instance the colon (:). Yes, I know it is the 'cons' operator for a certain concrete data type that implements stacks (so called 'lists'). However I am generally opposed to wasting good operator and function names as well as syntactic sugar of any kind on a /concrete/ data type, and especially not for stacks aka lists. For a hypothetical Haskell2 I'd propose to get rid of all special 'list' constructs and re-use the good symbols and names for /abstract/ interfaces to sequences and collections resp. (in case of the colon) for record selection. Just my 2 cent. Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On 17/11/05, Sebastian Sylvan [EMAIL PROTECTED] wrote: On 11/17/05, Greg Woodhouse [EMAIL PROTECTED] wrote: Isn't there a potential for confusion with function composition (f . g)? That being said, I like this idea (I just need to think it through a bit). I've been wanting this for ages. It's SO much better than the current horribly broken records we have. There could be confusion with function composition, but there's no ambiguity (compositon have spaces around the dot, while record accessors do not). Personally I think that the dot is way to good of a symbol to be wasted on function composition. I mean, how often do you really use function composition in a way which doesn't obfuscate your code? I use ($) way more often than (.). Some people do use it more often than I do, but I find that in most cases except simple pipelined functions it only makes the code harder to read. I'd rather function composition was left out of the prelude alltogether (or defined as (#) or something). Anyway. The current records system is a wart. Actually, I didn't mention this in the other post, but why not the other way around? Make record selection (#) or (!) (though the latter gets in the way of array access), and leave (.) for function composition. Personally, I'd like something which looked like an arrow for record selection, but most of the good 2-character ones are unavailable. (~) is a bit hard to type and looks wrong in some fonts. There's a triangle which is not taken, and isn't so hard to type (|). I never really understood the attachment to (.) for record selection. There's no reason that we have to make things look like Java and C. Another option is to make application of a label to a record mean projection, somewhat like things currently are, though since labels aren't really functions anymore that is potentially confusing. - Cale ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On 11/17/05, Cale Gibbard [EMAIL PROTECTED] wrote: On 17/11/05, Sebastian Sylvan [EMAIL PROTECTED] wrote: On 11/17/05, Greg Woodhouse [EMAIL PROTECTED] wrote: Isn't there a potential for confusion with function composition (f . g)? That being said, I like this idea (I just need to think it through a bit). I've been wanting this for ages. It's SO much better than the current horribly broken records we have. There could be confusion with function composition, but there's no ambiguity (compositon have spaces around the dot, while record accessors do not). Personally I think that the dot is way to good of a symbol to be wasted on function composition. I mean, how often do you really use function composition in a way which doesn't obfuscate your code? I use ($) way more often than (.). Some people do use it more often than I do, but I find that in most cases except simple pipelined functions it only makes the code harder to read. I'd rather function composition was left out of the prelude alltogether (or defined as (#) or something). Anyway. The current records system is a wart. Actually, I didn't mention this in the other post, but why not the other way around? Make record selection (#) or (!) (though the latter gets in the way of array access), and leave (.) for function composition. Personally, I'd like something which looked like an arrow for record selection, but most of the good 2-character ones are unavailable. (~) is a bit hard to type and looks wrong in some fonts. There's a triangle which is not taken, and isn't so hard to type (|). I never really understood the attachment to (.) for record selection. There's no reason that we have to make things look like Java and C. This is going to be highly fuzzy and completely subjective. Here it goes. I find that for selections (records, or qualified modules etc.) I want the operator to be small and so that the important word groups become the module or the record. When I read the following two variants myPoint#x myPoint.x I definatly prefer the latter. In the first one the operator is so large that it makes myPoint and x blend together as you read it (step away from the monitor and squint and you'll see what I mean), whereas in the second example the operator is small and makes the two operands naturally separate slightly when reading it, which makes it easier to tell which identifier is accessed. Also, it's certainly not a BAD thing if Haskell uses the same operators as other languages. With function composition, though, the operator is just as important to identify when reading as the operands are. So I don't think a big operator is a problem there - likewise I have no problems with ($) being large. How about (¤)? It looks like a ring to me, I'm not sure where that's located on a EN keyboard, but it's not terribly inconvenient on my SE keyboard. f ¤ g looks better than f . g for function composition, if you ask me. That's my subjective view on why the dot-operator is so darn nice, anyway. Oh and to answer to your other post. I realise that function composition is a fundamental operation, but it's so fundamental that it's quite useless for most real-world cases unless your willing to seriously ubfuscate your code. IMO it really only works well for simple chains like foo . bar . oof . rab but as soon as you start working with functions that take more parameters it starts looking very unreadable and you'd be better off to just use $ or write out paranthesis and apply arguments explicitly, or better yet, introduce some temporary descriptive variables in a let or where clause. It's a matter of personal preference, but I certainly haven't found it used enough to warrant giving it perhaps the best symbol on the keyboard. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
--- Cale Gibbard [EMAIL PROTECTED] wrote: Actually, I didn't mention this in the other post, but why not the other way around? Make record selection (#) or (!) (though the latter gets in the way of array access), and leave (.) for function composition. Actually, the fact that (!) is the array selector makes it all the more attractive as a record selector. (It does make you wonder if a record isn't a kind of a typed associative array, though...) Personally, I'd like something which looked like an arrow for record selection, but most of the good 2-character ones are unavailable. (~) is a bit hard to type and looks wrong in some fonts. Well, yeah, but the arrows have such a fundamentally different meaning in Haskell. (I thought of that one, too). There's a triangle which is not taken, and isn't so hard to type (|). If we're not careful, though, Haskell will end up looking like APL. I never really understood the attachment to (.) for record selection. There's no reason that we have to make things look like Java and C. Another option is to make application of a label to a record mean projection, somewhat like things currently are, though since labels aren't really functions anymore that is potentially confusing. Actually, I thought of that, too, or rather something like get label record or get record label (I haven't made up my mind which way the currying makes more sense. Do you have a generic function for getting records with a certain label, or do you apply get label, tget the field with this label, to record?) - Cale === Gregory Woodhouse [EMAIL PROTECTED] Interaction is the mind-body problem of computing. --Philip Wadler ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On 17/11/05, Sebastian Sylvan [EMAIL PROTECTED] wrote: On 11/17/05, Cale Gibbard [EMAIL PROTECTED] wrote: On 17/11/05, Sebastian Sylvan [EMAIL PROTECTED] wrote: On 11/17/05, Greg Woodhouse [EMAIL PROTECTED] wrote: Isn't there a potential for confusion with function composition (f . g)? That being said, I like this idea (I just need to think it through a bit). I've been wanting this for ages. It's SO much better than the current horribly broken records we have. There could be confusion with function composition, but there's no ambiguity (compositon have spaces around the dot, while record accessors do not). Personally I think that the dot is way to good of a symbol to be wasted on function composition. I mean, how often do you really use function composition in a way which doesn't obfuscate your code? I use ($) way more often than (.). Some people do use it more often than I do, but I find that in most cases except simple pipelined functions it only makes the code harder to read. I'd rather function composition was left out of the prelude alltogether (or defined as (#) or something). Anyway. The current records system is a wart. Actually, I didn't mention this in the other post, but why not the other way around? Make record selection (#) or (!) (though the latter gets in the way of array access), and leave (.) for function composition. Personally, I'd like something which looked like an arrow for record selection, but most of the good 2-character ones are unavailable. (~) is a bit hard to type and looks wrong in some fonts. There's a triangle which is not taken, and isn't so hard to type (|). I never really understood the attachment to (.) for record selection. There's no reason that we have to make things look like Java and C. This is going to be highly fuzzy and completely subjective. Here it goes. I find that for selections (records, or qualified modules etc.) I want the operator to be small and so that the important word groups become the module or the record. When I read the following two variants myPoint#x myPoint.x I think both of those look crowded -- smashing operator punctuation up against symbols basically never looks good to me. The right amount of spacing isn't generally available without proper typesetting, but a full space is a lot closer than no space at all. Why not myPoint # x and myPoint . x? I definatly prefer the latter. In the first one the operator is so large that it makes myPoint and x blend together as you read it (step away from the monitor and squint and you'll see what I mean), whereas in the second example the operator is small and makes the two operands naturally separate slightly when reading it, which makes it easier to tell which identifier is accessed. Also, it's certainly not a BAD thing if Haskell uses the same operators as other languages. With function composition, though, the operator is just as important to identify when reading as the operands are. So I don't think a big operator is a problem there - likewise I have no problems with ($) being large. How about (¤)? It looks like a ring to me, I'm not sure where that's located on a EN keyboard, but it's not terribly inconvenient on my SE keyboard. f ¤ g looks better than f . g for function composition, if you ask me. That symbol actually does look better, but isn't on any English keyboards to the best of my knowledge. I can get it in my setup with compose-key o x, but not many people have a compose key assigned. Also, this may just be a bug, but currently, ghc gives a lexical error if I try to use that symbol anywhere, probably just since it's not an ASCII character. That's my subjective view on why the dot-operator is so darn nice, anyway. Oh and to answer to your other post. I realise that function composition is a fundamental operation, but it's so fundamental that it's quite useless for most real-world cases unless your willing to seriously ubfuscate your code. I disagree, there are plenty of cases where it's just what you want, and saves you from introducing a lambda term for nothing. This occurs very often in parameters to higher order functions. A simple example would be something like filter (not . null), or any ((`elem` consumers) . schVertex). More sophisticated examples come up all the time, and often the functions being composed have some parameters applied to them. I disagree that it's just for obfuscation. Using function composition puts emphasis on the manipulation of functions rather than on the manipulation of the elements those functions act on, and quite often in a functional language that's just what you want. IMO it really only works well for simple chains like foo . bar . oof . rab but as soon as you start working with functions that take more parameters it starts looking very unreadable and you'd be better off to just use $ or write out paranthesis
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On 17/11/05, Benjamin Franksen [EMAIL PROTECTED] wrote: On Thursday 17 November 2005 19:21, Cale Gibbard wrote: Sebastian Sylvan wrote: Personally I think that the dot is way to good of a symbol to be wasted on function composition. I mean, how often do you really use function composition in a way which doesn't obfuscate your code? I use ($) way more often than (.). Some people do use it more often than I Function composition is a very important and fundamental operation on functions, and I use it all the time. Haskell is supposed to be a functional language. I'd vote against any motion to make it less convenient. Of course, it really shouldn't be (.) but a small circle centred on the line, which isn't on ordinary keyboards. (°) looks closer, but is much less convenient to type. (I need to type Compose 0 ^ in order to get that character.) Spelling it as (.) really is the best easy-to-type approximation. Yes, yes, yes. I'd rather use a different operator for record selection. For instance the colon (:). Yes, I know it is the 'cons' operator for a certain concrete data type that implements stacks (so called 'lists'). However I am generally opposed to wasting good operator and function names as well as syntactic sugar of any kind on a /concrete/ data type, and especially not for stacks aka lists. However, the way things are currently, all symbols starting with ':' are constructors of concrete data types, as that's how infix data constructors are distinguished. Also, I must point out that lists are a pretty important structure in lazy functional programming, taking the place of loops in an imperative language, and their importance shouldn't be taken so lightly. Given how much they are used, giving them a little syntax sugar and good looking data constructors doesn't seem all that far off. On the other hand, I would like to see list comprehensions generalised to monad comprehensions again. For a hypothetical Haskell2 I'd propose to get rid of all special 'list' constructs and re-use the good symbols and names for /abstract/ interfaces to sequences and collections resp. (in case of the colon) for record selection. However, you can't abstract data constructors. If cons was abstracted, then you couldn't use it in pattern matching, which is problematic. Just my 2 cent. Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On 11/17/05, Cale Gibbard [EMAIL PROTECTED] wrote: On 17/11/05, Sebastian Sylvan [EMAIL PROTECTED] wrote: On 11/17/05, Cale Gibbard [EMAIL PROTECTED] wrote: On 17/11/05, Sebastian Sylvan [EMAIL PROTECTED] wrote: On 11/17/05, Greg Woodhouse [EMAIL PROTECTED] wrote: Isn't there a potential for confusion with function composition (f . g)? That being said, I like this idea (I just need to think it through a bit). I've been wanting this for ages. It's SO much better than the current horribly broken records we have. There could be confusion with function composition, but there's no ambiguity (compositon have spaces around the dot, while record accessors do not). Personally I think that the dot is way to good of a symbol to be wasted on function composition. I mean, how often do you really use function composition in a way which doesn't obfuscate your code? I use ($) way more often than (.). Some people do use it more often than I do, but I find that in most cases except simple pipelined functions it only makes the code harder to read. I'd rather function composition was left out of the prelude alltogether (or defined as (#) or something). Anyway. The current records system is a wart. Actually, I didn't mention this in the other post, but why not the other way around? Make record selection (#) or (!) (though the latter gets in the way of array access), and leave (.) for function composition. Personally, I'd like something which looked like an arrow for record selection, but most of the good 2-character ones are unavailable. (~) is a bit hard to type and looks wrong in some fonts. There's a triangle which is not taken, and isn't so hard to type (|). I never really understood the attachment to (.) for record selection. There's no reason that we have to make things look like Java and C. This is going to be highly fuzzy and completely subjective. Here it goes. I find that for selections (records, or qualified modules etc.) I want the operator to be small and so that the important word groups become the module or the record. When I read the following two variants myPoint#x myPoint.x I think both of those look crowded -- smashing operator punctuation up against symbols basically never looks good to me. The right amount of spacing isn't generally available without proper typesetting, but a full space is a lot closer than no space at all. Why not myPoint # x and myPoint . x? Well, again this is just preference, but to me I'd like selectors to not have space between the record and the label, they still need to be connected, but with a symbol which is small enought to help you easily see what's what. I definatly prefer the latter. In the first one the operator is so large that it makes myPoint and x blend together as you read it (step away from the monitor and squint and you'll see what I mean), whereas in the second example the operator is small and makes the two operands naturally separate slightly when reading it, which makes it easier to tell which identifier is accessed. Also, it's certainly not a BAD thing if Haskell uses the same operators as other languages. With function composition, though, the operator is just as important to identify when reading as the operands are. So I don't think a big operator is a problem there - likewise I have no problems with ($) being large. How about (¤)? It looks like a ring to me, I'm not sure where that's located on a EN keyboard, but it's not terribly inconvenient on my SE keyboard. f ¤ g looks better than f . g for function composition, if you ask me. That symbol actually does look better, but isn't on any English keyboards to the best of my knowledge. I can get it in my setup with compose-key o x, but not many people have a compose key assigned. Also, this may just be a bug, but currently, ghc gives a lexical error if I try to use that symbol anywhere, probably just since it's not an ASCII character. Hmm. On my keyboard it's Shift+4. Strange that it's not available on other keyboards. As far as I know that symbol means nothing particularly swedish. In fact, I have no idea what it means at all =) That's my subjective view on why the dot-operator is so darn nice, anyway. Oh and to answer to your other post. I realise that function composition is a fundamental operation, but it's so fundamental that it's quite useless for most real-world cases unless your willing to seriously ubfuscate your code. I disagree, there are plenty of cases where it's just what you want, and saves you from introducing a lambda term for nothing. This occurs very often in parameters to higher order functions. A simple example would be something like filter (not . null), or any ((`elem` consumers) . schVertex). More sophisticated examples come up all the time, and often
Re: [Haskell-cafe] Project postmortem
Hi Joel, What would your impression be of building an application in Haskell versus Erlang from a practical point of view given your experiences with this project and the Erlang poker server? My feelings having developed a little with Erlang and embarking on a Haskell project are that the learning curve is far steeper with Haskell but it is far more elegant and readable. I'm still climbing that curve though (IO makes me want to pull my hair out). Thanks for writing up that post mortem. There's lots of good info in there, especially for a newbie like myself. Cheers, Scott On 18/11/2005, at 12:43 AM, Joel Reymont wrote: Folks, I have done a lot of experiments over the past few weeks and came to a few interesting conclusions. First some background, then issues, solutions and conclusions. I wrote a test harness for a poker server that understands the different binary packets and can send and receive them. The harness launches each script in a separate unbound thread that connects to the server via TCP and does its work. The main goals of the project were: easy scripting, very high number of connections from the harness (a few thousand) and running on Windows. I develop on Mac OSX but have a Windows machine for testing and to run the poker server. Another key goal was to support the server encryption. SSL encryption is done in a wierd way that requires attaching read/ write OpenSSL BIOs to the SSL descriptor so that SSL encrypts to/ from memory. Encrypted chunks are then taken from the BIOs and sent as payload in servver packets. Overall, I probably spent about 4 weeks writing the server and about 2 more weeks grappling with the various issues. The issues centered around 1) the program trashing memory like no tomorrow, 2) intermittent crashes on Windows and 3) not being able to launch a high number of connections on Windows before crashing. I significantly improved trashing of memory by switching to plain Haskell structures from nested lists of wxHaskell-style properties (attr := value). Intermittent crashes were harder to troubleshoot, specially given that things were running smoothly on Mac OSX. Stack traces pointed into libcrypto (part of OpenSSL) and thus to the BIOs that I was allocating. I guesses that OpenSSL was maxing out some resources and closed the leak by explicitly freeing the SSL descriptor which freed the associated BIO structures. Then things got wierder as my program started crashing in a different place entirely with stack traces like this: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x3139322e 0x0027c174 in s8j1_info () (gdb) where #0 0x0027c174 in s8j1_info () #1 0x0021c9f4 in StgRunIsImplementedInAssembler () at StgCRun.c:576 #2 0x0021cdc4 in schedule (mainThread=0x1100360, initialCapability=0x308548) at Schedule.c:932 #3 0x0021dd6c in waitThread_ (m=0x1100360, initialCapability=0x0) at Schedule.c:2156 #4 0x0021dc50 in scheduleWaitThread (tso=0x13c, ret=0x0, initialCapability=0x0) at Schedule.c:2050 #5 0x00219548 in rts_evalLazyIO (p=0x29b47c, ret=0x0) at RtsAPI.c:459 #6 0x001e4768 in main (argc=2262116, argv=0x308548) at Main.c:104 I took waitThread_ as a clue and started digging deeper. Whenever I connect to the server or send a command I wait for X seconds and if not connected or desired command is not received I throw an exception which fails the script. I implemented the timeout combinator a couple of different ways, including that in the Asynchronous Exceptions paper but it did not help. I think the issue has to do with killing threads that are using FFI. Although I'm killing threads that call the Haskell connectTo, hGetBuf, etc. I think it's still FFI. I disposed of timeouts entirely, leaving connectTo as it is and using hWaitForInput on my socket handle to simulate timeouts. This improved things tremendously and I'm now able to run a few thousands of unbound script threads on Windows with OpenSSL FFI and everything. Memory usage is still higher than I would have liked and crashes in OpenSSL still happen when the number of threads/memory usage is really high so there's still room for improvement. I should probably go back to using a foreign finalizer (SSL_free) on the SSL descriptors rather than freeing them explicitly as the freeing does not happen if a script fails mid-way. I'm quite satisfied with my first Haskell project. I love Haskell and will continue hacking away with it. This list is invaluable in the depth of offered help whereas #haskell (IRC) is invaluable when speed matters. I'm quite amazed at the things I have been able to do, the expressiveness of Haskell and the clean looks. Clean looks can be deceptive, though, as they can hide code of amazing complexity. Fundeps, existential types, HList take a while to grasp. Also, I feel somewhat like a pioneer
Re: [Haskell-cafe] Project postmortem
On Nov 17, 2005, at 10:59 PM, Scotty Weeks wrote: What would your impression be of building an application in Haskell versus Erlang from a practical point of view given your experiences with this project and the Erlang poker server? I would have been done much faster and with far less trouble. The scripting would have been a royal pain in the rear for the customer, though. But, again, I would have been done much faster as network clients/servers is what Erlang excels at. That and concurrency. Haskell... I'm still trying to figure out why reading from a Chan with getChanContents and then printing out the contents works and doing the same with readChan and looping blocks. Or why the app now crashes violently on Mac OSX but works without a hitch on Windows. And I still don't have a good timeout combinator. I felt very excited this morning given the newly found love between my app and Windows but the excitement lasted only until I realized that hWaitForIO blocks all other threads :-(. My feelings having developed a little with Erlang and embarking on a Haskell project are that the learning curve is far steeper with Haskell but it is far more elegant and readable. I'm still climbing that curve though (IO makes me want to pull my hair out). Unless lightning strikes and tomorrow morning I figure out what's the deal with the spurious Mac OSX crashes, I think this might be my last network app in Haskell. I should really be spending time on the business end of the app intead of figuring out platform differences and the like. Joel -- http://wagerlabs.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
another thing is that for any record syntax, we would want higher order versions of the selection, setting, and updating routines. A quick perusal of my source code shows over half my uses of record selectors are in a higher order fashion. (which need to be generated with DrIFT with the current syntax) I mean something like map (.foo) xs to pull all the 'foo' fields out of xs. (using made up syntax) or map (foo_s 3) xs to set all the foo fields to 3. (using DrIFT syntax) John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On Nov 17, 2005, at 1:52 PM, Benjamin Franksen wrote: ... Yes, yes, yes. I'd rather use a different operator for record selection. For instance the colon (:). Yes, I know it is the 'cons' operator for a certain concrete data type that implements stacks (so called 'lists'). However I am generally opposed to wasting good operator and function names as well as syntactic sugar of any kind on a /concrete/ data type, and especially not for stacks aka lists. Would you be happier if it were the yield operator for iterators? Yours lazily, Jan-Willem Maessen Just my 2 cent. Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
Chris Kuklewicz writes: Would the record system describe at http://lambda-the-ultimate.org/node/view/1119 also be convertable into System Fw, GHC's existing, strongly-typeed intermediate language. ? Probably. Daan's current implementation uses MLF, which I believe is system F implemented for ML. (We're talking about the system in Daan Leijen's paper, Extensible Records With Scoped Labels. Good stuff.) -- David Menendez [EMAIL PROTECTED] | In this house, we obey the laws http://www.eyrie.org/~zednenem |of thermodynamics! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On 11/18/05, John Meacham [EMAIL PROTECTED] wrote:
another thing is that for any record syntax, we would want higher order
versions of the selection, setting, and updating routines. A quick
perusal of my source code shows over half my uses of record selectors
are in a higher order fashion. (which need to be generated with DrIFT
with the current syntax)
I mean something like
map (.foo) xs
to pull all the 'foo' fields out of xs. (using made up syntax)
Well I suppose this is just a section on the selection operator?
map (foo_s 3) xs
This is trickier I think. I think I can live with map (\r - {r | s =
3}), though.
--
Sebastian Sylvan
+46(0)736-818655
UIN: 44640862
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On Fri, Nov 18, 2005 at 07:32:53AM +0100, Sebastian Sylvan wrote:
On 11/18/05, John Meacham [EMAIL PROTECTED] wrote:
map (.foo) xs
to pull all the 'foo' fields out of xs. (using made up syntax)
Well I suppose this is just a section on the selection operator?
So field labels are first-class citizens? Great!
map (foo_s 3) xs
This is trickier I think. I think I can live with map (\r - {r | s =
3}), though.
I think this special case could be treated specially, for example
(\r - {r | s = 3})
could be equivalent to
{|s = 3}
Best regards
Tomasz
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On Thu, Nov 17, 2005 at 06:56:09PM +0100, Sebastian Sylvan wrote: Personally I think that the dot is way to good of a symbol to be wasted on function composition. I mean, how often do you really use function composition in a way which doesn't obfuscate your code? I just checked in two recent projects, and it's about one (.) in 100 lines of code. I wanted to disagree with you, but in the end I could accept pressing more keys when I wanted function composition, especially if I got something in return. BTW, I think there was some tool to calculate various metrics on Haskell code. It would be interesting to make some graphs showing how often you use various features of Haskell, how it changed with time. I use ($) way more often than (.). Me too, measurement shows it's about four times more often. However, I like my uses of (.) much more than uses of ($). I often turn $'s into parentheses, because I feel it looks better this way. Of course, there are cases where $ is indispensable. Some people do use it more often than I do, but I find that in most cases except simple pipelined functions it only makes the code harder to read. But this case is quite important, isn't it? Best regards Tomasz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
