Re: [Haskell-cafe] Where to start about writing web/HTTP apps ?
gary ng wrote: >I want to write apps for WEB and have briefly read >WASH. I'm thinking of doing the same. The approach taken by WASH seems very cool and I'd love to use it. I've only started looking at it, but WASH seems to require that JavaScript be enabled on the user's web browser, even for the simplest forms. e.g. from the authors web page: http://nakalele.informatik.uni-freiburg.de/cgi/WASH/Counter.cgi Also, the error checking doesn't seem to work as I'd expect: if you submit a page without a required field it will complain the first time, then make something up the second time around -- even if you haven't entered anything in the field. Sam ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Annotating calculations
Rene de Visser wrote: >Designing the data structures to store the calculation results seems to be >non-trivial, so I guess I should do this first. I think that part of the problem is that when you need to be able to reference results from the inside of a calculation (or any sort of expression) you need to be able to refer to them somehow. One of the easier ways of doing this would be to bung them into some sort of data structure, alternatives would be to use a spreadsheet type abstraction that allows you to pull things out. Someone posted a reference to an interesting paper that you may be able to build on: http://citeseer.ist.psu.edu/carlsson02monads.html It's probably not going to be a trivial translation, but once you've written your calculations in this style, you should be able to get at out the intermediate values easily. At least I wrote something similar in Java a few years ago that did similar things, and it was quite a nice of abstraction to work with. I guess it's not going to matter much for you, but the problem of using some specific data structure is that it's probably going to be very closely related to the structure of the code. If you need to change the code in any non-trivial way the data structure is going to have to change and all of the code that deals with the data structure will as well. Because your report is probably going to have to change in sync with the calcs this probably isn't going to be much of a problem, but in other situations it can be a bit of a pain. >Then maybe the solution to the other >problem will be apparent. I think your main problem is that you need some way of labeling the intermediate results so you can refer to them later when you need them in the report. One you've worked out how you're going to do that, everything else should fall into place. Hope that helps! Sam ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Looking for lost library
Samuel Bronson wrote: >On 05/06/05, Dean Herington <[EMAIL PROTECTED]> wrote: >> I believe you're describing: >> http://portal.acm.org/citation.cfm?doid=581478.581482 . > >I don't suppose you know of any place to get it *free*? Just out of interest; CiteSeer (previously known as ResearchIndex) is good for searching for these sorts of things: http://citeseer.ist.psu.edu/ Or you can try google's more specialized search: http://scholar.google.com/ Both of these find the above paper without much trouble. . . Sam ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Are handles garbage-collected?
Marcin 'Qrczak' Kowalczyk wrote: >I would not be surprised if relying on GC to close open files would >be generally considered kosher in a few years - in cases when it has >little visible effects outside, i.e. excluding network connections, >but including reading configuration files. The best idea I've seen is another one from Microsoft Research. It's an extension to C that allows the the programmer to use the type system to specify the lifetime of things. Seems like a pretty good idea: http://research.microsoft.com/vault/ Not sure how you'd do something like that in Haskell though! Cheers, Sam ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Subsequence near solved hopefully
Peter Simons wrote: >This version should do it: > >isSubSeq :: (Eq a) => [a] -> [a] -> Bool >isSubSeq [] _= True >isSubSeq _ []= False >isSubSeq (x:xs) (y:ys) > | x == y= isSubSeq xs ys I think you want to refer to List.isPrefixOf here - your version is a sort of "ordered subset" test. I.e. I get: "abc" `isSubSeq` ".a.b.c." ===> True > | otherwise = isSubSeq (x:xs) ys My version would've been: isSubSeq x = any (isPrefixOf x) . tails But Remi beat me to it (and for that I'll never forgive him! :-). Sam ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Subsequence near solved hopefully
Peter Stranney wrote: >isSubStrand:: String -> String -> Bool >isSubStrand [] [] = True >isSubStrand [] (y:ys) = False >isSubStrand (x:xs) [] = False >isSubStrand (x:xs) (y:ys) > | length(x:xs)>length(y:ys) = False > | take (length (x:xs)) (y:ys)==(x:xs) = True > | otherwise = isSubStrand (x:xs) ys Just to muddy the water a bit. . . What happens if the second string is infinite? Sam ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OCaml list sees abysmal Language Shootout results
Greg Buchholz wrote: >The algorithm isn't correct (it counts spaces instead of words), but >anyone have advice for improving its performance? You probably want some strictness annotations in there. . . When I tried the same thing, I came up with something like: > import Char; > > cclass c | isSpace c = (c == '\n', False) > | otherwise = (False, True) > > data Cdata = Cdata !Bool !Int !Int !Int > deriving Show > > combine (Cdata last l w c) (nl, iw) = Cdata iw l' w' (c + 1) > where l' = if nl then l + 1 else l > w' = if not last && iw then w + 1 else w > > wc = foldl combine (Cdata False 0 0 0) . map cclass > > main = getContents >>= putStrLn . show . wc It seems to work in constant stack space, and gives the same answers (albeit not very beautifully) as my GNU copy of "wc". >Is the problem >caused by the laziness of the Int's inside the tuple? I'm pretty sure that's what's causing it. I had quite a search around when my version was running out of memory and everything seemed to suggest that, basically, the algorithm is building a massive list of "+1"s that only actually get executed when the you try and print the totals at the end. Any comments from more authoritative sources? >Here is the >report from ghc with the '-ddump-simpl' option. If anyone has any hints about how to read this output, I'd be grateful. It makes a bit of sense, but I don't really know what it "means". I.e. it's obviously the simplified parse tree and I can see how it relates back to the source (loosely), but attempting to figure out if something's going to be as leaky as a sieve or not is beyond me. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Fun with multi-parameter type classes
karczma wrote: >Actually, I would like to know what was the purpose of all >that... I was writing some new code and wanted to break it into two parts, they should have very little knowledge of each other other than what methods are available in each (hence the classes). The actual types of the values that were being passed around should have remained invisible to the other half of the code. Anyway, I didn't want to dump loads of code on you so I rewrote it in a simpler manner that took the form of the "read" and "show". The actual implementations weren't supposed to be of importance, just the fact that they were passing around something that the calling code shouldn't have known about. I've since realised that I can't solve the problem in the way I originally wanted to and have now sort of turned the code inside out so that there aren't any magically typed references floating around. Hope that makes a bit more sense now, Sam ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Fun with multi-parameter type classes
karczma wrote: >Don't forget that this is the toplevel business, not a universal >"disease". GHCi says > >Prelude> :t (show . read) >(show . read) :: String -> String > >and doesn't complain. But if you define > >bz = show . read > >the attempt to load this definition (file: ctest.hs) results in: > >ctest.hs:3: > Ambiguous type variable `a' in these top-level constraints: >`Read a' arising from use of `read' at ctest.hs:5 >`Show a' arising from use of `show' at ctest.hs:5 >Failed, modules loaded: none. >Prelude> OK, you've got me interested! Why doesn't GHCi complain about the ambiguity? >So, as one of my friends used to say: it should be obvious for >everybody that what is obvious for one, need not be obvious for >the others... Suitably abstruse! ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fun with multi-parameter type classes
Jon Cast wrote: >The intermediate type /is/ needed---it's a (hidden) parameter to your >`encode' and `decode' functions. Why do you think it shouldn't be? Because I couldn't see the woods for the trees. I think I had almost figured out what I was asking (the impossible) before your message appeared. I've actually been getting quite confused over this for quite a while and got a lot of it sorted out while I wrote the original email. That's why the subject doesn't match the body at all - I completly rewrote the message several times as I figured out what was going on, but forgot to update the subject. Thanks, Sam ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Fun with multi-parameter type classes
Hi, I've been getting into Haskell over the past few months and have just come up against a bit of a brick wall when trying to encapsulate some of the data structures in my code nicely. Basically what I want to have, is a type class where one of the intermediate values is opaque with respect to code using its implementations. This is a simplified version of what I'm trying to accomplish: class Foo t where encode :: String -> t decode :: t -> String instance Foo Int where encode = read decode = show test = decode . encode This currently fails, because the type checker insists on trying to figure out what its type should be - even though it shouldn't be needed. Any suggestions on how to encode this sort of thing? And if it is possible, can it be extended to multiple type parameters? as this is really what I want to use it for. About the only way I can think of "fixing" it, is by turning the code inside out - sort of like the way an AST drives the compiler, but without knowing how it represents things internally. Thanks, Sam ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
