Re: [Haskell-cafe] ANNOUNCE: citeproc-hs, a Haskell implementation of the Citation Style Language designed for Pandoc

[Andrea Rossato]

Hi Gwern,

On Fri, Sep 19, 2008 at 09:01:46PM -0400, Gwern Branwen wrote:
> Hi Andrea. So I was looking at the README. Does citeproc-hs only
> support adding refs from a .xml file when one's written in Pandoc
> markdown? That is, I don't see how I could take a .lhs file and a .bib
> file and produce one of the Pandoc-supported outputs. In particular,
> I'd really like to be able to go .lhs -> .wiki, with refs; this would
> let me convert The Monad Reader articles for haskell.org.

as far as I remember Pandoc can deal with literate Haskell. Check here:
http://groups.google.com/group/pandoc-discuss/t/aaaf768ab730192

for bibtex databases, you can use Bibutils (check the citeproc-hs
homepage for a link): bibutils is a set of utilities for converting
from/to MODS to/from many different bibliographic databases.

As you know, Pandoc has a mediawiki writer, so, you should be able to
use extended markdown with referecnes to produce articles for the
wiki.

Keep in mind that pandoc latex reader doesn't use citeproc-hs (yet,
I'd like to add).

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

Re: [Haskell-cafe] Climbing up the shootout...

[Andrew Coppin]

Don Stewart wrote:

Thanks to those guys who've submitted parallel programs to the language
benchmarks game, we're climbing up the rankings, now in 3rd, and ahead
of C :)

http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=all
  


Yay! This makes me very happy. ;-)

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

Re: [Haskell-cafe] Line noise

[Andrew Coppin]

Mads Lindstrøm wrote:

Andrew Coppin wrote:

  
Idiomatic Haskell seems to consist *only* of single-letter variable 
names.



The more abstract (generic) thing gets, the less likely you will be able
to find a telling name. And if you cannot find a telling name, you can
just as well make it short. And as Haskell is more abstract, we get more
short identifiers. E.g. in your earlier sorting function:

  qsort (x:xs) = ...

what would you propose to call the elements?


Well, qsort (element : list) would be maximally intuitive, but who's 
going to implement it like that? ;-)


Now of course in C, you'd be forced to write something like

 list qsort(int x, list xs)

which makes it completely unambiguous what these things are - what their 
type is. But in Haskell, even if you add a type signature:


 qsort:: (Ord x) => [x] -> [x]

Nobody is going to realise that "[x]" means a list. And it's still not 
clear where ":" comes from, or... well you can see why people are 
getting lost! ;-)



However, I will grant you that Map k v, could have used longer type
variables. But we are not alone with using one letter type variable
names http://java.sun.com/javase/6/docs/api/java/util/HashMap.html . And
frankly, in this specific case, I think most programmers (Haskell or
non-Haskell) will be able to guess what k and v means, when they are
standing right after Map.
  


Only if you can figure out that "Map" means what every other programming 
language on the face of the Earth calls a "dictionary". (This took me a 
while!)


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

Re: [Haskell-cafe] Line noise

[Andrew Coppin]

Dan Piponi wrote:

I suspect that most of the complaints about line noise stem
from this - to beginners Haskell expressions just look like sequences
of identifiers with no apparent grammar to "bind" them together.
  


This was the exact complaint that some people voiced, yes. (The (.) and 
($) operators just compound the problem.)


Somebody else then came to my rescue and pointed out that "everybody 
says Lisp is unreadable because it has too many brackets - despite the 
fact that those brackets theoretically make parsing utterly trivial". ;-)


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

[Haskell-cafe] Climbing up the shootout...

[Don Stewart]

Thanks to those guys who've submitted parallel programs to the language
benchmarks game, we're climbing up the rankings, now in 3rd, and ahead
of C :)

http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=all

Just one or two more parallel programs required...

Submit them here, and we can test on quad core,

http://haskell.org/haskellwiki/Shootout/Parallel

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

Re: [Haskell-cafe] Line noise

[Richard A. O'Keefe]

On 22 Sep 2008, at 9:19 am, Albert Y. C. Lai wrote:
Everyone should use exclusively ancient Egyptian iconography. It is  
the only universally readable language.


I know this was full of (:-) (:-),
but it seems like the perfect chance to mention Blissymbols.
http://unicode.org/roadmaps/smp/smp-4-14.html (the Unicode SMP road map)
has a link to a proposal for adding them to Unicode,
and they _are_ in active use...

(A Haskell program in Blissymbols would be, well, bigger.)

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

Re: [Haskell-cafe] Line noise

[donn cave]

Quoth Andrew Coppin <[EMAIL PROTECTED]>:
...
| As one experienced C++ programmer put it, "there is no clear flow from 
| left to right or right to left". Personally I found that a little ironic 
| comming from the language that gave us
|
|   while (*x++ = *y++) { }
|
| which is every bit as non-linear! ;-)

Well, to be precise, C++ got that from C.  What C++ adds to it:

   fy(a.fx(b), c)  (in Haskell,  fy (fx a b) c)

I wouldn't worry too much about one letter identifiers and so forth.
Many programmers will secretly be rather attracted to this kind of thing.

Donn Cave, [EMAIL PROTECTED]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Bird-style and blank lines

[Paulo Tanimoto]

Hello Wren,

On Sun, Sep 21, 2008 at 10:02 PM, wren ng thornton <[EMAIL PROTECTED]> wrote:
> By intention, probably. But by accident it is a lot more common than you
> might think. Accidents like corrupting the linebreaks or line wrapping in a
> file are quite prevalent when exchanging files across different platforms or
> medium formats. Consider also file type misdetection with other languages
> like HTML; or more convincingly, consider language interleaving. And
> there're always garden variety typos like dropping a bird track or adding a
> space before it.
>
> Usually such corruption is easily captured by code not compiling, but I
> think the big thing to consider when suggesting changes to the .lhs format
> is how it affects the robustness of detecting file corruption, typos, etc.
> The whitespace restriction captures a goodly number of typos mentioned
> above, though it may not be so helpful for the other corruptions.

Thanks for your thoughts.  I see your point and I agree it's an
important one.  For example, as you well know, if you produce HTML
with our Haskell libraries, there's some good chance you'll end up
with a ">" mark in the beginning of the line, because of the way the
tags are written.

However, that's HTML.  If you decide to interleave with other
languages, I don't think the probability of having a ">" unexpectedly
showing up in the beginning of the line is enough to justify making
this a rule.

In most languages it would be like writing a condition very close to
the end of the line and having it break in the middle:

 if (x
> y)

I think the restriction made sense when the report was written, but
what I'm arguing is that given new developments we have made, the
benefits of lifting the restriction are greater than keeping it.  At
least for me!  : )  To be sure, I'm weighting the chances that the
mandatory blank lines will save you versus the possibility of writing
in Bird-style more freely.

Again, please do point out other flaws in my argument.

Thanks,

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

[Haskell-cafe] Re: Bird-style and blank lines

[Paulo Tanimoto]

Hi John,

On Sun, Sep 21, 2008 at 3:33 PM, John MacFarlane <[EMAIL PROTECTED]> wrote:
> Note: I've changed pandoc in the repository so that it no longer
> shows these blank lines. The next point release will incorporate this
> change, making it easier to use pandoc for literate haskell. Note also
> that if you begin the code block with
>
> ~~~ {.haskell}
>
> the HTML output will be syntax-highlighted (assuming you compiled
> pandoc with the -fhighlighting flag).

Thank you for taking care of that for us.  I can check this in the
code, but does this apply only to (leading and trailing) blank lines
for haskell?  I like the idea of automatically highlighting if it's
available, it's working very well here.

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

Re: [Haskell-cafe] [m..n] question

[ajb]

G'day.

Quoting wren ng thornton <[EMAIL PROTECTED]>:


I'm sure you know *why* it's an infinite list[1], but as for why that's
useful I can't say. It has the feel of a bug in implementation, though
it is ...consistent.


Right.  I have no problem with [5,5..5] being logically an anamorphism,
but thinking abstractly about what I'd want it to mean, I'm pretty sure
I don't want it to mean an infinite list of 5's.

I asked a class of about a dozen bright undergrads about 10 years ago
what they thought it should mean, and IIRC the consensus seemed to be
split between [5] and [5,5].  Nobody correctly guessed what it actually
did.  So whether the behaviour is technically right or wrong, it violates
the Principle of Least Surprise.

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

Re: [Haskell-cafe] [m..n] question

[wren ng thornton]

[EMAIL PROTECTED] wrote:

Having said that, I don't know of a good reason why [5,5..5] is an
infinte list of 5's.


I'm sure you know *why* it's an infinite list[1], but as for why that's 
useful I can't say. It has the feel of a bug in implementation, though 
it is ...consistent.


As for the OP, like Python, Perl also takes [m..n] to be [] when n < m. 
They may not be as principled as Haskell or Erlang, but it does seem to 
be the consensus view.



[1] Because the "5,5.." yields an (unfoldr (Just . (\x -> (x,x)) . (+0)) 
5) stream but the "..5" only causes termination just as soon as the 
stream is surpassing 5, which it never will.


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

Re: [Haskell-cafe] Bird-style and blank lines

[wren ng thornton]

Paulo Tanimoto wrote:

[1] I don't think it's that common to add a ">" by accident.


By intention, probably. But by accident it is a lot more common than you 
might think. Accidents like corrupting the linebreaks or line wrapping 
in a file are quite prevalent when exchanging files across different 
platforms or medium formats. Consider also file type misdetection with 
other languages like HTML; or more convincingly, consider language 
interleaving. And there're always garden variety typos like dropping a 
bird track or adding a space before it.


Usually such corruption is easily captured by code not compiling, but I 
think the big thing to consider when suggesting changes to the .lhs 
format is how it affects the robustness of detecting file corruption, 
typos, etc. The whitespace restriction captures a goodly number of typos 
mentioned above, though it may not be so helpful for the other corruptions.


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

Re: [Haskell-cafe] Line noise

[Dan Piponi]

On Sun, Sep 21, 2008 at 7:49 PM, wren ng thornton <[EMAIL PROTECTED]> wrote:
> We inherited our use of spaces for function application from Lisp and
> friends, so "foo bar baz" looks perfectly natural to functionalists. But to
> those used to seeing "foo(bar, baz)" the meaning attached to the spaces is
> alien.

I have to admit, it took me a long time to be able to parse the
ML-style function notation in Haskell. I found it the biggest "barrier
to entry". I suspect that most of the complaints about line noise stem
from this - to beginners Haskell expressions just look like sequences
of identifiers with no apparent grammar to "bind" them together.
--
Dan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Line noise

[wren ng thornton]

Andrew Coppin wrote:
I hang out on another forum that is populated by various kinds of 
computer geeks. There's a fair few programmers in there, as well as 
nerds of every degree. And yet, every time I post anything written in 
Haskell, everybody complains that it "looks like line noise".


Actually, none of these things were mentioned. The things people have 
*actually* complained to me about are:

- Haskell expressions are difficult to parse.


To anyone who doesn't know the language, this seems quite true. Haskell 
was designed with a hyper-minimalist syntax, whereas C/C++/Java are very 
heavy with syntactic boilerplate. I am a devout fan of the minimalism, 
but it is something of a barrier to entry for those unwilling to 
consider anything that doesn't look familiar.


We inherited our use of spaces for function application from Lisp and 
friends, so "foo bar baz" looks perfectly natural to functionalists. But 
to those used to seeing "foo(bar, baz)" the meaning attached to the 
spaces is alien. The 'difference' in meaning for the two spaces only 
drives the alienness home, since (ubiquitous) currying is not well known 
or practiced outside of Haskell. Even with functionalists ---of the 
OCaml and SML ilk--- this use of spaces can be confusing if noone 
explains that function application binds tighter than all operators.


Similarly, we use linebreaks to denote various things whereas the 
syntax-heavy languages require a semicolon or similar delimiter. We are 
in fortuitous arms here since we can use the redundant {;} notation to 
sell new folks. Though it is wise to use the notation with the semicolon 
trailing on the previous line:


do {
foo;
bar;
baz;
}

rather than the more idiomatic leading version:

do { foo
   ; bar
   ; baz
   }

Again, the minimalist version that omits the {;} which lends a meaning 
to whitespace that syntax-heavy users are not familiar with. Here I 
think is largely a question of knowing your audience; the explicit 
version is better for any audience with many non-Haskell folks, even if 
it's a functional audience.


We also allow for omitting parentheses in many places required by other 
languages. In particular, the case...of construct mentioned previously. 
The if...then...else construct can have similar problems, though they 
are more easily overlooked by foreigners. Again this is easy to correct 
for when talking with outsiders: just add redundant parentheses.


The meaning of = and how it differs from -> are also quite subtle. 
Pattern matching and guards, like currying, are concepts that are quite 
alien to users of most other languages. The simplicity of their syntax 
in Haskell probably serves to further confuse questions of the syntax 
associated with =. I know from experience that these simple ideas can be 
a tough sale. Few languages have the notion that defining a function is 
the same as any other 'assignment' and so most languages have radically 
different syntaxes for the two. This trait of treating functions as 
first-class citizens tends to have large brain-breaking capabilities-- 
moreso than passing functions as arguments, it seems.



All of these are just basic things about Haskell's syntax and have 
nothing to do with all the interesting higher-order stuff which is 
really novel. It is unfortunate that there are so many people, 
intelligent people even, who are so hidebound as to be unwilling to 
gloss over syntax, but sadly it is the way of things. To be fair to 
them, the meanings assigned to whitespaces are not the sort of thing 
which is trivial to intuit. Perhaps we need a _Guide to Reading Haskell 
(for non-Haskell Programmers)_?


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

Re: [Haskell-cafe] [m..n] question

[Evan Laforge]

> In Haskell,
> "The sequence enumFromTo e1 e3 is the list [e1,e1+1,e1+2,...e3].
>  The list is empty if e1 > e3."

I like it, since it means that things like [n .. n + length m - 1]
work as expected when m is [].  Or say 'map (array!) [bsearch x ..
bsearch y - 1]'.

Tangent:  Of course, I would prefer the range be half-open, which is a
pretty consistent standard in the rest of the world.  I've had a
number of off by one errors from this, and from Array.bounds.  I guess
it's too late to fix those, though, even if there were agreement that
they need to be fixed.

This is similar to the way python considers that xs[4:2] is valid, and
is [].  Of course python uses half-open ranges so xs[4:4] is still [].
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Language.Haskell and strings

[Sterling Clover]

A quick glance at the code reveals that there's an instance of Pretty  
like such:


instance Pretty HsLiteral where
pretty (HsInt i)= integer i
pretty (HsChar c)   = text (show c)
pretty (HsString s) = text (show s)
pretty (HsFrac r)   = double (fromRational r)

That HsString instance is wrong for what you want, but there doesn't  
seem any way to simply override it. It should, however, be easy  
enough to add a further postprocessing layer to your already pretty- 
printed text, looking line by line for those lines that are a) too  
long and b) contain a very large quoted string. This layer could  
fairly easily do something reasonable to break the string up.  
Alternately, you could write a preprocessing layer that walked the  
source tree directly and chunked all HsStrings over a certain length  
into "" ++ "" ++ "", etc. At which point, the pretty  
printer could then decide how to distribute them properly across  
lines. Neither would be as perfect a solution as integrating with the  
pretty printer directly, but both would be helpful, and the latter  
could probably even be a one or two liner with an appropriate use of  
SYB.


--Sterl


On Sep 21, 2008, at 5:37 PM, Sukit Tretriluxana wrote:


Data.List

prettyStr :: Int -> String -> IO ()
prettyStr maxlen str = do
   putStr ("\"" ++ head brokenStr)
   mapM_ (\str -> putStr ("\\\n\\" ++ str)) (tail brokenStr)
   putStr "\"\n"
   where brokenStr = map (snd.unzip) $ groupBy (\_ (i,_) -> i `mod`  
maxlen /= 0) $ zip [0..] str


Ed

On Sat, Sep 20, 2008 at 4:14 PM, Maurí cio  
<[EMAIL PROTECTED]> wrote:

Hi,

I'm using Language.Haskell.* and would
like to know if it's possible to
pretty-print big strings like this:

""

into something like this:

"\
\\
\\
\\
\\
\\


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

[Haskell-cafe] Re: Language.Haskell and strings

[Maurí­cio]

Ed, thanks for your code. However,
I need to use something that fits
inside the whole pretty-print engine.
I would like to call parseModule
in some string of Haskell code and
get it nicely typed, with those big
strings inside.

Best,
Maurício

I'm not a Haskell expert but here the solution to your problem that I 
can think of.


import Data.List

prettyStr :: Int -> String -> IO ()
prettyStr maxlen str = do
   putStr ("\"" ++ head brokenStr)
   mapM_ (\str -> putStr ("\\\n\\" ++ str)) (tail brokenStr)
   putStr "\"\n"
   where brokenStr = map (snd.unzip) $ groupBy (\_ (i,_) -> i `mod` 
maxlen /= 0) $ zip [0..] str


Ed

On Sat, Sep 20, 2008 at 4:14 PM, Maurí­cio <[EMAIL PROTECTED] 
> wrote:


Hi,

I'm using Language.Haskell.* and would
like to know if it's possible to
pretty-print big strings like this:

""

into something like this:

"\
\\
\\
\\
\\
\\
\"

to respect the limit on number of
columns. Can you help me? Is it
possible to do that?

Thanks,
Maurício

___
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


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

Re: [Haskell-cafe] [m..n] question

[ajb]

G'day all.

Quoting "Richard A. O'Keefe" <[EMAIL PROTECTED]>:


I'm currently arguing that lists:seq(1, 0) should be [],
not an exception.  Oddly enough, I'm being beaten over the
head with Haskell, of all things.

[...]

Does anyone remember why the definition of enumFromTo is the way it is?


I don't know if this is the reason, but there's another nice property
that enumerations have, namely:

[p..q-1] ++ [q..r-1] == [p..r-1]  -- if p <= q <= r

If you think of the abstract semantics of ranges, this makes perfect
sense.  There needs to be a notation for empty ranges.

Having said that, I don't know of a good reason why [5,5..5] is an
infinte list of 5's.

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

[Haskell-cafe] [m..n] question

[Richard A. O'Keefe]

Erlang's equivalent of [m..n] is lists:seq(M, N),
which is currently defined to raise an exception when N < M.
In particular, lists:seq(1, N) returns a list of length N
when N > 0, but not when N = 0.
I'm currently arguing that lists:seq(1, 0) should be [],
not an exception.  Oddly enough, I'm being beaten over the
head with Haskell, of all things.

In Haskell,
"The sequence enumFromTo e1 e3 is the list [e1,e1+1,e1+2,...e3].
 The list is empty if e1 > e3."

It is being claimed that the reason for this is that "exceptions
are problematic" in Hasell, so the Haskell designers went out of
their way to make this function total whether it made sense or not.

I am currently suggesting that it's to keep the specification
(for integers) simple:
"[m..n] is the set of integers x such that m<=x<=n,
 listed in ascending order".
There's also the nice equivalence between
[m..n] and takeWhile (<= n) [m..].
Unfortunately, no such "abstract" characterisation of [m..n] is
mentioned in the report, and the takeWhile connection is
inferred from numericEnumFromTo.

Does anyone remember why the definition of enumFromTo is the way it is?

--
If stupidity were a crime, who'd 'scape hanging?







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

Re: [Haskell-cafe] Language.Haskell and strings

[Sukit Tretriluxana]

I'm not a Haskell expert but here the solution to your problem that I can
think of.

import Data.List

prettyStr :: Int -> String -> IO ()
prettyStr maxlen str = do
   putStr ("\"" ++ head brokenStr)
   mapM_ (\str -> putStr ("\\\n\\" ++ str)) (tail brokenStr)
   putStr "\"\n"
   where brokenStr = map (snd.unzip) $ groupBy (\_ (i,_) -> i `mod` maxlen
/= 0) $ zip [0..] str

Ed

On Sat, Sep 20, 2008 at 4:14 PM, Maurí­cio <[EMAIL PROTECTED]> wrote:

> Hi,
>
> I'm using Language.Haskell.* and would
> like to know if it's possible to
> pretty-print big strings like this:
>
> ""
>
> into something like this:
>
> "\
> \\
> \\
> \\
> \\
> \\
> \"
>
> to respect the limit on number of
> columns. Can you help me? Is it
> possible to do that?
>
> Thanks,
> Maurício
>
> ___
> 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] Parsing arguments and reading configuration

[Magnus Therning]

On Sun, Sep 21, 2008 at 4:02 PM, Sterling Clover <[EMAIL PROTECTED]> wrote:
> Alternately, just go with a map initially with default values. Then parse
> the command line args into a second map (especially if they're all of a
> format like -argname argvalue). Then lookup your args file with the command
> line map, and failing that the default map. Then read the args file and
> finally merge all three maps in the proper order. No need for monoid
> instances, special data types or any of that, so at a little cost in
> elegance a much more succinct way to get what you want. As a final step, you
> can always project the map values into a record type, to get some safety for
> the rest of your program. The entire process, aside from creating the
> record, should probably be no more than four or so lines.

Yes, that's the direction I'll end up going in, I think.  The idea
with the monoid was nice, but I couldn't really turn it into a usable
idea in my head, since the whole idea with an entity turns out to be
somewhat strange.  At least in the way I look at arguments.  However,
the idea of using a product to "merge" to configurations is
interesting and I think I might explore it more when I find the time.
(So far I've only identified that I probably will have use for
template haskell once I decide to play more with it.)

Thanks for the help and suggestions offered on the list.

/M

-- 
Magnus Therning (OpenPGP: 0xAB4DFBA4)
magnus＠therning．org Jabber: magnus＠therning．org
http://therning.org/magnus identi.ca|twitter: magthe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Line noise

[Albert Y. C. Lai]

I read from many reviews and shootouts that cell phones sold in Japan 
are more diverse, advanced, and user-friendly than cell phones sold in 
the US.


So I bought one, but to my dismay, both the offline manual and the 
on-screen menu are line noise.


Then I found a web dictionary to translate them word-for-word. The 
result is still unparsible, like "water submerge in don't ever". Are we 
supposed to be human beings or are we supposed to be all Master Yoda's?


Why and how the whole Japanese population put up with this epic fail is 
beyond me.


Everyone should use exclusively ancient Egyptian iconography. It is the 
only universally readable language.

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

Re: [Haskell-cafe] Line noise

[Mads Lindstrøm]

Andrew Coppin wrote:

> Idiomatic Haskell seems to consist *only* of single-letter variable 
> names. When did you last see a pattern like (customer:customers)? No, 
> it'd be (c:cs), which isn't very self-documenting. Ditto for type 
> variables by the way. (Map k v, anyone?) It also seems to be Haskell 
> convention to use "a" as a type variable; personally I always use "x". I 
> guess that's the algebra in my blood or something...
> 

The more abstract (generic) thing gets, the less likely you will be able
to find a telling name. And if you cannot find a telling name, you can
just as well make it short. And as Haskell is more abstract, we get more
short identifiers. E.g. in your earlier sorting function:

  qsort (x:xs) = ...

what would you propose to call the elements? Yes, if it sorted
customers, you call 'em (customer:customers). But you have made a very
abstract sorting function, which sorts a lot besides customers. And then
you are bound to end up with a non-telling name.

However, I will grant you that Map k v, could have used longer type
variables. But we are not alone with using one letter type variable
names http://java.sun.com/javase/6/docs/api/java/util/HashMap.html . And
frankly, in this specific case, I think most programmers (Haskell or
non-Haskell) will be able to guess what k and v means, when they are
standing right after Map.


Greetings,

Mads



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

[Haskell-cafe] Re: Bird-style and blank lines

[John MacFarlane]

> 3. Pandoc, via markdown, is a very interesting alternative to latex.
> Right now you can write a block of code like this:
> 
> ~~~
> > fact :: Integer -> Integer
> > fact 0 = 1
> > fact n = n * fact (n-1)
> ~~~
> 
> except that that won't work, precisely because you must have a blank
> line before and after the code.  Unfortunately, when you go and add
> the blank lines, the output will show them.

Note: I've changed pandoc in the repository so that it no longer
shows these blank lines. The next point release will incorporate this
change, making it easier to use pandoc for literate haskell. Note also
that if you begin the code block with

~~~ {.haskell}

the HTML output will be syntax-highlighted (assuming you compiled
pandoc with the -fhighlighting flag).

John

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

Re: [Haskell-cafe] Line noise

[Claus Reinke]

I posted a snippet of code which included the phrase

 mapM_ (\(n,v) -> putStrLn $ "[" ++ show n ++ "] = " ++ show v) (zip [0..] vs)


"Don't do that, then"?-) 


mapM_ putStrLn $
   map (\(n,v) -> "[" ++ show n ++ "] = " ++ show v) 
   (zip [0..] vs)

->
mapM_ putStrLn $
   map (\(n,v) -> "[" ++ show n ++ "] = " ++ show v) 
   (addIndices vs)

   where addIndices vs = zip [0..] vs
->
mapM_ putStrLn (map formatPair (addIndices vs))
   where { addIndices vs = zip [0..] vs;
formatPair (n,v) = "[" ++ show n ++ "] = " ++ show v }
-> ...
printList (map formatPair (addIndices vs))
   where { foreach :: [i] -> (i->IO ()) -> IO ();
foreach list action = mapM_ action list;

printList :: [String] -> IO ();
printList strings = foreach strings (\string->putStrLn string);

addIndices :: [x] -> [(Integer,x)];
addIndices vs = zip [0..] vs;

formatPair :: Show x => (Integer,x) -> String
formatPair (n,v) = "[" ++ show n ++ "] = " ++ show v }

Add comments (or replace types with comments, if you don't
want to explain type classes), perhaps use an explicit loop instead 
of mapM_, add salt and pepper (or some more parens), check 
for correctness, etc.


Not as cute as the one-liner, but quite possibly easier to read
and explain. Haskell isn't APL - boldly break the line barrier,
if you want to be understood by non-Haskellers. Breaking 
stuff up into digestible pieces, and going more slowly than

necessary, might also help. Once your readers understand
your code, you can add the one-liner and ask for applause
(or show how to derive the one-liner from the long-hand
version if you want to motivate people to read about Haskell).

Just another opinion,
Claus

"Dr., it hurts when I do that."


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

Re: [Haskell-cafe] broken link in documentation

[Manlio Perillo]

Sean Leather ha scritto:


Sorry if I use the mailing list for this, but in the documentation
of Control.Monad.RWS (and the other Control.Monad.* modules), the link
http://www.cse.ogi.edu/~mpj/  is broken.


If you're trying to find the correct link, perhaps it's this: 
http://web.cecs.pdx.edu/~mpj/




Already found with Google, thanks.

By the way, there is another problem with the generated documentation.
Links like
http://haskell.org/ghc/docs/latest/html/libraries/base/GHC-Conc.html#v%3Aatomically

don't seems to work with Opera (I'm using version 9.52, on Linux).

With all other browsers I have used, it works.
But Opera have problems with the ':' character in the fragment.



Sean



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

Re: [Haskell-cafe] broken link in documentation

[Sean Leather]

> Sorry if I use the mailing list for this, but in the documentation of
> Control.Monad.RWS (and the other Control.Monad.* modules), the link
> http://www.cse.ogi.edu/~mpj/  is broken.
>

If you're trying to find the correct link, perhaps it's this:
http://web.cecs.pdx.edu/~mpj/

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

Re: [Haskell-cafe] Updated formlets sample?

[Martin Huschenbett]

Hi Chris,

thanks for the updated example. Compiling works now. But when I try to 
run it I alway get error messages like


 ["input0 is not in the data","input1 is not in the data"]

Regards,

Martin.

Chris Eidhof schrieb:

Hey Martin,

On 19 sep 2008, at 04:14, Martin Huschenbett wrote:

I found a blog post concerning formlets [1] in the web. Since looks 
very interesting I tried to compile the sample code with recent 
versions of HAppS and formlets from hackage. But this didn't work as 
the API of formlets has changed since this post.


I tried to adopt the code to the new API but I was unable to finish 
this since there is a new monadic context I don't know to handle in 
the right way.


So my question is, is there an updated version of this sample code in 
the web or has anybody tried to adopt it and can send me the results?



Yes, I'm sorry for that. The API is still very immature and due to 
changes, that's also why it hasn't been officially announced yet. I've 
just put an updated example at http://hpaste.org/10568, hope that'll 
work for you. I guess we should build a small homepage / wikipage that 
always has an up-to-date example.


-chris

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

Re: [Haskell-cafe] Line noise

[Andrew Coppin]

Philippa Cowderoy wrote:

On Sun, 21 Sep 2008, Andrew Coppin wrote:

  

Actually, none of these things were mentioned. The things people have
*actually* complained to me about are:
- Haskell expressions are difficult to parse.



This is partly an "it's not braces, semicolons and function(application)" 
complaint, though not entirely.
  


One person complained that "case compare guess target of" was unclear. 
Of course, you and I know that "case" and "of" are actually language 
keywords, and hence this is really "case (compare guess target) of", 
which makes far more sense. (Your suggestion about syntax hilighting is 
relevant here!)



- Several standard library functions have names which clash badly with the
usual meanings of those names - e.g., "break", "return", "id".



For this one, I'm inclined to say "welcome to a new paradigm". Though 
having to tell my dad briefly that do isn't a loop construct was odd for a 
moment.
  


Haha! Nice...

I think "return" is a rather bad choice of name. But on the other hand, 
I can't think of a better one. And let's face it, anything has to be 
better than (>>=). (Most cryptic name ever?)



- Variable names such as "x" and "f" aren't fabulously helpful to lost
programmers trying to find their way.



So don't use them? Though I think f in particular has its place in higher 
order functions.
  


Idiomatic Haskell seems to consist *only* of single-letter variable 
names. When did you last see a pattern like (customer:customers)? No, 
it'd be (c:cs), which isn't very self-documenting. Ditto for type 
variables by the way. (Map k v, anyone?) It also seems to be Haskell 
convention to use "a" as a type variable; personally I always use "x". I 
guess that's the algebra in my blood or something...



The people I
spoke to also seemed pretty confused about the usage of (.) and ($), even
after I explained it a few times. Several people also voiced being puzzled
about Haskell's layout rules


Pointless style is definitely newbie-unfriendly. I can understand being 
puzzled by layout: ultimately I had to go read the description in the 
Report to be happy.
  


I posted a snippet of code which included the phrase

 mapM_ (\(n,v) -> putStrLn $ "[" ++ show n ++ "] = " ++ show v) (zip 
[0..] vs)


To somebody familiar with Haskell, that is as clear as day. But to a 
newbie... well *you* try explaining that you start at the left end, take 
the thing in brackets, process it from left to right, then take the 
other thing in brackets, process the right side of it, then pass that to 
putStrLn, oh, but that thing right at the left edge is the argument 
list, and then pass the whole lot to mapM_, which is... are you still 
with me??


As one experienced C++ programmer put it, "there is no clear flow from 
left to right or right to left". Personally I found that a little ironic 
comming from the language that gave us


 while (*x++ = *y++) { }

which is every bit as non-linear! ;-)

Have you tried showing people code that's been syntax highlighted? It's 
likely to help, especially with things like "does function application 
bind tighter?" where the highlighting is something of a cue. So is marking 
out = as important!
  


I'd just like to mention that HPaste is invaluable here! ;-)

Oddly, nobody seemed to take much notice when I did this though. (I 
guess most people had seen "oh look, another Haskell thread" and hit the 
thread-kill button by that point...)



Btw, (> x) reads much more easily as a predicate to most people than (x <=).
  


Er, yeah, you're probably right. IIRC, (> x) is actually implemented as 
(flip (>) x), whereas (x <) isn't. I doubt there's any efficiency 
difference though. (Surely GHC would inline such a trivial function...)


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

[Haskell-cafe] Bird-style and blank lines

[Paulo Tanimoto]

Hi,

I'm a big fan of literate haskell, especially Bird-style, but there's
one behavior that I find rather annoying: the requirement that code be
preceded and followed by a blank line.

Quoth the Report:
"To capture some cases where one omits an ">" by mistake, it is an
error for a program line to appear adjacent to a non-blank comment
line, where a line is taken as blank if it consists only of
whitespace."

While that is something I do anyway, since it looks better, there are
some cases where it would be nice to relax that.  For example:

1. I see a blog post in literate style, but the author did not provide
a .lhs file, sometimes copying and pasting the text will result in
code being adjacent to the text.  Then I have to fix that manually.

2. It would be nice for prototyping if you could quickly comment out
code just by removing a ">" character, instead of inserting "--".

3. Pandoc, via markdown, is a very interesting alternative to latex.
Right now you can write a block of code like this:

~~~
> fact :: Integer -> Integer
> fact 0 = 1
> fact n = n * fact (n-1)
~~~

except that that won't work, precisely because you must have a blank
line before and after the code.  Unfortunately, when you go and add
the blank lines, the output will show them.  You may tell me to change
what Pandoc does, but my point is that getting any markup to work with
Bird-style will have this issue.


The only argument I can see for keeping the requirement is what the
report says, but feel free to provide others [1].  However, isn't that
a bit like saying "we will require two semicolons because forgetting a
semicolon is the number one source of mistake for our programmers"?
Besides, I suspect most of us uses an editor with syntax highlighting
(vi, emacs, yi, etc), and then it's immediately obvious you forgot
something.

Would it be hard to change this behavior in GHC?  Is this open for
discussion for Haskell Prime?

Thanks,

Paulo

[1] I don't think it's that common to add a ">" by accident.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Drawing an existing image into a cairo surface?

[Rafal Kolanski]

Jefferson Heard wrote:

Sorry.  In a hurry, and I don't have a lot of time to read the
message, so if I'm offering a lot of info you already have, I
apologize.  The best thing to do is to allocate either a pixmap or
Gtk.DrawingArea -- you can then use widgetGetDrawable to get the
drawing context from it and newGC to take drawing context and get a
graphics context.  After you have a drawing and graphics context, you
can use drawPixbuf to draw or update any image you want, then use the
same DrawngArea for Cairo after you've drawing the image.

If you need more help with it, let me know, and I can send some code
that will do it later today.


I'd be very much interested, as I also want to load SVG files and my 
version of Gtk2Hs (Ubuntu Hardy) doesn't have 
Graphics.Rendering.Cairo.SVG ...


Your method can get around this problem I think.

Sincerely,

Rafal Kolanski.

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

[Haskell-cafe] broken link in documentation

[Manlio Perillo]

Hi.

Sorry if I use the mailing list for this, but in the documentation of 
Control.Monad.RWS (and the other Control.Monad.* modules), the link

http://www.cse.ogi.edu/~mpj/ is broken.


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

Re: [Haskell-cafe] Line noise

[Philippa Cowderoy]

On Sun, 21 Sep 2008, Andrew Coppin wrote:

> Actually, none of these things were mentioned. The things people have
> *actually* complained to me about are:
> - Haskell expressions are difficult to parse.

This is partly an "it's not braces, semicolons and function(application)" 
complaint, though not entirely.

> - Several standard library elements have unhelpful names such as "elem", "Eq"
> and "fst". (My favourite has to be "Ix". I mean, WTH?)



> - Several standard library functions have names which clash badly with the
> usual meanings of those names - e.g., "break", "return", "id".

For this one, I'm inclined to say "welcome to a new paradigm". Though 
having to tell my dad briefly that do isn't a loop construct was odd for a 
moment.

> - Variable names such as "x" and "f" aren't fabulously helpful to lost
> programmers trying to find their way.
> 

So don't use them? Though I think f in particular has its place in higher 
order functions.

> The people I
> spoke to also seemed pretty confused about the usage of (.) and ($), even
> after I explained it a few times. Several people also voiced being puzzled
> about Haskell's layout rules.
> 

Pointless style is definitely newbie-unfriendly. I can understand being 
puzzled by layout: ultimately I had to go read the description in the 
Report to be happy.

> I'm not sure what we *do* with all this data, but I found it interesting so I
> thought I'd share. ;-) I've spent the last few years trying to convert a few
> people to The Haskell Way(tm), but so far I haven't succeeded in the
> slightest. I just get yelled at for pointing white noise. Heh. Oh well!
> 

Have you tried showing people code that's been syntax highlighted? It's 
likely to help, especially with things like "does function application 
bind tighter?" where the highlighting is something of a cue. So is marking 
out = as important!

Btw, (> x) reads much more easily as a predicate to most people than (x 
<=).

-- 
[EMAIL PROTECTED]

Sometimes you gotta fight fire with fire. Most
of the time you just get burnt worse though.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] The ultimate insult?

[Micah Cowan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andrew Coppin wrote:
> "Delphi is usable. If you're a single hobbiest programmer, use whatever
> gets the job done. But as far as a career goes, I'd say even Haskell has
> better prospects than Delphi."
> 
> So "even Haskell" is better? Ouch!

Oh come on... has anyone here actually pursued learning Haskell because
they thought it would help them rake in the jobs? :)

...I did once have a manager who habitually listed Lisp as a requirement
for software positions, even though it wasn't actually going to be used
(it was all C, C++ and Perl). He just wanted prospective employees to
have had experience understanding a different paradigm (functional-ish
programming). I wonder whether he's updated that to "Lisp, Scheme or
Haskell"? XSLT would do as well, I suppose...

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer.
GNU Maintainer: wget, screen, teseq
http://micah.cowan.name/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI1pcH7M8hyUobTrERAoaDAJ4g+Eom8k52MlidTASj8JhtJDubhACdEhjN
MGXfz3V3/5HHwpMkTuKZ7Cw=
=5Q8x
-END PGP SIGNATURE-
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Line noise

[Andrew Coppin]

I hang out on another forum that is populated by various kinds of 
computer geeks. There's a fair few programmers in there, as well as 
nerds of every degree. And yet, every time I post anything written in 
Haskell, everybody complains that it "looks like line noise".


What do "normal" programmers find so puzzling about Haskell? You might 
guess some of the following:

- High-order functions.
- Lambda functions.
- Algebraic data types.
- Lazy evaluation.
- Recursion.
- Monads.

Actually, none of these things were mentioned. The things people have 
*actually* complained to me about are:

- Haskell expressions are difficult to parse.
- Several standard library elements have unhelpful names such as "elem", 
"Eq" and "fst". (My favourite has to be "Ix". I mean, WTH?)
- Several standard library functions have names which clash badly with 
the usual meanings of those names - e.g., "break", "return", "id".
- Variable names such as "x" and "f" aren't fabulously helpful to lost 
programmers trying to find their way.


If you take a "typical" lump of C or Java code, there's so much 
redundancy and noise in it that you can *usually* figure out vaguely 
what's going on, even if it doesn't completely make sense. When 
presented with a typical Haskell fragment... uh... well, good luck with 
that. Let's take Haskell's most celebrated example:


 qsort [] = []
 qsort (x:xs) = qsort (filter (x <) xs) ++ [x] ++ qsort (filter (x >=) xs)

To a novice, it's not actually real clear what the arguments to qsort 
are. You and I know that function application binds much more tightly 
than (++), but a novice isn't going to know that. You might also not 
immediately realise that "xs" is also an argument to filter, not just (x 
<) or whatever. The people I spoke to also seemed pretty confused about 
the usage of (.) and ($), even after I explained it a few times. Several 
people also voiced being puzzled about Haskell's layout rules.


I'm not sure what we *do* with all this data, but I found it interesting 
so I thought I'd share. ;-) I've spent the last few years trying to 
convert a few people to The Haskell Way(tm), but so far I haven't 
succeeded in the slightest. I just get yelled at for pointing white 
noise. Heh. Oh well!


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

Re: [Haskell-cafe] haskell shootout -- mandelbrot

[Tim Newsham]

Here's a whack at regex-dna:
  http://haskell.org/haskellwiki/Shootout/Parallel/RegexDNA

only modest speedup (memory bw bound?).  A regex engine that could
run several machines concurrently in one pass would prob be a big win.

Tim Newsham
http://www.thenewsh.com/~newsham/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] The ultimate insult?

[Andrew Coppin]

"Delphi is usable. If you're a single hobbiest programmer, use whatever 
gets the job done. But as far as a career goes, I'd say even Haskell has 
better prospects than Delphi."


So "even Haskell" is better? Ouch!

Still, in a bank-handed kind of way, I guess that means Haskell isn't as 
dead as Delphi yet, so it's also kind of a complement... of sorts...


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

Re: [Haskell-cafe] OpenSPARC project applicant chosen

[Brent Yorgey]

On Sat, Sep 20, 2008 at 11:03:41PM +0100, Duncan Coutts wrote:
> On Sat, 2008-09-20 at 23:50 +0300, Roman Cheplyaka wrote:
> > * Duncan Coutts <[EMAIL PROTECTED]> [2008-09-20 16:37:08+0100]
> > > If you want to follow the progress we will be using the existing ghc
> > > development mailing list:
> > > http://www.haskell.org/mailman/listinfo/cvs-ghc
> > > 
> > > and a corner of the ghc development wiki:
> > > http://hackage.haskell.org/trac/ghc/wiki/OpenSPARC
> > 
> > I hope Brent also will be publishing the news of the project in HWN.
> 
> I'm also hoping Ben might post updates to a blog, but I've not asked him
> yet.

If Ben does so, I would be happy to feature them prominently in the HWN!

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

Re: [Haskell-cafe] Drawing an existing image into a cairo surface?

[Jefferson Heard]

Sorry.  In a hurry, and I don't have a lot of time to read the
message, so if I'm offering a lot of info you already have, I
apologize.  The best thing to do is to allocate either a pixmap or
Gtk.DrawingArea -- you can then use widgetGetDrawable to get the
drawing context from it and newGC to take drawing context and get a
graphics context.  After you have a drawing and graphics context, you
can use drawPixbuf to draw or update any image you want, then use the
same DrawngArea for Cairo after you've drawing the image.

If you need more help with it, let me know, and I can send some code
that will do it later today.

-- Jeff

On Sun, Sep 21, 2008 at 10:09 AM, Rafal Kolanski <[EMAIL PROTECTED]> wrote:
>
> Bulat Ziganshin wrote:
>>
>> afair, Render is a super-IO monad so you can just lift any IO
>> operation to Render:
>>
>> x <- liftIO$ imageSurfaceCreateFromPNG file
>
> You are indeed correct.
>
> I feel really silly now, using unsafePerformIO in the IO monad. D'oh!
>
> Thank you very much!
>
> Rafal Kolanski.
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
I try to take things like a crow; war and chaos don't always ruin a
picnic, they just mean you have to be careful what you swallow.

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

Re: [Haskell-cafe] Hugs on the iphone

[Alberto R. Galdo]

And there it is!

Hugs98 is now available for installation on the iphone/ipod touch.

It is being served through the community sources at cydia, one the most
"official" unofficial installers for pwnaged iphone/ipods. That means that
if you have cydia already installed, if you look for hugs98 in the search
tab, it will be there waiting for you.

Just install hugs98 and/or hugs98-packages (for full library support), open
a terminal console and run 'hugs', everything should be familiar from now
on...

If not, just install cydia, and hugs98 is included in the default source
list.

And, for those brave of you, here are the packages for own/custom
installation:

com.wordpress.argaldo.hugs98 (interpreter and minimal packages) ->
http://iphone.sleepers.net/onepackage.php?bundleid=com.wordpress.argaldo.hugs98&db=

com.wordpress.argaldo.hugs98-packages (full library support) ->
http://iphone.sleepers.net/onepackage.php?bundleid=com.wordpress.argaldo.hugs98-packages&db=


Greets


On Sat, Sep 20, 2008 at 6:03 PM, Alberto R. Galdo <[EMAIL PROTECTED]
> wrote:

> Hi,
>
>I finally got hugs to compile for the iPhone 2.x firmware (
> pwnaged,obviously ).
>
>It was a matter of using the gcc compiler version distributed by apple
> in their iPhone SDK ( wich generates ARM code and suitable for
> cross-compiling C code in a mac ), autoconf 'configure' script tweaking and
> some system variables hacking here and there.
>
>So, now you ( and I ), people will be able to run your Haskell code
> directly on the iPhone using hugs ( hoping not to be the only one... ;-))
>
>I'm in the process of submitting the package to one of those "public"
> repositories of iphone apps... you'll have notices soon.
>
>If someone can resist, and like to have cydia compatible packages, just
> drop me a note and I'll send them to you by mail.
>
> Greets,
>
> Alberto
>
> On Mon, Sep 15, 2008 at 6:01 PM, Miguel Mitrofanov <[EMAIL PROTECTED]>wrote:
>
>> My iPhone (iPod Touch, actually) have 1.1.4 firmware, so there isn't any
>> code signing involved. I've just "configure"d and "make"d.
>>
>>
>> On 15 Sep 2008, at 09:47, Alberto R. Galdo wrote:
>>
>>  Cool! That's such a proof that it can be done...
>>>
>>> I had lots of problems trying to cross compile hugs from my mac to arm
>>> architecture ( seems that hugs codebase is not capable of cross compiling )
>>>
>>> And when compiling directly  on the iPhone, first there where problems
>>> with code signing, now with the configure script and C preprocessor sanity
>>> check...
>>>
>>> Any light on the topic from your experience?
>>>
>>> On 15/09/2008, at 7:24, Miguel Mitrofanov <[EMAIL PROTECTED]> wrote:
>>>
>>>  Did that.
 http://migmit.vox.com/library/photo/6a00e398c5c26f000500fa9696d8c40002.html

 On 14 Sep 2008, at 14:17, Alberto R. Galdo wrote:

  Hi, is there any chance of having hugs  compile for the iPhone?
>
> Cross-compiling? Compiling directly on the iPhone?
>
> Greets,
> Alberto
> ___
> 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] Parsing arguments and reading configuration

[Sterling Clover]

Alternately, just go with a map initially with default values. Then  
parse the command line args into a second map (especially if they're  
all of a format like -argname argvalue). Then lookup your args file  
with the command line map, and failing that the default map. Then  
read the args file and finally merge all three maps in the proper  
order. No need for monoid instances, special data types or any of  
that, so at a little cost in elegance a much more succinct way to get  
what you want. As a final step, you can always project the map values  
into a record type, to get some safety for the rest of your program.  
The entire process, aside from creating the record, should probably  
be no more than four or so lines.


--Sterl.

On Sep 19, 2008, at 8:39 PM, Antoine Latter wrote:

On Fri, Sep 19, 2008 at 7:35 PM, Antoine Latter  
<[EMAIL PROTECTED]> wrote:
I'm not sure how well it would hold up under maintenance, but you  
coud

have a config sum-type which is itself a monoid, and then create two
of them:



And by sum-type I mean product type.  Sheesh.

Although having your config options in a sum-type packed into a Set,
which is itself a Monoid is another option.  Then you get 'mempty' and
'mappend' for free.

I think I saw a blog-post or something detailing this, but I don't
have a book-mark.

-Antoine
___
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: Iteratee-based IO

[Adam Langley]

On Sat, Sep 20, 2008 at 8:17 PM, Don Stewart <[EMAIL PROTECTED]> wrote:
> Wonderful. Thanks Oleg, I'll be studying these on the trip up to
> Victoria. See you there!

Something similar is available in binary-strict[1], although there I
have (versions of) IE_Done, IE_Cont and (additionally) IE_Fail, for
indicating a parse failure.

The actual implementation is unpleasant, although functional.


[1]  
http://darcs.imperialviolet.org/darcsweb.cgi?r=binary-strict;a=headblob;f=/src/Data/Binary/Strict/IncrementalGet.hs


-- 
Adam Langley [EMAIL PROTECTED] http://www.imperialviolet.org
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ropes

[Nicolas Pouillard]

Excerpts from Rafael Gustavo da Cunha Pereira Pinto's message of Sat Sep 20 
12:54:26 +0200 2008:
> I am doing the ICFPC07 task right now, to learn Haskell and tried to use the
> Sequence, but the final code is too damn slow (a few iterations per
> minute!).

Is your structure a sequence of *Char*s, if so you should consider to use a
sequence of strict bytestrings of a given size (chunks).

> The DNA needs only 2 operations: head (or take) and concat.
> 
> I am thinking in using ropes for the DNA and sequences for all the rest
> (patterns, templates and RNA).
> 
> On Fri, Sep 19, 2008 at 23:15, Ryan Ingram <[EMAIL PROTECTED]> wrote:
> 
> > I think Data.Sequence uses fingertrees which are pretty fast.
> >
> > I used a handgrown rope-like structure for ICFPC07 but I wish I had
> > known about Sequence; it would have likely just been better.
> >
> >  -- ryan
> >
> > 2008/9/19 Rafael Gustavo da Cunha Pereira Pinto <
> > [EMAIL PROTECTED]>:
> > > Hi all,
> > >
> > > Is there any implementation of the rope data structure in Haskell?
> > >
> > > I couldn't find any on Hackage, and I am intending to implement it.
> > >
> > > Regards,
> > >
> > > Rafael Gustavo da Cunha Pereira Pinto
> > > Electronic Engineer, MSc.
> > >
> > > ___
> > > Haskell-Cafe mailing list
> > > Haskell-Cafe@haskell.org
> > > http://www.haskell.org/mailman/listinfo/haskell-cafe
> > >
> > >
> >
> 

-- 
Nicolas Pouillard aka Ertai


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

Re: [Haskell-cafe] Drawing an existing image into a cairo surface?

[Rafal Kolanski]

Bulat Ziganshin wrote:

afair, Render is a super-IO monad so you can just lift any IO
operation to Render:

x <- liftIO$ imageSurfaceCreateFromPNG file


You are indeed correct.

I feel really silly now, using unsafePerformIO in the IO monad. D'oh!

Thank you very much!

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

Re[2]: [Haskell-cafe] Drawing an existing image into a cairo surface?

[Bulat Ziganshin]

Hello Rafal,

Sunday, September 21, 2008, 5:43:14 PM, you wrote:

>  withImageSurfaceFromPNG file $ \png -> do
>  w <- renderWith png $ imageSurfaceGetWidth png
>  h <- renderWith png $ imageSurfaceGetHeight png

this is very idiomatic Haskell, consider it as a sort of RAII. you may
even omit additional tab here:

>  withImageSurfaceFromPNG file $ \png -> do
>  w <- renderWith png $ imageSurfaceGetWidth png
>  h <- renderWith png $ imageSurfaceGetHeight png
>  ...

afair, Render is a super-IO monad so you can just lift any IO
operation to Render:

x <- liftIO$ imageSurfaceCreateFromPNG file



-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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

Re: [Haskell-cafe] Packages

[Andrew Coppin]

Austin Seipp wrote:

Cabal can handle things for you like when your package depends on
external data files; when cabal compiles the code it autogenerates a
module which you import that will give you the path name to where-ever
it is installed, which is nifty in case you for example are uploading
a language for an interpreter and want to store the languages' prelude
somewhere.
  


OK, fair enough. I'm unlikely to ever need this personally, but it has 
utility.



It also allows for more tight constraints on dependent package versions
i.e. with it you can specify the exact package and version you need to
build (for example, parsec < 2.1 && > 3.0 which a few packages do.)
With --make you would have to include a lot of -hide-package flags and
a lot of other things, too.
  


So you're saying that using Cabal allows you to check that all your 
build dependencies are already installed?


(Certainly just building something with GHC means that if some package 
isn't installed, you're going to have a hard time figuring out what's 
missing.)



It is also naturally the easiest way to actually install libraries
since it will register that library with ghc-pkg for you.
  


Mmm, OK.

2. If we already have a Cabal package, why do we also need seperate 
packages for Arch, Gentoo, Debian...? Isn't Cabal cross-platform?



Having these packages available as native packages for a package
manager lets you distribute applications easier for example; if
someone just wants to install  from say, the archlinux user
repository (which is source-based, mind you - the official repo is
binary based,) it may also depend on parsec, haskell98, HTTP,
etc.. Having these packages available natively to the manager means it
can track the dependencies and install the application by itself -
this is useful for example if someone just wants to use a haskell
application but they don't code haskell (example: darcs or pandoc.)

Of course, if you are doing haskell development, the best possible way
to go (IMO) full-blown cabal install.


Having native packages for stand-alone applications such as Darcs makes 
sense to me - after all, you don't need to install GCC just to use (say) 
KEdit, so why would you need to install GHC and build Darcs from source 
just to use it? However, managing individual Haskell libraries via the 
local package management system seems slightly redundant to me.


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

Re: [Haskell-cafe] Drawing an existing image into a cairo surface?

[Rafal Kolanski]

I finally came up with a solution that suits my context. For those 
interested, I'm supplying it here.


Safely get a surface containing your .png image (note that the surface 
has to be freed when you're done with it using surfaceFinish)


imageSurfaceCreateFromPNG :: FilePath -> IO Surface
imageSurfaceCreateFromPNG file =
withImageSurfaceFromPNG file $ \png -> do
w <- renderWith png $ imageSurfaceGetWidth png
h <- renderWith png $ imageSurfaceGetHeight png
surf <- createImageSurface FormatRGB24 w h
renderWith surf $ do
setSourceSurface png 0 0
paint
return surf

Now the unsafe part (hack until I have an associative list storing my 
images to pull into relevant pages for rendering):


unsafeLoadPNG file = unsafePerformIO $ imageSurfaceCreateFromPNG file

This allows drawing an image directly in a Render () context:

paintImage :: FilePath -> Double -> Double -> Render ()
paintImage file x y = do
surf <- return $ unsafeLoadPNG file
setSourceSurface surf x y
paint

Looking at this irc log from 2005:
  http://www.cse.unsw.edu.au/~dons/code/irc-logs/05.11.20
someone's had this problem before, and although they did not show their 
solution, I think it might've been similar to mine.


Hope this helps the next person to get stuck.

Sincerely,

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

Re: [Haskell-cafe] Drawing an existing image into a cairo surface?

[Rafal Kolanski]

Austin Seipp wrote:

Excerpts from Rafal Kolanski's message of Sun Sep 21 07:28:37 -0500 2008:

The best I can find is withImageSurfaceFromPNG, but I can't
make it work.


Why not? Seems to me all you need to do is:

 withImageSurfaceFromPNG "blah.png" $ \surface -> do
...

Lots of code is written this way (create a resource, pass it to a
function and then release it after the function is over.)


Well, but withImageSurfaceFromPNG only lets you work within that scope
and wipes out the surface straight afterwards ...


I tried playing around with unsafePerformIO but that just gets me into:


Without further context as to what you are doing, I really see no
reason why you would have to use unsafePerformIO at all.


The context is, I want to render a multi-page PDF with a variety of
things on it, so I have something like (very simplified):

main :: IO ()
main = do
withPDFSurface outputFile pdfWidth pdfHeight renderer

renderer s = renderWith s renderPresentation

renderPresentation = do
myDraw1
showPage
myDraw2
showPage

myDraw1 = do
setSourceRGB 1 0 0
setLineWidth 1
moveTo 0 0
lineTo 100 100
stroke

so renderPresentation will have type Render ()

Now lets say I want to draw an image on page 2, that will only appear on
page 2 ... with one image, your technique makes sense to me, but with
multiple images on multiple pages, I don't understand how to make it scale.

Perhaps this code is very naive, but I'm kinda new to the pure world of
Haskell.

Sincerely,

Rafal Kolanski.

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

Re: [Haskell-cafe] Drawing an existing image into a cairo surface?

[Austin Seipp]

Excerpts from Rafal Kolanski's message of Sun Sep 21 07:28:37 -0500 2008:
> The best I can find is withImageSurfaceFromPNG, but I can't
> make it work.

Why not? Seems to me all you need to do is:

 withImageSurfaceFromPNG "blah.png" $ \surface -> do
...

Lots of code is written this way (create a resource, pass it to a
function and then release it after the function is over.)

> I tried playing around with unsafePerformIO but that just gets me into:

Without further context as to what you are doing, I really see no
reason why you would have to use unsafePerformIO at all.

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

[Haskell-cafe] Drawing an existing image into a cairo surface?

[Rafal Kolanski]

Hi,

I'm trying to, in addition to all the other things on my cairo surface,
pull some images in from .png files. I've googled, I've looked in the
docs, but there isn't any way I can see to load a .png file into a
surface. The best I can find is withImageSurfaceFromPNG, but I can't
make it work.

The C guys can do:
 image = cairo_image_surface_create_from_png("blah.png");
and then:
 cairo_set_source_surface(cr, image, 10, 10);
 cairo_paint(cr)

I tried playing around with unsafePerformIO but that just gets me into:
/build/buildd/cairo-1.6.0/src/cairo-surface.c:382:
cairo_surface_reference: Assertion
`((*&(&surface->ref_count)->ref_count) > 0)' failed.

Are any gtk2hs people around who can throw me in the right direction?

Sincerely,

Rafal Kolanski.

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

Re: [Haskell-cafe] OpenSPARC project applicant chosen

[Bulat Ziganshin]

Hello Duncan,

Saturday, September 20, 2008, 7:37:08 PM, you wrote:

> http://haskell.org/opensparc/

the page says that you still search for a student

how community server may be used to measure performance? i'm
interested in doing some benchmarks but afaiu this needs exclusive
access for some time?


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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

Re: [Haskell-cafe] Packages

[Don Stewart]

andrewcoppin:
> Ivan Lazar Miljenovic wrote:
> >On Sat, 20 Sep 2008 23:38:16 -0700
> >Don Stewart <[EMAIL PROTECTED]> wrote:
> >
> >  
> >>And by now you know where which distro has it:
> >>
> >>http://aur.archlinux.org/packages.php?ID=18343
> >>
> >
> >I'm sorry, Don, but you're late... Gentoo had it last night (as soon as 
> >Matthew
> >told me he uploaded it to Hackage)! ;-)
> >  
> 
> I'm sorry, I'm confused...
> 
> 1. How is putting something into a Cabal package different from just 
> handing somebody the source code and telling them to run ghc --make?
> 
> 2. If we already have a Cabal package, why do we also need seperate 
> packages for Arch, Gentoo, Debian...? Isn't Cabal cross-platform?
> 
> 3. Why isn't any of this explained in print anywhere?

It's all about users.  To see more of the philosophy here, check out,

Haskell: Batteries Included
http://www.cse.unsw.edu.au/~dons/papers/CPJS08.html

Ubiquitous, easy, complete Haskell.

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

Re: [Haskell-cafe] Packages

[Austin Seipp]

Excerpts from Andrew Coppin's message of Sun Sep 21 02:44:10 -0500 2008:
> 1. How is putting something into a Cabal package different from just 
> handing somebody the source code and telling them to run ghc --make?

Cabal can handle things for you like when your package depends on
external data files; when cabal compiles the code it autogenerates a
module which you import that will give you the path name to where-ever
it is installed, which is nifty in case you for example are uploading
a language for an interpreter and want to store the languages' prelude
somewhere.

It also allows for more tight constraints on dependent package versions
i.e. with it you can specify the exact package and version you need to
build (for example, parsec < 2.1 && > 3.0 which a few packages do.)
With --make you would have to include a lot of -hide-package flags and
a lot of other things, too.

It is also naturally the easiest way to actually install libraries
since it will register that library with ghc-pkg for you.

> 2. If we already have a Cabal package, why do we also need seperate 
> packages for Arch, Gentoo, Debian...? Isn't Cabal cross-platform?

Having these packages available as native packages for a package
manager lets you distribute applications easier for example; if
someone just wants to install  from say, the archlinux user
repository (which is source-based, mind you - the official repo is
binary based,) it may also depend on parsec, haskell98, HTTP,
etc.. Having these packages available natively to the manager means it
can track the dependencies and install the application by itself -
this is useful for example if someone just wants to use a haskell
application but they don't code haskell (example: darcs or pandoc.)

Of course, if you are doing haskell development, the best possible way
to go (IMO) full-blown cabal install since you will always get the
most up-to-date code - plus mixing and matching native package
managers and e.g. cabal install doesn't really work well IME; for
example if you want to install alex from macports, it will
automatically install ghc too, even if you actually have it installed,
but you didn't install it through macports (I just used the .dmg file
that Manual Chak. made.) Likewise you may want to get something and it
might depend on the HTTP library - it could very well already be
installed via cabal-install, but the native manager won't dig into GHC
to find out and will instead just work based on what it knows is
installed in its package database.

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

[Haskell-cafe] Packages

[Andrew Coppin]

Ivan Lazar Miljenovic wrote:

On Sat, 20 Sep 2008 23:38:16 -0700
Don Stewart <[EMAIL PROTECTED]> wrote:

  

And by now you know where which distro has it:

http://aur.archlinux.org/packages.php?ID=18343



I'm sorry, Don, but you're late... Gentoo had it last night (as soon as Matthew
told me he uploaded it to Hackage)! ;-)
  


I'm sorry, I'm confused...

1. How is putting something into a Cabal package different from just 
handing somebody the source code and telling them to run ghc --make?


2. If we already have a Cabal package, why do we also need seperate 
packages for Arch, Gentoo, Debian...? Isn't Cabal cross-platform?


3. Why isn't any of this explained in print anywhere?

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