July 2003 - Haskell - Haskell.org

RE: How overload operator in Haskell?
by Hal Daume 06 Nov '03

06 Nov '03

What you want to do is make your Vector an instance of the Num(eric) type class. For instance: instance Num Vector where (+) v1 v2 = zipWith (+) v1 v2 (-) v1 v2 = zipWith (-) v1 v2 negate v1 = map negate v1 abs v1 = map abs v1 (*) v1 v2 = ... fromInteger i = ... signum v1 = ... I've left the last three blank because it's unclear what should go there. Since (*) has type Vector->Vector->Vector (in this instance), you can't use dot product or something like that. signum :: Vector->Vector could be written and just return [-1], [0] or [1], I suppose. fromInteger :: Integer->Vector is a little harder. Perhaps just 'fromInteger i = [fromInteger i]' would be acceptable. Or you could leave these undefined. -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume > -----Original Message----- > From: haskell-admin(a)haskell.org > [mailto:haskell-admin@haskell.org] On Behalf Of Liu Junfeng > Sent: Wednesday, July 09, 2003 7:25 AM > To: haskell(a)haskell.org > Subject: How overload operator in Haskell? > > > I've learned haskell months, but I still can't understand the > type system very well. > I can only write: > ----------------------------------- > type Vector = [Double] > vadd,vsub :: Vector->Vector->Vector > v1 `vadd` v2 = zipWith (+) v1 v2 > v1 `vsub` v2 = zipWith (-) v1 v2 > svmul :: Double->Vector->Vector > s `svmul` v = map (s*) v > ------------------------------------ > Tough it works, it is not convenient to use. How to create a > Vector type and overload > mathematical operators? > Thanks for your help. > > Liu Junfeng > liujf(a)softhome.net > > > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell >

12 14

Enum on Float/Double
by George Russell 23 Oct '03

23 Oct '03

The situation with Enum on Ratio is pretty bad but at least it's not hopeless, since rational numbers are at least exact. But for Float/Double it seems to be a total disaster area. Since it seems to be impossible to abolish Enum Float/Double altogether, would it at least be possible to make it rather more useful, by making succ x return the next representable float after x (or x if x is non-finite) and pred x the previous representable float. This would (a) be useful; (b) make mathematical sense; (c) is tricky to implement with the existing primitives. Before someone else points it out, this is of course unimplementable should someone in the future implement infinite-precision reals in Haskell, but as (barring a solution to the halting problem) Eq would be as well, that does not bother me. My preference would be for succ (+-0) to return the smallest positive real, since then you could define succ x to be the unique y with x < y and forall z . z < y => not (x < z), where such a y exists, and I'm not sure if the Haskell standard knows about signed zeros. Feri wrote > Everybody working with floats should know their quirks While in an ideal world, everyone who represented a mouse position or anything else as a float should have a PhD in numerical analysis, in practice they do not. Indeed I think the Haskell Library Report contains quite a few examples of floating point code which a numerical analyst would have written rather better. So I don't think it's good enough to treat every Float/Double operation as if it had an implicit "UNSAFE" flag indicating that the compiler was entitled to wierd behaviour only comprehensible to experts, as seems to be the case with floating enumerations now.

8 11

Pure functional TypeRep [Was: Existentials...]
by oleg＠pobox.com 05 Aug '03

05 Aug '03

This message shows how to map _types_ to integers at compile time -- and then extend this facility to run-time so it can be used with existentially-quantified types. It is statically guaranteed that different types receive different integer labels. Unlike TyCons of Dynamics, our mapping does NOT rely on unsafePerformIO. We use the typechecker itself to compare types. It seems our typemap can also be used for _safe_ casts, in particular, for casting away the existential blemish. This message was inspired by Amr Sabry's problem on existentials. Unlike Hal Daume's solution posted here earlier, we do not use Dynamics nor GMap -- therefore, we completely avoid unsafePerformIO and unsafeCoerce. Our solution is purely functional and assuredly type-safe (to the extent the typechecker can be trusted). Extensions used: -fglasgow-exts -fallow-undecidable-instances -fallow-overlapping-instances First, the compile-time mapping from types to integers. Polytypic list: > data Nil t r = Nil > data Cons t r = Cons t r > > class PList ntype vtype cdrtype where > cdr:: ntype vtype cdrtype -> cdrtype > empty:: ntype vtype cdrtype -> Bool > value:: ntype vtype cdrtype -> vtype > > instance PList Nil vtype cdrtype where > empty = const True > > instance (PList n v r) => PList Cons v' (n v r) where > empty = const False > value (Cons v r) = v > cdr (Cons v r) = r and the finite map from types to integers > class TypeSeq t s where > type_index:: t -> s -> Int > > instance (PList Cons t r) => TypeSeq t (Cons t r) where > type_index _ _ = 0 > > instance (PList Cons t' r', TypeSeq t r') => TypeSeq t (Cons t' r') where > type_index v s = 1 + (type_index v $ cdr s) Let us build some finite map > init_typeseq = Cons (undefined::Char) $ > Cons (undefined::Int) $ > Cons (undefined::Bool) $ > Cons (undefined::String) $ > Cons (undefined::Maybe Char) $ > Nil A typeseq maps a type to an integer -- which is the type's position in the polytypic list. We are satisfied with the first occurrence of the type in the list. It is plain that a typeseq maps different types to different integers. Let us see how it works: -- *Main> type_index True init_typeseq -- 2 -- *Main> type_index 'a' init_typeseq -- 0 -- *Main> type_index "a" init_typeseq -- 3 -- *Main> type_index (1::Int) init_typeseq -- 1 -- *Main> type_index (Just 'a') init_typeseq -- 4 -- *Main> type_index (Just True) init_typeseq -- <interactive>:1: -- No instance for (TypeSeq (Maybe Bool) (Nil t r)) -- arising from use of `type_index' at <interactive>:1 -- In the definition of `it': type_index (Just True) init_typeseq We call this mapping compile-time because the translation from a type to the corresponding encoding (1+1+...1) is done at compile time, when the appropriate instance of the TypeSeq class is chosen. A sufficiently smart compiler can just as well fold the constant expression (1+1...+1) down to a single integer. Also, errors in the translation are reported at compile-time. However, to apply the mapping to existential types, we need to extend the former to run-time. > class TypeRep t where > tr_index:: t -> Int > > -- All of the following are almost the same. > -- The Template Haskell can really help us here > instance TypeRep Char where > tr_index x = type_index x init_typeseq > > instance TypeRep Int where > tr_index x = type_index x init_typeseq > > instance TypeRep Bool where > tr_index x = type_index x init_typeseq > > instance TypeRep String where > tr_index x = type_index x init_typeseq > > instance TypeRep (Maybe Char) where > tr_index x = type_index x init_typeseq Now, Amr Sabry's Problem > data F a b = > forall c. (TypeRep c) => PushF (a -> c) (F c b) > | Bottom (a -> b) > > f1 :: Char -> Bool > f1 'a' = True > f1 _ = False > > f2 :: Bool -> String > f2 True = "true" > f2 False = "false" > > f3 :: String -> Int > f3 = length > > fs = PushF f1 (PushF f2 (PushF f3 (Bottom id))) First, we make fs an instance of class Show. It is jolly convenient. > data HF = forall a b. (TypeRep a,TypeRep b) => HF (F a b) > show_fn_type (g::(a->b)) > = "(" ++ (show (tr_index (undefined::a))) ++ > "->"++(show (tr_index (undefined::b))) ++ ")" > > instance (TypeRep a, TypeRep b) => Show (F a b) where > show = show . hsf_to_lst . HF > where > hsf_to_lst (HF (Bottom g)) = [show_fn_type g] > hsf_to_lst (HF (PushF g next)) = (show_fn_type g):(hsf_to_lst$HF next) Now, Amr Sabry's question: ] Is it possible to write a function ] f :: F a b -> T c -> F c b ] where (T c) is some type for values of type 'c' or values representing ] the type 'c' or whatever is appropriate. Thus if given the ] representation of Bool, the function should return: ] PushF f2 (PushF f3 (Bottom id)) ] and if given the representation of String the function should return ] PushF f3 (Bottom id) ] and so on. First, we prepend to the given F a b structure the identity composition. We see the meaning of it below. > f fs v = f' (PushF id fs) v > f':: (TypeRep c) => (F a b) -> c -> F a b > f' here@(PushF g next) (v::tv) = > if tr_index v == tr_index (g undefined) > then here > else case next of > PushF g1 next' -> f' (PushF (g1.g) next') v > Bottom g1 -> f' (Bottom (g1.g)) v The function f' takes a data structure F a b and a value of type c and returns another data structure F a b, but of a different structure PushF g next here 'next' has the type F c b -- which is the answer to Amr Sambry's question. The function g::a->c is a composition of all previously occurring functions. This is a neat "side-effect" of the function f': we partially compose the given F a b structure up to the given type. Let us see how it works: *Main> fs ["(0->2)","(2->3)","(3->1)","(1->1)"] *Main> f fs 'a' ["(0->0)","(0->2)","(2->3)","(3->1)","(1->1)"] *Main> f fs True ["(0->2)","(2->3)","(3->1)","(1->1)"] *Main> f fs "a" ["(0->3)","(3->1)","(1->1)"] *Main> f fs (1::Int) ["(0->1)","(1->1)"] Because f is capable of producing any partial composition, it can do the full composition just as easily: > flatten:: (TypeRep a, TypeRep b) => F a b -> (a -> b) > flatten fs :: (a->b) > = case f fs (undefined::b) of > PushF g (Bottom g1) -> g1.g And it indeed works: *Main> flatten fs 'a' 4 -- the length of the word true *Main> flatten fs 'b' 5 -- the length of the word false Again, I can't seem to write any Haskell code that doesn't explicitly use undefined.

4 8

ANNOUNCE: GHC version 6.0.1
by Simon Marlow 04 Aug '03

04 Aug '03

============================================================= The (Interactive) Glasgow Haskell Compiler -- version 6.0.1 ============================================================= We are pleased to announce a new patchlevel release of the Glasgow Haskell Compiler (GHC), version 6.0.1. This is a bug-fix release relative to 6.0. The most important bugfixes are: * Fixes to make GHC work with GCC 3.3 * Fix for the "GHC deletes source files" bug * :cd now unloads any loaded modules in GHCi. * -mk-dll should work better on Windows. in addition to various other bugfixes. The release notes lists the changes in the 6.0 line relative to 5.04: http://www.haskell.org/ghc/docs/latest/html/users_guide/release-6-0.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the WWW page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for various flavours of Linux and BSD, and in Windows Installer (MSI) form for Windows folks. Binary builds for other platforms are available as a .tar.gz which can be installed wherever you want. The source distribution is also available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998, and revised in December 2002. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ Haskell home page http://www.haskell.org/ comp.lang.functional FAQ http://www.cs.nott.ac.uk/~gmh/faq.html System requirements ~~~~~~~~~~~~~~~~~~~ To compile programs with GHC, you need a machine with 64+MB memory, GCC and perl. This release is known to work on the following platforms: * i386-unknown-{linux,*bsd,mingw32} * sparc-sun-solaris2 * alpha-dec-osf3 * powerpc-apple-darwin (Mac OS X) Ports to the following platforms should be relatively easy (for a wunderhacker), but haven't been tested due to lack of time/hardware: * hppa1.1-hp-hpux{9,10} * i386-unknown-solaris2 * mips-sgi-irix{5,6} * {rs6000,powerpc}-ibm-aix The builder's guide on the web site gives a complete run-down of what ports work; it can be found at http://www.haskell.org/ghc/docs/latest/html/building/building-guide.html Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Please report bugs using our SourceForge page at http://sourceforge.net/projects/ghc/ or send them to glasgow-haskell-bugs(a)haskell.org. GHC users hang out on glasgow-haskell-users(a)haskell.org. Bleeding edge CVS users party on cvs-ghc(a)haskell.org.

5 4

a breaking monad
by Hal Daume 01 Aug '03

01 Aug '03

i've noticed in a lot of my imperative-looking monadic code, i have lots of stuff that looks like: > ... = do > q <- some test > if q > then return some constant > else do > major code body here lots of these things embedded makes the code hard to read and introduces way too much indentation (i'm one of those who doesn't like curly braces). one solution to this is to write it as: > ... = do > q <- some test > if q then return some constant else do > major code body here but this is ugly, IMO :). my solution was to fashion a monad transformer that supports a break statement. basically, it looks like: > data Break b m a = Break { runBreak :: m (Maybe b, a) } > > instance MonadTrans (Break b) where > lift x = Break $ do a <- x; return (Nothing, a) > > instance Monad m => Monad (Break b m) where > return a = Break $ return (Nothing, a) > b >>= k = Break $ runBreak b >>= \ (broken, a) -> > case broken of > Nothing -> runBreak (k a) > Just br -> return (Just br, undefined) > > breakable :: Monad m => Break a m a -> m a > breakable b = runBreak b >>= \ (broken, a) -> > case broken of > Nothing -> return a > Just br -> return br > > break :: Monad m => b -> Break b m a > break b = Break (return (Just b, undefined)) essentially you introduce code blocks with the "breakable" function and then can break with the break function. a useful combinator i've found is: > breaksTo :: Monad m => m Bool -> b -> Break b m () > breaksTo k b = lift k >>= \x -> if x then break b else return () using this, you can write stuff which looks like: > test1 :: IO [String] > test1 = breakable $ do > lift $ putStrLn "Enter something, or nothing to quit:" > l <- lift $ getLine > when (null l) $ break [] > rest <- lift test1 > return (l:rest) > > test2 :: IO () > test2 = breakable $ repeatM $ do > x <- lift $ getLine >>= passThrough putStrLn > when (null x) $ break () > > test3 :: Handle -> IO [String] > test3 h = breakable $ do > hIsEOF h `breaksTo` [] > lift $ do > l <- hGetLine h > rest <- test3 h > return (l:rest) where passThrough and repeatM are: > repeatM :: Monad m => m () -> m () > repeatM x = x >> repeatM x > > passThrough :: Monad m => (a -> m b) -> a -> m a > passThrough f a = f a >> return a so, my questions are: does this exist in some other form I'm not aware of? is there something fundamentally broken about this (sorry for the pun)? any other comments, suggestions? -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume

3 3

Text I/O library proposal, first draft
by Ben Rudiak-Gould 01 Aug '03

01 Aug '03

[Crossposted to Haskell and Libraries. Replies to Libraries.] {- Good things about this text library design: * Efficient implementation should be straightforward * Character coder interface is public, so users can supply their own encodings, or write coder transformers (there are some in the proposal) Bad things: * There's no way to implement fgetpos/fsetpos type functionality, because coders don't expose their internal state. (In fact, there would need to be a way to explicitly copy the state, since it may well include IORefs, Ptrs, etc.) Is this a serious problem? -} module System.TextIOFirstDraft (...) where -- A BlockRecoder takes source and destination buffers and does some sort -- of translation between them. It returns the number of values (not -- bytes!) consumed and the number of values produced. It does not have to -- empty the input buffer or fill the output buffer on each call, but it -- must do something (i.e. it's not acceptable to return (0,0)). Coders -- will in general have internal state which is updated on each call. type BlockRecoder from to = Ptr from -> BlockLength -> Ptr to -> BlockLength -> IO (BlockLength,BlockLength) type TextEncoder = BlockRecoder Word32 Octet type TextDecoder = BlockRecoder Octet Word32 -- IO TextEncoder and IO TextDecoder below denote "coder factories" which -- produce a new coder in its initial state each time they're called. compatibilityEncoder :: IO TextEncoder -- "mod 256" currentLocaleEncoder :: IO TextEncoder iso88591Encoder :: IO TextEncoder latin1Encoder = iso88591Encoder utf8Encoder, utf16BEEncoder, utf16LEEncoder, utf32BEEncoder, utf32LEEncoder :: IO TextEncoder compatibilityDecoder :: IO TextDecoder currentLocaleDecoder :: IO TextDecoder iso88591Decoder :: IO TextDecoder latin1Decoder = iso88591Decoder utf8Decoder, utf16BEDecoder, utf16LEDecoder, utf32BEDecoder, utf32LEDecoder :: IO TextDecoder -- An attempt at supporting setlocale-type locale strings. lookupEncoder :: String -> Maybe (IO TextEncoder) lookupDecoder :: String -> Maybe (IO TextDecoder) -- prependBOM takes an existing UTF encoder and causes it to prepend -- a BOM (byte-order mark) to its output. autodetectUTF takes an existing -- decoder and modifies it to check for a BOM, switching to the -- appropriate type of UTF decoding if one is found. prependBOM :: IO TextEncoder -> IO TextEncoder autodetectUTF :: IO TextDecoder -> IO TextDecoder -- Attaches a TextInputChannel to the supplied InputChannel. After -- this operation the InputChannel should be considered owned by the -- TextInputChannel; any attempt to use it directly will cause -- unpredictable results. This takes a decoder factory rather than a -- decoder to prevent the error of attaching the same decoder to more than -- one channel. icAttachTextDecoder :: InputChannel -> IO TextDecoder -> IO TextInputChannel ticGetChar :: TextInputChannel -> IO Char ticGetLine :: TextInputChannel -> IO String ticLazyGetContents :: TextInputChannel -> IO String ocAttachTextEncoder :: OutputChannel -> IO TextEncoder -> IO TextOutputChannel tocPutChar :: TextOutputChannel -> Char -> IO () tocPutStr :: TextOutputChannel -> String -> IO () tocPutStrLn :: TextOutputChannel -> String -> IO () -- ... etc ... -- Ben

2 1

RE: Text I/O library proposal, first draft
by Hal Daume 31 Jul '03

31 Jul '03

Hi Ben, > Bad things: > > * There's no way to implement fgetpos/fsetpos type functionality, > because coders don't expose their internal state. (In fact, there > would need to be a way to explicitly copy the state, since it may > well include IORefs, Ptrs, etc.) Is this a serious problem? Yes! This is an enormously serious problem. At least for me. It's not a problem for writing files, but I really really really need this functionality when reading files. Reason: I'm often tooling around in very large (1gb or greater) files which happen to be sorted on some sort of index and I need to do binary search in them. To load all the file into Haskell or to do linear search is impossible. Other than that, I rather like the design. - Hal

2 1

RE: a breaking monad
by Hal Daume 31 Jul '03

31 Jul '03

> This looks like a bizarre rendition of the Error/Exception monad. Yes, of course. *Hal slaps himself* Thanks. > Also, your motivating example is ambiguous. I think you mainly care > about the case where the test is testing for some "exceptional" > condition. I personally wouldn't want to use this style every place I > would use an if. Definitely not! :) - Hal

1 0

Raw I/O library proposal, second (more pragmatic) draft
by Ben Rudiak-Gould 31 Jul '03

31 Jul '03

[Crossposted to Haskell and Libraries. Replies to Libraries.] -- More comments, please. Bad names? Important missing functionality? -- Still unimplementable? module System.RawIOSecondDraft (...) where data File -- now essentially a file handle data InputChannel -- renamed for less confusing function prefixes data OutputChannel -- | A Moniker is a slight generalization of a pathname. In principle this -- could be extended to support URIs, host:port SSL connections, memory -- buffers, and so on, though it might be better to give them their own -- functions. -- "Compatibility" refers to compatibility with existing Haskell -- implementations, which treat Char values like octets. RawPathname is -- there to avoid an octet -> string -> octet translation in cases where -- that's undesirable. This is slightly problematic on Win32, where -- pathnames really *are* strings. type Moniker = Pathname String | CompatibilityPathname String | RawPathname [Octet] {- if supported, maybe: | DirectoryEntry Directory String | ResourceFork Moniker | NamedFork String Moniker -} -- * File and channel creation functions -- I still use "lookup" rather than "open" to emphasize that there's an -- irreversible and time-dependent translation going on here. lookupFileRO :: Moniker -> IO File lookupFileRW :: Moniker -> IO File lookupInputChannel :: Moniker -> IO InputChannel lookupOutputChannelAppend :: Moniker -> IO OutputChannel createOutputChannel :: Moniker -> IO OutputChannel -- * File access functions -- | Indicates that a File value will never be used again. Calling -- fRelease is not mandatory, but it assists the implementation in -- closing file handles as early as possible. It is an error to use the -- argument in any way after making this call. fRelease :: File -> IO () -- | Returns a new File value which is identical to the argument except -- that calling fRelease on one does not affect the other. fDup :: File -> IO File -- | Returns True if fRelease has not been called on the File value. fIsValid :: File -> IO Bool -- | Reads from a file to a memory buffer. If the read extends beyond the -- end of the file, the extra buffer space is filled with zeroes and the -- return value is the number of octets which actually came from the file. -- Otherwise the return value is the same as the length argument. fReadBuf :: File -> FilePos -> BlockLength -> Ptr Word8 -> IO BlockLength -- | Writes to a file from a memory buffer. fWriteBuf :: File -> FilePos -> BlockLength -> Ptr Word8 -> IO () -- | Returns the current size of the file. fGetSize :: File -> IO FilePos -- | If the size argument is less than the current file size, the file size -- is reduced, destroying any octets beyond the new end of the file. If the -- size argument is greater than the current file size, the file may or may -- not be increased in length. If it is increased, the contents of the file -- beyond the old end of file are undefined. fSetSize :: File -> FilePos -> IO () fIsReadable :: File -> IO Bool fIsWritable :: File -> IO Bool -- * Layering channels on files -- | Opens an input channel (octet source) which reads from the specified -- file, starting at the specified offset. Effectively fDups the File -- argument, so the original File value may be released at any later time -- without affecting the channel. fInputChannelFrom :: File -> FilePos -> IO InputChannel -- | Opens an output channel (octet source) which writes to the specified -- file, starting at the specified offset. Because input and output -- channels may be buffered, the result of an fRead call on a file region fOutputChannelFrom :: File -> FilePos -> IO OutputChannel -- | Like fInputChannelFrom, but stops after reading the octet which -- immediately precedes the second FilePos argument, or at end of file, -- whichever comes first. fInputChannelFromTo :: File -> FilePos -> FilePos -> IO InputChannel -- * Standard channels stdin :: InputChannel stdout, stderr :: OutputChannel -- * Input channel access functions -- | Indicates that no more octets will be read from the InputChannel. -- It is not necessary to call this function if all available octets -- have already been read. icRelease :: InputChannel -> IO () icGet :: InputChannel -> IO Octet icGetBuf :: InputChannel -> Ptr a -> BlockLength -> IO BlockLength icAtEnd :: InputChannel -> IO Bool -- | Returns the File associated with its argument, if any. May fail even -- on a channel created with fInputChannel, since the channel is permitted -- to release its internal File value on reaching end-of-input. May succeed -- on a channel not created with fInputChannel, such as stdin. The caller -- is responsible for releasing the returned File. icTellFile :: InputChannel -> IO Maybe File -- | Returns the current read offset in the underlying file, if any. May -- succeed even if icTellFile fails. Always succeeds if the channel was -- created on top of a File. icTellPos :: InputChannel -> IO (Maybe FilePos) icPeek :: InputChannel -> IO Octet icReady :: InputChannel -> IO Bool icGetBuffering :: InputChannel -> IO BufferMode icSetBuffering :: InputChannel -> BufferMode -> IO () icIsTerminal :: InputChannel -> IO Bool -- | Read an InputChannel lazily as a list of octets. It is an error to -- read from the InputChannel directly after this is called. icLazyGetContents :: InputChannel -> IO [Octet] -- * Output channel access functions ocRelease :: OutputChannel -> IO () ocPut :: OutputChannel -> Octet -> IO () ocPuts :: OutputChannel -> [Octet] -> IO () ocPutBuf :: OutputChannel -> Ptr a -> BlockLength -> IO () ocTellFile :: OutputChannel -> IO (Maybe File) ocTellPos :: OutputChannel -> IO (Maybe FilePos) ocGetBuffering :: OutputChannel -> IO BufferMode ocSetBuffering :: OutputChannel -> BufferMode -> IO () ocFlush :: OutputChannel -> IO () ocIsTerminal :: OutputChannel -> IO Bool -- Ben

1 0

New Haskell and FP merchandise logos for review
by Fritz K Ruehr 31 Jul '03

31 Jul '03

John Peterson recently handed over control of the Haskell Merchandise area of haskell.org to me and, in celebration, I've created a bunch of provisional designs for new Haskell, FP and types-related "swag". The logos include the original and new haskell.org logos and about 15 others, designed around traditional T-shirt logo aesthetics (puns, strident dogmatic posturings and mild sexual suggestion). I've tried to represent a range of Haskell community viewpoints, from pure/theory to systems/"hacker". (A couple of the designs will likely appeal to a very limited audience, for example the catamorphism evaluation law expressed with *real* banana brackets ... ). For now the logos are just graphic files in PNG format, available from this URL, linked from thumbnails and accompanied by a few comments: <http://www.willamette.edu/~fruehr/logos/intro.html> My intent is to convert them, as called for, into products on the CafePress site and link them in via the Haskell Merchandise page (see the docs at the URL for more details). I'm not sure exactly what the protocol for selecting logo/product combinations should be, but for now I will just take e-mails from people (if this becomes laborious maybe a Wiki page would be better). I am open to suggestions for changes or additions, or to other peoples' designs. Note that neither I nor haskell.org will make any profit, but there is some possibility of using a modest charge to off-set a more convenient CafePress set-up (again, go to the URL for details). -- Fritz Ruehr PS: replies to haskell-cafe please! PPS to whomever requested the new haskell.org logo: sorry for the delay, I will consider your request as first in the queue and open a new store presently. But write me with your specific interest for a product (i.e., white t-shirt, grey t-shirt, tank-top, etc.).

2 1