Re: [Haskell-cafe] How to catch exception within the Get monad (the Binary package)

[Victor Gorokhov]

> If however something goes wrong, and prs fails, the whole function
> fails (error is thrown). Since [a] (result of decoding) is a lazy
> list, actual exception may be thrown at any moment the list is being
> processed, and exception handler may not be properly set.

> True -> return (reverse a)
> False -> many' (s:a)

Lazy lists are built in left to right order, but Yours is right to left.


> Is there any way to catch/detect failures inside the Get monad?
lookAhead, lookAheadM, etc
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Restricted type classes

[Ivan Lazar Miljenovic]

On 5 September 2010 03:34, David Menendez  wrote:
> On Fri, Sep 3, 2010 at 8:23 AM, John Lato  wrote:
>> Do you have a kind * implementation of Foldable?  I'd be interested in
>> seeing it, because I was unable to create a usable implementation (based
>> upon the RMonad scheme) on my last attempt.
>
> I always figured it would look something like:
>
> class Foldable f where
>  type Elem f :: *
>  foldMap :: Monoid m => (Elem f -> m) -> f -> m
>
> with the usual definitions for foldr, foldl, etc.
>
>> +1 for using the proper constraints, and especially for bringing over
>> Pointed (and anything else that applies).
>
> What's the argument for Pointed? Are there many types which are
> instances of Pointed but not Applicative? Are there many algorithms
> which require Pointed but not Applicative?

Presumably just that it's another possible abstraction.

-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] How to catch exception within the Get monad (the Binary package)

[Dimitry Golubovsky]

Hi,

The following function* is supposed to decode a list of some
serialized objects following each other in a lazy Bytestring:

many :: Get a -> Get [a]

many prs = many' [] where
  many' a = do
s <- prs
r <- isEmpty
case r of
  True -> return (reverse a)
  False -> many' (s:a)

prs is a "parser" to decode a single object.

If however something goes wrong, and prs fails, the whole function
fails (error is thrown). Since [a] (result of decoding) is a lazy
list, actual exception may be thrown at any moment the list is being
processed, and exception handler may not be properly set.

Is there any way to catch/detect failures inside the Get monad? It is
not an instance of MonadError, so catchError does not work.

Ideally, the function would keep decoding as long as it is possible,
and upon the first failure of the parser, return whatever has been
decoded.

Thanks.

---
* there is one intentional inaccuracy in this function: isEmpty is
called _after_ decoding is tried, so an empty ByteString would cause
parser failure and exception right away; this is used as a test case.

-- 
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] ANNOUNCE: Haddock version 2.8.0

[John Millikin]

On Sat, Sep 4, 2010 at 14:46, Jeremy Shaw  wrote:
> So the choices are:
>
>  1. only focus on getting the xhtml 1.0 served as application/xml
> working correctly, and ie users get nothing..
>
>  2. create xhtml 1.0 that would work correctly if served as
> application/xml, but serve it as text/html, and ignore that fact that
> some stuff might not be rendering correctly when treated as text/html.
>
>  3. create xhtml documents which render correctly whether served as
> application/xml or text/html, but then only serve them as text/html
> anyway
>
>  4. forget about how the xhtml documents render as application/xml,
> and only focus on how they render as text/html.

5. Do as my patch does; default to HTML 4 (supported by all browsers),
and allow users to generate correct XHTML if they want/need to.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0

[Jeremy Shaw]

On Sat, Sep 4, 2010 at 8:47 PM, Brandon S Allbery KF8NH
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 9/4/10 21:27 , Jeremy Shaw wrote:
>> Here is why I am dubious. Browsers that support html and xhtml have
>> two different code paths for rending html vs xhtml. The *only* way to
>> select which code path is taken is by specifying the mime-type when
>> you serve it. Either application/xml or text/html.
>
> XHTML starts with a .  You've just asserted that no browser is
> capable of noticing that and responding to it even though it's right at the
> start, while somehow managing to support  tags buried
> in the  that can force it to go back and start from scratch.  Really?

Browsers *could* look at the doctype to pick the path. But they  *do
not*. What they look at is the http header that is sent before the
response body is even parsed. (Obviously, things are a little
different if it is reading a file from the disk).

For example, if you do, curl -v http://www.w3.org/, you will see this:

< Content-Type: text/html; charset=utf-8
<
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en">

Where the, Content-Type: text/html; charset=utf-8, is an HTTP response
header. Rather than second guess what the response body is, the
browsers consider that content-type header to be authoritative over
the  tag.
(http://www.dev-archive.net/articles/xhtml.html#types)

If you open that url in firefox, and go to, Tools > Page Info, it will tell you:

Type: text/html
Render Mode: Standards Compliance Mode
Encoding: utf-8

Meaning that even though it has the xhtml doctype (clearly shown in
the curl output), firefox is only paying attention to the text/html
content type.

If you visit this page, http://www.echoofeden.com/htmlTests/xhtmlFix/index.xhtml

Then it shows:

Type: application/xhtml+xml

Or, perhaps more relevant is this page:
http://www.schillmania.com/content/entries/2004/10/24/application-xhtml+xml/invalid-xml.xml

Which contains an xml error. You can tell it is using the XML
rendering path, because it correctly gives an error instead of trying
to guess what you mean and rendering the page anyway.

Now, in the case of firefox. If you serve an xhtml with the DOCTYPE as
text/html, it will trigger the use of the text/html renderer. If the
DOCTYPE is xhtml 1.0 transition, then the browser will sniff that and
use 'almost standards' mode. Which is exactly like the normal
text/html standards mode except for one thing: the layout of images
inside table cells is handled as they are in Gecko's "quirks" mode.
(https://developer.mozilla.org/en/Gecko's_"Almost_Standards"_Mode).

Everything I have ever read says that browsers only look at the
content-type header to choose html vs xhtml rendering. And the
supporting evidence seems to indicate that is true. If you have
contrary evidence I would be glad to hear it. It's really difficult to
find reliable information on this topic.

- jeremy



>  Or have we all been imagining the latter for the past, oh, 15 or so years?
>  (Mozilla had a serious bug relating to that restart for years; I assure you
> it's not a fantasy.)
>
> I wouldn't be surprised if HTML and XHTML ultimately follow different
> rendering paths --- but your assertions are raising red flags and smell
> suspiciously like ideology taking offense at reality not automatically
> constraining itself to fit in its assigned pigeonhole.
>
> - --
> brandon s. allbery     [linux,solaris,freebsd,perl]      allb...@kf8nh.com
> system administrator  [openafs,heimdal,too many hats]  allb...@ece.cmu.edu
> electrical and computer engineering, carnegie mellon university      KF8NH
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.10 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkyC9qsACgkQIn7hlCsL25U8uACfdDA4RLUv5LedObrIaO4DpQE1
> 0CMAnj5ntJ6dhRju5sCw7IGfor68Aaa4
> =TaCL
> -END PGP SIGNATURE-
> ___
> 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] ANNOUNCE: Haddock version 2.8.0

[Brandon S Allbery KF8NH]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 9/4/10 21:27 , Jeremy Shaw wrote:
> Here is why I am dubious. Browsers that support html and xhtml have
> two different code paths for rending html vs xhtml. The *only* way to
> select which code path is taken is by specifying the mime-type when
> you serve it. Either application/xml or text/html.

XHTML starts with a .  You've just asserted that no browser is
capable of noticing that and responding to it even though it's right at the
start, while somehow managing to support  tags buried
in the  that can force it to go back and start from scratch.  Really?
 Or have we all been imagining the latter for the past, oh, 15 or so years?
 (Mozilla had a serious bug relating to that restart for years; I assure you
it's not a fantasy.)

I wouldn't be surprised if HTML and XHTML ultimately follow different
rendering paths --- but your assertions are raising red flags and smell
suspiciously like ideology taking offense at reality not automatically
constraining itself to fit in its assigned pigeonhole.

- -- 
brandon s. allbery [linux,solaris,freebsd,perl]  allb...@kf8nh.com
system administrator  [openafs,heimdal,too many hats]  allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon university  KF8NH
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyC9qsACgkQIn7hlCsL25U8uACfdDA4RLUv5LedObrIaO4DpQE1
0CMAnj5ntJ6dhRju5sCw7IGfor68Aaa4
=TaCL
-END PGP SIGNATURE-
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0

[Jeremy Shaw]

On Thu, Sep 2, 2010 at 11:14 PM, Mark Lentczner  wrote:
> I am well aware of the differences between HTML and XHTML.
>
> I choose to switch Haddock's output from HTML to XHTML mostly because I have 
> found the consistency of rendering cross-browser to be greater and easier to 
> achieve with XHTML. I'm not alone in this opinion: Many well respected web 
> design authorities have promoted, and publish their own sites, in XHTML.[1] 
> Even Microsoft's own developer web site uses it[2]!

I am very glad for the new CSS based layout! Thanks!

I am very dubious that switching from HTML to XHTML makes anything
more consistent. If you have a counter example I would love to see it,
because this is an issue that affects my daily work.

Here is why I am dubious. Browsers that support html and xhtml have
two different code paths for rending html vs xhtml. The *only* way to
select which code path is taken is by specifying the mime-type when
you serve it. Either application/xml or text/html.

So, if you take xhtml and serve it as text/html, then the browser will
treat it as html and send it to the html code rendering path. In other
words, it will send it down a code path that knows nothing about
xhtml.

The reason it works at all is because browsers do their darnest to
make it render. So in xhtml you might have a tag like:

 

Which, in xhtml, is short for .

When you send it down the html path, it the html render will see it as:

 

That is, it will see it as the normal  tag with a bogus attribute named /.

Now, perhaps you can understand why I am dubious? Whether or not you
send html or xhtml, it is being rendered by the same code that only
understands html. So it is hard to see how adding bogus attributes
like / to elements is going to improve cross browser compatibility.
You are basically saying that if you add bogus markup to your html
that the browser ignores, it is works more reliably than producing
valid html. The fact that the bogus markup happens to make it valid
xhtml is unimportant, because the code path knows nothing of xhtml
anyway.

If you converted the current code from xhtml to html, and anything
changes in the rendering, I, for one, will be shocked, and very
curious about why that happened.

Also, if you plan to eventually migrate to the x/html 5, that spec says:

 "generally speaking, authors are discouraged from trying to use XML on the Web"

Since the Web Hypertext Application Technology Working Group is full
of people that actually develop browsers, I think their opinion
carries some weight ;)

Anyway, I expect the use of xhtml (served as text/html) instead of
valid html in haddock will have no negative effects for me whatsoever.
But the use of CSS will be a big win! So thanks again for doing that!

- jeremy
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] help me evangelize haskell

[Leonel Fonseca]

Michael:

Hi. I take the risk to mention some facts you might already be working on.

I speculate on three perceptions in the mind of decision makers
related to the adoption of a new language in a shop.
This perceptions can be modified in stages.

First Stage: Awareness. Why programming in that language matters?
Once you can justified this, advance to the following stage.

Haskell is nice, quick to develop, brings tools to make abstractions
at any level and has tools and libraries.
And community support is really awesome!

If you invest more in learning, you can strive to use it  as formal
programming method and earn safety guarantees.

Please, see elsewere for success stories that help you to motivate and
encourage management to test the new alternative.



Second Stage: Small term engagment.

Why your shop should do little investment in trying a new language in
a small but representative project?

Here you can make two arguments to gain support in this stage:

   2.A) The shortcommings of the current tools/languages.

   2.B) Small concept programs of how your current language/tool would
fail where the new one would success.
   You can gain credibility by showing how your new tool could
be short on some aspect that it's well mastered in the old one.
   (i.e. be impartial).

   Someone has already pointed how fragile interpreted programs are.

In this stage you must gain both decision makers and peers recognition
of the problem the shop is facing with the current language versus the
improvements of using the new language.

A project must be acomplished and reviewed, so a decision can be made
over the facts of costs and benefits.


Third Stage: Adoption.

Is it really better to adopt a new language?

At this point you have evidence of possible benefits and costs. And a
decision is made.

Among other costs, please take in account that embracing any new
language in a shop will require formalised (funded, time alloted to,
machines, any other resource) learning  and coaching activities.

Haskell has long learning curve. And you must consider this cost of
being less productive than in your current language.
There's too the risk of hitting walls in a tight-schedule situation.
You can lower this risk of failure if you arrange to have a mentor
(master) who can lead, provide hints to co-workers, discuss approaches
and solve hard issues whenever they appear.

Counter-arguments that you must deal with:

c1) Why not...
 Erlang?
 F#?  See Jon Harrop's claims.
 Scala or Clojure?

c2) Performance predictability.

c3) On the fly script generation and execution.

c4) Will your co-workers be happy of embracing a new paradigm of
solving problems?
  Will type signatures appear as pain or a valuable thing to them?


--
Leonel Fonseca.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] help me evangelize haskell.

[Jason Dagit]

On Sat, Sep 4, 2010 at 5:53 PM, Michael Litchard  wrote:
> I will be going into a situation where there are tasks that have yet
> to be automated, so I will be going after that before re-writing
> anything. But if I can come up with "here's why", there will be less
> eyebrows raised. Thanks for all feedback so far.

Perhaps give this talk:
  http://donsbot.wordpress.com/2010/08/17/practical-haskell/

Jason
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] help me evangelize haskell.

[Michael Litchard]

I will be going into a situation where there are tasks that have yet
to be automated, so I will be going after that before re-writing
anything. But if I can come up with "here's why", there will be less
eyebrows raised. Thanks for all feedback so far.

On Sat, Sep 4, 2010 at 10:21 AM, Gaius Hammond  wrote:
> My usual rhetoric is that one-off, throwaway scripts never are, and not only 
> do they tend to stay around but they take on a life of their own. Today's 
> 10-line file munger is tomorrow's thousand-line ETL batch job on which the 
> business depends for some crucial data - yet the original author is long gone 
> and no-one dares modify in case it breaks. So it is just good sense to use 
> sound practices from the very beginning.
>
>
> One of the features of Perl is that it will try to work even if you make type 
> errors (e.g. give it a scalar in place of a list, or a string instead of an 
> int). One day, however, it WILL fail. Haskell finds these types of bugs 
> upfront, and not when your pager goes off at 3am...
>
>
> Cheers,
>
>
> G
>
> --Original Message--
> From: Michael Litchard
> Sender: haskell-cafe-boun...@haskell.org
> To: haskell-cafe@haskell.org
> Subject: [Haskell-cafe] help me evangelize haskell.
> Sent: Sep 4, 2010 17:38
>
> I'll be starting a new job soon as systems tool guy. The shop is a
> perl shop as far as internal automation tasks go. But I am fortunate
> to not be working with bigots. If they see a better way, they'll take
> to it. So please give me your best arguments in favor of using haskell
> for task automation instead of perl, or awk or any of those scripting
> lanugages.
> ___
> 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] Unnecessarily strict implementations

[Albert Y. C. Lai]

On 10-09-03 06:11 AM, Henning Thielemann wrote:

Yes, something this way. (<) suggests a notion of magnitude for me,
which some orderings do not have.


Like for example -1000 has a larger magnitude than -0.0001, therefore 
you also reject the common ordering -1000 < -0.0001?


http://groups.google.com/group/alt.algebra.help/browse_frm/thread/87ca3963373ddeb5
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0

[Albert Y. C. Lai]

On 10-09-04 05:46 PM, Jeremy Shaw wrote:

Mark suggested that it was easier to achieve multi-browser
compatibility using xhtml instead of html, but I am quite certain he
is mistaken. There are really three different rendering modes found in
browsers:

  1. standards mode
  2. quirks mode
  3. xhtml mode

By serving xhtml content as text/html, he is getting browsers to use
quirks mode instead of standards mode.


No.

https://developer.mozilla.org/en/Mozilla%27s_DOCTYPE_sniffing
http://reference.sitepoint.com/css/doctypesniffing
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0

[Mark Lentczner]

We all seem to understand that there are a complex of issues surrounding the 
HTML and XHTML dialects, doc types, MIME Types, and file extensions. It is a 
tangle of intentions and compatibility issues, and one where experts and 
standards writers admit to practical compromises, which at times are even 
contradictory.

The choice to generate Haddock output as XHTML 1.0 Transitional and Frames, 
stored into files with an extension of .html, and that would likely be served 
as text/html, was mine and I did so with review of current best practices. The 
output Haddock now generates renders correctly and consistently in all browses 
in use by the Haskell community (Firefox, Chrome, Safari, Opera, IE 6, IE 7, 
and IE 8), the Javascript is handled properly, and with one minor exception[1] 
it validates as served by the W3C.

The main aim of the work was achieved: Being able to restyle the output with 
clear, "semantic" CSS, and do so in a way that works in all browsers, and all 
serving environments. If there is a particular issue that is causing the 
documentation generated to not be usable, please let me know.

- Mark

[1] John Milliken caught that anchor identifiers for groups didn't validate, 
though they did work in every browser. The fix is already coded and pushed to 
the development repo. The sample pages on my site updated. You can check the 
validation with:

http://validator.w3.org/check?uri=http%3A%2F%2Fwww.ozonehouse.com%2Fmark%2Fsnap-xhtml%2Fcontainers%2FData-Map.html

This fix isn't crucial, and so I've recommended that we not produce a Haddock 
point release just for this.___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0

[Albert Y. C. Lai]

On 10-09-04 01:31 AM, John Millikin wrote:

It's not correct. Here's the exact same XHTML document (verify by
viewing the source), served with different mimetypes:

http://ianen.org/temp/inline-svg.html
http://ianen.org/temp/inline-svg.xhtml


This relies on xhtml+svg. While it is in the xhtml family, it is not 
xhtml 1.0 (Section 3.1.2). This is a non-example and non-reason.


New haddock pages are xhtml 1.0 (after repairing IDs).


I'm not debating that it's *possible* to serve HTML with an XHTML
mimetype and still see something rendered to the screen. Hundreds of
thousands of sites do so every day. But to call this XHTML is absurd.


You have got the order reversed.

serve html with an xhtml mimetype /= serve xhtml with the html mimetype

But suppose you made a typo.

And bear in mind again we are talking about specifically xhtml 1.0, and 
furthermore with restrictions.


"serve xhtml with the html mimetype, call this xhtml" is not absurd. The 
syntax is xhtml.


"serve xhtml with the html mimetype, call this html" is not absurd. A 
bit of a kludge, yes --- officially blessed kludge, mind you. But not 
absurd.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Why does ghci recompile the module compiled in different OS ?

[Gaius Hammond]

Are you trying to use the .o compiled on BSD on Linux? They are two  
different operating systems. So the Linux ghci isn't using the .o,  
it's using the .hs. Even getting Haskell binaries to run on two  
different versions of Linux can be an adventure...




http://gaiustech.wordpress.com/2010/09/03/on-deployment/



Cheers,



G




On 4 Sep 2010, at 02:36, zaxis wrote:



Both linux and freebsd has the same .ghci file.

cat ~/.ghci

:def hoogle \str -> return $ ":! hoogle --count=15 \"" ++ str ++ "\""
:cd /media/G/www/qachina/db/doc/money

the money.hs has many functions i need to use.

On freebsd, i use the following command to compile it:

ghc -c -O2 money.hs
ls

Money.hi  Money.hs  Money.o

When entering ghci, it indeed doesnot recompile the module.

ghci

...
Ok, modules loaded: Money

However, when i use the same module in archlinux, the ghci does  
recompile

the module:

ghci

...
[1 of 1] Compiling Money( Money.hs, interpreted )
Ok, modules loaded: Money.

Any suggestion is appreciated!

-
e^(π⋅i) + 1 = 0
--
View this message in context: 
http://old.nabble.com/Why-does-ghci-recompile-the-module-compiled-in-different-OS---tp29619740p29619740.html
Sent from the Haskell - Haskell-Cafe mailing list archive at  
Nabble.com.


___
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] Re: Haskell Platform on Windows - cabal update problems.

[Serguey Zefirov]

2010/9/5 Mikhail Glushenkov :
> Try removing the 'Application Data/cabal' directory and running
> 'cabal update'. You probably made a syntax error in the config
> file.

You are clearly a magician. ;)

Now it works flawlessly.

Thank you very much.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: New .hs File Icons

[Mikhail Glushenkov]

Christian Eltges  googlemail.com> writes:

> 
> Hello,
> 
> I was wondering why the File-Icon installed by GHC with the lambda for
> .hs files hasn't changed to the new
>
> [...]
>
> So if the only reason for using the old icon was, that there is no new
> one, then you can use this.

Cool, thanks! I'll include this in the next Haskell Platform 
installer.

It'd be also nice to have separate icons for .lhs files - a
differently colored lambda perhaps?

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Haskell Platform on Windows - cabal update problems.

[Mikhail Glushenkov]

Hi,

Serguey Zefirov  gmail.com> writes:

> 
> I've installed recent Haskell Platform and tried to wrap my head
> around cabal to finally figure out how to use it.
> 
> [...]
> 
> Now it gives me even more interesting error: "cabal.EXE: fromFlag
> NoFlag. Use fromFlagOrDefault"
> 
> Googling doesn't help here. What does it mean and how to get rid of it?
> 

Try removing the 'Application Data/cabal' directory and running
'cabal update'. You probably made a syntax error in the config
file.

Here's a log of what I do after a clean HP install:

E:\>cabal
no command given (try --help)

E:\>cabal install pointfree
Config file path source is default config file.
Config file Application Data\cabal\config not found.
Writing default configuration to Application Data\cabal\config
Warning: The package list for 'hackage.haskell.org' does not exist. Run 'cabal
update' to download it.
cabal: There is no package named pointfree. Perhaps you need to run 'cabal
update' first?

E:\>cabal update
Downloading the latest package list from hackage.haskell.org

E:\>cabal install pointfree
Resolving dependencies...
Downloading pointfree-1.0.3...
Configuring pointfree-1.0.3...
Preprocessing executables for pointfree-1.0.3...
Building pointfree-1.0.3...
[1 of 7] Compiling Plugin.Pl.Common ( Plugin\Pl\Common.hs, dist\build\pointfree\
pointfree-tmp\Plugin\Pl\Common.o )
[2 of 7] Compiling Plugin.Pl.Parser ( Plugin\Pl\Parser.hs, dist\build\pointfree\
pointfree-tmp\Plugin\Pl\Parser.o )
[3 of 7] Compiling Plugin.Pl.PrettyPrinter ( Plugin\Pl\PrettyPrinter.hs, dist\bu
ild\pointfree\pointfree-tmp\Plugin\Pl\PrettyPrinter.o )
[4 of 7] Compiling Plugin.Pl.Transform ( Plugin\Pl\Transform.hs, dist\build\poin
tfree\pointfree-tmp\Plugin\Pl\Transform.o )
[5 of 7] Compiling Plugin.Pl.Rules  ( Plugin\Pl\Rules.hs, dist\build\pointfree\p
ointfree-tmp\Plugin\Pl\Rules.o )
[6 of 7] Compiling Plugin.Pl.Optimize ( Plugin\Pl\Optimize.hs, dist\build\pointf
ree\pointfree-tmp\Plugin\Pl\Optimize.o )
Linking dist\build\pointfree\pointfree.exe ...
Installing executable(s) in E:\\Application Data\cabal\bin

E:\>pointfree 1 + 2
3



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0

[Jeremy Shaw]

On Sat, Sep 4, 2010 at 12:19 PM, David Menendez  wrote:
> HTML and XHTML are not encodings of anything. They are markup
> languages defined using SGML and the XML subset of SGML. There are
> multiple HTML definitions of varying popularity, and the fact that we
> can pass some XHTML documents to a web browser expecting HTML and get
> acceptable results is consistent with the fact that we can pass HTML
> 3.0 (never implemented by any popular browser) with minimal loss.

But what is the point? The w3c originally suggested serving xhtml as
text/html back in 2000
(http://www.w3.org/2000/01/xhtml-pressrelease.html.en), because they
believed that it would be an easy way for people to transition to
xhtml while the browsers caught up. Well, a decade later, ie still
doesn't support xhtml, so perhaps their recommendation should be
viewed in light of the fact that the web does not appear to be moving
to xhtml at any great speed.

Creating output that renders the same as both text/html and
application/xml is not a trivial task. For starters, the contents of
the 

Re: [Haskell-cafe] On to applicative

[michael rice]

Hi Dave,

I wrote the first one sometime last year and it seemed a suitably simple 
example for applicative-izing to cement the ideas in some of the code I've been 
going though in "Learn You a Haskell ..." Interesting stuff.

Onward and upward.

Thanks,

Michael

--- On Sat, 9/4/10, David Menendez  wrote:

From: David Menendez 
Subject: Re: [Haskell-cafe] On to applicative
To: "michael rice" 
Cc: haskell-cafe@haskell.org
Date: Saturday, September 4, 2010, 2:23 PM

On Sat, Sep 4, 2010 at 2:06 PM, michael rice  wrote:

The two myAction functions below seem to be equivalent and, for this small 
case, show an interesting economy of code, but being far from a Haskell expert, 
I have to ask, is the first function as small (code wise) as it could be?


Michael


import Control.Applicative

data Color
    = Red
    | Blue
    | Green
    | Yellow
    | Orange
    | Brown
    | Black
    | White
    deriving (Show, Read, Eq, Enum, Ord, Bounded)


-- myAction :: IO Color
-- myAction = getLine
--    >>= \str -> return (read str :: Color)

First, you don't need the type annotation here. Haskell will infer it from the 
annotation on myAction. (You also don't need the type on myAction, but that's 
not important now.)

myAction = getLine >>= \str -> return (read str)
Second, you have the pattern \x -> f (g x), so you can replace the lambda with 
function composition.

myAction = getLine >>= return . read
Third, there is a standard function liftM, defined in Control.Monad, 
where liftM f m = m >>= return . f, so
myAction = liftM read getLine

Finally, we expect an instance of Monad to also be an instance of Functor, with 
fmap = liftM, and we also have f <$> m = fmap f m, so 
myAction :: IO Color
myAction = read <$> getLine
-- 
Dave Menendez 






  ___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] On to applicative

[David Menendez]

On Sat, Sep 4, 2010 at 2:06 PM, michael rice  wrote:

> The two myAction functions below seem to be equivalent and, for this small
> case, show an interesting economy of code, but being far from a Haskell
> expert, I have to ask, is the first function as small (code wise) as it
> could be?
>
> Michael
>
>
> import Control.Applicative
>
> data Color
> = Red
> | Blue
> | Green
> | Yellow
> | Orange
> | Brown
> | Black
> | White
> deriving (Show, Read, Eq, Enum, Ord, Bounded)
>
> -- myAction :: IO Color
> -- myAction = getLine
> -->>= \str -> return (read str :: Color)
>

First, you don't need the type annotation here. Haskell will infer it from
the annotation on myAction. (You also don't need the type on myAction, but
that's not important now.)

myAction = getLine >>= \str -> return (read str)

Second, you have the pattern \x -> f (g x), so you can replace the lambda
with function composition.

myAction = getLine >>= return . read

Third, there is a standard function liftM, defined in Control.Monad,
where liftM f m = m >>= return . f, so

myAction = liftM read getLine

Finally, we expect an instance of Monad to also be an instance of Functor,
with fmap = liftM, and we also have f <$> m = fmap f m, so


> myAction :: IO Color
> myAction = read <$> getLine


-- 
Dave Menendez 

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] On to applicative

[michael rice]

The two myAction functions below seem to be equivalent and, for this small 
case, show an interesting economy of code, but being far from a Haskell expert, 
I have to ask, is the first function as small (code wise) as it could be?

Michael


import Control.Applicative

data Color
    = Red
    | Blue
    | Green
    | Yellow
    | Orange
    | Brown
    | Black
    | White
    deriving (Show, Read, Eq, Enum, Ord, Bounded)

-- myAction :: IO Color
-- myAction = getLine
--    >>= \str -> return (read str :: Color)

myAction :: IO Color
myAction = read <$> getLine




  ___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Regular expressions on Windows 7

[Chris Kuklewicz]

I think version 0.94.4 has the regex.h file and works on Windows:
 http://hackage.haskell.org/package/regex-posix-0.94.4

On 04/09/2010 18:10, John Sampson wrote:
>  Hello -
> 
> I am following the book "Real World Haskell". I am looking at the
> chapter on regular expressions
> and trying examples on WinGHCi. However, it cannot load
> regex-posix-0.94.2 - apparently a file
> regex.h is missing. I think this has been known for some time. Are there
> plans to have working
> regexes on the Windows platform?
> 
> I am not enough of a hacker to be able to understand material on the Web
> on this subject -
> the problem may have been solved somewhere.
> 
> Regards
> 
> _John Sampson_


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Restricted type classes

[David Menendez]

On Fri, Sep 3, 2010 at 8:23 AM, John Lato  wrote:
> Do you have a kind * implementation of Foldable?  I'd be interested in
> seeing it, because I was unable to create a usable implementation (based
> upon the RMonad scheme) on my last attempt.

I always figured it would look something like:

class Foldable f where
  type Elem f :: *
  foldMap :: Monoid m => (Elem f -> m) -> f -> m

with the usual definitions for foldr, foldl, etc.

> +1 for using the proper constraints, and especially for bringing over
> Pointed (and anything else that applies).

What's the argument for Pointed? Are there many types which are
instances of Pointed but not Applicative? Are there many algorithms
which require Pointed but not Applicative?

-- 
Dave Menendez 

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] help me evangelize haskell.

[Gaius Hammond]

My usual rhetoric is that one-off, throwaway scripts never are, and not only do 
they tend to stay around but they take on a life of their own. Today's 10-line 
file munger is tomorrow's thousand-line ETL batch job on which the business 
depends for some crucial data - yet the original author is long gone and no-one 
dares modify in case it breaks. So it is just good sense to use sound practices 
from the very beginning. 


One of the features of Perl is that it will try to work even if you make type 
errors (e.g. give it a scalar in place of a list, or a string instead of an 
int). One day, however, it WILL fail. Haskell finds these types of bugs 
upfront, and not when your pager goes off at 3am...


Cheers,


G

--Original Message--
From: Michael Litchard
Sender: haskell-cafe-boun...@haskell.org
To: haskell-cafe@haskell.org
Subject: [Haskell-cafe] help me evangelize haskell.
Sent: Sep 4, 2010 17:38

I'll be starting a new job soon as systems tool guy. The shop is a
perl shop as far as internal automation tasks go. But I am fortunate
to not be working with bigots. If they see a better way, they'll take
to it. So please give me your best arguments in favor of using haskell
for task automation instead of perl, or awk or any of those scripting
lanugages.
___
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] ANNOUNCE: Haddock version 2.8.0

[David Menendez]

On Sat, Sep 4, 2010 at 11:07 AM, John Millikin  wrote:
> On Fri, Sep 3, 2010 at 23:02, David Menendez  wrote:
>> Yes, using foreign namespaces is one of the things recommended against
>> when serving XHTML as text/html. This says nothing about documents
>> following the recommendations in Appendix C.
>>
>>> I'm not debating that it's *possible* to serve HTML with an XHTML
>>> mimetype and still see something rendered to the screen. Hundreds of
>>> thousands of sites do so every day. But to call this XHTML is absurd.
>>
>> I agree, if by "absurd" you mean "consistent with the letter and
>> spirit of the XHTML recommendation".
>
> Content served as text/html is not XHTML, any more than content served
> as text/plain or image/jpg is.

Metadata does not determine data. If I write "created: 1810" on the
Haskell Report, that does not make it 200 years old. If I seve a JPEG
image as text/html, it's still a JPEG image. We just wouldn't expect a
browser to render it correctly, because the metadata is wrong.

Appendix C describes a subset of XHTML, such that a document in
conformance with it may be interpreted usefully as HTML by most web
browsers. The document is still XHTML, and may be given to XHTML or
generic XML tools without difficulty.

> You seem to be under the common misconception that XHTML is merely an
> alternative encoding of HTML.

HTML and XHTML are not encodings of anything. They are markup
languages defined using SGML and the XML subset of SGML. There are
multiple HTML definitions of varying popularity, and the fact that we
can pass some XHTML documents to a web browser expecting HTML and get
acceptable results is consistent with the fact that we can pass HTML
3.0 (never implemented by any popular browser) with minimal loss.

-- 
Dave Menendez 

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Restricted type classes

[Ben Millwood]

I have only one thing to add to this discussion:

On Fri, Sep 3, 2010 at 5:16 AM, Ivan Lazar Miljenovic
 wrote:
> 2b) Is it OK to promote functions that use a class to being class
> methods?  When I was discussing this in #haskell several people
> mentioned that defining something like liftA2 for the Set instance of
> (restricted) Applicative would make more sense than the default <*>
> (since (a -> b) isnt' an instance of Ord).

One problem with defining both <*> and liftA2 in the class in terms of
each other is that omitting them from instances is no longer a
compile-time error, nor is it even an obvious runtime error - it's
frequently an infinite loop, which is unpleasant. Though I understand
that it's nice to be able to choose the methods you want to define, I
think static error detection is nice too, so I tend to avoid providing
extra class methods with defaults unless the alternative is much
worse.

On that note, why *do* we have missing instance methods filled in with
bottoms, so that even without defaults, it's a warning rather than an
error? It seems like quite an un-Haskelly thing to do. I know there
may be some cases where you do not need to define a particular method,
but imo you should be required to explicitly opt out of it if that's
the case.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Regular expressions on Windows 7

[John Sampson]

 Hello -

I am following the book "Real World Haskell". I am looking at the 
chapter on regular expressions
and trying examples on WinGHCi. However, it cannot load 
regex-posix-0.94.2 - apparently a file
regex.h is missing. I think this has been known for some time. Are there 
plans to have working

regexes on the Windows platform?

I am not enough of a hacker to be able to understand material on the Web 
on this subject -

the problem may have been solved somewhere.

Regards

_John Sampson_
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] help me evangelize haskell.

[Vo Minh Thu]

2010/9/4 Michael Litchard :
> I'll be starting a new job soon as systems tool guy. The shop is a
> perl shop as far as internal automation tasks go. But I am fortunate
> to not be working with bigots. If they see a better way, they'll take
> to it. So please give me your best arguments in favor of using haskell
> for task automation instead of perl, or awk or any of those scripting
> lanugages.

Hi,

At a talk presented during a Ghent FPG meeting, someone explained how
they brought Ocaml to the work place. Basically, they made a drop-in
replacement for a C++ (or maybe was it C) library. Less code, same or
above performance.

Maybe they had also a good reason to rewrite the library (because it
was too big, or too difficult to maintain), not just as a proof that
Ocaml was better suited.

I guess that in your case, "Perl for internal automation task", you
should find some little tool for which it would be acceptable to
dedicate some time rewriting it in Haskell.

Tell us how all this unfolds.

Cheers,
Thu
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] help me evangelize haskell.

[Michael Litchard]

I'll be starting a new job soon as systems tool guy. The shop is a
perl shop as far as internal automation tasks go. But I am fortunate
to not be working with bigots. If they see a better way, they'll take
to it. So please give me your best arguments in favor of using haskell
for task automation instead of perl, or awk or any of those scripting
lanugages.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Laziness bug in Data.List.intersperse (was: ANNOUNCE: text 0.8.0.0, fast Unicode text support)

[Bryan O'Sullivan]

On Wed, Sep 1, 2010 at 1:00 PM, Daniel Fischer wrote:

> I'm not keen on subscribing to libraries@ to follow the official proposal
> process, any takers?
>

I'll take it up.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Crypto-API is stabilizing

[Thomas DuBuisson]

Sorry, the example was all messed up, even if it did communicate what
I wanted its just so broken I must fix.

Slightly contrived example:

   buildAgreementMessage :: (Monad m, CryptoRandomGen g,
ASymetricCipher k) => g -> k -> m (B.ByteString, (k,k), g)
   buildAgreementMessages g k = do
   ((p,q),g') <- eitherToFail (buildKeyPair g)
   let pBS = encode p
   msg = runPut $ do
   putByteString agreementHeader
   putWord16be (B.length pBS)
   putByteString pBS
   return $ (sign msg k, (p,q), g')

Again, this is simply trying to re-enforce the fact that buildKeyPair
(formerly 'generateKeyPair') does have a place.

Cheers,
Thomas

On Sat, Sep 4, 2010 at 7:45 AM, Thomas DuBuisson
 wrote:
>
> Slightly contrived example:
>
>    buildAgreementMessage :: (Monad m, CryptoRandomGen g,
> ASymetricCipher k) => g -> k -> m (B.ByteString,g)
>    buildAgreementMessages g k = do
>        (e,g') <- liftM eitherToFail (buildAsymKey g `asTypeOf` k)
>        let eBS = encode e
>            msg = runPut (putByteString agreementHeader >> putWord16be
> (B.length eBS) >> putByteString eBS)
>        return msg
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0

[John Millikin]

On Fri, Sep 3, 2010 at 23:02, David Menendez  wrote:
> Yes, using foreign namespaces is one of the things recommended against
> when serving XHTML as text/html. This says nothing about documents
> following the recommendations in Appendix C.
>
>> I'm not debating that it's *possible* to serve HTML with an XHTML
>> mimetype and still see something rendered to the screen. Hundreds of
>> thousands of sites do so every day. But to call this XHTML is absurd.
>
> I agree, if by "absurd" you mean "consistent with the letter and
> spirit of the XHTML recommendation".

Content served as text/html is not XHTML, any more than content served
as text/plain or image/jpg is. *IF* XHTML could be served using
"text/html", then my example pages would render identically in
browsers with XHTML support.

Appendix C is a guideline on how to make the same byte content render
*something* when treated as HTML or XHTML; it's intended as a
low-fidelity fallback for user agents without support for XHTML (IE).
It is *not* a means by which HTML may be labelled XHTML for the sake
of buzzword compliance.

You seem to be under the common misconception that XHTML is merely an
alternative encoding of HTML. This is incorrect. XHTML has a different
DOM, different CSS support, and different syntax. HTML and XHTML are
like Java and C# -- beneath a superficial resemblance, distinct.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] New .hs File Icons

[Daniel Díaz]

 GHC's icon is a little different from Hugs' icon. However, your icon is
prettier. WinGHCi's icon is nice too. Off course, it's just an opinion.


>  --
> Daniel Díaz
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Crypto-API is stabilizing

[Thomas DuBuisson]

On Sat, Sep 4, 2010 at 3:23 AM, Heinrich Apfelmus
 wrote:
>>> A better reason is the data structure has
>>> no way to implement generateKeyPair.
>
> That's a non-problem: each algorithm (RSA, DSA, ...) implements a
> function with the same type as  generateKeyPair . Compare
>
>   rsa :: RangomGen g => BitLength -> g -> ((Key,Key), g)
>
> vs
>
>   ((k1 :: RSA, k2), g') = generateKeyPair g
>
> You always have to write down the name of the algorithm ("RSA") when
> using  generateKeyPair , so you may as well drop it entirely.

That simply isn't true.  What if you have a key exchange in which the
ephemeral key is of the same type as your signing key?

Slightly contrived example:

buildAgreementMessage :: (Monad m, CryptoRandomGen g,
ASymetricCipher k) => g -> k -> m (B.ByteString,g)
buildAgreementMessages g k = do
(e,g') <- liftM eitherToFail (buildAsymKey g `asTypeOf` k)
let eBS = encode e
msg = runPut (putByteString agreementHeader >> putWord16be
(B.length eBS) >> putByteString eBS)
return msg
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Haskell Platform on Windows - cabal update problems.

[Serguey Zefirov]

I've installed recent Haskell Platform and tried to wrap my head
around cabal to finally figure out how to use it.

First thing I bumped into is that cabal.exe does not know about any
remote repositories, even about hackage. So after googling I found
that I should add a line "remote-repo:
hackage.haskell.org:http://hackage.haskell.org/packages/archive"; into
my cabal config file. So I did.

And now I have "cabal update" command trying to download packages list
from hackage. To no avail.

Now it gives me even more interesting error: "cabal.EXE: fromFlag
NoFlag. Use fromFlagOrDefault"

Googling doesn't help here. What does it mean and how to get rid of it?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haddock: Documentation of instances with un-documentable type arguments

[Ivan Lazar Miljenovic]

On 4 September 2010 19:01, Alexander McPhail
 wrote:
> Hi
>
> Is there a similar ticket for GHC to not export instances in the case that
> other instances are explicitly specified?
>
> module Foo (
>    Foo(Monad)
>   )
>
> instance Monad Foo where ...
> instance MonadState (Foo Bar) where ...
>
> i.e. the monad instance gets exported but the MonadState one does not?  This
> helps in maintaining opacity with respect to the package user.  I may not
> want the user to be able to call 'get' and 'put' when using my custom monad.

No: instances are implicitly imported and exported (if the class and
the type are visible, then so are any possible instances).

-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] TryHaskell in the classroom!

[Christopher Done]

On 4 September 2010 02:02, Fritz Ruehr  wrote:
> I just wanted to send out a more public "Thanks!" to Chris Done for the
> tryhaskell.org website and to everyone else
> (including Chris) who was on the #haskell channel of IRC this afternoon when
> I "tried haskell", along with the chat feature,
> during my introductory functional programming class.

Glad to hear it! This is an ideal scenario for Try Haskell! Thanks for using it!

On 4 September 2010 02:11, Benjamin L. Russell  wrote:
> I have also enjoyed using Try Haskell.  It would be wonderful if it
> could be expanded with more content.  Many thanks to the developers for
> their efforts!

Community contributed lessons are welcome! I'll be adding some hpaste
integration too. A markdown format like the below should be
sufficient:

Title: Example
Message:

Here is a message about integers! Here are some numbers:

23^75
23/52

Enter a number like `23`.

Title: Well done
Type-Trigger: Num t => t
Value-Trigger: 23
Message:

Great, you typed %value% and it has type %type%.

Etc.

And so on. Until I write a tutorial composer.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Restricted type classes

[Stephen Tetley]

On 4 September 2010 09:57, Ivan Lazar Miljenovic
 wrote:

> Where exactly can I find these observations on the analogies between
> data structures and numerical representations?
>

Chris Okasaki - Chapter 9 of Purely Functional Data Structures.

Ralf Hinze's slides Number Systems and Data Structures, March 2005 -
http://www.cs.nott.ac.uk/~gmh/bctcs-slides/hinze.pdf


On second thoughts, I don't think C++ has a collection classes library
designed in this way. The message on the Cafe I had in mind was this
one, but it is talking about something else:

http://www.haskell.org/pipermail/haskell-cafe/2010-April/076157.html
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haddock: Documentation of instances with un-documentable type arguments

[Alexander McPhail]

Hi

Is there a similar ticket for GHC to not export instances in the case that
other instances are explicitly specified?

module Foo (
   Foo(Monad)
  )

instance Monad Foo where ...
instance MonadState (Foo Bar) where ...

i.e. the monad instance gets exported but the MonadState one does not?  This
helps in maintaining opacity with respect to the package user.  I may not
want the user to be able to call 'get' and 'put' when using my custom monad.

Cheers,

Vivian

On 26 August 2010 02:20, David Waern  wrote:

> 2010/8/25 Alexander McPhail :
>
> > Perhaps Haddock could exclude class instance reporting when it cannot
> find a
> > documentable link to a parameter?
>
> Yes, it should. BTW, we have a trac ticket for it:
>
>  http://trac.haskell.org/haddock/ticket/37
>
> You can add yourself to the CC list to show that you want this feature.
>
> Currently we don't have many people working on these types of tickets
> in Haddock (I'm mostly fixing bugs, others are working on bigger
> improvements), so if more people would volunteer to help out, that'd
> be great. The mailing list hadd...@projects.haskell.org can be used to
> ask for directions and help.
>
> David
>



-- 
---
yolar et elver.
---

DISCLAIMER

This transmission contains information that may be confidential. It is
intended for the named addressee only. Unless you are the named addressee
you may not copy or use it or disclose it to anyone else.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Restricted type classes

[Ivan Lazar Miljenovic]

On 4 September 2010 18:54, Stephen Tetley  wrote:
> Supposing classes is the way to go, I think there's still a lot of
> design work to be done on what the classes should be rather than how
> they are implemented. The current design space (ListLike and your
> Data.Containers) looks like a factoring of the operations from
> Data.List and Data.Sequence, personally I have serious doubts that
> this will lead to a nice API. If I was looking at it myself, I'd start
> from Chris Okasaki and Ralf Hinze's observations that data structures
> have analogies to numerical representations. So, I would try to build
> classes upwards from that (monoid is obviously already in place),
> rather than design by factoring what List already has. As an example,
> I think someone has pointed out on the Cafe that C++ has a container
> library following the analogy to numerical representations.

Where exactly can I find these observations on the analogies between
data structures and numerical representations?

-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Restricted type classes

[Stephen Tetley]

On 4 September 2010 08:50, Ivan Lazar Miljenovic
 wrote:

>>> 3) Am I wasting my time with this?
>>
>> Not at all. Many people want a good containers API, and many people want a
>> cleaned up version of the categorical classes which isn't quite as involved
>> as category-extras. Go for it!
>
> *sigh* I was almost wishing people would say I _was_ wasting my time
> with this... ;-)

Hi Ivan

Okay, I'll bite...

Its good someone is looking into arity versions of Monad, Applicative
etc. I think previously pointed you to Conor McBride's message on the
subject:

http://www.haskell.org/pipermail/haskell-cafe/2008-June/044011.html


But, I don't know that work on this will lead to a better API for
collection classes...

Supposing classes is the way to go, I think there's still a lot of
design work to be done on what the classes should be rather than how
they are implemented. The current design space (ListLike and your
Data.Containers) looks like a factoring of the operations from
Data.List and Data.Sequence, personally I have serious doubts that
this will lead to a nice API. If I was looking at it myself, I'd start
from Chris Okasaki and Ralf Hinze's observations that data structures
have analogies to numerical representations. So, I would try to build
classes upwards from that (monoid is obviously already in place),
rather than design by factoring what List already has. As an example,
I think someone has pointed out on the Cafe that C++ has a container
library following the analogy to numerical representations.

As an aside I thought someone added an implementation of Simon Peyton
Jones's "Bulk Types with Class" to Hackage recently? If they did they
didn't give it a findable description.


Best wishes

Stephen
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] New .hs File Icons

[Lyndon Maydwell]

This looks great!

On Fri, Sep 3, 2010 at 4:59 PM, Christian Eltges  wrote:
> Hello,
>
> I was wondering why the File-Icon installed by GHC with the lambda for
> .hs files hasn't changed to the new
> bind+lambda icon used on haskel.org.
> Is this because it should be the same as the icon used by hugs?
> I've created a new icon myself, which I use on my pc (using the svg
> file from the haskell wiki).
> So if the only reason for using the old icon was, that there is no new
> one, then you can use this.
>
> Best regards
>
> Christian
>
> ___
> 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] Restricted type classes

[Ivan Lazar Miljenovic]

On 4 September 2010 18:27, wren ng thornton  wrote:
> On 9/4/10 3:50 AM, Ivan Lazar Miljenovic wrote:
>>
>> On 4 September 2010 17:40, wren ng thornton  wrote:
>>>
>>> So, in the interest of generality, perhaps you should just pick a letter
>>> or
>>> a short prefix and use that for each of the classes. In my blog posts I
>>> called them 0-monads, 1-monads, and 2-monads; following Ganesh
>>> Sittampalam
>>> and Matthieu Sozeau, they'd be monads, r-monads, and g-monads.
>>
>> I think I'd prefer to put the prefix on the kind * versions (though
>> does a kind * version of something like Monad even make sense?).
>
> Oh sure. I was just meaning that you should do something systematic like
> have XFoo and YFoo, instead of having Foo and Bar. That way people can just
> remember ({X,Y},{Foo,Fob,Fez}) instead of having to remember {(Foo,Bar),
> (Fob,Baz), (Fez,Quux)}.
>
> I'm a fan of keeping the undecorated names for the current versions, and
> using a prefix for the * versions.

Right, so what prefix? ;-)

> Well, liftA and liftM are just generic implementations of fmap using
> pure/(<*>) and return/(>>=). If you can define fmap directly, then you
> should do so. If you can't, you're always free to use the implementations
> that liftA and liftM use. The liftA function is defined explicitly for
> allowing you can say """instance Functor F where fmap = liftA""". There's no
> reason for liftA to belong to Applicative, because it has Functor as a
> superclass and therefore fmap exists. Since fmap can be more efficient than
> liftA, it is better to use fmap when writing code. Note that (<$>) is
> defined as fmap, and liftA2, liftA3, etc are defined in terms of (<$>) i.e.
> fmap.

Gah, you're right.  I didn't think that liftA = fmap.

> For liftM things are a bit hazier because Monad fails to mention Functor as
> an explicit superclass, but it really ought to. Assuming it did, then
> there's no reason for liftM to belong to Monad, because we're assured that
> fmap exists. Though, again, liftM should be defined as a non-class function
> in order to serve as a default implementation of fmap for those who need it.

Hmmm, I was thinking of just having "liftM = fmap", but yeah using the
monadic defaults makes sense to avoid having to define fmap
explicitly.

> This is the same reason why Data.Traversable defines fmapDefault and
> foldMapDefault: not so that they can be used as functions, but so that they
> can be used for giving class instances. Perhaps we should be calling them
> fmapApplictiveDefault, fmapMonadDefault, and fmapTraversableDefault
> instead...
>
> I suppose you could use liftA2 as the basis of Applicative instead of (<*>),
> but that seems a bit perverse to me. The (<*>) operation captures exactly
> what we want to say--- namely the K axiom for modal logics; which is
> equivalent to saying the applicative category has exponentials; which is
> also the name for the whitespace of function application;... . Whereas
> liftA2 seems like a far more round-about way of getting there. There may be
> efficiency reasons for arguing that liftA2 should be included in _addition_
> to (<*>), but I'm not aware of them.

Well,  I _can_ define <*> for Sets (and have done so), but such an
instance doesn't make any sense because functions don't have Ord
instances.  As such, the default liftA2, etc. definitions don't work
with Sets because of this.

-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Restricted type classes

[wren ng thornton]

On 9/4/10 3:50 AM, Ivan Lazar Miljenovic wrote:

On 4 September 2010 17:40, wren ng thornton  wrote:

So, in the interest of generality, perhaps you should just pick a letter or
a short prefix and use that for each of the classes. In my blog posts I
called them 0-monads, 1-monads, and 2-monads; following Ganesh Sittampalam
and Matthieu Sozeau, they'd be monads, r-monads, and g-monads.


I think I'd prefer to put the prefix on the kind * versions (though
does a kind * version of something like Monad even make sense?).


Oh sure. I was just meaning that you should do something systematic like 
have XFoo and YFoo, instead of having Foo and Bar. That way people can 
just remember ({X,Y},{Foo,Fob,Fez}) instead of having to remember 
{(Foo,Bar), (Fob,Baz), (Fez,Quux)}.


I'm a fan of keeping the undecorated names for the current versions, and 
using a prefix for the * versions.



I'd say you should include: Functor, Foldable, Traversable, Pointed,
Applicative, Monad, and Monoid (both additive and multiplicative in separate
classes, as in the monoids package). Those eight make for a really
comprehensive toolkit that does most of the things people frequently need.
Of course, not every collection will have instances for all of them.


Monoid was probably just going to be re-exported from base, since it's
already for kind * (and as such works with all types, and doens't need
any parametricity).


I was just talking general API, not necessarily what you need to write. 
Reusing the standard classes is fine.



Well, the point was that liftA/liftA2 might make more sense as being
the methods to be defined for some types rather than<*>, but you
could define them in terms of each other.


Well, liftA and liftM are just generic implementations of fmap using 
pure/(<*>) and return/(>>=). If you can define fmap directly, then you 
should do so. If you can't, you're always free to use the 
implementations that liftA and liftM use. The liftA function is defined 
explicitly for allowing you can say """instance Functor F where fmap = 
liftA""". There's no reason for liftA to belong to Applicative, because 
it has Functor as a superclass and therefore fmap exists. Since fmap can 
be more efficient than liftA, it is better to use fmap when writing 
code. Note that (<$>) is defined as fmap, and liftA2, liftA3, etc are 
defined in terms of (<$>) i.e. fmap.


For liftM things are a bit hazier because Monad fails to mention Functor 
as an explicit superclass, but it really ought to. Assuming it did, then 
there's no reason for liftM to belong to Monad, because we're assured 
that fmap exists. Though, again, liftM should be defined as a non-class 
function in order to serve as a default implementation of fmap for those 
who need it. This is the same reason why Data.Traversable defines 
fmapDefault and foldMapDefault: not so that they can be used as 
functions, but so that they can be used for giving class instances. 
Perhaps we should be calling them fmapApplictiveDefault, 
fmapMonadDefault, and fmapTraversableDefault instead...


I suppose you could use liftA2 as the basis of Applicative instead of 
(<*>), but that seems a bit perverse to me. The (<*>) operation captures 
exactly what we want to say--- namely the K axiom for modal logics; 
which is equivalent to saying the applicative category has exponentials; 
which is also the name for the whitespace of function application;... . 
Whereas liftA2 seems like a far more round-about way of getting there. 
There may be efficiency reasons for arguing that liftA2 should be 
included in _addition_ to (<*>), but I'm not aware of them.


--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Restricted type classes

[Ivan Lazar Miljenovic]

On 4 September 2010 17:40, wren ng thornton  wrote:
> On 9/3/10 12:16 AM, Ivan Lazar Miljenovic wrote:
>>
>> 1) How should I name the kind * versions?  For example, the kind *
>> version of Functor is currently called Mappable with a class method of
>> rigidMap.  What should I call the kind * version of Foldable and its
>> corresponding methods?  Is there a valid system I can use for these?
>
> I think it'd be good to be consistent, whatever you do. For (*->*->*) monads
> I've seen them called GMonads (for "generalized") and indexed monads. For
> the (*->*) monads, I've seen RMonads and parameterized monads. Here are some
> links for those who may be interested; they have more links to independent
> invention by Oleg Kiselyov and also by Bob Atkey, as well as a Coq
> implementation and a mention of Agda. (For my part, I've since moved on to
> playing with monads between different categories, which isn't really germane
> here.)
>
>    http://winterkoninkje.dreamwidth.org/65416.html
>    http://winterkoninkje.dreamwidth.org/65585.html
>
> So, in the interest of generality, perhaps you should just pick a letter or
> a short prefix and use that for each of the classes. In my blog posts I
> called them 0-monads, 1-monads, and 2-monads; following Ganesh Sittampalam
> and Matthieu Sozeau, they'd be monads, r-monads, and g-monads.

I think I'd prefer to put the prefix on the kind * versions (though
does a kind * version of something like Monad even make sense?).

>> 2) How far should I go?  Should I restrict myself to the
>> "data-oriented" classes such as Functor, Traversable, etc. or should I
>> try to make restricted versions of Applicative and Monad?  Assuming I
>> should:
>
> I'd say you should do as much as seems reasonable. I tend to take things as
> far as I can, but that'd end up doing a lot of the same work as
> category-extras. For a general collections library, I think it'd make sense
> to try to keep things simpler than that if possible. The simpler it is, the
> better the uptake will be, so long as it's still complex enough to capture
> what it needs to.
>
> I'd say you should include: Functor, Foldable, Traversable, Pointed,
> Applicative, Monad, and Monoid (both additive and multiplicative in separate
> classes, as in the monoids package). Those eight make for a really
> comprehensive toolkit that does most of the things people frequently need.
> Of course, not every collection will have instances for all of them.

Monoid was probably just going to be re-exported from base, since it's
already for kind * (and as such works with all types, and doens't need
any parametricity).

>> 2b) Is it OK to promote functions that use a class to being class
>> methods?  When I was discussing this in #haskell several people
>> mentioned that defining something like liftA2 for the Set instance of
>> (restricted) Applicative would make more sense than the default<*>
>> (since (a ->  b) isnt' an instance of Ord).
>
> That depends. In general, it's better to have smaller classes because it
> reduces the burden on programmers writing instances and it allows for
> smaller dictionaries at runtime. In general, I'd say that functions should
> be included into the class when they often permit specialized definitions
> which are more efficient than the generic one. And of course, they should be
> included when they serve as the basis of the class (e.g., both (==) and (/=)
> should be included in Eq since they both serve as a basis for equality, with
> no one being obviously easier to implement than the other). If there's
> little chance of a performance gain, then why would you want it in the class
> at all?

Well, the point was that liftA/liftA2 might make more sense as being
the methods to be defined for some types rather than <*>, but you
could define them in terms of each other.

>> 2c) Should I keep the classes as-is, or should I explicitly put in the
>> constraints mentioned in the Typeclassopedia (e.g. make Applicative an
>> explicit superclass of Monad, and define return = pure for
>> compatability reasons)?  If so, should I bring over Pointed, etc. from
>> category-extras to round out the set or just stick with classes that
>> are already in base?
>
> If you're defining a new hierarchy, I'd say you should do it correctly, i.e.
>
>    class                Functor     where fmap
>    class Functor     => Pointed     where unit -- or point
>    class Pointed     => Applicative where (<*>) ; (<*) ; (*>)
>    class Applicative => Monad       where (>>=) ; join
>
> There's no benefit to preserving the ill designs of the past.

Yes, that was my point.

>> 3) Am I wasting my time with this?
>
> Not at all. Many people want a good containers API, and many people want a
> cleaned up version of the categorical classes which isn't quite as involved
> as category-extras. Go for it!

*sigh* I was almost wishing people would say I _was_ wasting my time
with this... ;-)
-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljen

Re: [Haskell-cafe] Restricted type classes

[wren ng thornton]

On 9/3/10 12:16 AM, Ivan Lazar Miljenovic wrote:

1) How should I name the kind * versions?  For example, the kind *
version of Functor is currently called Mappable with a class method of
rigidMap.  What should I call the kind * version of Foldable and its
corresponding methods?  Is there a valid system I can use for these?


I think it'd be good to be consistent, whatever you do. For (*->*->*) 
monads I've seen them called GMonads (for "generalized") and indexed 
monads. For the (*->*) monads, I've seen RMonads and parameterized 
monads. Here are some links for those who may be interested; they have 
more links to independent invention by Oleg Kiselyov and also by Bob 
Atkey, as well as a Coq implementation and a mention of Agda. (For my 
part, I've since moved on to playing with monads between different 
categories, which isn't really germane here.)


http://winterkoninkje.dreamwidth.org/65416.html
http://winterkoninkje.dreamwidth.org/65585.html

So, in the interest of generality, perhaps you should just pick a letter 
or a short prefix and use that for each of the classes. In my blog posts 
I called them 0-monads, 1-monads, and 2-monads; following Ganesh 
Sittampalam and Matthieu Sozeau, they'd be monads, r-monads, and g-monads.



2) How far should I go?  Should I restrict myself to the
"data-oriented" classes such as Functor, Traversable, etc. or should I
try to make restricted versions of Applicative and Monad?  Assuming I
should:


I'd say you should do as much as seems reasonable. I tend to take things 
as far as I can, but that'd end up doing a lot of the same work as 
category-extras. For a general collections library, I think it'd make 
sense to try to keep things simpler than that if possible. The simpler 
it is, the better the uptake will be, so long as it's still complex 
enough to capture what it needs to.


I'd say you should include: Functor, Foldable, Traversable, Pointed, 
Applicative, Monad, and Monoid (both additive and multiplicative in 
separate classes, as in the monoids package). Those eight make for a 
really comprehensive toolkit that does most of the things people 
frequently need. Of course, not every collection will have instances for 
all of them.


(N.B., following the naming convention in those blog posts, 2-monoids 
are exactly the same as categories.)



2b) Is it OK to promote functions that use a class to being class
methods?  When I was discussing this in #haskell several people
mentioned that defining something like liftA2 for the Set instance of
(restricted) Applicative would make more sense than the default<*>
(since (a ->  b) isnt' an instance of Ord).


That depends. In general, it's better to have smaller classes because it 
reduces the burden on programmers writing instances and it allows for 
smaller dictionaries at runtime. In general, I'd say that functions 
should be included into the class when they often permit specialized 
definitions which are more efficient than the generic one. And of 
course, they should be included when they serve as the basis of the 
class (e.g., both (==) and (/=) should be included in Eq since they both 
serve as a basis for equality, with no one being obviously easier to 
implement than the other). If there's little chance of a performance 
gain, then why would you want it in the class at all?


For example, many types can implement fmap/(<$>) more efficiently than 
by using the liftM/liftA implementations or the default implementation 
from Foldable. (Of course, fmap is also a basis for the class.)


For applicatives, the (<*) and (*>) operators should be included in the 
class too. While they seem trivial, some parser combinator libraries can 
get major performance improvements by using non-generic definitions. 
There was a discussion about this a while back, I forget if it was here 
or on the libraries list. And I forget if (<**>) also had efficient 
implementations...


For another example of the principle, while compare is a sufficient 
basis for defining Ord, we include (<), (<=), (>), (>=) because they can 
often be implemented more efficiently than by using compare.




2c) Should I keep the classes as-is, or should I explicitly put in the
constraints mentioned in the Typeclassopedia (e.g. make Applicative an
explicit superclass of Monad, and define return = pure for
compatability reasons)?  If so, should I bring over Pointed, etc. from
category-extras to round out the set or just stick with classes that
are already in base?


If you're defining a new hierarchy, I'd say you should do it correctly, i.e.

classFunctor where fmap
class Functor => Pointed where unit -- or point
class Pointed => Applicative where (<*>) ; (<*) ; (*>)
class Applicative => Monad   where (>>=) ; join

There's no benefit to preserving the ill designs of the past.


3) Am I wasting my time with this?


Not at all. Many people want a good containers API, and many people want 
a cleaned up v