[Haskell-cafe] Sneaky method for var-arg fns?
So, just for fun, I came up with a way to abuse the language in order to
define a function whose argument is optional:
-- dirty-trick.hs - A sneaky way to do var args fns in Haskell
{-# LANGUAGE FlexibleInstances #-}
class Hello a where
hello :: a
instance Hello (String - String) where
hello = (\str - Hello ++ str)
instance Hello String where
hello = hello World
In ghci,
putStrLn $ hello
gives Hello World, while
putStrLn $ hello There
gives Hello.
.
I was wondering if there was a way to do it in pure Haskell (i.e., no
GHC pragmas required), and also the specific reason for why the above
example doesn't work without the pragma (I think it's just that in
general a - b is not syntactically allowed for type specifiers within
instance declarations)?
I'm also interested in alternative approaches to creating
variable-argument functions, if there are any.
.
If anyone's curious, this was prompted by a discussion with a friend
(copied), about Haskell and Clojure. He mentioned that Clojure can
accept variable arguments, though AFAICT all Clojure functions basically
act like they take a list (that supports variable types), so accepting
an empty argument list is a bit analogous to Haskell accepting an empty
list, rather than no arguments.
Part of the reason Haskell can't really take variable arguments is
that all Haskell functions really just take one argument. But I figured
you could use the contextually expected type to decide whether to return
a simple value (not /technically/ a function in that case), or a function
expecting further arguments, which could then be extended to define a
function taking any arbitrary number of arguments.
Cheers!
-mjc
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wolfgang Jeltsch wrote: Am Donnerstag, 2. Oktober 2008 20:33 schrieben Sie: Wolfgang Jeltsch wrote: You mean shared libraries without the opportunity to inline library code? This would result in a huge performance loss, I think. Usually _mild_ performance loss, in exchange for major code-size savings, I would think. C obviously has worked quite fine under exactly this restraint (though C implementations obviously aren't built to take as great advantage of inlining library code as Haskell may be). I think that the performance loss is much higher in the case of Haskell because of Lazy Evaluation, massive use of higher order functions and possibly more. Maybe one of the GHC developers could comment on this? Perhaps the best approach currently for creating dynamically loadable modules in Haskell is to expose the interface via FFI, then? (I suspect that in most cases, you'd want to provide that as an option, but of course not as the only means of interfacing with the library, for those who don't want to make the DLL-vs-optimizations tradeoff.) - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer. GNU Maintainer: wget, screen, teseq http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI5lq/7M8hyUobTrERAn7aAJwPz4wbu0W4RPNhlgKGmd+2glZDewCfbi9d LQtahiILQg83vkzyfAR2BV4= =mjFe -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hmm, what license to use?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wolfgang Jeltsch wrote: Am Dienstag, 30. September 2008 00:18 schrieb Duncan Coutts: Yet another reason for getting dynamic linking / shared libs for Haskell packages working reliably on all platforms. You mean shared libraries without the opportunity to inline library code? This would result in a huge performance loss, I think. Usually _mild_ performance loss, in exchange for major code-size savings, I would think. C obviously has worked quite fine under exactly this restraint (though C implementations obviously aren't built to take as great advantage of inlining library code as Haskell may be). Just because there's an important loss in value, doesn't mean there's not a significant net gain for some needs. Dynamically linked libs in Haskell have obvious benefits, as well as obvious drawbacks. - -- But hey, YMMV. Just my opinion. Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer. GNU Maintainer: wget, screen, teseq http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI5RP37M8hyUobTrERAgn3AJ9JfWDY269PiRyh2hei1uH6W+dJ2wCfY/YG ztVcGYvH1+pQqG/fryr+YPw= =ekJT -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: hGetContents and lazyness
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Max Vasin wrote: Micah Cowan [EMAIL PROTECTED] writes: I think we'd need to see the actual input and expected output, to understand what's going wrong here. It worked fine for me, for small tests. The gzipped example file is here: ftp://ftp.debian.org/debian/dists/lenny/contrib/binary-i386/Packages.gz By the way, it's good policy to always post complete, runnable examples. Requiring anyone who wants to help you to write additional code just to get it to run decreases the chances that someone will bother to do so. Sorry. I've just omitted module imports: import Control.Monad (filterM, mapM) import System.IO (withFile, IOMode (ReadMode), hGetContents) import qualified System.Posix.Files as SPF (isDirectory, getFileStatus) Actually, I meant more the missing main function; but the example invocation you gave will do fine. As previously mentioned, the full list will be output if you ensure that the putStrLn calls take place within withFile, rather than without: getPackageList :: FilePath - IO () getPackageList packageFile = withFile packageFile ReadMode $ \h - do c - hGetContents h mapM_ (putStrLn . drop 10) $ filter (startsWith Filename:) $ lines c where startsWith [] _ = True startsWith _ [] = False startsWith (x:xs) (y:ys) | x == y= startsWith xs ys | otherwise = False Your experiments with $! don't work, I believe because seq only does a shallow evaluation: in particular, it doesn't evaluate successive elements in a list (RWH puts it: seq stops as soon as it reaches a constructor ($! is defined in terms of seq)). In order to work around this, you'd need to define your own versions of map and filter to manage the construction using seq. Not worth it, IMO, especially since accomplishing this forces the whole list to be held in memory, which isn't as nice as processing things sequentially before the file has been closed. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer. GNU Maintainer: wget, screen, teseq http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI2R9z7M8hyUobTrERAggSAJwIVUAEyeoeIRbNaljHIycTrub4UQCeM1j7 ARGXhGNl//o3SlipDuGhUyw= =KVlj -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hGetContents and lazyness
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Max Vasin wrote: Hello, haskellers! Suppose we have function (it filters package filenames from apt Packages file): getPackageList :: FilePath - IO [FilePath] getPackageList packageFile = withFile packageFile ReadMode $ \h - do c - hGetContents h return $ map (drop 10) $ filter (startsWith Filename:) $ lines c -- (1) where startsWith [] _ = True startsWith _ [] = False startsWith (x:xs) (y:ys) | x == y= startsWith xs ys | otherwise = False When, I apply it to a Packages file I (surely) get an empty list. This is an expected result due to lazyness of hGetContents. Combined with the fact that you're not evaluating its non-strict result until after the file handle has been closed, yes. Your current set of IO actions is probably similar to: . open file . process file . close file . use results from processing the file. where the first three steps are all handled by your getPackageList. To avoid either getting incomplete (or empty) results, or having to strictify everything with $!, it'd be better for you to use a process more like: . open file . process file . use results from processing the file. . close file probably by moving the withFile outside of getPackageList, to wrap a function that prints the results after they've been obtained. The function passed to withFile should generally include all the processing related to the file and its results, I believe. I tried changing line (1) to return $ map (drop 10) $ filter (startsWith Filename:) $! lines c The $! forces strictness, but since it's deep in the result, it isn't evaluated until it's too late. Chaning it to return $! map (drop 10) $ filter (startsWith Filename:) $ lines c makes getPackageList function return several (but not all) filenames. I think we'd need to see the actual input and expected output, to understand what's going wrong here. It worked fine for me, for small tests. By the way, it's good policy to always post complete, runnable examples. Requiring anyone who wants to help you to write additional code just to get it to run decreases the chances that someone will bother to do so. (Disclaimer: I'm quite new to Haskell myself, so take what I say with more than a pinch of salt.) - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer. GNU Maintainer: wget, screen, teseq http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI1/AT7M8hyUobTrERAo5qAJ9PKLbQv09UGffmxy6/eRuGS1eYbQCgj3gH 8zvxMrGk5pvCMCOQ6LVz0Yo= =GAvg -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The ultimate insult?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Coppin wrote: Delphi is usable. If you're a single hobbiest programmer, use whatever gets the job done. But as far as a career goes, I'd say even Haskell has better prospects than Delphi. So even Haskell is better? Ouch! Oh come on... has anyone here actually pursued learning Haskell because they thought it would help them rake in the jobs? :) ...I did once have a manager who habitually listed Lisp as a requirement for software positions, even though it wasn't actually going to be used (it was all C, C++ and Perl). He just wanted prospective employees to have had experience understanding a different paradigm (functional-ish programming). I wonder whether he's updated that to Lisp, Scheme or Haskell? XSLT would do as well, I suppose... - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer. GNU Maintainer: wget, screen, teseq http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI1pcH7M8hyUobTrERAoaDAJ4g+Eom8k52MlidTASj8JhtJDubhACdEhjN MGXfz3V3/5HHwpMkTuKZ7Cw= =5Q8x -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
