[Haskell-cafe] Simple HTTP lib for Windows?
I'd like to write a very simple Haskell script that when given a URL, looks up the page, and returns a string of HTML. I don't see an HTTP library in the standard libs, and the one in Hackage requires Windows machines have GHC and MinGW to be installed and in the PATH. Is there a simple way to get the contents of a webpage using Haskell on a Windows box? Thanks, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Article review: Category Theory
I wrote: It is nice that you gave proofs of the >>= monad laws in terms of the join monad laws... Maybe give the proofs in the opposite direction as an exercise. David House wrote: Yes, they are, here are my proofs:... I've added the suggested exercise. Alas, too late - you've published the solutions! :) Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Article review: Category Theory
On 17/01/07, Brian Hulley <[EMAIL PROTECTED]> wrote: Ok I understand it now, because David has just clarified offlist the thing that puzzled me about the diagram: namely that morphisms have an individuality of their own that isn't fully determined by the lhs and rhs of the arrow like the relationship between a function and its type. I've written a bit more, moved things around and just generally made the intro section clearer. Your troubles have been addressed with an explanatory sentence that gives sin and cos as examples of morphisms with the same source and target objects but that are different. We now deal with composition a bit better too; when we're defining a category we briefly mention composition but the closure under the composition operator is now defined and exemplified alongside the other two laws. Thanks, Brian, for your input, it's been valuable. I hope everything's clear now. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ICFP07 Call for Papers
Call for Papers ICFP 2007: International Conference on Functional Programming Freiburg, Germany, 1-3 October 2007 ICFP 2007 seeks original papers on the art and science of functional programming. Submissions are invited on all topics from principles to practice, from foundations to features, from abstraction to application. The scope includes all languages that encourage functional programming, including both purely applicative and imperative languages, as well as languages with objects and concurrency. Particular topics of interest include * Applications and domain-specific languages: systems programming; scientific and numerical computing; symbolic computing; artificial intelligence; databases; graphical user interfaces; multimedia programming; scripting; system administration; distributed-systems and web programming; XML processing; security * Foundations: formal semantics; lambda calculus; type theory; monads; continuations; control; state; effects * Design: algorithms and data structures; modules; type systems; concurrency and distribution; components and composition; relations to object-oriented or logic programming * Implementation: abstract machines; compile-time and run-time optimization; just-in-time compilers; memory management; parallel hardware; interfaces to foreign functions, services, components or low-level machine resources * Transformation and analysis: abstract interpretation; partial evaluation; program transformation * Software-development techniques: design patterns; specification; verification; validation; debugging; test generation; tracing; profiling * Practice and experience: novel results drawn from experience in education or industry * Functional pearls: elegant, instructive examples of functional programming A functional pearl need not report original research results, but it must be instructive, elegant, and fun. ICFP 2007 also seeks Experience Reports. An Experience Report is a short paper (2-4 pages) which need not present novel results, but which should provide evidence that functional programming really works or should describe obstacles that prevented it from working. Detailed guidelines appear below. What's new this year? ~ Experienced ICFP authors may want to pay special attention to the points below, which are new this year. * Double-blind review * Author-date citations * Supplemental material in a separate document, not appended to the main text * Morning deadline (but equivalent to late afternoon or early evening in many time zones of interest) * Experience Reports Instructions for authors By 11:00 AM Friday, 6 April 2007, Samoan time, submit an abstract of at most 300 words and a full paper of at most 12 pages or an Experience Report of at most 4 pages. Submissions will be accepted electronically, at a URL to be named later. The deadline is set at Samoan time, so if your submission is in by 11:00 AM Friday according to your local time, wherever you are, the submission will be on time. The world clock at http://www.timeanddate.com/worldclock/fixedtime.html?month=4&day=6&year=2007&hour=11&min=0&sec=0&p1=282 can give you the equivalent in your local time, e.g., 3:00 PM Friday in Portland, 6:00 PM Friday in Boston, and midnight Friday in Freiburg. The deadline is firm. Your submission should explain its contributions in both general and technical terms, clearly identifying what has been accomplished, explaining why it is significant, and comparing it with previous work. Make the technical content understandable to a broad audience. Each submission must adhere to SIGPLAN's republication policy, which appears in full at http://www.acm.org/sigplan/republicationpolicy.htm. The policy means in part that your paper may not have already appeared in a journal, conference, or workshop with published proceedings; that you may not submit substantially the same work simultaneously to ICFP and to another venue; and that your submission must discuss any closely related material, including your own, that was previously accepted at a journal, conference, or workshop with or without published proceedings. Full details of the policy are available at the SIGPLAN site. If you are in any doubt about whether this policy applies to your paper, either consult the program chair in advance or notify the chair when you submit. To do otherwise risks summary rejection of your submission. If your submission is accepted, you must assign copyright to ACM. Proceedings will be published by the ACM Press. Double-blind review ~~~ To increase confidence in the fairness and objectivity of the reviewing process, reviewing will be double blind. Make it possible for reviewers to evaluate your paper without having to know who you are. It should suffice to omit your names from
[Haskell-cafe] Re: IO in lists
Hi, It's probably eaiser to work with normal lists: listChars :: IO [Char] listChars = do c <- getChar if c == 'q' then return c else liftM2 (:) (return c) listChars But that is not lazy any more, is it? The idea of the OT was, I think, that he can use the first elements of the list even before the last one was entered. But it's possible to make it lazy again using System.IO.Unsafe.unsafeInterleaveIO: listChars :: IO [Char] listChars = unsafeInterleaveIO $ do c <- getChar if c == 'q' then return c else liftM2 (:) (return c) listChars Regards, Martin. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Article review: Category Theory
On 17/01/07, Yitzchak Gale <[EMAIL PROTECTED]> wrote:
A few semicolons were missing in the do blocks
of the Points-free style/Do-block style table. I
fixed that. I think it would be simpler without the
do{} around f x and m - are you sure it's needed?
They're not needed, but I think it makes it more symmetric. It also
clarifies that we're talking about moving things around within
do-blocks; one could potentially have statements before and after the
given statements. There isn't much of a case either way, I guess.
You wrote: "category theory doesn't have a notion
of 'polymorphism'". Well, of course it does - after
all, this is "abstract nonsense", it has a notion
of *everything*. But obviously we don't want to
get into that complexity here. Here is a first
attempt at a re-write of that paragraph:
Note: The function id in Haskell is 'polymorphic' -
it can have many different types as its domain
and range. But morphisms in category theory
are by definition 'monomorphic' - each morphism
has one specific object as its domain and one
specific object as its range. A polymorphic
Haskell function can be made monomorphic by
specifying its type, so it would be more
precise if we said that the Haskell function
corresponding to idA is (id :: A -> A).
However, for simplicity, we will ignore this
distinction when the meaning is clear.
I've changed the paragraph to almost what you said, modulo a few
tweaks to make it sit nicer with the rest of the article.
It is nice that you gave proofs of the >>= monad
laws in terms of the join monad laws. I think
you should state more clearly that the two
sets of laws are completely equivalent.
(Aren't they?) Maybe give the proofs in the opposite
direction as an exercise.
Yes, they are, here are my proofs:
join . fmap join = join . join
join . fmap join
(\m -> m >>= id) . fmap (\m -> m >>= id)
\m -> (m >>= (\n -> return (n >>= id))) >>= id
\m -> m >>= (\n -> return (n >>= id) >>= id)
\m -> m >>= (\n -> id (n >>= id))
\m -> m >>= (\n -> n >>= id)
\m -> m >>= (\n -> id n >>= id)
\m -> (m >>= id) >>= id
\m -> join m >>= id
\m -> join (join m)
join . join
join . fmap return = id
join . fmap return
(\m -> m >>= id) . (\m -> m >>= return . return)
\m -> (m >>= return . return) >>= id
\m -> m >>= (\n -> return (return n) >>= id)
\m -> m >>= (\n -> id (return n))
\m -> m >>= (\n -> return n)
\m -> m >>= return
\m -> m
id
join . return = id
join . return
(\m -> m >>= id) . (\m -> return m)
\m -> return m >>= id
\m -> id m
id
return . f = fmap f . return
return . f
(\x -> fmap f x) . return
\x -> fmap f (return x)
\x -> return x >>= return . f
\x -> (return . f) x
return . f
join . fmap (fmap f) = fmap f . join
join . fmap (fmap f)
(\m -> m >>= id) . (\m -> m >>= return . (\n -> n >>= return . f))
\m -> (m >>= return . fmap f) >>= id
\m -> (m >>= \x -> return (fmap f x)) >>= id
\m -> m >>= (\x -> return (fmap f x) >>= id)
\m -> m >>= (\x -> id (fmap f x))
\m -> m >>= (\x -> fmap f x)
\m -> m >>= (\x -> x >>= return . f)
\m -> m >>= (\x -> id x >>= return . f)
\m -> (m >>= id) >>= return . f
(\m -> m >>= id) >>= return . f
fmap f . (\m -> m >>= id)
fmap f . join
I've added the suggested exercise.
--
-David House, [EMAIL PROTECTED]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Article review: Category Theory
Yitzchak Gale wrote: David House wrote: I've added a bit more explanation, so it may now be palatable. It is quite a hard exercise, though, perhaps it shouldn't come so early on. In my opinion, it is now much more clear. And it is a very instructive example. If people still find it too hard, you could add the additional hint: Keep in mind that there are no morphisms other than the ones shown in the diagram. Ok I understand it now, because David has just clarified offlist the thing that puzzled me about the diagram: namely that morphisms have an individuality of their own that isn't fully determined by the lhs and rhs of the arrow like the relationship between a function and its type. Brian. -- http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] type and class problems compiling code on GHC 6.6
Dear Haskellers,
I had used some code which worked fine on GHC 6.4 and now it dont compile
on GHC 6.6.
Can anyone please give me some workarounds and/or explanations about these 2
errors?
instance InfoKind a b => InfoKind (Maybe a) b where
blank = Nothing
check n _ Nothing = ["No info value stored with "++n]
check n g (Just a) = check n g a
GHC complains that
Illegal instance declaration for `InfoKind (Maybe a) b'
(the Coverage Condition fails for one of the functional
dependencies)
In the instance declaration for `InfoKind (Maybe a) b'
multiListViewGetTSelections :: MultiListView x () -> IO [x]
multiListViewGetTSelections multiListView =
do { Just ((model, _) :: (Var [x], x -> String)) <-
unsafeObjectGetClientData multiListView
; -- more and more code
}
GHC complains that
A pattern type signature cannot bind scoped type variables `x'
unless the pattern has a rigid type context
In the pattern: (model, _) :: (Var [x], x -> String)
I would really appreciate some help.
Best regards
Miguel Vilaça
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Article review: Category Theory
David House wrote: I've added a bit more explanation, so it may now be palatable. It is quite a hard exercise, though, perhaps it shouldn't come so early on. In my opinion, it is now much more clear. And it is a very instructive example. If people still find it too hard, you could add the additional hint: Keep in mind that there are no morphisms other than the ones shown in the diagram. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Article review: Category Theory
David House wrote:
I've written a chapter for the Wikibook that attempts to teach some
basic Category Theory in a Haskell hacker-friendly fashion.
http://en.wikibooks.org/wiki/Haskell/Category_theory
Very, very nice!
A few comments:
A few semicolons were missing in the do blocks
of the Points-free style/Do-block style table. I
fixed that. I think it would be simpler without the
do{} around f x and m - are you sure it's needed?
You wrote: "category theory doesn't have a notion
of 'polymorphism'". Well, of course it does - after
all, this is "abstract nonsense", it has a notion
of *everything*. But obviously we don't want to
get into that complexity here. Here is a first
attempt at a re-write of that paragraph:
Note: The function id in Haskell is 'polymorphic' -
it can have many different types as its domain
and range. But morphisms in category theory
are by definition 'monomorphic' - each morphism
has one specific object as its domain and one
specific object as its range. A polymorphic
Haskell function can be made monomorphic by
specifying its type, so it would be more
precise if we said that the Haskell function
corresponding to idA is (id :: A -> A).
However, for simplicity, we will ignore this
distinction when the meaning is clear.
It is nice that you gave proofs of the >>= monad
laws in terms of the join monad laws. I think
you should state more clearly that the two
sets of laws are completely equivalent.
(Aren't they?) Maybe give the proofs in the opposite
direction as an exercise.
Regards,
Yitz
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Article review: Category Theory
On 17/01/07, Brian Hulley <[EMAIL PROTECTED]> wrote: I still have no idea what the solution to the second exercise is though. I've added a bit more explanation, so it may now be palatable. It is quite a hard exercise, though, perhaps it shouldn't come so early on. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Default (or empty) values
> "Pedro" == Pedro Baltazar Vasconcelos <[EMAIL PROTECTED]> writes: Pedro> On Wed, 17 Jan 2007 16:57:54 +0300 Pedro> Max Vasin <[EMAIL PROTECTED]> wrote: > It does not enforce presence of required fields at type level. Also it >> does not enforce that fields pages and year are Int. And I want >> to move as much checks to compile time as possible. Pedro> You can combine the two solutions: a product-type of Pedro> required fields plus list of optional fields. You're right Pedro> that you lose the typing constraints on fields. I probabily Pedro> woudn't bother, but you might be able to recover that with Pedro> the type-classes or GADTs (?). I have only a very basic understading of what GADTs are :-( Pedro> But more important: it sounds to me like you have two Pedro> conflicting requirements: one the one hand you want to have Pedro> required fields (presumability those that were not Maybe Pedro> types) but on the other hand you want an "empty" book Pedro> (i.e. with "" for title, etc.). I want to get as strict type checking as possible while writing as little code handling Book as possible. The empty value is needed only to start with when analising external represenation. And as suggested by Colin DeVilbiss and Henning Thielemann it will be better to use undefined for required fields. -- WBR, Max Vasin. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Default (or empty) values
> "Henning" == Henning Thielemann <[EMAIL PROTECTED]> writes:
Henning> On Wed, 17 Jan 2007, Max Vasin wrote:
> Hello all!
>>
>> Let
>>
>> > data Book = Book { > authors :: [String], > title :: String,
>> > editor :: Maybe String, > edition :: Maybe String, > volume
>> :: Maybe (Int, Int), -- e.g. volume 1 of 3 > publisher ::
>> String, > year :: Int, > pages :: Int
>> > }
>>
>> and
>>
>> > convertBook :: Map String String -- a map from field names to
>> values (string representation) > -> Maybe Book
>>
>> convertBook takes info about book from some external source
>> (e.g. a BibTeX database) and returns Just book value or Nothing
>> (if convertion failed). Fields of the Book datatype which are
>> not (Maybe a) are required to be present.
>>
>> convertBook looks like
>>
>> > convertBook = (rq "title" (\b v -> b { title = v }) <.> > rq
>> "publisher" (\b v -> b { publisher = v }) <.> > ... ) (Just $
>> Book [] "" Nothing Nothing Nothing "" 0 0)
>>
>> I don't like the `(Just $ Book [] "" Nothing Nothing Nothing ""
>> 0 0)' part, I would prefer instead someting like `empty ::
>> Book'. So I define
>>
>> > class Empty e where > empty :: e
>>
>> But still I have to emplement instances by hand. There are a
>> number of approaches to automatically derive instances (TH,
>> generic classes in GHC, drift). What would you recommend using
>> in this case? Or may be it would be better to drop out Empty
>> and use something else?
Henning> Using a record with named fields is good style, as you
Henning> pointed out later. Stick to it! Why do you need a type
Henning> class? What about simply
Henning> empty :: Book empty = Book [] "" Nothing Nothing Nothing
Henning> "" 0 0
Well the type class is not necessary, a TH function generating
an empty value for given datatype. OTOH convertBook can be
rewritten (using type class) as:
> convertBook = (rq "title" (\b v -> b { title = v }) <.>
>rq "publisher" (\b v -> b { publisher = v }) <.>
>... )
and it will be used like 'convertBook empty'. I like this way more
since convertBook looks more declarative.
Henning> For updates empty { title = "new title" } is perfectly
Henning> ok.
Henning> You can also let undefined fields undefined. In
Henning> Book {}
This will be enough if there were no optional fields.
--
WBR,
Max Vasin.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Default (or empty) values
> "Colin" == Colin DeVilbiss <[EMAIL PROTECTED]> writes: Colin> On 1/17/07, Max Vasin <[EMAIL PROTECTED]> wrote: >> Fields of the Book datatype which are not (Maybe a) are >> required to be present. Colin> This doesn't actually answer your question, but if those Colin> fields are really required and you want to avoid the Colin> possibility of a "default" value sneaking into the program Colin> through a bug, you may prefer to use undefined instead of a Colin> non-bottom value for the required fields. That is, Colin> Book undefined undefined Nothing Nothing Nothing undefined Colin> undefined undefined Hmm that's interesting... Colin> (lots of typing, but if a bug slips in and you get a Colin> partially-defined book into the guts of the program, you'll Colin> die instead of silently using invalid data.) >> > class Empty e where > empty :: e >> >> But still I have to emplement instances by hand. Colin> What would the strategy be here for automatically defining Colin> the instances? For example, what are the Empty instances Colin> for Colin> data Foo = Bar | Baz | Quux data Foo2 = Bar2 Int | Baz2 Colin> String | Quux2 (Maybe String) In my program (a BibTeX analog) Empty instances will be defined for datatypes representing bibliography entries which will have only one value constructor (records can't be used with newtype AFIAK). So for > data Foo = Foo t1 t2 ... tN > instance Empty Foo where > empty = Foo (empty :: t1) (empty :: t2) ... (empty :: tN) >> Or may be it would be better to drop out Empty and use >> something else? Colin> I see no inherent problem with Empty, just with the Colin> automated instantiation. Then again, I'd be tempted to Colin> wait to define Empty until I saw the second or third Colin> instance of its use. There will be datatypes representing books, articles, thesis, reports, etc. -- WBR, Max Vasin. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Default (or empty) values
On Wed, 17 Jan 2007 16:57:54 +0300 Max Vasin <[EMAIL PROTECTED]> wrote: > It does not enforce presence of required fields at type level. Also it > does not enforce that fields pages and year are Int. And I want to > move as much checks to compile time as possible. You can combine the two solutions: a product-type of required fields plus list of optional fields. You're right that you lose the typing constraints on fields. I probabily woudn't bother, but you might be able to recover that with the type-classes or GADTs (?). But more important: it sounds to me like you have two conflicting requirements: one the one hand you want to have required fields (presumability those that were not Maybe types) but on the other hand you want an "empty" book (i.e. with "" for title, etc.). Regards, Pedro ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Default (or empty) values
On Wed, 17 Jan 2007, Max Vasin wrote:
> Hello all!
>
> Let
>
> > data Book = Book {
> > authors :: [String],
> > title :: String,
> > editor:: Maybe String,
> > edition :: Maybe String,
> > volume:: Maybe (Int, Int), -- e.g. volume 1 of 3
> > publisher :: String,
> > year :: Int,
> > pages :: Int
> > }
>
> and
>
> > convertBook :: Map String String -- a map from field names to values
> > (string representation)
> > -> Maybe Book
>
> convertBook takes info about book from some external source (e.g. a BibTeX
> database) and returns
> Just book value or Nothing (if convertion failed). Fields of the Book
> datatype which are not (Maybe a)
> are required to be present.
>
> convertBook looks like
>
> > convertBook = (rq "title" (\b v -> b { title = v }) <.>
> >rq "publisher" (\b v -> b { publisher = v }) <.>
> >... ) (Just $ Book [] "" Nothing Nothing Nothing "" 0 0)
>
> I don't like the `(Just $ Book [] "" Nothing Nothing Nothing "" 0 0)' part, I
> would prefer
> instead someting like `empty :: Book'. So I define
>
> > class Empty e where
> > empty :: e
>
> But still I have to emplement instances by hand. There are a number of
> approaches to automatically
> derive instances (TH, generic classes in GHC, drift). What would you
> recommend using in this case?
> Or may be it would be better to drop out Empty and use something else?
Using a record with named fields is good style, as you pointed out later.
Stick to it!
Why do you need a type class? What about simply
empty :: Book
empty = Book [] "" Nothing Nothing Nothing "" 0 0
For updates
empty { title = "new title" }
is perfectly ok.
You can also let undefined fields undefined. In
Book {}
all fields are undefined.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Article review: Category Theory
Brian Hulley wrote: David House wrote: http://en.wikibooks.org/wiki/Haskell/Category_theory But in the second exercise in the intro it's clear that function composition is not associative. Apologies. I got totally confused with the way function composition is back to front etc. I still have no idea what the solution to the second exercise is though. Thanks, Brian. -- http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Default (or empty) values
On 1/17/07, Max Vasin <[EMAIL PROTECTED]> wrote: Fields of the Book datatype which are not (Maybe a) are required to be present. This doesn't actually answer your question, but if those fields are really required and you want to avoid the possibility of a "default" value sneaking into the program through a bug, you may prefer to use undefined instead of a non-bottom value for the required fields. That is, Book undefined undefined Nothing Nothing Nothing undefined undefined undefined (lots of typing, but if a bug slips in and you get a partially-defined book into the guts of the program, you'll die instead of silently using invalid data.) > class Empty e where > empty :: e But still I have to emplement instances by hand. What would the strategy be here for automatically defining the instances? For example, what are the Empty instances for data Foo = Bar | Baz | Quux data Foo2 = Bar2 Int | Baz2 String | Quux2 (Maybe String) Or may be it would be better to drop out Empty and use something else? I see no inherent problem with Empty, just with the automated instantiation. Then again, I'd be tempted to wait to define Empty until I saw the second or third instance of its use. Colin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Article review: Category Theory
David House wrote: http://en.wikibooks.org/wiki/Haskell/Category_theory I'd love comments from newcomers and experts alike regarding my approach, the content, improvements and so on. Of course, it's on the wikibook, so if you have anything to add (that's not _too_ substantial otherwise I'd recommend discussion first) then go ahead. Hi David, In the introduction you say that Set is the category of all sets with morphisms as standard functions and composition as standard function composition. But in the second exercise in the intro it's clear that function composition is not associative. Therefore surely this means everything based on function composition can't be a category? Also, why does this exercise contain redundant morphisms (I hope I'm not spoiling it for anyone by saying this or perhaps I've just totally misunderstood everything)? Thanks, Brian. -- http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Default (or empty) values
> "Pedro" == Pedro Baltazar Vasconcelos <[EMAIL PROTECTED]> writes:
Pedro> On Wed, 17 Jan 2007 15:58:04 +0300
Pedro> Max Vasin <[EMAIL PROTECTED]> wrote:
> Hello all!
>>
>> Let
>>
>> > data Book = Book { > authors :: [String], > title :: String,
>> > editor :: Maybe String, > edition :: Maybe String, > volume
>> :: Maybe (Int, Int), -- e.g. volume 1 of 3 > publisher ::
>> String, > year :: Int, > pages :: Int
>> > }
> One suggestion: why not make the Book type more general, e.g. a list of
> labeled fields:
>> data Label = Author | Title | Editor | type Field =
>> String newtype Book = Book [(Label,Field)]
Pedro> The idea is that e.g. multiple authors would be represented
Pedro> by multiple entries with an "Author" label and optional
Pedro> fields can be omitted. Then the empty book is simply
It does not enforce presence of required fields at type level. Also it
does not enforce that fields pages and year are Int. And I want to
move as much checks to compile time as possible.
--
WBR,
Max Vasin.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Default (or empty) values
On Wed, 17 Jan 2007 15:58:04 +0300
Max Vasin <[EMAIL PROTECTED]> wrote:
> Hello all!
>
> Let
>
> > data Book = Book {
> > authors :: [String],
> > title :: String,
> > editor:: Maybe String,
> > edition :: Maybe String,
> > volume:: Maybe (Int, Int), -- e.g. volume 1 of 3
> > publisher :: String,
> > year :: Int,
> > pages :: Int
> > }
One suggestion: why not make the Book type more general, e.g. a list of labeled
fields:
> data Label = Author | Title | Editor |
> type Field = String
> newtype Book = Book [(Label,Field)]
The idea is that e.g. multiple authors would be represented by multiple entries
with an "Author" label and optional fields can be omitted.
Then the empty book is simply
> empty = Book []
You might also find that this makes the processing of fields more uniform and
easier to extend.
Best regards,
Pedro Vasconcelos.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Default (or empty) values
Hello all!
Let
> data Book = Book {
> authors :: [String],
> title :: String,
> editor:: Maybe String,
> edition :: Maybe String,
> volume:: Maybe (Int, Int), -- e.g. volume 1 of 3
> publisher :: String,
> year :: Int,
> pages :: Int
> }
and
> convertBook :: Map String String -- a map from field names to values (string
> representation)
> -> Maybe Book
convertBook takes info about book from some external source (e.g. a BibTeX
database) and returns
Just book value or Nothing (if convertion failed). Fields of the Book datatype
which are not (Maybe a)
are required to be present.
convertBook looks like
> convertBook = (rq "title" (\b v -> b { title = v }) <.>
>rq "publisher" (\b v -> b { publisher = v }) <.>
>... ) (Just $ Book [] "" Nothing Nothing Nothing "" 0 0)
I don't like the `(Just $ Book [] "" Nothing Nothing Nothing "" 0 0)' part, I
would prefer
instead someting like `empty :: Book'. So I define
> class Empty e where
> empty :: e
But still I have to emplement instances by hand. There are a number of
approaches to automatically
derive instances (TH, generic classes in GHC, drift). What would you recommend
using in this case?
Or may be it would be better to drop out Empty and use something else?
TIA
--
WBR,
Max Vasin.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO in lists
G'day all. Quoting Yitzchak Gale <[EMAIL PROTECTED]>: > What can be done to get an improved list transformer > into MTL? Not sure. But a lot of people use mine: http://sigcomp.srmr.co.uk/~rjp/Nondet.hs (My darcs repository is down at the moment, unfortunately.) Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO in lists
I wrote: But the list monad [] is not a transformer, so you can't lift in it, even if the contained type happens also to be a monad. Andrew Bromage wrote: ListT is also not a transformer. True, unfortunately. But it does provide MonadTrans and MonadIO instances that solve problems like this in practice. What can be done to get an improved list transformer into MTL? See here for details: http://www.haskell.org/hawiki/ListTDoneRight Can someone with permissions on the new wiki please get this important page moved over? Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
