Re: [Haskell-cafe] What's in a name?

[Henning Thielemann]

On Fri, 15 Aug 2008, Andrew Coppin wrote:


Henning Thielemann wrote:


http://www.haskell.org/haskellwiki/Hierarchical_module_names



Right. So if for some reason two people both developed a hashtable 
implementation (say), we would end up with two modules both called 
Data.Hashtable, but (hopefully) the packages themselves would be called 
james-hashtable and chris-hashtable (or something).


Now both packages can be installed at once, but when I say "import 
Data.Hashtable", GHC has no way to know which one I mean. That doesn't sound 
too clever to me...


Although it is possible to hide packages by GHC options, we should not do 
this, because several libraries might use different Hash tables and it 
would not be possible to write a program which uses many of these 
libraries. It's better to add a distinguishing part to the module name, 
like Data.HashTable.Coppin or so.

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

Re: [Haskell-cafe] What's in a name?

[wren ng thornton]

David Menendez wrote:

On Fri, Aug 15, 2008 at 7:24 PM, wren ng thornton <[EMAIL PROTECTED]> wrote:

(( For readers who don't want to slog through the rest of this post, the
conclusion is that I feel an agile packaging system is an imperative, as
discussed above. The trick is finding a way to be agile without creating a
maintenance and conflict nightmare. But given the imperative: baby,
bathwater, etc. ))


Have you seen the PackageMounting proposal?



Essentially, each package would get its own hierarchy, which would
then be attached to the larger module hierarchy at compile-time
according to compiler options, or Cabal data, or methods as yet
unseen. If, for some reason, you need to import two versions of the
same package, or two packages that have a module name collision, you
can change the default mounting point for one or both.



I hadn't seen it. It looks pretty nice. It reminds me of the recent 
discussion about hierarchical imports for the Gtk library.[1]


A feature that's typically nice in grafting systems is to allow 
re-grafting (and pruning), so that after a package is mounted 
subpackages can be moved around (or removed). These features add 
complication to building the right tree before linking, but it adds a 
great deal of power and flexibility.


A typical use case is when your project is using some other large 
project and you want to mark certain parts of that project as 
deprecated, unsafe, overridden, etc so that your own code doesn't 
accidentally use it. Defensive programming and all that.


Of course, used improperly, it also lets you create byzantine structures 
that channel mind-bending energies that keep systems administrators 
tossing and turning at nights.


[1] 
http://www.haskell.org/pipermail/haskell-cafe/2008-June/thread.html#44133



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

Re: [Haskell-cafe] What's in a name?

[Robert Greayer]

--- On Sat, 8/16/08, wren ng thornton <[EMAIL PROTECTED]> wrote:
> Personally, I have major qualms with the Java package
> naming scheme. In 
> particular, using domain names sets the barrier to entry
> much too high 
> for casual developers (e.g. most of the Haskell user base).
> Yes, DNs are 
> cheap and plentiful, but this basically requires a lifetime
> lease of the 
> DN in question and the migration path is covered in
> brambles. The 
> alternative is simply to lie and make up a DN, in which
> case this 
> degenerates into the exact same resource quandary as doing
> nothing (but 
> with high overhead in guilt or registration paperwork).

This does sound in theory like a real problem; the actual practice has worked 
out much differently for Java: the existence of durable domains willing to host 
development of small libraries for the Java space are plentiful.  In other 
words, the barrier to entry has turned out to be quite low.

Nevertheless, hackage of course provides an even cheaper alternative to 
DN-based naming, since package names registered on hackage are guaranteed 
unique (across the hackage-using community).  The ubiquitous convention for 
Haskell could easily be that if you want your library to interoperate without 
conflict, register it on hackage (otherwise you take your chances, just as in 
Java if you ignore the DN-based convention).  Having the ability to use package 
names to avoid module-name conflicts (i.e. an agile packaging system, in your 
words) would still be needed.

The need to *recompile* to avoid conflicts is a problem though, if haskell 
aspires to attract commercial package vendors.  I don't know how it could be 
avoided though.

rcg



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

Re: [Haskell-cafe] What's in a name?

[David Menendez]

On Fri, Aug 15, 2008 at 7:24 PM, wren ng thornton <[EMAIL PROTECTED]> wrote:
> (( For readers who don't want to slog through the rest of this post, the
> conclusion is that I feel an agile packaging system is an imperative, as
> discussed above. The trick is finding a way to be agile without creating a
> maintenance and conflict nightmare. But given the imperative: baby,
> bathwater, etc. ))

Have you seen the PackageMounting proposal?



Essentially, each package would get its own hierarchy, which would
then be attached to the larger module hierarchy at compile-time
according to compiler options, or Cabal data, or methods as yet
unseen. If, for some reason, you need to import two versions of the
same package, or two packages that have a module name collision, you
can change the default mounting point for one or both.

-- 
Dave Menendez <[EMAIL PROTECTED]>

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

Re: [Haskell-cafe] ANN: logfloat

[wren ng thornton]

Felipe Lessa wrote:

I should point out just in case that 1 / 0 isn't infinity on all
Fractional types (e.g. Rational). I guess it shouldn't cause a problem
with your library, but a warning on the Haddock entry would be nice to
avoid surprising people who didn't see the internal implementation.

Nice lib, by the way. Thanks,


Ah, interesting. I missed that one. I'm wondering if there's any 
portable notion of infinity on Rationals. GHC.Real uses 1%0, but Hugs 
gives an overflow for toRational(1/0)... Time to go digging.


In the mean time I'll add a note about it. Thanks.

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

Re: [Haskell-cafe] ANN: logfloat

[Felipe Lessa]

I should point out just in case that 1 / 0 isn't infinity on all
Fractional types (e.g. Rational). I guess it shouldn't cause a problem
with your library, but a warning on the Haddock entry would be nice to
avoid surprising people who didn't see the internal implementation.

Nice lib, by the way. Thanks,

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

Re: [Haskell-cafe] ANN: logfloat

[wren ng thornton]

wren ng thornton wrote:


-- Announcing: logfloat 0.8.2


[...]
The code is very heavily documented, largely for pedagogical reasons. 
Since Haddock doesn't play very nicely with literate Haskell, there's 
also a small lhs2hs converter script which gets run when you call: 
runhaskell Setup.hs haddock. This converter requires the bytestring 
package. The library proper does not, so I didn't include this 
dependency for the package itself.



It looks like Hackage's build bot doesn't do `runhaskell Setup.hs 
haddock` for generating the documentation. So for now at least, the 
documentation can be found at:


http://code.haskell.org/~wren/logfloat/dist/doc/html/logfloat/

I'll work on correcting that in the future.

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

Re: [Haskell-cafe] ANN: logfloat

[Don Stewart]

wren:
> 
> -- Announcing: logfloat 0.8.2
> 
> 
> I just released a new package, logfloat, for manipulating log-domain 
> floating numbers.
> 

Arch Linux package now ready,

http://aur.archlinux.org/packages.php?ID=18832
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ANN: logfloat

[wren ng thornton]

-- Announcing: logfloat 0.8.2


I just released a new package, logfloat, for manipulating log-domain 
floating numbers.


The main reason for casting numbers into the log-domain is to prevent 
underflow when multiplying many small probabilities as is done in Hidden 
Markov Models and other statistical models often used for natural 
language processing. The log-domain also helps prevent overflow when 
multiplying many large numbers. In rare cases it can speed up numerical 
computation (since addition is faster than multiplication, though 
logarithms are exceptionally slow), but the primary goal is to improve 
accuracy of results. A secondary goal has been to maximize efficiency 
since these computations are frequently done within a /O(n^3)/ loop.


The Data.Numeric.LogFloat module provides a new data type LogFloat which 
handles all the conversions and optimizations and can be treated as any 
other number thanks to type classes.




-- Links


Homepage:
http://code.haskell.org/~wren/

Hackage:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/logfloat

Darcs:
http://code.haskell.org/~wren/logfloat



-- Details


The package's version numbers start from 0.8 since this began as a port 
of my Perl module for doing the same thing.


The code is very heavily documented, largely for pedagogical reasons. 
Since Haddock doesn't play very nicely with literate Haskell, there's 
also a small lhs2hs converter script which gets run when you call: 
runhaskell Setup.hs haddock. This converter requires the bytestring 
package. The library proper does not, so I didn't include this 
dependency for the package itself.


The package uses GHC's rewrite rules to do log/exp fusion. In general, 
since a newtype is used, the module shouldn't add overhead (beyond 
crossing the log/exp boundary). In the future I'll be experimenting with 
strictness as well to try to ensure that everything stays in registers 
for those /O(n^3)/ loops. I'm not sure whether it'd be helpful to keep a 
lazy version around as well...


The LogFloat type is restricted to non-negative numbers. In the future 
I'll also add a signed variant for those who aren't just doing 
statistical work.


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

Re: [Haskell-cafe] What's in a name?

[wren ng thornton]

Sean Leather wrote:
That doesn't work if you want to use two packages that have modules 
sharing the same hierarchical name, and this is a definite possibility 
given my statements above. Of course, having the ability to import 
modules from specific packages [1] would fix this, but only as long as 
the package names are also unique.


Personally, I like the Java package naming scheme recommendation. It 
scales better, because each package name uses the organization or URI to 
uniquely identify a subset.



Personally, I have major qualms with the Java package naming scheme. In 
particular, using domain names sets the barrier to entry much too high 
for casual developers (e.g. most of the Haskell user base). Yes, DNs are 
cheap and plentiful, but this basically requires a lifetime lease of the 
DN in question and the migration path is covered in brambles. The 
alternative is simply to lie and make up a DN, in which case this 
degenerates into the exact same resource quandary as doing nothing (but 
with high overhead in guilt or registration paperwork).


The way CPAN is set up is much more egalitarian, though mired in a bit 
much administrivia for casual developers.


The orthogonality of package names to module names is something I 
consider very much a feature, and not a bug. The only other packaging 
system I've seen to offer this is Monticello for Squeak/SmallTalk, and 
I've missed it ever since. By making packages orthogonal that allows for 
developers to create drop-in replacement packages that offer the same 
module services as another package, without needing to alter any code 
that uses the old package (save relinking/recompiling). This is the same 
advantage as allowing different modules to offer the same functions 
(e.g. having Data.ByteString as a drop-in for the [ ]-portions of the 
Prelude), but lifted up to the next tier.



The question then is two-fold. First, is the question of how to minimize 
the problems of ambiguity and how to resolve conflicts when they arise. 
Second, is the question of whether this is really the job of Haskell, 
the language itself, or whether it is more appropriately dealt with by 
the build tools, e.g. Cabal. I'll deal a bit more with the latter question.


(( For readers who don't want to slog through the rest of this post, the 
conclusion is that I feel an agile packaging system is an imperative, as 
discussed above. The trick is finding a way to be agile without creating 
a maintenance and conflict nightmare. But given the imperative: baby, 
bathwater, etc. ))



I do like your (Sean Leather's) patch for being able to specify package 
names in source code, though I'd think something like Core's 
"package:module.module.module" syntax would be better if it gets adopted 
into Haskell'. I do however think that specifying the package should be 
optional, with conflicts to be resolved by commandline flags or via 
Cabal. Without this we loose the ability to have drop-in replacement 
packages, which in turn greatly complicates migration paths. The 
community is still young, but forks do happen and we would do best to 
allow for forwards compatibility whenever possible.


This approach also gives the same sort of split control as the various 
{-# FOO #-} pragma give. As an ad-hoc GHC solution, adding a new PACKAGE 
pragma would be better than just using a string there. In theory we can 
already do this with OPTIONS_GHC, though that pragma seems not to 
respect the -package option. Of course, the new pragma should be 
position restricted to make it obvious which imports it applies to, 
rather than assuming to apply to the whole file (i.e. by putting it 
where you put the strings).



One issue with this and Java's scheme of just concatenating package 
names onto module names is that they offer no provisions for specifying 
version restrictions. For a PACKAGE pragma we could design it deal with 
this too, since the modules themselves don't have versions. Of course 
this starts getting into hairy issues which Cabal was designed to 
resolve, so porting it back to the compiler seems misguided.


Perhaps a simpler option, for a Haskell' world, would be to give modules 
versions and give the import syntax some way of specifying the version 
to use. Sticking with something like the current packaging system, 
packages would just specify the module versions they provide, and those 
versions need not be related to the version of the package itself. This 
has the benefit of being able to release and maintain legacy packages, 
once the world has forked or moved on to a new major version.


As an addendum to this, it could be helpful if "package" names (i.e. 
alphanumeric sequences) were a part of the module version specification. 
This way a package hfoo-legacy could continue to provide the hfoo-1.24 
versions of modules, and it would be the package that forked off rather 
than forcing the new hfoo package to rename itself to break ties from 
the legacy code.


Another ability tha

Re: [Haskell-cafe] What's in a name?

[David Menendez]

Whoops. Forgot to hit "reply all".

On Wed, Aug 13, 2008 at 4:58 PM, Andrew Coppin
<[EMAIL PROTECTED]> wrote:
> The naming of cats is a difficult matter...
>
> Ahem. So as you may have noticed, we seem to have a profusion of packages
> all called "binary" or something dangeriously similar. There's also several
> "MD5" packages. I could point out a few others. So what I'm wondering is...
> Do we have a formal convention for the naming of packages and/or the naming
> of the modules they contain? How are name collisions supposed to be avoided?
> (E.g., Java uses domain names for this. If I write a package named Foo, I
> put all the classes in orphi.me.uk.Foo.*)

So far as I know, there are no rules about naming packages, except
that Hackage won't allow two packages with the same name.

There is a loose convention about fitting modules into the larger
hierarchy. Personally, I think trying to fit modules from different
packages into the same hierarchy is a mistake, in that you either get
the same module name used twice (meaning that both packages can't be
used in the same program), or need to insert the package name into the
name.

Thus, "Test.HUnit", "Test.QuickCheck",
"Text.ParserCombinators.Parsec", "Text.Pretty.HughesPJ", and so forth.

We'd be better off just using the package name as the first element of
the module names. Or, if that's objectionable, using something like
"Package.Parsec" or "Lib.Parsec" (or "Hackage.Parsec", since Hackage
enforces the uniqueness of package names).

This is arguably one area where Java does better than Haskell. The
resulting module names are long, but they don't require coordination
and they don't raise tricky questions. (Quick, what's the difference
between Data.* and Control.*? Is QuickCheck under Debug.* or Test.*?)

-- 
Dave Menendez <[EMAIL PROTECTED]>

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

Re: [Haskell-cafe] What's in a name?

[Sean Leather]

> Andrew Coppin wrote:
> > Now both packages can be installed at once, but when I say "import
> > Data.Hashtable", GHC has no way to know which one I mean. That doesn't
> sound
> > too clever to me...
>

I agree, Andrew. The hierarchical module approach depends on a global
resource for allocating names (or at least everybody agreeing on the scheme
of choice). By trying to make all module names equal descriptive categories,
it doesn't scale well. There are too many possibilities for overlap or
different categorizations for the same thing.

Felipe Lessa wrote:

> GHC can hide packages or, put it another way, can show only the
>  packages you want. That's what Cabal does when compiling. For example,
> try to remove some package from the dependencies and watch GHC
> complain.
>

That doesn't work if you want to use two packages that have modules sharing
the same hierarchical name, and this is a definite possibility given my
statements above. Of course, having the ability to import modules from
specific packages [1] would fix this, but only as long as the package names
are also unique.

Personally, I like the Java package naming scheme recommendation. It scales
better, because each package name uses the organization or URI to uniquely
identify a subset.

Sean

[1] http://thread.gmane.org/gmane.comp.lang.haskell.cvs.ghc/29319 - But
notice the not really intended for general use bit.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] GHC 6.8.3 package for ArchLinux x86_64

[Don Stewart]

kolar:
> Hello all,
> 
>  Is there any plan to make a package for archlinux x86_64 with (more or 
> less) complete GHC 6.8.3 binaries? I know I can download and install 
> myself, usually I do so myself, but the reason is to prepare a list of 
> packages for others. So far, the 6.8.2 is available.
> 
>  Is there any possibility I could help with it? Some guidelines, how to 
> prepare such a package, submit to a right place, etc.
> 

We can certainly host a ghc 6.8.3 package -- these are easy to produce. 
However, since it's identical to 6.8.2, functionality-wise, we're not
upgrading officially yet.

If you're interested in Arch/Haskell, I'd also recommend hanging out 
in the #arch-haskell IRC channel on freenode, where most design 
decisions get discussed.

Finally, I'd like to mention we now have 489 Haskell packages natively 
bundled for Arch. :) Kick butt!


http://aur.archlinux.org/packages.php?O=0&L=0&C=0&K=arch-haskell&SB=v&SO=d&PP=25&SeB=m&do_Orphans=

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

Re: [Haskell-cafe] Re: Fwd: Haskell job opportunity: Platform Architect at Peerium, Inc.

[Don Stewart]

DekuDekuplex:
> On Thu, 14 Aug 2008 14:17:05 -0700, Don Stewart <[EMAIL PROTECTED]>
> wrote:
> 
> >[...]
> >
> >Skills:
> >Proficiency and a strong interest in Haskell programming :)  
> >
> >Bachelor's degree in computer science or equivalent from a four-year
> >institution.
> 
> This is the required background of Haskell-related job offering that I
> am looking for, except that I happen to be located in Tokyo, Japan.

Have you been to the Tokyo user group meetings? 
They're organised by Starling software, so perhaps a good place to
network,
 
 http://www.starling-software.com/en/tsac.html
  

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

Re: [Haskell-cafe] What's in a name?

[Felipe Lessa]

On Fri, Aug 15, 2008 at 2:37 PM, Andrew Coppin
<[EMAIL PROTECTED]> wrote:
> Now both packages can be installed at once, but when I say "import
> Data.Hashtable", GHC has no way to know which one I mean. That doesn't sound
> too clever to me...

GHC can hide packages or, put it another way, can show only the
packages you want. That's what Cabal does when compiling. For example,
try to remove some package from the dependencies and watch GHC
complain.

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

Re: [Haskell-cafe] What's in a name?

[Andrew Coppin]

Henning Thielemann wrote:


On Thu, 14 Aug 2008, Henning Thielemann wrote:


On Wed, 13 Aug 2008, Andrew Coppin wrote:


The naming of cats is a difficult matter...

Ahem. So as you may have noticed, we seem to have a profusion of 
packages all called "binary" or something dangeriously similar. 
There's also several "MD5" packages. I could point out a few others. 
So what I'm wondering is... Do we have a formal convention for the 
naming of packages and/or the naming of the modules they contain?


There is a page on the Wiki which lists several common top-level 
module names. Unfortunately www.haskell.org seems to be down currently.


http://www.haskell.org/haskellwiki/Hierarchical_module_names



Right. So if for some reason two people both developed a hashtable 
implementation (say), we would end up with two modules both called 
Data.Hashtable, but (hopefully) the packages themselves would be called 
james-hashtable and chris-hashtable (or something).


Now both packages can be installed at once, but when I say "import 
Data.Hashtable", GHC has no way to know which one I mean. That doesn't 
sound too clever to me...


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

Re: [Haskell-cafe] whatever happened to sendFile?

[Brandon S. Allbery KF8NH]

On 2008 Aug 15, at 9:34, Tony Finch wrote:


On Thu, 14 Aug 2008, Brandon S. Allbery KF8NH wrote:
Actually, while I'm not sure how Linux does it, on the *BSDs pipes  
are

actually socketpairs.


Not any more. FreeBSD replaced the socketpair implementation with a  
faster

one in 1996 and OpenBSD imported it soon after. NetBSD imported it in
2001 and Mac OS X in 10.4 (2005). Dragonfly BSD forked from FreeBSD  
after

the new pipe code was introduced.



Hm.  Somehow I missed that.

In any case, the real point is that historically (the socketpair stuff  
goes back to 4.2BSD) pipes were often considered a special case of  
sockets, so documentation referring to pipes might well actually mean  
or include sockets.  Someone will have to inspect the Linux splice()  
implementation to see if it actually works on sockets.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH


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

Re: [Haskell-cafe] Cabal has trouble with projects that have both src and lib directories?

[Nicholas Andrews]

Sorry, I meant runhaskell Setup.hs . To clarify, I DO
have a Setup.hs, and am getting the error in my original post when
running it.

On Fri, Aug 15, 2008 at 1:42 AM, Ketil Malde <[EMAIL PROTECTED]> wrote:
> "Nicholas Andrews" <[EMAIL PROTECTED]> writes:
>
>> $ runhaskell blah.cabal configure
>
> blah.cabal isn't a Haskell file, you need a file Setup.hs that you can
> 'runhaskell'.  Setup.hs need only contain the following three lines:
>
> #!/usr/bin/env runhaskell
> import Distribution.Simple
> main = defaultMain
>
> -k
> --
> If I haven't seen further, it is by standing in the footprints of giants
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] RE: Pretty Print, text or ++?

[Paul Keir]

Awesome! Thanks to you all. I'll start with

hsep[map a, b, c, d]

and then I can try changing hsep for other things.

Paul


-Original Message-
From: Benedikt Huber [mailto:[EMAIL PROTECTED]
Sent: Fri 15/08/2008 14:53
To: Paul Keir
Cc: haskell-cafe@haskell.org
Subject: Re: Pretty Print, text or ++?
 
Paul Keir schrieb:
 > Hi there,
 >
 > I'm writing a pretty printer using the Text.PrettyPrint library, and
 > there's a pattern I'm coming across quite often. Does anyone know 
whether,
 >
 > text (a ++ b ++ c ++ d)
 > or
 > text a <+> text b <+> text c <+> text d
 >
 > runs quicker?

Hi Paul,

 > text (a ++ b ++ c ++ d)

is the same as

 > hcat (map text [a,b,c,d])

(horizontal concatenation without seperating spaces)
while

 > text a <+> text b <+> text c <+> text d

corresponds to

 > hsep (map text [a,b,c,d])

or

 > text (unwords [a,b,c,d])

With <+>, hsep or hcat, pretty printing won't choose the best layout -
you tell the pretty printer to layout documents 'beside'.
For autolayout, see sep,cat and the paragraph-fill variants fsep and fcat.

Regarding performance: `unwords` will propably be a little faster 
(untested), but less flexible. There is no asymptotic overhead when 
using the pretty printer.

cheers,
benedikt

 >
 > Cheers,
 > Paul
 >
 >
 > 
 >
 > ___
 > 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] Pretty Print, text or ++?

[John Van Enk]

Paul,

I'm sorry, I ignored the "PrettyPrint" part and latched onto the "faster"
part. You definitely don't want concat. I was looking at run-time. :)

/jve

On Fri, Aug 15, 2008 at 9:35 AM, Paul Keir <[EMAIL PROTECTED]> wrote:

>  Thanks,
>
> So you're recommending:
>
> text (concat [a,b,c,d,e])
>
> Might this not transform my pretty printing into ugly printing; when longer
> strings are used?
>
> Paul
>
>
>
> -Original Message-
> From: [EMAIL PROTECTED] on behalf of John Van Enk
> Sent: Fri 15/08/2008 14:31
> To: Paul Keir
> Cc: haskell-cafe@haskell.org
> Subject: Re: [Haskell-cafe] Pretty Print, text or ++?
>
> Paul,
>
> Something tells me you might want to look at `concat':
>
> concat :: [[a]] -> [a]
>
> /jve
>
>
> 2008/8/15 Paul Keir <[EMAIL PROTECTED]>
>
> >  Hi there,
> >
> > I'm writing a pretty printer using the Text.PrettyPrint library, and
> > there's a pattern I'm coming across quite often. Does anyone know
> whether,
> >
> > text (a ++ b ++ c ++ d)
> > or
> > text a <+> text b <+> text c <+> text d
> >
> > runs quicker?
> >
> > Cheers,
> > Paul
> >
> > ___
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> >
>
>
> --
> /jve
>
>


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

Re: [Haskell-cafe] Pretty Print, text or ++?

[Malcolm Wallace]

"Paul Keir" <[EMAIL PROTECTED]> wrote:

> text (a ++ b ++ c ++ d)

The above is going to be ugly-printed onto a single line, whilst this:

> text a <+> text b <+> text c <+> text d

has a chance to be pretty-printed onto several lines, if each component
is individually long.

It doesn't really matter which expression is faster, if they do
different things.  The first solution fails to use the pretty-printing
API to any significant advantage, whilst the second is more in the
spirit of the thing.

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

[Haskell-cafe] Re: Pretty Print, text or ++?

[Benedikt Huber]

Paul Keir schrieb:
> Hi there,
>
> I'm writing a pretty printer using the Text.PrettyPrint library, and
> there's a pattern I'm coming across quite often. Does anyone know 
whether,

>
> text (a ++ b ++ c ++ d)
> or
> text a <+> text b <+> text c <+> text d
>
> runs quicker?

Hi Paul,

> text (a ++ b ++ c ++ d)

is the same as

> hcat (map text [a,b,c,d])

(horizontal concatenation without seperating spaces)
while

> text a <+> text b <+> text c <+> text d

corresponds to

> hsep (map text [a,b,c,d])

or

> text (unwords [a,b,c,d])

With <+>, hsep or hcat, pretty printing won't choose the best layout -
you tell the pretty printer to layout documents 'beside'.
For autolayout, see sep,cat and the paragraph-fill variants fsep and fcat.

Regarding performance: `unwords` will propably be a little faster 
(untested), but less flexible. There is no asymptotic overhead when 
using the pretty printer.


cheers,
benedikt

>
> Cheers,
> Paul
>
>
> 
>
> ___
> 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] Re: Pretty Print, text or ++?

[Christian Maeder]

Paul Keir wrote:

Hi there,

I'm writing a pretty printer using the Text.PrettyPrint library, and 
there's a pattern I'm coming across quite often. Does anyone know whether,


text (a ++ b ++ c ++ d)
or
text a <+> text b <+> text c <+> text d

runs quicker?


Don't worry about speed. Write it as:

  hsep[text a, text b, text c, text d]

and you can easily change hsep to sep or fsep, if the lines get too 
long. (And maybe you have some other docs that may be part of the list 
that are not constructed using "text".)


HTH Christian

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

RE: [Haskell-cafe] Pretty Print, text or ++?

[Paul Keir]

Thanks,

So you're recommending:

text (concat [a,b,c,d,e])

Might this not transform my pretty printing into ugly printing; when longer 
strings are used?

Paul


-Original Message-
From: [EMAIL PROTECTED] on behalf of John Van Enk
Sent: Fri 15/08/2008 14:31
To: Paul Keir
Cc: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] Pretty Print, text or ++?
 
Paul,

Something tells me you might want to look at `concat':

concat :: [[a]] -> [a]

/jve


2008/8/15 Paul Keir <[EMAIL PROTECTED]>

>  Hi there,
>
> I'm writing a pretty printer using the Text.PrettyPrint library, and
> there's a pattern I'm coming across quite often. Does anyone know whether,
>
> text (a ++ b ++ c ++ d)
> or
> text a <+> text b <+> text c <+> text d
>
> runs quicker?
>
> Cheers,
> Paul
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>


-- 
/jve

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

Re: [Haskell-cafe] whatever happened to sendFile?

[Tony Finch]

On Thu, 14 Aug 2008, Brandon S. Allbery KF8NH wrote:
>
> Actually, while I'm not sure how Linux does it, on the *BSDs pipes are
> actually socketpairs.

Not any more. FreeBSD replaced the socketpair implementation with a faster
one in 1996 and OpenBSD imported it soon after. NetBSD imported it in
2001 and Mac OS X in 10.4 (2005). Dragonfly BSD forked from FreeBSD after
the new pipe code was introduced.

Tony.
-- 
f.anthony.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
SOUTHEAST ICELAND: SOUTHWESTERLY BACKING SOUTHEASTERLY 4 OR 5, OCCASIONALLY 6
IN NORTH. MODERATE. SHOWERS. MODERATE OR GOOD.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Pretty Print, text or ++?

[John Van Enk]

Paul,

Something tells me you might want to look at `concat':

concat :: [[a]] -> [a]

/jve


2008/8/15 Paul Keir <[EMAIL PROTECTED]>

>  Hi there,
>
> I'm writing a pretty printer using the Text.PrettyPrint library, and
> there's a pattern I'm coming across quite often. Does anyone know whether,
>
> text (a ++ b ++ c ++ d)
> or
> text a <+> text b <+> text c <+> text d
>
> runs quicker?
>
> Cheers,
> Paul
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>


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

[Haskell-cafe] Pretty Print, text or ++?

[Paul Keir]

Hi there,

I'm writing a pretty printer using the Text.PrettyPrint library, and there's a 
pattern I'm coming across quite often. Does anyone know whether,

text (a ++ b ++ c ++ d)
or
text a <+> text b <+> text c <+> text d

runs quicker?

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

Re: [Haskell-cafe] Phantoms

[Jules Bean]

Henning Thielemann wrote:

instance on Foo a?


Btw. was anything bad about the suggested Haskell98 solution?


You called it 'non-hacky'; I would call it 'slightly hacky' since, IMO, 
it qualifies as a hack around a deficiency in the class system.


However, I don't think there is anything wrong with it. After all it's 
the same trick the Prelude uses for instance Show [Char].


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

[Haskell-cafe] Re: Fwd: Haskell job opportunity: Platform Architect at Peerium, Inc.

[Benjamin L . Russell]

On Thu, 14 Aug 2008 14:17:05 -0700, Don Stewart <[EMAIL PROTECTED]>
wrote:

>[...]
>
>Skills:
>Proficiency and a strong interest in Haskell programming :)  
>
>Bachelor's degree in computer science or equivalent from a four-year
>institution.

This is the required background of Haskell-related job offering that I
am looking for, except that I happen to be located in Tokyo, Japan.

Does anybody know of any job offerings with this required background
that are either located within commuting distance, or that allow
telecommuting?

Alternatively, equivalent Haskell-related offerings in other areas of
Japan, in both academia and industry, could also prove to be
alternatives.  In particular, Haskell-related career paths that would
lead from a Bachelor's degree in Computer Science to documenting
Haskell libraries/tools and writing beginner-level Haskell textbooks
would be of particular interest.

-- Benjamin L. Russell

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

Re: [Haskell-cafe] GHC 6.8.3 package for ArchLinux x86_64

[Dusan Kolar]

  Is there any plan to make a package for archlinux x86_64 with (more or
less) complete GHC 6.8.3 binaries? I know I can download and install myself,
usually I do so myself, but the reason is to prepare a list of packages for
others. So far, the 6.8.2 is available.



Hi, Arch ghc maintainer here.

We have opted to delay the upgrade of ghc because that version
includes some regressions that we're not so wild about, and because
upgrading ghc leads to lots of recompilations to prevent breakage.

Do you have a specific need for that version?
  
Well, just wanted to get ready some stuff for the coming academic year.  
So the main reason was to force everybody involved to use the version 
and, if possible, with not too much effort. If it is much effort to make 
the package, I can prepare a workaround, no problem, thanks.


Dusan

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

Re: [Haskell-cafe] GHC 6.8.3 package for ArchLinux x86_64

[Vesa Kaihlavirta]

On 8/15/08, Dusan Kolar <[EMAIL PROTECTED]> wrote:
> Hello all,
>
>   Is there any plan to make a package for archlinux x86_64 with (more or
> less) complete GHC 6.8.3 binaries? I know I can download and install myself,
> usually I do so myself, but the reason is to prepare a list of packages for
> others. So far, the 6.8.2 is available.
>
>   Is there any possibility I could help with it? Some guidelines, how to
> prepare such a package, submit to a right place, etc.

Hi, Arch ghc maintainer here.

We have opted to delay the upgrade of ghc because that version
includes some regressions that we're not so wild about, and because
upgrading ghc leads to lots of recompilations to prevent breakage.

Do you have a specific need for that version?

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

[Haskell-cafe] GHC 6.8.3 package for ArchLinux x86_64

[Dusan Kolar]

Hello all,

 Is there any plan to make a package for archlinux x86_64 with (more or 
less) complete GHC 6.8.3 binaries? I know I can download and install 
myself, usually I do so myself, but the reason is to prepare a list of 
packages for others. So far, the 6.8.2 is available.


 Is there any possibility I could help with it? Some guidelines, how to 
prepare such a package, submit to a right place, etc.


 Thanks,

   Dusan

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

Re: [Haskell-cafe] Phantoms

[Henning Thielemann]

On Fri, 15 Aug 2008, Jules Bean wrote:


Malcolm Wallace wrote:

Andrew Coppin <[EMAIL PROTECTED]> wrote:


instnace Show (Foo Int) ...
instnace Show (Foo Double) ...


...WHY did I not think of this myself? o_O


Because it is not Haskell'98?  It requires {-# LANGUAGE 
OverlappingInstances #-}


No it doesn't?

It requires the much more semantically simple -XFlexibleInstances, as far as 
I know.


Overlapping would only be needed if there was also a polymorphic instance on 
Foo a?


Btw. was anything bad about the suggested Haskell98 solution?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe