Re[2]: [Haskell-cafe] Pure hashtable library

[Bulat Ziganshin]

Hello Don,

Thursday, August 28, 2008, 10:32:43 AM, you wrote:

> Seems like you can make a pure hashtable by unsafePerformIO on the
> impure one, and exporting only 'lookup'..

probably yes, but it will lose a bit of performance due to incremental
building of hashtable. actually, writing HT module from scratch is
very easy - all we need is a prime searching function (in order to
establish array size). everything else:

data HT a b = HT (a->Int) (Array Int [(a,b)])

create size hash list = HT hashfunc
   (accumArray (flip (:))
   []
   (0, arrsize-1)
   (map (\(a,b) -> (hashfunc a,b)) list)
   )

  where arrsize =  head$ filter (>size)$ iterate (\x->3*x+1) 1
hashfunc a  =  hash a `mod` arrsize


lookup a (HT hash arr) = List.lookup a (arr!hash a)




-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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

Re: [Haskell-cafe] Haskell Propeganda

[Don Stewart]

ketil:
> Aaron Tomb <[EMAIL PROTECTED]> writes:
> 
> >> Huh? Type safety buys [...] nothing about dereferencing null
> >> pointers, which are the moral equivalent of Nothing.
> 
> > What type safety buys you, in my mind, is that Nothing is only a valid
> > value for explicit Maybe types. In cases where you don't use Maybe,
> > the "null" situation just can't occur. In languages with null
> > pointers, any pointer could possibly be null.
> 
> To write Haskell that is obviously safe, you need to check all cases
> of algebraic data types - both Just and Nothing.
> To do something similar in C, you need to check every pointer for NULL.  
> 
> The great thing about Maybe is that once I've checked it isn't
> Nothing, I can extract the value and dispense with further checks.
> 
>   foo mbx = maybe default (bar x) mbx

And GHC will warn me when I forget to check all cases, and prevent me
from compiling at all, if I don't do any check.

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

Re: [Haskell-cafe] Haskell Propeganda

[Ketil Malde]

Aaron Tomb <[EMAIL PROTECTED]> writes:

>> Huh? Type safety buys [...] nothing about dereferencing null
>> pointers, which are the moral equivalent of Nothing.

> What type safety buys you, in my mind, is that Nothing is only a valid
> value for explicit Maybe types. In cases where you don't use Maybe,
> the "null" situation just can't occur. In languages with null
> pointers, any pointer could possibly be null.

To write Haskell that is obviously safe, you need to check all cases
of algebraic data types - both Just and Nothing.
To do something similar in C, you need to check every pointer for NULL.  

The great thing about Maybe is that once I've checked it isn't
Nothing, I can extract the value and dispense with further checks.

  foo mbx = maybe default (bar x) mbx
  
Usually, you don't want to go on processing a NULL pointer anyway, but
in C, 'bar' might be called with NULL, so it'll have to check it
again.  And 'bar' is less likely than 'foo' to be able to do
anything sensible with NULL, and thus 'foo' needs to be able to handle
errors returned from 'bar', too.

I think an important reason we get NULL pointer SEGVs is that all this
checking when you "know" it can't happen gets tedious, and thus
ignored and forgotten.

-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

Re: [Haskell-cafe] Pure hashtable library

[Don Stewart]

bulat.ziganshin:
> Hello Richard,
> 
> Thursday, August 28, 2008, 5:28:46 AM, you wrote:
> 
> >>> trie: O(len)*O(width)
> >>> hashed trie: O(len)
> >>> hash: O(len)
> 
> > If "width" here refers to the branching factor of the trie,
> > it's actually O(len.lg(width)), and the width that matters
> > is not the *possible* number of choices but the *actual*
> > number.
> 
> i thought about using list to hold all variations at the trie node. with
> a (balanced) tree at each node we will have even more overheads
> 
> 
> > The great problem with hash tables is devising good hash
> > functions.  There is a vast literature about hash tables,
> > but there is very little about how to design good hash
> > functions for anything other than numbers and maybe strings.
> 
> 1. tries also work only for strings and other lists
> 2. i don't want to go into discussing well-known pluses and minuses of
> data structures. my point was just that we have great alternative to
> trees/tries which should be implemented many years ago. i've used a
> lots of assoclists in my program, sometimes this really degraded
> performance (although it's yet another question - why tree/trie
> structures doesn't provide simple List.lookup replacement function and
> why i'm so lazy to still not learning their APIs)
> 

Seems like you can make a pure hashtable by unsafePerformIO on the
impure one, and exporting only 'lookup'..

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

Re[2]: [Haskell-cafe] Pure hashtable library

[Bulat Ziganshin]

Hello Richard,

Thursday, August 28, 2008, 5:28:46 AM, you wrote:

>>> trie: O(len)*O(width)
>>> hashed trie: O(len)
>>> hash: O(len)

> If "width" here refers to the branching factor of the trie,
> it's actually O(len.lg(width)), and the width that matters
> is not the *possible* number of choices but the *actual*
> number.

i thought about using list to hold all variations at the trie node. with
a (balanced) tree at each node we will have even more overheads


> The great problem with hash tables is devising good hash
> functions.  There is a vast literature about hash tables,
> but there is very little about how to design good hash
> functions for anything other than numbers and maybe strings.

1. tries also work only for strings and other lists
2. i don't want to go into discussing well-known pluses and minuses of
data structures. my point was just that we have great alternative to
trees/tries which should be implemented many years ago. i've used a
lots of assoclists in my program, sometimes this really degraded
performance (although it's yet another question - why tree/trie
structures doesn't provide simple List.lookup replacement function and
why i'm so lazy to still not learning their APIs)



-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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

Re: [Haskell-cafe] Is there GHC 6.8.3 on Ubuntu?

[Ketil Malde]

"Rafael Gustavo da Cunha Pereira Pinto" <[EMAIL PROTECTED]>
writes:

> Is there anyone packing GHC 6.8.3 for Ubuntu Hardy?

The next Ubuntu release (8.10 Intrepid), seems to come with 6.8.2 as
well.  

If you want to pack 6.8.3, go for it!  If you just wanted to use it,
I've had success using the binary snapshots on previous Ubuntus.

-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

Re: [Haskell-cafe] Pure hashtable library

[Jules Bean]

Jason Dusek wrote:

  I would much rather have a pure Trie that is foldable. If we
  have a Trie, we get a space efficient sorted list, too.



Well, Data.Sequence can be used as a space efficient sorted list which 
is Foldable - if you make the decision to insert elements into it in a 
sorted way, obviously.


It's a fingertree not a trie, of course.

What advantages would a Trie have over Data.Sequence?

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

Re: [Haskell-cafe] Haskell Propeganda

[Johannes Waldmann]

The ECMA Eiffel standard has
?Teither a void reference or a reference to an instance of T
!Ta reference to an instance of T
 Tsame as !T in ECMA Eiffel; used to be same as ?T


similarly, C# "invented" Maybe and called it Nullable:
http://msdn.microsoft.com/en-us/library/1t3y8s4s(VS.80).aspx

NB: this is very good "propaganda" also in the sense that
as a teacher you can say: if you learn Haskell now,
with high probability you are learning things that will appear
in following years' versions of C#/Java/whatever.

Best regards, J.W.



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

Re: [Haskell-cafe] Pure hashtable library

[Jason Dusek]

  I would much rather have a pure Trie that is foldable. If we
  have a Trie, we get a space efficient sorted list, too.

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

Re: [Haskell-cafe] dangling symbolic links

[Brandon S. Allbery KF8NH]

On 2008 Aug 28, at 0:46, Nicolas Frisby wrote:

I think I've exhausted my options without catching exceptions.

If I have an invalid symbolic link, how can I identify that it exists?



getSymbolicLinkStatus vs. getFileStatus?  The former will return if  
the link exists, the latter if its target does.  (Where not returning  
means throwing an exception in IO.)


--
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

[Haskell-cafe] Re: dangling symbolic links

[Nicolas Frisby]

Ah the magic of using a mailing list... I just realized that using
getDirectoryContents lists the entry.

Still, a "doesLinkExist" function might be nice...

On Wed, Aug 27, 2008 at 11:46 PM, Nicolas Frisby
<[EMAIL PROTECTED]> wrote:
> I think I've exhausted my options without catching exceptions.
>
> If I have an invalid symbolic link, how can I identify that it exists?
>
> (Sorry about the line wrap.)
>
> tmp$ ls -l# no tricks up my sleeve, empty directory
> tmp$ touch foo
> tmp$ ln -s foo bar
> tmp$ ls -l
> total 8
> lrwxr-xr-x   1 nfrisby  nfrisby  3 Aug 27 23:29 bar -> foo
> -rw-r--r--   1 nfrisby  nfrisby  0 Aug 27 23:29 foo
> tmp$ ghc -e 'System.Directory.doesFileExist "bar"'
> True
> tmp$ rm foo
> tmp$ ls -l
> total 8
> lrwxr-xr-x   1 nfrisby  nfrisby  3 Aug 27 23:29 bar -> foo
> tmp$ ghc -e 'System.Directory.doesFileExist "bar"'  # it follows
> the broken link
> False
> tmp$ ghc -e 'System.Posix.Files.fileExist "bar"'# the
> POSIX API also follows
> False
> tmp$ ghc -e 'System.Posix.Files.isSymbolicLink `fmap`
> System.Posix.Files.getFileStatus "bar"'  # so does this one POSIX API
> also follows
> *** Exception: bar: getFileStatus: does not exist (No such file or directory)
> tmp$ ghc -e 'System.Posix.Files.isSymbolicLink `fmap`
> System.Posix.Files.getSymbolicLinkStatus "bar"'   # the most
> successful so far
> True
> tmp$ rm bar  # but it isn't an existence check...
> tmp$ ls -l
> tmp$ ghc -e 'System.Posix.Files.isSymbolicLink `fmap`
> System.Posix.Files.getSymbolicLinkStatus "bar"'
> *** Exception: bar: getSymbolicLinkStatus: does not exist (No such
> file or directory)
>
> Is there a way to check for the existence of a symbolic link without
> testing if getSymbolicLinkStatus raises an exception?
>
> This is with Darwin Kernel Version 8.11.1, GHC 6.8.2,
> directory-1.0.0.0, and unix-2.3.0.0.
>
> Thanks.
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] dangling symbolic links

[Nicolas Frisby]

I think I've exhausted my options without catching exceptions.

If I have an invalid symbolic link, how can I identify that it exists?

(Sorry about the line wrap.)

tmp$ ls -l# no tricks up my sleeve, empty directory
tmp$ touch foo
tmp$ ln -s foo bar
tmp$ ls -l
total 8
lrwxr-xr-x   1 nfrisby  nfrisby  3 Aug 27 23:29 bar -> foo
-rw-r--r--   1 nfrisby  nfrisby  0 Aug 27 23:29 foo
tmp$ ghc -e 'System.Directory.doesFileExist "bar"'
True
tmp$ rm foo
tmp$ ls -l
total 8
lrwxr-xr-x   1 nfrisby  nfrisby  3 Aug 27 23:29 bar -> foo
tmp$ ghc -e 'System.Directory.doesFileExist "bar"'  # it follows
the broken link
False
tmp$ ghc -e 'System.Posix.Files.fileExist "bar"'# the
POSIX API also follows
False
tmp$ ghc -e 'System.Posix.Files.isSymbolicLink `fmap`
System.Posix.Files.getFileStatus "bar"'  # so does this one POSIX API
also follows
*** Exception: bar: getFileStatus: does not exist (No such file or directory)
tmp$ ghc -e 'System.Posix.Files.isSymbolicLink `fmap`
System.Posix.Files.getSymbolicLinkStatus "bar"'   # the most
successful so far
True
tmp$ rm bar  # but it isn't an existence check...
tmp$ ls -l
tmp$ ghc -e 'System.Posix.Files.isSymbolicLink `fmap`
System.Posix.Files.getSymbolicLinkStatus "bar"'
*** Exception: bar: getSymbolicLinkStatus: does not exist (No such
file or directory)

Is there a way to check for the existence of a symbolic link without
testing if getSymbolicLinkStatus raises an exception?

This is with Darwin Kernel Version 8.11.1, GHC 6.8.2,
directory-1.0.0.0, and unix-2.3.0.0.

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

Re: [Haskell-cafe] Parsec and network data

[Ryan Ingram]

On Tue, Aug 26, 2008 at 1:35 PM, brian <[EMAIL PROTECTED]> wrote:
> One unworkable approach I tried is to get a lazy String from the
> handle with hGetContents.
> [...]
> The OP had the same problem I did, so he made a variant of
> hGetContents with timeout support. The problem: he used something from
> unsafe*. I came to Haskell for rigor and reliability and it would make
> me really sad to have to use a function with 'unsafe' in its name that
> has a lot of wacky caveats about inlining, etc.

unsafeInterleaveIO has no weird inlining caveats (as opposed to
unsafePerformIO, which does).  In fact, hGetContents is implemented
using unsafeInterleaveIO; the source is here:
http://haskell.org/ghc/docs/latest/html/libraries/base/src/GHC-IO.html#hGetContents

The "unsafe" bit is that it potentially allows side effects embedded
within pure values; if the value is never demanded, the side effect
never executes, so the observable behavior of your program can be made
to depend on whether or not (or when) that value is evaluated.

But when you are reading from a network stream, that's exactly what you want.

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

Re: [Haskell-cafe] Re: [Haskell] Top Level <-

[John Meacham]

On Thu, Aug 28, 2008 at 12:15:10AM +0100, Lennart Augustsson wrote:
> I didn't say NetBSD doesn't use global variables, I said the device
> driver model doesn't use global variables.  And quite a few things
> that used to be in global variables have been moved into allocated
> variables and are being passed around instead.  That's simply a better
> way to structure the code.

Indeed. I have experimented with single address space operating systems where
it is pretty much the only way to do things at the user level. But I
still want to be able to implement my kernel in haskell. :)

> 
> I don't don't think global variables should be banned, I just think
> they should be severly discouraged.

Oh, I certainly agree with that. especially among new programmers. I
think ACIO is a particularly elegant way to provide them in haskell for
when they are needed. Every time I can avoid resorting to C code for a
task without sacrificing performance, aethetics, or correctness, it is a
good day.

John



-- 
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haskell Propeganda

[Richard A. O'Keefe]

On 28 Aug 2008, at 8:34 am, Aaron Tomb wrote:
What type safety buys you, in my mind, is that Nothing is only a  
valid value for explicit Maybe types. In cases where you don't use  
Maybe, the "null" situation just can't occur. In languages with null  
pointers, any pointer could possibly be null.


This is not true of Eiffel.
The ECMA Eiffel standard has
?T  either a void reference or a reference to an instance of T
!T  a reference to an instance of T
 T  same as !T in ECMA Eiffel; used to be same as ?T

I suppose you could call the detachable type ?T an *implicit* Maybe.
Needless to say, the switch in semantics of undecorated T helped to
fork the Eiffel community...


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

Re: [Haskell-cafe] Pure hashtable library

[Richard A. O'Keefe]

Someone wrote:


trie: O(len)*O(width)
hashed trie: O(len)
hash: O(len)


If "width" here refers to the branching factor of the trie,
it's actually O(len.lg(width)), and the width that matters
is not the *possible* number of choices but the *actual*
number.

The great problem with hash tables is devising good hash
functions.  There is a vast literature about hash tables,
but there is very little about how to design good hash
functions for anything other than numbers and maybe strings.
It would be nice to think that _had__ there been plenty of
good advice about constructing good hash functions the Java
library implementors would have taken it.  As it is, their
hashing functions for collections leave much to be desired.

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

RE: [Haskell-cafe] Haskell Propeganda

[Tim Docker]

Dan Weston wrote: 

> Tim Docker wrote:
>
> > That differs from my experience. Most segfaults that *I've* caused
(in 
> > C or C++) have been due to dereferencing null pointers. Type safety 
> > does help you here, in that Maybe lets you distinguish the types of 
> > things that are optionally present from those that must be.
>
> Huh? Type safety buys you not having to worry about dereferencing
stale nonnull
> pointers (lifetime of reference exceeding lifetime of referent), but
nothing
> about dereferencing null pointers, which are the moral equivalent of
Nothing.
>
> Failure to handle a null pointer is just like using fromJust and
results in
> the same program termination (undefined).

Well as someone else pointed out, you can reliably catch a pattern match
failure. You may or may not be able to catch a segfault.

But my point is that haskell trivially lets you distinguish between
values (type X),
and nullable values (type Maybe X), and doing so is standard practice
when using
the language. The compiler will disallow any inconsistency in the use of
these two
types.

C however, does not have a compile time distinction between a pointer to
a value
that might be null, and one that is guaranteed not to be null. The code
writer
must track this distinction manually. Mistakes result in segvs, not
compile errors.

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

Re: [Haskell-cafe] xmonad on the openmoko mobile phone

[John Meacham]

On Wed, Aug 27, 2008 at 02:15:48PM -0700, Don Stewart wrote:
> john:
> > On Sun, Aug 10, 2008 at 08:36:27PM +0400, Miguel Mitrofanov wrote:
> > >
> > > On 9 Aug 2008, at 23:43, Don Stewart wrote:
> > >
> > >> Haskell on the iphone next?
> > >
> > > Did that. Hugs compiles well; GHC will probably too, I just didn't have 
> > > time for this. No haskell-specific hacks, only jailbreak.
> > 
> > jhc cross compiles to iPhone as well.
> 
> That's rather exciting. Any chance of a demo on your blog?

I'll see if I can put something together. jhc is in some sense natively
a cross compiler, it spits out 100% portable C code by default and you
have to work (by using 'foreign' imports on nonportable functions for
instance) at breaking cross-compilation.

So, for a quick and dirty cross compilation, take the foo_code.c file
that jhc generates, the first 3 lines will look something like so:

char jhc_c_compile[] = "gcc '-std=gnu99' -D_GNU_SOURCE '-falign-functions=4' 
-ffast-math -Wshadow -Wextra -Wall -Wno-unused-parameter  -DNDEBUG -O3 
-fomit-frame-pointer";
char jhc_command[] = "jhc --noauto -v --ho-dir regress/results/ho --noauto 
-i./lib/base -i./lib/haskell98 -flint -o enum enum.hs";
char jhc_version[] = "jhc 0.5.20080307 (eogmidkiv-1)";

and just change the 'gcc' in the jhc_c_compile line to gcc-iphone-arm or
whatever and run it on the command line.

I usually only test on linux so I occasionally accidentally break
cross compilation, but it is generally easy to fix. I try to test on Mac
OSX, solaris, and OpenBSD when possible as that gives a nice wide range.

Of course, you probably want to use some Mac OSX framework features,
which will require writing some foreign bindings, but I endevour to
ensure that if you only use haskell 98 or haskell' features (or your
library is built on top of said features) then jhc's output is pure,
portable (in practice), C.

John

-- 
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Haskell] Top Level <-

[Brandon S. Allbery KF8NH]

On 2008 Aug 27, at 12:12, Jonathan Cast wrote:

* I wonder why that name was chosen?  The design doesn't seem to have
anything to do with IO, it's more of a `we have this in C so we want  
it

in Haskell too' monad.



As I understand it, "IO" means "anything not encompassed by  
equationally-reasoned visible program state".  This includes  
randomness (the IO-based aspect of which requires process or OS  
state).  This also encompasses mutable state (e.g. IORefs), since  
mutability doesn't fit with equational reasoning.  So the name is  
perhaps poorly chosen, because it only encompasses the most common  
visible application.  (And IORefs particularly so, since they're only  
so named by analogy with STRefs.)


--
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] Haskell Propeganda

[Brandon S. Allbery KF8NH]

On 2008 Aug 27, at 16:39, Jonathan Cast wrote:
The last `case' is a catch-all, so you do know the result of the  
mplus's

is a Just, but you still need the Maybe.



I have to admit my thought here is that the problem isn't the Maybe,  
it's the fromJust. Make it go away, force people to explicitly pattern  
match so they have to think about it (and hopefully the compiler warns  
them of the missing pattern).


--
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] Re: [Haskell] Top Level <-

[Lennart Augustsson]

I didn't say NetBSD doesn't use global variables, I said the device
driver model doesn't use global variables.
And quite a few things that used to be in global variables have been
moved into allocated variables and are being passed around instead.
That's simply a better way to structure the code.

I don't don't think global variables should be banned, I just think
they should be severly discouraged.

On Wed, Aug 27, 2008 at 11:25 PM, John Meacham <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 27, 2008 at 12:17:46PM -0500, Derek Elkins wrote:
>> On Wed, 2008-08-27 at 02:35 -0700, John Meacham wrote:
>> > However, note the weasel words. Those are in there on purpose, every
>> > design calls for different solutions. To blanketly say certain
>> > constructs are just wrong to the point of disallowing them in the
>> > language, especially when they are common practice at the moment, just
>> > doesn't seem right.
>>
>> How can a Haskell user say this?  And this is indeed exactly what
>> capability languages do.  In fact, this is what almost every language
>> does (for one thing in common practice or another.)
>
> But as a system designer I *need* things like peek/poke/ACIO etc. I am
> the one implementing 'Random' or 'Data.Unique'. If I have to resort to C
> code to do such things, that makes haskell unsuitable for a wide variety
> of systems programming tasks (including implementing the haskell 98
> libraries). I know it is certainly possible to do a lot of things in a
> capability-based system. but you don't always want or have the ability
> to use such a system.
>
> I am not sure why it was thought netbsd didn't use global state. a
> simple grep of the kernel headers for '^extern' turns up hundreds of
> them. even pure capability based systems such as EROS need it for their
> implementation. What such systems strive for is no or reduced state in
> their interface. which is a very different thing and also something that
> I strive for in haskell code. (and is fairly easy to achieve actually)
>
>John
>
>
> --
> John Meacham - ⑆repetae.net⑆john⑈
> ___
> 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: Haskell Propaganda

[Ben Franksen]

Brandon S. Allbery KF8NH wrote:
> On 2008 Aug 27, at 16:49, Daniel Fischer wrote:
>> Am Mittwoch, 27. August 2008 22:34 schrieb Aaron Tomb:
>>> When you do use Maybe, you have to explicitly handle the Just and
>>> Nothing cases separately. Pattern matching reminds you that both are
>>> possible. I tend to view fromJust as a function you should only use
>>> if
>>> you're _very_, _very_ sure that the Nothing case is impossible. But,
>>> if so, why are you using a Maybe type in the first place?
>>
>> Good question. Maybe because you use a function which returns a
>> Maybe result
>> but you know in your use case it's always a Just. But then still a
>> case fun args of
>> Just val -> use val
>> Nothing -> error $ LOCATION ++ " Hey, that ought to be impossible! Go
>> investigate!"
>>
>> would be cleaner. If fromJust is more efficient and this code is
>> called many
>> times in your programme, that could count as a reason.
> 
> I have more than once seen a NULL dereference not get caught until
> later (admittedly I think most POSIX-like systems unmap page 0 these
> days; but think of embedded systems or other non-POSIX environments).

Oh yes, embedded systems indeed. We have only recently discovered a subtle
bug in some C code I wrote years ago where I mixed up the order of two
statements. The result was that memory at address zero was overwritten with
a string. Interestingly, we /never/ had any segfaults, exceptions,
whatever, not even broken behavior of any sort. I discovered the problem
only when I explicitly looked at the memory area in question to find out
what the system uses as default interrupt handler (yes, this was VxWorks on
an 68040, and the interrupt vector table is located at zero). In the end I
managed to crash a computer by issuing '1/0' on the shell (apparently the
vector for the division by zero fault handler had been overwritten)...
however, that was after I already knew there was something bad going on.

Note that C compilers are, in principle, free to interpret the value 0, when
compared or assigned to a pointer, as any address they like, so in
principle the C compiler could 're-map' 0 to some never-mapped memory
region. I know of no case where this is done, though.

> even fromJust gives you more of an ability to track the problem down
> in that case.

Definitely.

Cheers
Ben

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

Re: Re[6]: [Haskell-cafe] Re: [Haskell] Top Level <-

[Jonathan Cast]

On Wed, 2008-08-27 at 23:00 +0100, Lennart Augustsson wrote:
> IMO, there's no justification for having IORefs etc in the IO monad.
> They should be in a separate monad.  There could then be an operation
> to lift that monad to the IO monad, if you so wish.
> But wait, we already have that, it's the ST monad!  (So there is no
> justification.)

Right.  We'd have ST (which has the advantage that, if you don't have
any free variables of STRef type, your code can be used in a pure
context), together with a monad homomorphism

  stToProgram :: ST RealWorld alpha -> Program alpha

We'd also have IO (stripped of IORef, Random, Unique, and other such
irrelevant ugliness), together with a monad homomorphism

  ioToProgram :: IO alpha -> Program alpha

Then, the top-level type rule would be

  Main.main :: Program ()

We'd flame people for using the Program monad outside of the Main module
or monad homomorphisms like ioToProgram or stToProgram.  Then, using the
functional programming language research of the last 20 years instead of
ignoring it for historical reasons, we'd get a free monad homomorphism

  ioAndStToProgram :: Coproduct IO (ST RealWorld) alpha -> Program alpha

which would let you use both in the same program.

It doesn't dispense with the need for top-level Program (yet), but it's
a step in the right direction.

jcc


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

Re: [Haskell-cafe] Re: [Haskell] Top Level <-

[John Meacham]

On Wed, Aug 27, 2008 at 12:17:46PM -0500, Derek Elkins wrote:
> On Wed, 2008-08-27 at 02:35 -0700, John Meacham wrote:
> > However, note the weasel words. Those are in there on purpose, every
> > design calls for different solutions. To blanketly say certain
> > constructs are just wrong to the point of disallowing them in the
> > language, especially when they are common practice at the moment, just
> > doesn't seem right.
> 
> How can a Haskell user say this?  And this is indeed exactly what
> capability languages do.  In fact, this is what almost every language
> does (for one thing in common practice or another.) 

But as a system designer I *need* things like peek/poke/ACIO etc. I am
the one implementing 'Random' or 'Data.Unique'. If I have to resort to C
code to do such things, that makes haskell unsuitable for a wide variety
of systems programming tasks (including implementing the haskell 98
libraries). I know it is certainly possible to do a lot of things in a
capability-based system. but you don't always want or have the ability
to use such a system.

I am not sure why it was thought netbsd didn't use global state. a
simple grep of the kernel headers for '^extern' turns up hundreds of
them. even pure capability based systems such as EROS need it for their
implementation. What such systems strive for is no or reduced state in
their interface. which is a very different thing and also something that
I strive for in haskell code. (and is fairly easy to achieve actually)

John


-- 
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Building SDL-image package on Windows

[Garrick Chin]

Hello,

Adding the main macro undef has solved the linker errors and both SDL_image
and SDL_ttf build and install correctly now.  For both SDL_image and SDL_ttf
only the ./Graphics/UI/SDL/Image/Version.hsc file needed to be changed,
pasting in the undef macro under "#include SDL_image.h" and "#include
SDL_ttf.h" respectively.  Thanks for your help!

It would probably be a good idea to include these notes in a WIN32 file like
for the SDL package for other users.  I sent an e-mail to the listed
maintainer on Hackage yesterday, is that the best way to about doing this?

On Wed, Aug 27, 2008 at 4:40 AM, Bit Connor <[EMAIL PROTECTED]> wrote:

> Hi, I wrote the instructions in the WIN32 file.
>
> This looks like the same problem that I originally had with the SDL
> package, mangling of "main" function in C land by the hand of the C
> SDL.h include file.
>
> If you look at the .hsc files from the SDL package, you will see the
> fix I applied at the top of each file, after #including SDL.h the evil
> "main" macro is undefined:
>
> #include "SDL.h"
> #ifdef main
> #undef main
> #endif
>
> Probably the same must be done for all the .hsc files in SDL-image(and
> probably also all other haskell SDL addon packages).
>
> Please let me know if this information is helpful.
>
> 2008/8/27 Garrick Chin <[EMAIL PROTECTED]<[EMAIL PROTECTED]>
> >:
> > Hello,
> >
> > I'm trying to build the latest SDL-image package (0.5.2) from Hackage on
> > Windows and encountering problems.  These are the steps I've taken so
> far:
> >
> > 1.  Downloaded SDL 1.2.13 developmental library for Mingw32 to
> > E:\SDL-1.2.13, and SDL_image 1.2.6 developmental library for VC8 to
> > E:\SDL_image-1.2.6.
> > 2.  Installed SDL package from Hackage, modifying the SDL.cabal according
> to
> > the included WIN32 readme file and then runghc Setup.lhs
> > configure/build/install
> > 3.  Downloaded the SDL-image package from Hackage, modified the
> > SDL-image.cabal file to add the line "Include-Dirs:
> > E:\SDL_image-1.2.6\include\SDL, E:\SDL-1.2.13\include\SDL" so Cabal can
> find
> > the header files.  After doing "runghc Setup.lhs configure", "runghc
> > Setup.lhs build -v" gives me the following output:
> >
> > Creating dist\build (and its parents)
> > Creating dist\build\autogen (and its parents)
> > Preprocessing library SDL-image-0.5.2...
> > Creating dist\build\Graphics\UI\SDL\Image (and its parents)
> > E:\ghc\ghc-6.8.2\bin\hsc2hs.exe --cc=E:\ghc\ghc-6.8.2\bin\ghc.exe
> > --ld=E:\ghc\ghc-6.8.2\bin\ghc.exe --cflag=-package --cflag=SDL-0.5.4
> > --cflag=-package --cflag=base-3.0.1.0
> > --cflag=-IE:\SDL_image-1.2.6\include\SDL
> --cflag=-IE:\SDL-1.2.13\include\SDL
> > -o dist\build\Graphics\UI\SDL\Image\Version.hs
> > Graphics\UI\SDL\Image\Version.hsc
> > E:/ghc/ghc-6.8.2/libHSrts.a(Main.o)(.text+0x7):Main.c: undefined
> reference
> > to `__stginit_ZCMain'
> > E:/ghc/ghc-6.8.2/libHSrts.a(Main.o)(.text+0x36):Main.c: undefined
> reference
> > to `ZCMain_main_closure'
> > collect2: ld returned 1 exit status
> > linking dist\build\Graphics\UI\SDL\Image\Version_hsc_make.o failed
> > command was: E:\ghc\ghc-6.8.2\bin\ghc.exe
> > dist\build\Graphics\UI\SDL\Image\Version_hsc_make.o -o
> > dist\build\Graphics\UI\SDL\Image\Version_hsc_make.exe
> >
> > The results of a limited google search suggests that the __stginit_ZCMain
> > linker error has to do with GHC expecting a main function, but I'm not
> > really sure how that works in context of a library.
> >
> > ___
> > 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: Re[6]: [Haskell-cafe] Re: [Haskell] Top Level <-

[Lennart Augustsson]

IMO, there's no justification for having IORefs etc in the IO monad.
They should be in a separate monad.  There could then be an operation
to lift that monad to the IO monad, if you so wish.
But wait, we already have that, it's the ST monad!  (So there is no
justification.)

  -- Lennart

On Wed, Aug 27, 2008 at 10:50 PM, Jonathan Cast
<[EMAIL PROTECTED]> wrote:
> On Thu, 2008-08-28 at 01:23 +0400, Bulat Ziganshin wrote:
>> Hello Jonathan,
>>
>> Thursday, August 28, 2008, 1:11:35 AM, you wrote:
>> >> IORefs got their names because they are implemented in IO monad :)
>>
>> > But why are they implemented in the IO monad?
>>
>> because they need its features. but i/o may be implemented w/o IORefs.
>> so sequence was: searching for a was to make i/o in Haskell (you can
>> read about this in "History of Haskell"), finding monads as general
>> approach to implement side-effects,
>
> Note that this was true even in Haskell 1.0: the Haskell report included
> example code with definitions of (>>=) and return in the context of I/O,
> but without the explicit recognition of the connection to monads.
>
>> naming one of monads used to
>> interact with external world as IO, adding "variables" support to list
>> of operations of this monad
>
> Do you really think I'm unaware of the history?  I know what happened,
> what I don't understand is, looking at the matter from a language-design
> perspective circa 2008, IORefs would go in the same monad as Handles.
> What is the theoretical justification for this, independent of GHC's
> current implementation of these and their requisite monad(s)?
>
> jcc
>
>
> ___
> 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: Re[6]: [Haskell-cafe] Re: [Haskell] Top Level <-

[Jonathan Cast]

On Wed, 2008-08-27 at 14:50 -0700, Jonathan Cast wrote:
> On Thu, 2008-08-28 at 01:23 +0400, Bulat Ziganshin wrote:
> > Hello Jonathan,
> > 
> > Thursday, August 28, 2008, 1:11:35 AM, you wrote:
> > >> IORefs got their names because they are implemented in IO monad :)
> > 
> > > But why are they implemented in the IO monad?
> > 
> > because they need its features.

Oh, and by the way: what `features' of IO do IORefs use?  Other than the
fact that IO can implement anything in C, of course.

jcc


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

Re: Re[6]: [Haskell-cafe] Re: [Haskell] Top Level <-

[Jonathan Cast]

On Thu, 2008-08-28 at 01:23 +0400, Bulat Ziganshin wrote:
> Hello Jonathan,
> 
> Thursday, August 28, 2008, 1:11:35 AM, you wrote:
> >> IORefs got their names because they are implemented in IO monad :)
> 
> > But why are they implemented in the IO monad?
> 
> because they need its features. but i/o may be implemented w/o IORefs.
> so sequence was: searching for a was to make i/o in Haskell (you can
> read about this in "History of Haskell"), finding monads as general
> approach to implement side-effects,

Note that this was true even in Haskell 1.0: the Haskell report included
example code with definitions of (>>=) and return in the context of I/O,
but without the explicit recognition of the connection to monads.

> naming one of monads used to
> interact with external world as IO, adding "variables" support to list
> of operations of this monad

Do you really think I'm unaware of the history?  I know what happened,
what I don't understand is, looking at the matter from a language-design
perspective circa 2008, IORefs would go in the same monad as Handles.
What is the theoretical justification for this, independent of GHC's
current implementation of these and their requisite monad(s)?

jcc


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

Re: [Haskell-cafe] Re: [Haskell] Top Level <-

[Jonathan Cast]

On Wed, 2008-08-27 at 23:20 +0200, Daniel Fischer wrote:
> Am Mittwoch, 27. August 2008 22:57 schrieb Jonathan Cast:
> > On Thu, 2008-08-28 at 00:53 +0400, Bulat Ziganshin wrote:
> > > Hello Jonathan,
> > >
> > > Wednesday, August 27, 2008, 8:12:42 PM, you wrote:
> > > > * I wonder why that name was chosen?  The design doesn't seem to have
> > > > anything to do with IO, it's more of a `we have this in C so we want it
> > > > in Haskell too' monad.
> > >
> > > s/it/exchange with external world, i.e., essentially, I/O/
> >
> > Bald assertion.  I don't buy it.  What do IORefs have to do with
> > exchange with the external world?
> >
> > jcc
> >
> 
> Well, you wrote
> 
> > change your IO monad*
> 
> > * I wonder why that name was chosen?  The design doesn't seem to have
> > anything to do with IO, it's more of a `we have this in C so we want it
> > in Haskell too' monad.
> 
> I believe, Bulat took it to include getLine, readFile, writeFile et al.

These things existed in Haskell 1.0, before IORefs ever did.

jcc


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

Re: [Haskell-cafe] Re: problem with cabal for syb-with-class

[Duncan Coutts]

On Wed, 2008-08-27 at 12:33 +0100, Claus Reinke wrote:
> >> Cabal doesn't have to pass on ghc's messages uninterpreted. That's
> >> a lot like implementing a map as a list and complaining about empty
> >> list instead of element not found.
> > 
> > I see what you're saying, but in practise it's just not possible. GHC
> > can return a non-zero exit code for a multitude of reasons (most of
> > which will be genuine errors in your source code). It's just not
> > practical to parse the error messages that ghc produces and try and
> > reinterpret them. I fear it'd quite easy to introduce more problems than
> > are solved this way.
> 
> Introducing more problems is quite possible, though changes in error
> messages should mostly mean that the rules won't trigger and no
> helpful explanation is given.

Yes, it if it can degrade gracefully that's not so bad.

> And even that could be cured by having the collection of rules
> updateable, separately from Cabal itself. 

Hmm. Yet more work.

> What I don't understand are your "in practise it's just not possible"
> and "It's just not practical to parse the error messages that ghc produces 
> and try and reinterpret them". I assume you've tried the code I first
> sent some 9 months ago, and again this week, and found that it wouldn't 
> work for some reasons,but you haven't told me those reasons yet.

The easiest reason is that we cannot use regexes in Cabal, but that's
really just skirting the issue. The next reason is that it is still a
not insignificant effort to integrate this concept. The honest reason is
that I don't like the whole approach and I'm not inclined to spend my
time on it.

I'm not saying I'd reject a working patch against Cabal HEAD, just that
I'm not interested it doing it myself. Feel free to file a ticket,
attach your proof of concept code and persuade someone to put in the
time. If it works and doesn't look like it'd cause more problems than it
solves then I'd be happy to apply such a patch.

Duncan

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

Re: [Haskell-cafe] Compiler's bane

[Jeremy Apthorp]

2008/8/28 Lennart Augustsson <[EMAIL PROTECTED]>:
> You can get rid of all recursive bindings by transforming them into a
> use of a fixpoint combinator.
> And then you can use a non-recursive definition of the fixpoint
> combinator, and never worry about recursive bindings again.

This[1] might be a good explanation of why that works. It helped me
understand it, at least.

[1] - http://mvanier.livejournal.com/2897.html

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

Re: [Haskell-cafe] Associative Commutative Unification

[Matthieu Sozeau]

Le 12 juil. 08 à 04:02, John D. Ramsdell a écrit :


CIMe[1] might be useful to solve the generated diophantine equations.


It also has AC unification, and it probably wouldn't be all that hard
to translate our code into OCaml.  I think CiME isn't supported
anymore.  Still it's worth considering.  It's quite large.  The source
distribution compiled effortlessly on Ubuntu.  That's about all I know
now.


CIMe 2 is not maintained anymore, but a third version is in the works,  
see:

http://www3.iie.cnam.fr/~urbain/a3pat/a3pat_intro.en.html

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

Re: [Haskell-cafe] Re: [Haskell] Top Level <-

[Ganesh Sittampalam]

On Wed, 27 Aug 2008, Jonathan Cast wrote:


* I wonder why that name was chosen?  The design doesn't seem to have
anything to do with IO, it's more of a `we have this in C so we want it
in Haskell too' monad.


The 'C' in ACIO says that it commutes with any operation in the IO
monad. Without that property you can't safely implement it in a
program where the top-level has type IO a.

http://www.haskell.org/pipermail/haskell-cafe/2004-November/007664.html

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

Re: [Haskell-cafe] Haskell Propaganda

[Brandon S. Allbery KF8NH]

On 2008 Aug 27, at 16:49, Daniel Fischer wrote:

Am Mittwoch, 27. August 2008 22:34 schrieb Aaron Tomb:

When you do use Maybe, you have to explicitly handle the Just and
Nothing cases separately. Pattern matching reminds you that both are
possible. I tend to view fromJust as a function you should only use  
if

you're _very_, _very_ sure that the Nothing case is impossible. But,
if so, why are you using a Maybe type in the first place?


Good question. Maybe because you use a function which returns a  
Maybe result

but you know in your use case it's always a Just. But then still a
case fun args of
Just val -> use val
Nothing -> error $ LOCATION ++ " Hey, that ought to be impossible! Go
investigate!"

would be cleaner. If fromJust is more efficient and this code is  
called many

times in your programme, that could count as a reason.


I have more than once seen a NULL dereference not get caught until  
later (admittedly I think most POSIX-like systems unmap page 0 these  
days; but think of embedded systems or other non-POSIX environments).   
even fromJust gives you more of an ability to track the problem down  
in that case.


--
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] Compiler's bane

[Lennart Augustsson]

You can get rid of all recursive bindings by transforming them into a
use of a fixpoint combinator.
And then you can use a non-recursive definition of the fixpoint
combinator, and never worry about recursive bindings again.

  -- Lennart

On Wed, Aug 27, 2008 at 8:59 PM, Andrew Coppin
<[EMAIL PROTECTED]> wrote:
> Hi guys.
>
> I'm writing a simple interpretter for a small extended-lambda-calculus sort
> of language. And I'd just like to say... RECURSIVE LET-BINDS! GH!!! >_<
>
> No other part of the program has consumed nearly as much brain power as me
> trying to figure out when it is and isn't safe to replace a variable with
> its RHS.
>
> To illustrate:
>
>  let x = f x; y = 5 in x y
>
> A simple-minded interpretter might try to replace every occurrance of "x"
> with "f x". This yields
>
>  let y = 5 in (f x) y
>
> ...and x is now a free variable. OOPS!
>
> Trying to tease out exactly under which conditions you can and cannot
> perform the substitution is utterly maddening. Since this is a Haskell
> mailing list and as such it is populated by vast numbers of people with PhDs
> and so forth... does anybody happen to know the *correct* solution to this
> conundrum? Before I become clinically insane...? o_O
>
>
>
> By the way... To all those people who work on projects like GHC and so on,
> who have to get this stuff right "for real": you have my infinite respect!
>
> ___
> 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[6]: [Haskell-cafe] Re: [Haskell] Top Level <-

[Bulat Ziganshin]

Hello Jonathan,

Thursday, August 28, 2008, 1:11:35 AM, you wrote:
>> IORefs got their names because they are implemented in IO monad :)

> But why are they implemented in the IO monad?

because they need its features. but i/o may be implemented w/o IORefs.
so sequence was: searching for a was to make i/o in Haskell (you can
read about this in "History of Haskell"), finding monads as general
approach to implement side-effects, naming one of monads used to
interact with external world as IO, adding "variables" support to list
of operations of this monad




-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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

Re: [Haskell-cafe] Re: [Haskell] Top Level <-

[Daniel Fischer]

Am Mittwoch, 27. August 2008 22:57 schrieb Jonathan Cast:
> On Thu, 2008-08-28 at 00:53 +0400, Bulat Ziganshin wrote:
> > Hello Jonathan,
> >
> > Wednesday, August 27, 2008, 8:12:42 PM, you wrote:
> > > * I wonder why that name was chosen?  The design doesn't seem to have
> > > anything to do with IO, it's more of a `we have this in C so we want it
> > > in Haskell too' monad.
> >
> > s/it/exchange with external world, i.e., essentially, I/O/
>
> Bald assertion.  I don't buy it.  What do IORefs have to do with
> exchange with the external world?
>
> jcc
>

Well, you wrote

> change your IO monad*

> * I wonder why that name was chosen?  The design doesn't seem to have
> anything to do with IO, it's more of a `we have this in C so we want it
> in Haskell too' monad.

I believe, Bulat took it to include getLine, readFile, writeFile et al.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] xmonad on the openmoko mobile phone

[Don Stewart]

john:
> On Sun, Aug 10, 2008 at 08:36:27PM +0400, Miguel Mitrofanov wrote:
> >
> > On 9 Aug 2008, at 23:43, Don Stewart wrote:
> >
> >> Haskell on the iphone next?
> >
> > Did that. Hugs compiles well; GHC will probably too, I just didn't have 
> > time for this. No haskell-specific hacks, only jailbreak.
> 
> jhc cross compiles to iPhone as well.

That's rather exciting. Any chance of a demo on your blog?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Re[4]: [Haskell-cafe] Re: [Haskell] Top Level <-

[Jonathan Cast]

On Thu, 2008-08-28 at 01:09 +0400, Bulat Ziganshin wrote:
> Hello Jonathan,
> 
> Thursday, August 28, 2008, 12:57:19 AM, you wrote:
> 
> >> s/it/exchange with external world, i.e., essentially, I/O/
> 
> > Bald assertion.  I don't buy it.  What do IORefs have to do with
> > exchange with the external world?
> 
> IORefs got their names because they are implemented in IO monad :)

But why are they implemented in the IO monad?

jcc


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

Re[4]: [Haskell-cafe] Re: [Haskell] Top Level <-

[Bulat Ziganshin]

Hello Jonathan,

Thursday, August 28, 2008, 12:57:19 AM, you wrote:

>> s/it/exchange with external world, i.e., essentially, I/O/

> Bald assertion.  I don't buy it.  What do IORefs have to do with
> exchange with the external world?

IORefs got their names because they are implemented in IO monad :)


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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

Re: [Haskell-cafe] Haskell Propeganda

[Robert Greayer]

--- On Wed, 8/27/08, Dan Weston <[EMAIL PROTECTED]> wrote:
> 
> Failure to handle a null pointer is just like using
> fromJust and results 
> in the same program termination (undefined).
> 
> Dan
> 

Well, not (IMHO) 'just like': 'fromJust Nothing' turns into a 'catchable' 
exception in the IO Monad, but a SEGFAULT certainly doesn't.

E.g.
> import Control.Exception as C
> import Data.Maybe
> main = do
>(fromJust Nothing >>= ( \ s -> putStrLn s)) `C.catch` 
>(\ _ -> putStrLn "ok")

prints 'ok', whereas:

> import Foreign.Ptr
> import Foreign.Storable
> import qualified Control.Exception as E
> main = poke nullPtr '\0' `E.catch` (\ _ -> putStrLn "ok")

just segfaults...





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

Re: Re[2]: [Haskell-cafe] Re: [Haskell] Top Level <-

[Jonathan Cast]

On Thu, 2008-08-28 at 00:53 +0400, Bulat Ziganshin wrote:
> Hello Jonathan,
> 
> Wednesday, August 27, 2008, 8:12:42 PM, you wrote:
> 
> > * I wonder why that name was chosen?  The design doesn't seem to have
> > anything to do with IO, it's more of a `we have this in C so we want it
> > in Haskell too' monad.
> 
> s/it/exchange with external world, i.e., essentially, I/O/

Bald assertion.  I don't buy it.  What do IORefs have to do with
exchange with the external world?

jcc


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

Re: [Haskell-cafe] xmonad on the openmoko mobile phone

[John Meacham]

On Sun, Aug 10, 2008 at 08:36:27PM +0400, Miguel Mitrofanov wrote:
>
> On 9 Aug 2008, at 23:43, Don Stewart wrote:
>
>> Haskell on the iphone next?
>
> Did that. Hugs compiles well; GHC will probably too, I just didn't have 
> time for this. No haskell-specific hacks, only jailbreak.

jhc cross compiles to iPhone as well.

John

-- 
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re[2]: [Haskell-cafe] Re: [Haskell] Top Level <-

[Bulat Ziganshin]

Hello Jonathan,

Wednesday, August 27, 2008, 8:12:42 PM, you wrote:

> * I wonder why that name was chosen?  The design doesn't seem to have
> anything to do with IO, it's more of a `we have this in C so we want it
> in Haskell too' monad.

s/it/exchange with external world, i.e., essentially, I/O/


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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

[Haskell-cafe] Problem building the plugins package

[Emmanuel]

Hello

I am having troubles building the plugins package :

manu:~/Desktop/tmp manu$ cabal install plugins
Resolving dependencies...
cabal: cannot configure plugins-1.2. It requires ghc >=6.8
There is no available version of ghc that satisfies >=6.8

I am on a Mac PPC (OS X 10.4) with ghc-6.8.2 and Cabal-1.4.0.1

so the error message is puzzling...
Can anyone help ? I'd like to install Lambdabot and plugins is one of
the dependencies...

Thanks

Manu



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

Re[2]: [Haskell-cafe] Pure hashtable library

[Bulat Ziganshin]

Hello Jules,

Wednesday, August 27, 2008, 7:59:55 PM, you wrote:

>>> To get "much better efficient" than a trie, the hash function has to be
>>> so fast that it is faster than following (log n) pointers
>> 
>> afaiu, trie search follows n pointers 

> No.

> "n" is the number of strings in my data set (dictionary).

> If I have "n" strings the average string length is asymptotically, in 
> some sense, "log n". Of course for particular data sets it's may be more .

> But "log n" is the length of the shortest unique coding, it's also the
> number of characters you typically need to traverse before you have 
> reached a unique prefix, at which point your trie can short-circuit.

> I appreciate that I didn't define my terminology ;) You might have a 
> different "n".

> I repeat my challenge "Prove it". I will be interested to see how much a
> good immutable hash outperforms Data.Map.

> I would then also be interested to see how much it outperforms a decent
> Data.Map (such as your own AVL one) and a decent trie.

1) i don't have time/interest to do it, so i just pushed the idea

2) what you have proved there is that for set of n randomly chosen
strings trie lookup need O(log n) time - the same is true for hash

3) practical performance of trie will suffer by the need to follow
several trie levels each providing several elements to check. OTOH
hash lookup will usually need only 1-2 checks, including one check on
full string size

4) using ByteString for hash indexes would make lookups much faster

-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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

Re: [Haskell-cafe] Haskell Propaganda

[Daniel Fischer]

Am Mittwoch, 27. August 2008 22:34 schrieb Aaron Tomb:
> On Aug 27, 2008, at 12:23 PM, Dan Weston wrote:
> > Huh? Type safety buys you not having to worry about dereferencing
> > stale nonnull pointers (lifetime of reference exceeding lifetime of
> > referent), but nothing about dereferencing null pointers, which are
> > the moral equivalent of Nothing.
>
> What type safety buys you, in my mind, is that Nothing is only a valid
> value for explicit Maybe types. In cases where you don't use Maybe,
> the "null" situation just can't occur. In languages with null
> pointers, any pointer could possibly be null.
>
> When you do use Maybe, you have to explicitly handle the Just and
> Nothing cases separately. Pattern matching reminds you that both are
> possible. I tend to view fromJust as a function you should only use if
> you're _very_, _very_ sure that the Nothing case is impossible. But,
> if so, why are you using a Maybe type in the first place?

Good question. Maybe because you use a function which returns a Maybe result 
but you know in your use case it's always a Just. But then still a
case fun args of
Just val -> use val
Nothing -> error $ LOCATION ++ " Hey, that ought to be impossible! Go 
investigate!"

would be cleaner. If fromJust is more efficient and this code is called many 
times in your programme, that could count as a reason.
>
> Aaron
Cheers,
Daniel
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haskell Propeganda

[Jonathan Cast]

On Wed, 2008-08-27 at 13:34 -0700, Aaron Tomb wrote:
> On Aug 27, 2008, at 12:23 PM, Dan Weston wrote:
> 
> > Huh? Type safety buys you not having to worry about dereferencing  
> > stale nonnull pointers (lifetime of reference exceeding lifetime of  
> > referent), but nothing about dereferencing null pointers, which are  
> > the moral equivalent of Nothing.
> 
> What type safety buys you, in my mind, is that Nothing is only a valid  
> value for explicit Maybe types. In cases where you don't use Maybe,  
> the "null" situation just can't occur. In languages with null  
> pointers, any pointer could possibly be null.
> 
> When you do use Maybe, you have to explicitly handle the Just and  
> Nothing cases separately. Pattern matching reminds you that both are  
> possible. I tend to view fromJust as a function you should only use if  
> you're _very_, _very_ sure that the Nothing case is impossible. But,  
> if so, why are you using a Maybe type in the first place?

Consider:

 substType v ty x = fromJust $
   do
  TyVar s <- cast x
  guard $ v == s 
  cast ty
   `mplus` do
  ForAll s ty' <- cast x
  guard $ v == s
  cast $ ForAll s ty'
   `mplus` do
  ForAll s ty' <- cast x
  guard $ s `Set.member` freeTV ty
  let
v' = Set.findMax (freeTV ty `Set.union` freeTV ty') ++
"1"
ty'' = substType v ty $ substType s (TyVar v') $ ty'
  cast $ ForAll v' ty''
   `mplus` do
  ForAll s ty' <- cast x
  cast $ ForAll s $ substType v ty ty'
   `mplus` do
  TyLambda s ty' <- cast x
  guard $ v == s
  cast $ TyLambda s ty'
   `mplus` do
  TyLambda s ty' <- cast x
  guard $ s `Set.member` freeTV ty
  let
v' = Set.findMax (freeTV ty `Set.union` freeTV ty') ++
"1"
ty'' = substType v ty $ substType s (TyVar v') $ ty'
  cast $ TyLambda v' ty''
   `mplus` do
  TyLambda s ty' <- cast x
  cast $ TyLambda s $ substType v ty ty'
   `mplus` do return $ gmapT (substType v ty) x

 ForAll :: String -> Type -> Type
 TyLambda :: String -> Expr -> Expr

The last `case' is a catch-all, so you do know the result of the mplus's
is a Just, but you still need the Maybe.

jcc


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

Re[2]: [Haskell-cafe] Pure hashtable library

[Bulat Ziganshin]

Hello Jan-Willem,

Wednesday, August 27, 2008, 4:06:11 PM, you wrote:

> One obvious way to make non-modifiable hash tables useful is to "eat
> your own tail" non-strictly--- aggregate a set of hash table entries,
> construct a hash table from them, and plumb the resulting hash table  
> into the original computation by tying the knot.  This works really  
> well if you can construct the bucket lists lazily and if you specify  
> the table size up front.

i think it's impossible since you need to scan whole assoclist to
build list of entries for any value of hash function. actually, the
same is true for any array building code - while the *values* of array
elements may be calculated lazy, *positions* cannot



-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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

Re: [Haskell-cafe] Haskell Propeganda

[Aaron Tomb]

On Aug 27, 2008, at 12:23 PM, Dan Weston wrote:

Huh? Type safety buys you not having to worry about dereferencing  
stale nonnull pointers (lifetime of reference exceeding lifetime of  
referent), but nothing about dereferencing null pointers, which are  
the moral equivalent of Nothing.


What type safety buys you, in my mind, is that Nothing is only a valid  
value for explicit Maybe types. In cases where you don't use Maybe,  
the "null" situation just can't occur. In languages with null  
pointers, any pointer could possibly be null.


When you do use Maybe, you have to explicitly handle the Just and  
Nothing cases separately. Pattern matching reminds you that both are  
possible. I tend to view fromJust as a function you should only use if  
you're _very_, _very_ sure that the Nothing case is impossible. But,  
if so, why are you using a Maybe type in the first place?


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

Re: [Haskell-cafe] Cleaning up the Debian act (report from the trenches)

[David Bremner]

Ketil Malde wrote:

>Another Debian question, once I've populated the debian/ directory one
>way or another, how should this be integrated with the rest of the
>project?  Should it be part of the darcs archive, or a separate
>archive (foo-debian), or what?  How do people organize this?

[EMAIL PROTECTED] is a good place for generic debian
packaging questions.  After you have a package which works, and which
hopefully lintian (a tool for checking debian packages) does not
complain about, you can ask on debian-mentors for a sponsor, who will
check over the package and hopefully upload it. Right now there is not
too much interest in uploading new packages, because people are trying
to get lenny out the door.

If you like irc, there is also #debian-mentors on irc.oftc.net

In general the debian packaging should be maintained separately.
There are many different ways to implement this, but the end product (a
debian source package)  consists of blah.orig.tar.gz, and a blah.diff.gz
file that contains all of the debian specific changes. In practice
people maintain a seperate version control repo (or branch) for the
debian version.

John Goerzen has written a tool called darcs-buildpackage, which I
haven't used, but which might be helpful for you (there is also
git-buildpackage, and svn-buildpackage).

David


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

Re: [Haskell-cafe] Compiler's bane

[John Meacham]

On Wed, Aug 27, 2008 at 08:59:28PM +0100, Andrew Coppin wrote:
>  let y = 5 in (f x) y
>
> ...and x is now a free variable. OOPS!
>
> Trying to tease out exactly under which conditions you can and cannot  
> perform the substitution is utterly maddening. Since this is a Haskell  
> mailing list and as such it is populated by vast numbers of people with  
> PhDs and so forth... does anybody happen to know the *correct* solution  
> to this conundrum? Before I become clinically insane...? o_O

A simple solution is to separate your 'substitution' and
'simplification' passes. As in, perform any substitutions you like, but
_keep_ the original binding for x.  let the simplifier/optimizer
recognize when bindings are dead and remove them. It can do so simply by
keeping track of free variables in the subterms, which is also useful
for things like let floating transformations.

John


-- 
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Compiler's bane

[Neil Mitchell]

Hi

> I'm writing a simple interpretter for a small extended-lambda-calculus sort
> of language. And I'd just like to say... RECURSIVE LET-BINDS! GH!!! >_<

Agreed :-)

> To illustrate:
>
>  let x = f x; y = 5 in x y
>
> A simple-minded interpretter might try to replace every occurrance of "x"
> with "f x". This yields
>
>  let y = 5 in (f x) y

That's wrong, its a two step transformation. You just substitute all
occurances of x for f x:

let x = f (f x); y = 5 in (f x) y

For the case let x = 5 in x, you do the same thing:

let x = 5 in 5

Now as a second step you hoover up unused let bindings and disguard:

5

You seem to be combining the substitution and the removing of dead let
bindings, if you separate them you should have more luck.

Thanks

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

Re: [Haskell-cafe] Cleaning up the Debian act (report from the trenches)

[Don Stewart]

ketil:
> "Jason Dagit" <[EMAIL PROTECTED]> writes:
> 
> >> 2) Compile GHC yourself. 
> 
> > I find with Debian this is the way to go.
> 
> Ouch.  Okay, I've compiled GHC once.  But I would like end-users to be
> able to use my software, and I simply cannot require them to go
> through this.

Yes, scary and unacceptable.

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

[Haskell-cafe] Compiler's bane

[Andrew Coppin]

Hi guys.

I'm writing a simple interpretter for a small extended-lambda-calculus 
sort of language. And I'd just like to say... RECURSIVE LET-BINDS! 
GH!!! >_<


No other part of the program has consumed nearly as much brain power as 
me trying to figure out when it is and isn't safe to replace a variable 
with its RHS.


To illustrate:

 let x = f x; y = 5 in x y

A simple-minded interpretter might try to replace every occurrance of 
"x" with "f x". This yields


 let y = 5 in (f x) y

...and x is now a free variable. OOPS!

Trying to tease out exactly under which conditions you can and cannot 
perform the substitution is utterly maddening. Since this is a Haskell 
mailing list and as such it is populated by vast numbers of people with 
PhDs and so forth... does anybody happen to know the *correct* solution 
to this conundrum? Before I become clinically insane...? o_O




By the way... To all those people who work on projects like GHC and so 
on, who have to get this stuff right "for real": you have my infinite 
respect!


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

Re: [Haskell-cafe] Haskell symbol ~

[C.M.Brown]

I personally think it's bad to start using "let-patterns" as a synonym for
general pattern bindings when explaining these concepts. It may be
true that it's all transformed into the same thing at core level, but a let
expression binds a definition at the expression level, rather than at the 
equation level;
it becomes difficult when we have guards, for example:

f pat1
  | pat1 == x = x
  | pat2 == e2 = x
 where Just x = ...
f pat2 = ...

g pat1
  | pat1 == let Just x = ... in x = let Just x = ... in x
  | pat2 == e2 = let Just x = ... in x
g pat2 = ...

In theory x is lazy in f, but computed twice in g. The only way to make
the two the same is to introduce a case expression within a let binding
-- but then you have to start thinking about things like uncurrying g
if it has multiple parameters and its implications with partial applications.
Most decent compiler implementations would make a closue for x anyway (if
it's a big enough expression to compute), but I think it's certainly worth
making the distinction, otherwise new people are going to start thinking
they need to define everything using "let" clauses rather than "wheres"
for laziness.

Regards,
Chris.



On Wed, 27 Aug 2008, Jonathan Cast wrote:

> On Wed, 2008-08-27 at 20:14 +0100, C.M.Brown wrote:
> > Hi,
> >
> > I may be wrong here, but I don't belive it's just let-patterns that have
> > this property. I.e. what's the difference between...
> >
> > (Just x) = _|_
> >
> > f = x
> >
> > vs.
> >
> > f = let (Just x) = _|_ in x
> >
> > vs.
> >
> > f = x where (Just x) = _|_
> >
> > I believe Haskell uses Normal Order Reduction in all these cases. Why is
> > it just let-patterns? Can you give an example?
>
> Those are all syntax sugar for let patterns.
>
> jcc
>
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] 2 modules in one file

[Yitzchak Gale]

I have submitted this as Feature Request #2550

http://hackage.haskell.org/trac/ghc/ticket/2550

Please add any comments as appropriate.

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

Re: [Haskell-cafe] Haskell Propeganda

[Jonathan Cast]

On Wed, 2008-08-27 at 12:23 -0700, Dan Weston wrote:
> Tim Docker wrote:
> >  
> > David Roundy wrote:
> > 
> >> Which illustrates the point that it's not type safety 
> >> that protects us from segfaults, so much as bounds checking,
> >> and that's got a non-trivial runtime cost.  At least, most
> >> segfaults that *I've* caused (in C or C++) have been from
> >> overwriting the bounds of arrays, and that's precisely the problem
> >> that Haskell does *not* solve using its type system. 
> > 
> > That differs from my experience. Most segfaults that *I've* caused (in
> > C or C++) have been due to dereferencing null pointers. Type safety
> > does help you here, in that Maybe lets you distinguish the types of
> > things that are optionally present from those that must be. 
> > 
> > Tim
> 
> Huh? Type safety buys you not having to worry about dereferencing stale 
> nonnull pointers (lifetime of reference exceeding lifetime of referent), 
> but nothing about dereferencing null pointers, which are the moral 
> equivalent of Nothing.

Actually, that's garbage collection.

> Failure to handle a null pointer is just like using fromJust and results 
> in the same program termination (undefined).

jcc


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

Re: [Haskell-cafe] Haskell Propeganda

[Dan Weston]

Tim Docker wrote:
 
David Roundy wrote:


Which illustrates the point that it's not type safety 
that protects us from segfaults, so much as bounds checking,

and that's got a non-trivial runtime cost.  At least, most
segfaults that *I've* caused (in C or C++) have been from
overwriting the bounds of arrays, and that's precisely the problem
that Haskell does *not* solve using its type system. 


That differs from my experience. Most segfaults that *I've* caused (in
C or C++) have been due to dereferencing null pointers. Type safety
does help you here, in that Maybe lets you distinguish the types of
things that are optionally present from those that must be. 


Tim


Huh? Type safety buys you not having to worry about dereferencing stale 
nonnull pointers (lifetime of reference exceeding lifetime of referent), 
but nothing about dereferencing null pointers, which are the moral 
equivalent of Nothing.


Failure to handle a null pointer is just like using fromJust and results 
in the same program termination (undefined).


Dan

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

Re: [Haskell-cafe] Haskell symbol ~

[Jonathan Cast]

On Wed, 2008-08-27 at 20:14 +0100, C.M.Brown wrote:
> Hi,
> 
> I may be wrong here, but I don't belive it's just let-patterns that have
> this property. I.e. what's the difference between...
> 
> (Just x) = _|_
> 
> f = x
> 
> vs.
> 
> f = let (Just x) = _|_ in x
> 
> vs.
> 
> f = x where (Just x) = _|_
> 
> I believe Haskell uses Normal Order Reduction in all these cases. Why is
> it just let-patterns? Can you give an example?

Those are all syntax sugar for let patterns.

jcc


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

Re: [Haskell-cafe] Haskell symbol ~

[C.M.Brown]

Hi,

I may be wrong here, but I don't belive it's just let-patterns that have
this property. I.e. what's the difference between...

(Just x) = _|_

f = x

vs.

f = let (Just x) = _|_ in x

vs.

f = x where (Just x) = _|_

I believe Haskell uses Normal Order Reduction in all these cases. Why is
it just let-patterns? Can you give an example?

Thanks,
Chris.




On Wed, 27 Aug 2008, Brandon S. Allbery KF8NH wrote:

> On 2008 Aug 27, at 14:23, Maurí cio wrote:
> > What does '~' mean in Haskell? I
> > read in haskell.org/haskellwiki/Keywords
> > that “(...) Matching the pattern ~pat
> > against a value always suceeds, and
> > matching will only diverge when one of
> > the variables bound in the pattern is
> > used.” Isn't that true for any
> > variable, due to lazyness?
>
> Only in let-patterns; others, including case expressions and top level
> definitions, are strict (which is in fact the normal way to force a
> value).
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haskell symbol ~

[Ryan Ingram]

Here is another example:

> f1 n ~(x:xs) = (n, x)
> f2 n (x:xs) = (n,x)

f1 5 [] = (5, error "irrefutable pattern match failure")
f2 5 [] = error "pattern match failure"

In particular:

fst (f1 5 []) = 5
fst (f2 5 []) = error "pattern match failure"

The "~" delays the pattern match until evaluation of the variables
inside the pattern is demanded.  If the variable is never demanded,
the pattern match doesn't happen.

It's especially useful for single-constructor datatypes (like pairs)
if you want the code to be more lazy.

   -- ryan

On Wed, Aug 27, 2008 at 11:56 AM, Neil Mitchell <[EMAIL PROTECTED]> wrote:
> Hi
>
>> At the same place, I found that example,
>> but wasn't wise enough to figure out
>> what it does:
>>
>> (f *** g) ~(x,y) = (f x, g y)
>>
>> Can you help me understand it?
>
> It means exactly the same as:
>
> (f *** g) xy = (f (fst xy), g (snd xy))
>
> i.e. if you call (f *** g) undefined, you will get (f undefined, g
> undefined). If the pattern was strict (i.e. no ~) you would get
> undefined.
>
> Please update the keyword wiki so it makes sense to you, after you
> have got your head round it.
>
> Thanks
>
> Neil
> ___
> 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] Haskell symbol ~

[Benja Fallenstein]

Hi Maurí­cio,

I've got one thing to add to the replies so far:

On Wed, Aug 27, 2008 at 8:23 PM, Maurí­cio <[EMAIL PROTECTED]> wrote:
> What does '~' mean in Haskell? I
> read in haskell.org/haskellwiki/Keywords
> that "(...) Matching the pattern ~pat
> against a value always suceeds, and
> matching will only diverge when one of
> the variables bound in the pattern is
> used." Isn't that true for any
> variable, due to lazyness?

To any variable, yes. But you don't apply it to a variable, you apply
it to a constructor pattern: not ~xs but ~(x:xs).

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

Re: [Haskell-cafe] Haskell symbol ~

[Neil Mitchell]

Hi

> At the same place, I found that example,
> but wasn't wise enough to figure out
> what it does:
>
> (f *** g) ~(x,y) = (f x, g y)
>
> Can you help me understand it?

It means exactly the same as:

(f *** g) xy = (f (fst xy), g (snd xy))

i.e. if you call (f *** g) undefined, you will get (f undefined, g
undefined). If the pattern was strict (i.e. no ~) you would get
undefined.

Please update the keyword wiki so it makes sense to you, after you
have got your head round it.

Thanks

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

[Haskell-cafe] timer_create revisited

[Brandon S. Allbery KF8NH]

I'm trying to build GHC 6.8.2 (6.8.3 once I get all this nailed  
down...) from an old bootstrap ghc on SuSE 9.3-64 (yes, I know)  
because the 6.6.1 and newer binary tarballs for amd64 Linux doesn't  
work with the "timer_create" issue.


The problem is, having built a shiny new 6.8.2 both stage1 and stage2,  
the result works but compiled programs have the "timer_create"  
problem.  (??)


At this point I'm stymied.  Suggestions, other than "upgrade" (not  
currently possible due to commercial software support and timing  
issues)?


--
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] Haskell symbol ~

[Brandon S. Allbery KF8NH]

On 2008 Aug 27, at 14:23, Maurí cio wrote:

What does '~' mean in Haskell? I
read in haskell.org/haskellwiki/Keywords
that “(...) Matching the pattern ~pat
against a value always suceeds, and
matching will only diverge when one of
the variables bound in the pattern is
used.” Isn't that true for any
variable, due to lazyness?


Only in let-patterns; others, including case expressions and top level  
definitions, are strict (which is in fact the normal way to force a  
value).


--
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

[Haskell-cafe] Haskell symbol ~

[Maurí­cio]

Hi,

What does '~' mean in Haskell? I
read in haskell.org/haskellwiki/Keywords
that “(...) Matching the pattern ~pat
against a value always suceeds, and
matching will only diverge when one of
the variables bound in the pattern is
used.” Isn't that true for any
variable, due to lazyness?

At the same place, I found that example,
but wasn't wise enough to figure out
what it does:

(f *** g) ~(x,y) = (f x, g y)

Can you help me understand it?

Thanks,
Maurício

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

[Haskell-cafe] Is there GHC 6.8.3 on Ubuntu?

[Rafael Gustavo da Cunha Pereira Pinto]

Is there anyone packing GHC 6.8.3 for Ubuntu Hardy?

Thanks


-- 
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

Re: [Haskell-cafe] Cleaning up the Debian act (report from the trenches)

[David Bremner]

Ketil Malde wrote:

>Neither do I have an Etch system around, but I should probably
>install a virtual machine or something.  Ideally, I should
>work out the minimal requirements (including for dependencies, and for
>dependencies' dependencies), but in practice, I end up depending on
>whatever is installed on the computer I use.  Lazyness bites again. :-)

If you have a Debian (or presumably Ubuntu) machine of some kind, then
the package "pbuilder" makes it reasonably easy to set up build
environments for particular releases. It is oriented towards building
debian packages, but you can "login" to the environment. This is a lot
lighter weight than a virtual machine (it uses chroot).

David

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

Re: [Haskell-cafe] Re: [Haskell] Top Level <-

[Derek Elkins]

On Wed, 2008-08-27 at 02:35 -0700, John Meacham wrote:
[cut]
> 
> However, note the weasel words. Those are in there on purpose, every
> design calls for different solutions. To blanketly say certain
> constructs are just wrong to the point of disallowing them in the
> language, especially when they are common practice at the moment, just
> doesn't seem right.

How can a Haskell user say this?  And this is indeed exactly what
capability languages do.  In fact, this is what almost every language
does (for one thing in common practice or another.) 

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

Re: [Haskell-cafe] Cleaning up the Debian act (report from the trenches)

[Ketil Malde]

"David House" <[EMAIL PROTECTED]> writes:

>> 1. Etch comes with ghc-6.6, and that didn't work with my .cabal file.

> Is it not an option to make your software work with the
> not-quite-latest compiler?

Yes it is, although I don't have the details either.  

Neither do I have an Etch system around, but I should probably
install a virtual machine or something.  Ideally, I should
work out the minimal requirements (including for dependencies, and for
dependencies' dependencies), but in practice, I end up depending on
whatever is installed on the computer I use.  Lazyness bites again. :-)

Would it be an idea for hackage to have various "build hosts",
automatically trying to compile things on less-than-current installs?

-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] ANNOUNCE: Wired 0.1.1

[Emil Axelsson]

Hello,

This is to announce the first release of the hardware description library Wired. 
Wired can be seen as an extension to Lava that targets (not exclusively) 
semi-custom VLSI design. A particular aim of Wired is to give the designer more 
control over the routing wires' effects on performance.


The only working backends in this version are simulation and verification 
(through Lava), and generation of postscript layouts. Soon, there will also be 
static timing analysis and DEF file generation. The DEF format is accepted by 
most tools for physical design.


Wired is available from Hackage:

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

or using Darcs:

  darcs get http://www.cs.chalmers.se/~emax/darcs/Wired/

There is also a homepage at:

  http://www.cs.chalmers.se/~emax/wired/index.html

Comments, questions, patches are welcome.

Cheers,

/ Emil

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

[Haskell-cafe] Re: Parsec and network data

[brian]

I made a small example related to the problem: http://hpaste.org/9957

It's my attempt to run data from the network directly into Parsec
without having to fear deadlock due to blocking. The idea is that we
feed Parsec from a timeout-enabled Stream based on Handle. As long as
Parsec is able to read the data it wants reasonably quickly,
everything is OK. If the remote host stops sending data, we don't
hang; we just treat it as a parse error.

But the code demonstrates a problem. Why is it doing that? How to fix
it? Thanks.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re[2]: [Haskell-cafe] Pure hashtable library

[Bulat Ziganshin]

Hello Stephan,

Wednesday, August 27, 2008, 1:52:23 PM, you wrote:
> and on the other and, its implementation uses hash functions and arrays
> as well. IIRC it does that in a state monad that keeps the array mutable
> and finally freezes it before usage, which might be a good idea for pure
> hash table as well.

actually, any building of immutable arrays internally done in this
way. we just don't need to write this low-level function ourselves as
Array library provides us pure function to build array from
list/assoclist


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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

Re[2]: [Haskell-cafe] Pure hashtable library

[Bulat Ziganshin]

Hello Daniel,

Wednesday, August 27, 2008, 8:01:24 PM, you wrote:

>> trie: O(len)*O(width)
>> hashed trie: O(len)
>> hash: O(len)

> Wouldn't the hashtable have lookup time O(len+bucketsize)?

i suppose that bucketsize=O(1): constructor should get [approximate]
size of hashed assoclist and it will select appropriate Array size



-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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

Re: [Haskell-cafe] Re: [Haskell] Top Level <-

[Jonathan Cast]

On Wed, 2008-08-27 at 11:53 +0100, Adrian Hey wrote:
> John Meacham wrote:
> > As with all design decisions, it is sometimes the right thing and
> > sometimes the wrong one. And sometimes the most expedient. (which,
> > occasionally, is a perfectly valid driving force behind a certain bit of
> > coding). However, I am fully convinced it is necessary. You don't even
> > have to look further than Haskell 98 to find a use in the Random module,
> > and Data.Unique _depends_ on the state being global for correctness.
> 
> ..and of course there's stdin, stdout. That takes some explaining.

Not really.  If you don't have buffered IO, then you just say

stdin = 0
stdout = 1
stderr = 2

If you need buffered IO, you just change your IO monad* to look like:

newtype NewIO alpha = NewIO (ReaderT (Map Fd Buffer) OldIO alpha)

Of course, if you do this, you can't go mixing IO with unique values
with RNG with mutable state with everything else under the sun anymore.
You might actually have to declare exactly what effects you need when
you give your function's type, now.  Clearly, a horror we must avoid at
all costs.

jcc

* I wonder why that name was chosen?  The design doesn't seem to have
anything to do with IO, it's more of a `we have this in C so we want it
in Haskell too' monad.

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

Re: [Haskell-cafe] HEq and Context reduction stack overflow, non optimal ghc behaviour ?

[Marc Weber]

> -- packages: HList
> {-# OPTIONS_GHC -fallow-undecidable-instances -XEmptyDataDecls 
> -XMultiParamTypeClasses #-}
> module Main where
> import Data.HList
> import HAppS.Data
> import System.Environment
>  
>  
> class TypeToNat typE nr | typE -> nr
> instance ( TypeToNat a elNr
>  , TypeToNat b elNr'
>  , HEq elNr elNr' r) => HEq a b r
>  
> data Id_A
> instance TypeToNat Id_A HZero
> data Root_T
> instance TypeToNat Id_A nr => TypeToNat Root_T (HSucc nr)
>  
> main = do 
>   putStrLn (show (undefined :: (HEq Id_A Id_A a) => a ))
>  
>  
> || [1 of 1] Compiling Main ( test.hs, test.o )
> || 
> test.hs|19 error| 
> || Context reduction stack overflow; size = 20
> || Use -fcontext-stack=N to increase stack size to N
> || `$dHEq :: {HEq elNr elNr' a}'
> ||   arising from instantiating a type signature at test.hs:20:18-52
> || `$dHEq :: {HEq elNr elNr' a}'

I should have added that Data.HList exposes the more specific instances
instance HEq HZero HZero HTrue
instance HNat n => HEq HZero (HSucc n) HFalse
instance HNat n => HEq (HSucc n) HZero HFalse
instance (HNat n, HNat n', HEq  n n' b )
  =>  HEq (HSucc n) (HSucc n') b


That's why I think ghc tries to resolve the wrong instance first:

summary:
class TypeToNat a b | a -> b
class HEq a b c | a b -> c
 
instance ( TypeToNat a elNr   -- (1)
 , TypeToNat b elNr'  -- (2)
 , HEq elNr elNr' r) => HEq a b r -- (3)

putStrLn (show (undefined :: (HEq Id_A Id_A a) => a ))
 
 
When ghc tries to resolve HEq it starts with
   TypeToNat ( TypeToNat Id_A 
 , TypeToNat Id_A 
 , HEq)
 
Now ghc can try to resolve (1),(2),(3) in arbitrary order..
What happens if ghc starts with (3)?
  It tries to find an instance for not known types..
  Damn. There is even a matching instance..
  , the same one. This time it starts even with 
  HEqwhich is even more bad!
  after the second recursion it already knows that won't find a
  solution, because it will try to resolve 
  HEqagain and again..

What happens if ghc starts with (1 or 2)?
  It happily finds an instance *and* it can even resolve elNr and elNr'
  Those can then be used to find an instance for (3) easily
 
So I think the behaviour of ghc should be changed to prefer resolving
class constraints which reduce the amount of unkown types first

I even consider this beeing a bug ?

So maybe this thread should be moved to glasgow-haskell-users ?

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

Re: [Haskell-cafe] Cleaning up the Debian act (report from the trenches)

[David House]

2008/8/25 Ketil Malde <[EMAIL PROTECTED]>:
> 1. Etch comes with ghc-6.6, and that didn't work with my .cabal file.

Is it not an option to make your software work with the
not-quite-latest compiler? 6.8 is less than a year old, so I imagine
6.6 is still in quite a few major distro's stable repositories.

I don't know the details of what changed with Cabal between 6.6 and
6.8, and you didn't provide any details of what broke, so this might
not be an option. But something to consider.

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

Re: [Haskell-cafe] Pure hashtable library

[Jules Bean]

Bulat Ziganshin wrote:

Hello Jules,

Wednesday, August 27, 2008, 7:21:46 PM, you wrote:


given these constraints, it should be just a 10-20 lines of code, and provide 
much better efficiency than any tree/trie implementations



Prove it.



To get "much better efficient" than a trie, the hash function has to be
so fast that it is faster than following (log n) pointers


afaiu, trie search follows n pointers 


No.

"n" is the number of strings in my data set (dictionary).

If I have "n" strings the average string length is asymptotically, in 
some sense, "log n". Of course for particular data sets it's may be more .


But "log n" is the length of the shortest unique coding, it's also the 
number of characters you typically need to traverse before you have 
reached a unique prefix, at which point your trie can short-circuit.


I appreciate that I didn't define my terminology ;) You might have a 
different "n".


I repeat my challenge "Prove it". I will be interested to see how much a 
good immutable hash outperforms Data.Map.


I would then also be interested to see how much it outperforms a decent 
Data.Map (such as your own AVL one) and a decent trie.


Jules

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

Re: [Haskell-cafe] Pure hashtable library

[Daniel Fischer]

Am Mittwoch, 27. August 2008 17:36 schrieb Bulat Ziganshin:
> Hello Jules,
>
> Wednesday, August 27, 2008, 7:21:46 PM, you wrote:
> >> given these constraints, it should be just a 10-20 lines of code, and
> >> provide much better efficiency than any tree/trie implementations
> >
> > Prove it.
> >
> > To get "much better efficient" than a trie, the hash function has to be
> > so fast that it is faster than following (log n) pointers
>
> afaiu, trie search follows n pointers - i.e. every char in string
> forms a new trie level. add to this that every search need to scan a
> list of all possible chars - or you need to use the same hashing. so,
> we have the following lookup times:
>
> trie: O(len)*O(width)
> hashed trie: O(len)
> hash: O(len)

Wouldn't the hashtable have lookup time O(len+bucketsize)?

>
> where len is length of string searched and width is average amount of
> chars at each trie level

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

Re: [Haskell-cafe] Pure hashtable library

[Jed Brown]

On Wed 2008-08-27 16:21, Jules Bean wrote:
> Bulat Ziganshin wrote:
>> Hello haskell-cafe,
>>
>> solving one more task that uses English dictionary, i've thought: why we 
>> don't yet have pure hashtable library? There is imperative hashtables, 
>> pretty complex as they need to rebuild entire table as it grows. There is 
>> also simple assoc lists and tree/trie implementations, but there is no 
>> simple non-modifiable hashes.
>>
>> how should it look:
>> * hashtable is represented as an array of assoc lists: Array Int [(a,b)]
>>
>> * interface to extract data from ht is the same as from assoc list:
>> lookup :: HT a b -> a -> Maybe b
>>
>> * ht may be built from assoc list. we should just know it's size beforehand 
>> in order to create Array of reasonable size. constructor also need a hashing 
>> function:
>>
>> create :: [(a,b)] -> Int -> (a->Int) -> HT a b
>>
>>
>> given these constraints, it should be just a 10-20 lines of code, and 
>> provide much better efficiency than any tree/trie implementations
>
> Prove it.
>
> To get "much better efficient" than a trie, the hash function has to be  
> so fast that it is faster than following (log n) pointers, and yet also  
> so "perfect" that it doesn't generate too many collisions.

Many people have probably seen this and it has nothing to do with
Haskell, but it is a good performance comparison of a simple hash to an
optimized trie.

  http://www.nothings.org/computer/judy/

The conclusion (we're only interested in lookup times) is that the trie
is preferable for sequential lookups, slower for random access hits, and
about the same for random access misses.  Also, the hash was uniformly
better for small sizes (< 10k).

BTW a single cache miss has a latency around 250 cycles, you can compute
a hell of a hash for that.

Jed


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

Re[2]: [Haskell-cafe] Pure hashtable library

[Bulat Ziganshin]

Hello Jules,

Wednesday, August 27, 2008, 7:21:46 PM, you wrote:

>> given these constraints, it should be just a 10-20 lines of code, and 
>> provide much better efficiency than any tree/trie implementations

> Prove it.

> To get "much better efficient" than a trie, the hash function has to be
> so fast that it is faster than following (log n) pointers

afaiu, trie search follows n pointers - i.e. every char in string
forms a new trie level. add to this that every search need to scan a
list of all possible chars - or you need to use the same hashing. so,
we have the following lookup times:

trie: O(len)*O(width)
hashed trie: O(len)
hash: O(len)

where len is length of string searched and width is average amount of
chars at each trie level



-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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

Re: [Haskell-cafe] 2 modules in one file

[Henrik Nilsson]

Hi,

Yitzchak Gale wrote:

> But for large and complex projects, this policy really complicates
> the task of the project manager who wants to be able to
> present various views of the source to teams working on
> different subprojects, while juggling the version control
> in an intelligent way. Directory tree structure is sometimes
> the perfect tool for that, but Haskell has stolen it away.
> It would be nice if compilers would offer, as an optional alternative,
> a system of locating modules based on manifest files.
> That would then allow multiple modules per source file.

Not that it is of any practical relevance now, but this was exactly
the thinking behind the design (some 10 - 15 years ago, time flies!)
of how Freja manages files and modules, as Malcolm mentioned.
I believe a clear separation between a language and aspects of the
environment in which programs are developed, such as file systems, is a
good thing. And while the Haskell standard as such respects this, I've
always found the fact that most tools rely on naming conventions for
mapping names of modules to names of files very unfortunate.
Hierarchical modules makes this even worse: what says that I necessarily
want the module hierarchy reflected in the directory hierarchy? And 
indeed, as Yitzchak said, what about non-hierarchical file systems, or

maybe storing source code by completely different means? And there are
also potential issues with not every legal module name being a legal
file name across all possible file systems.

So, yes, a system of locating modules based on manifest files would
be great. I'd use it all the time whenever possible, and never look
back!

Best,

/Henrik

--
Henrik Nilsson
School of Computer Science
The University of Nottingham
[EMAIL PROTECTED]

This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

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

Re: [Haskell-cafe] Pure hashtable library

[Jules Bean]

Bulat Ziganshin wrote:

Hello haskell-cafe,

solving one more task that uses English dictionary, i've thought: why we don't 
yet have pure hashtable library? There is imperative hashtables, pretty complex 
as they need to rebuild entire table as it grows. There is also simple assoc 
lists and tree/trie implementations, but there is no simple non-modifiable 
hashes.

how should it look:
* hashtable is represented as an array of assoc lists: Array Int [(a,b)]

* interface to extract data from ht is the same as from assoc list:
lookup :: HT a b -> a -> Maybe b

* ht may be built from assoc list. we should just know it's size beforehand in 
order to create Array of reasonable size. constructor also need a hashing 
function:

create :: [(a,b)] -> Int -> (a->Int) -> HT a b


given these constraints, it should be just a 10-20 lines of code, and provide 
much better efficiency than any tree/trie implementations


Prove it.

To get "much better efficient" than a trie, the hash function has to be 
so fast that it is faster than following (log n) pointers, and yet also 
so "perfect" that it doesn't generate too many collisions.


As you correctly say, a simple implementation is easy to do, so why not 
do it and see how it performs? :)


Jules

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

Re: [Haskell-cafe] Re: [Haskell] Another First course in Haskell

[Johannes Waldmann]

Neil Mitchell wrote:

>> If you want to program Haskell, get the basics sorted. Once you have
>> sorted the basics of functional programming, you can move on to the
>> Haskell specific bits. The course I learnt from at York left out
>> things such as modules, type classes (beyond slight Eq/Ord
>> signatures), monads, IO (other than interact) and anything not in
>> Haskell 98. 

I think what you describe as "basics" is "basics of programmning"
(i.e. how to write one "toy" function) and sure this is important.

But I think the other topics (modules, classes, monads, extra libraries)
are equally important because they are "basics of software engineering"
(how to write/organize a bunch of functions that do some "real" work).

I wouldn't call these "Haskell specific" because the underlying concepts
are perfectly general  - and if you leave them out,
students will ask for them because  they already know
Java has a module system, and interfaces, etc.
and they have been trained early to use this
(this is basic undergraduate CS stuff, no?)

Perhaps you're saying that *because* students already know that,
one shouldn't spend too much time on it in a Haskell course.
Agreed, but then my conclusion is to  use e.g. (hierarchical) modules
right from the start.

I generally tell my students that Haskell has about everything
you would expect from a modern general-purpose programming language
(that's where I'd put modules, classes, libraries)
*plus* additional benefits: more efficiency (in writing - you need
less code because you have more ways of abstraction)
and more safety (because of strong typing).

This does not contradict what you write.
Indeed one can practice abstraction and typing rules
using functions over lists of lists of ints.
Problem is that afterwards, the student knows about
functions and types but still has to unlearn the habit
of coding everything as lists of lists of ints...

J.W.








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

Re: [Haskell-cafe] 2 modules in one file

[Yitzchak Gale]

Maurí­cio wrote:
>> Is it allowed to write two
>> different modules in a single
>> file?

That would be a really nice feature, especially
since modules are Haskell's only encapsulation
tool. You want it to be a lightweight as possible.

Malcolm Wallace wrote:
> Some compilers permit it (e.g. Freja), most do not (e.g. ghc).  The
> Language Report makes no specification for the mapping between module
> sources and the files that contain them.

The Hierarchical Module Namespace Extension addendum to the
Haskell 98 Report

http://www.haskell.org/hierarchical-modules/

recommends, but does not require, a Java-like mapping between
hierarchical module names and and the filesystem.
In particular, compilers complying with that recommendation
require there to be only one module per file. Most compilers
do comply.

In my opinion, that is a bad policy. It is fine as a simple default for
small projects, even though it's a bit ugly and ad hoc. (For example -
what does this mean on platforms whose filesystem is not
hierarchical?)

But for large and complex projects, this policy really complicates
the task of the project manager who wants to be able to
present various views of the source to teams working on
different subprojects, while juggling the version control
in an intelligent way. Directory tree structure is sometimes
the perfect tool for that, but Haskell has stolen it away.

It would be nice if compilers would offer, as an optional alternative,
a system of locating modules based on manifest files.
That would then allow multiple modules per source file.

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

Re: [Haskell-cafe] Re: apparent minor bug in "Getting started" tutorial at "Haskell Hacking: a journal of Haskell programming"

[Brandon S. Allbery KF8NH]

On 2008 Aug 27, at 3:28, Benjamin L.Russell wrote:

On Wed, 27 Aug 2008 16:22:56 +0900, Benjamin L.Russell
<[EMAIL PROTECTED]> wrote:

Sorry, what I really meant was not to update the reference to "a.out"
to be changed to "main.exe", but to change the following line:

This produces a new executable, ./a.out (a.out.exe on windows),  
which you can run like any other program on your system:


to read as follows:

This produces a new executable, ./a.out (main.exe on windows),  
which you can run like any other program on your system:


There was no "a.out.exe" on Windows, but only a "main.exe".


Both the Unix and Windows examples need to be changed, actually; IIRC  
that behavior changed with 6.8.


--
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] Re: [Haskell] Top Level <-

[Adrian Hey]

Lennart Augustssom wrote:
Since at some point you have to interface with the hardware you are 
forced to obey whatever convention is used for interrupts etc. At that 
point you may very well have to use global variables. But you can 
quickly abstract away from that in stay in the safe land without globals.


BTW, did you notice that the non-hosted driver API example I put on the
wiki page doesn't use "globals" either :-) The two device handles are
at the top level (are "globals" as you would say), but the driver
code takes these as an argument so doesn't care if they're top
level or not.

If I don't have the device handles at the top level or some means to get
them from the top level then I have no alternative but to export
createDeviceHandle either directly to the "user level" API (really bad!)
or to some other bit of higher level system code that can be trusted not
to create 2 or more handles for the same device (and no handles for
non-existant devices). Let's assume it's that latter.

In the simple case where it is known at compile time that there are
exactly 2 devices in the system at known base addresses, can you explain
how the higher level bit of the system guarantees that user level
application code will only ever have access to 2 different device
handles in total (one for each device), no matter what?

How does it solve this problem in the more complex complex case where
hardware must be probed somehow to discover how many devices there
are and where they are?

All without using any global variables please. Also, assuming you
succeed, please explain what advantages or extra safety your solution
provides over a solution which does use global variables.

The obvious solution seems to be to have this code present this function
to the user level API..

getAvailableDeviceHandles :: IO [DeviceHandle]

Which shouldn't be hard to implement in either case, except for the fact
IO state "getters" can't be implemented at all without top level mutable
state or runOnce primitives or something like that (AFAICS).

newAvailableDeviceHandles perhaps? I guess that could come in handy
if the user code decides it doesn't like the old ones for some
reason :-)

Regards
--
Adrian Hey





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

[Haskell-cafe] HEq and Context reduction stack overflow

[Marc Weber]

On Mon, Aug 25, 2008 at 09:17:19PM -0400, jeff p wrote:
>   The HList paper (http://homepages.cwi.nl/~ralf/HList/) presents a

Thanks Jeff


-- packages: HList
{-# OPTIONS_GHC -fallow-undecidable-instances -XEmptyDataDecls 
-XMultiParamTypeClasses #-}
module Main where
import Data.HList
import HAppS.Data
import System.Environment
 
 
class TypeToNat typE nr | typE -> nr
instance ( TypeToNat a elNr
 , TypeToNat b elNr'
 , HEq elNr elNr' r) => HEq a b r
 
data Id_A
instance TypeToNat Id_A HZero
data Root_T
instance TypeToNat Id_A nr => TypeToNat Root_T (HSucc nr)
 
main = do 
  putStrLn (show (undefined :: (HEq Id_A Id_A a) => a ))
 
 
|| [1 of 1] Compiling Main ( test.hs, test.o )
|| 
test.hs|19 error| 
|| Context reduction stack overflow; size = 20
|| Use -fcontext-stack=N to increase stack size to N
|| `$dHEq :: {HEq elNr elNr' a}'
||   arising from instantiating a type signature at test.hs:20:18-52
|| `$dHEq :: {HEq elNr elNr' a}'



However adding a dummy type T works fine:

-- packages: HList
{-# OPTIONS_GHC -XEmptyDataDecls -XMultiParamTypeClasses 
-fallow-undecidable-instances #-}
module Main where
import Data.HList
import HAppS.Data
import System.Environment
 
data T a
 
class TypeToNat typE nr | typE -> nr
instance ( TypeToNat a elNr
 , TypeToNat b elNr'
 , HEq elNr elNr' r) => HEq (T a) (T b) r
 
data Id_A
instance TypeToNat Id_A HZero
data Root_T
instance TypeToNat Id_A nr => TypeToNat Root_T (HSucc nr)
 
main = do 
  putStrLn (show (undefined :: (HEq (T Id_A) (T Id_A) a) => a ))

I don't see what's wrong with the first version.. Can you help me
understand this implicationa ?

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

Re: [Haskell-cafe] best runProcess solution to work with windows and linux

[Philip Weaver]

On Wed, Aug 27, 2008 at 5:40 AM, Andrew U. Frank <[EMAIL PROTECTED]
> wrote:

> i use System.POSIX.IO to run a process and access the handles (after due
> transformation) to get the values back.
> this solution is unfortunately not portable and works only on unix (or
> cygwin) but not for plain windows. there seems to be a somewhat
> comparable package in system.win32.process.
> is there a solution independent of OS? what is the best approach to use
> to run a process and read the result back which works in both unix and
> windows?
>


The System.Process module works well on both unix and windows:

http://hackage.haskell.org/packages/archive/process/1.0.0.0/doc/html/System-Process.html


>
> any suggestion highly appreciated!
>
> andrew
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Haskell] Another First course in Haskell

[Neil Mitchell]

> That book is about teaching Haskell, not advertising it. If I wanted
> to advertise how cool Haskell was, I probably wouldn't dwell on lists.
> But to learn Haskell, I spent the first few years doing either list
> processing or very simple algebraic data types, and I think it made me
> a better programmer as a result.
>
> If you want to program Haskell, get the basics sorted. Once you have
> sorted the basics of functional programming, you can move on to the
> Haskell specific bits. The course I learnt from at York left out
> things such as modules, type classes (beyond slight Eq/Ord
> signatures), monads, IO (other than interact) and anything not in
> Haskell 98. What it did cover very well was functional programming and
> functional reasoning.

Of course, after teaching these bits, say towards the end of a course
or in a Real World Haskell book, the extra Haskell bits should
definately be covered! They are what makes a Haskell programmer, but
not what makes a functional programmer.

Thanks

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

Re: [Haskell-cafe] Re: [Haskell] Another First course in Haskell

[Johannes Waldmann]

Darrin Thompson wrote:

> If functions on lists isn't the thing, what is the thing? "Data structures"
> isn't a very satisfactory answer for a n00b like me, because it doesn't
> capture Haskell's distinctive. [...]

Well indeed you can (should) have problem-specific (algebraic) data
types in any language. In Haskell it's just a "data" declaration,
while in OO design they call it the "compositum" pattern
(and need some hundred more lines to write it down).

What is "distinctively Haskell"? The focus in teaching could be:
(1) data abstraction (-> functions, -> higher order functions)
(2) type abstraction (-> type constructors, polymorphism etc.)

... and of course all the benefits from abstraction (=> re-usability)
and strong typing (=> safety).

J.W.



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

Re: [Haskell-cafe] Re: [Haskell] Another First course in Haskell

[Neil Mitchell]

Hi

> (*) that's the main problem I see with Hutton's book
> http://www.cs.nott.ac.uk/~gmh/book.html :
> it has "Declaring types and classes" as chapter 10 (of 13 total).
> I think that's way off - and it leaves readers (students)
> with the impression that declarative programming
> basically deals with (functions on) lists.
> This may have been true in the 70s/80s (LISP, Prolog),
> but it certainly shouldn't be true today.

That book is about teaching Haskell, not advertising it. If I wanted
to advertise how cool Haskell was, I probably wouldn't dwell on lists.
But to learn Haskell, I spent the first few years doing either list
processing or very simple algebraic data types, and I think it made me
a better programmer as a result.

If you want to program Haskell, get the basics sorted. Once you have
sorted the basics of functional programming, you can move on to the
Haskell specific bits. The course I learnt from at York left out
things such as modules, type classes (beyond slight Eq/Ord
signatures), monads, IO (other than interact) and anything not in
Haskell 98. What it did cover very well was functional programming and
functional reasoning.

Thanks

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

Re: [Haskell-cafe] Re: [Haskell] Top Level <-

[John Meacham]

I think a strong advantage of the straight up ACIO formulation (rather
than a one-shot IO based thing) is that it can be fully, correctly, and
safely be defined without referencing the IO monad or its interaction
with the IO monad at all. In practice, ACIO will be generally be used to
interact with IO code. But being able to formalize it completely
independently of the IO monad and all the IO monad entails is an
enticing posibility.

John

-- 
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Haskell] Another First course in Haskell

[Darrin Thompson]

On Sat, Aug 23, 2008 at 8:41 AM, Johannes Waldmann <
[EMAIL PROTECTED]> wrote:

> (*) that's the main problem I see with Hutton's book
> http://www.cs.nott.ac.uk/~gmh/book.html:
> it has "Declaring types and classes" as chapter 10 (of 13 total).
> I think that's way off - and it leaves readers (students)
> with the impression that declarative programming
> basically deals with (functions on) lists.
> This may have been true in the 70s/80s (LISP, Prolog),
> but it certainly shouldn't be true today.
>
> Recall the proverb "Get your data structures correct first,
> and the rest of the program will write itself."
> (David Jones, cited in John Bentley: More Programming Pearls)
> I think this is independent of language and paradigm.
>
>
If functions on lists isn't the thing, what is the thing? "Data structures"
isn't a very satisfactory answer for a n00b like me, because it doesn't
capture Haskell's distinctive. I've had this same sense, but in a vague
newbie way.

This also seems to reflect a growing dissatisfaction with the prelude. Back
in the day lazy lists were the thing and the Prelude seems to largely
reflect that. Now it's something else I can't possibly articulate. But I can
definitely see it trying to replace a significant amount of prelude
functionality. Witness that nobody loves strings anymore because ByteStrings
are cooler. The stream/fusion lists are way cooler than the stock lists.
etc.

Or I have no idea what I'm talking about.

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

Re: [Haskell-cafe] Re: [Haskell] Top Level <-

[Adrian Hey]

Judah Jacobson wrote:

I've been wondering: is there any benefit to having top-level ACIO'd
<- instead of just using runOnce (or perhaps "oneshot") as the
primitive for everything?  For example:

oneshot uniqueRef :: IO (MVar Integer)
uniqueRef =< newMVar 0


I've been wondering about something like this too (in some way just have
a oneShot or runOnce and the *only* thing in ACIO as a magic primitive).

runOnce :: IO a -> ACIO (IO a)

It would certainly simplify the ACIO monad :-), but I'm not sure it's
really as flexible. Provided newMVar can be ACIO then this can be
implemented directly (doesn't need to be a primitive). But we can't
go the other way round (use runOnce to create genuine top level MVars
or channels say).

Does that matter? Probably not for monadic IO code. It's not a huge
inconvenience to write..

 do ...
thing <- getThing
foo thing

vs..
 do ...
foo thing -- thing is at top level

But for top level non monadic code/expressions/data structures I can
see a certain convenience in having thing as top level identifier
if possible, which it often won't be anyway I guess for other
reasons (like it's creation and initialisation requires real IO).

So I don't have any particularly strong opinion either way. In
practice if thing (or getThing) is to be exported then it
would probably be prudent to assume creation and initialisation
might require real IO at some point in the future even if they
don't right now, so you'd export getThing (= return thing) anyway,
rather then have an exported thing dissappear from the API at some
point.

My 2p..

Regards
--
Adrian Hey











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

[Haskell-cafe] best runProcess solution to work with windows and linux

[Andrew U. Frank]

i use System.POSIX.IO to run a process and access the handles (after due
transformation) to get the values back.
this solution is unfortunately not portable and works only on unix (or
cygwin) but not for plain windows. there seems to be a somewhat
comparable package in system.win32.process.
is there a solution independent of OS? what is the best approach to use
to run a process and read the result back which works in both unix and
windows?

any suggestion highly appreciated!

andrew


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

Re: [Haskell-cafe] Pure hashtable library

[Jan-Willem Maessen]

On Aug 27, 2008, at 3:41 AM, Bulat Ziganshin wrote:


Hello haskell-cafe,

solving one more task that uses English dictionary, i've thought:  
why we don't yet have pure hashtable library? There is imperative  
hashtables, pretty complex as they need to rebuild entire table as  
it grows. There is also simple assoc lists and tree/trie  
implementations, but there is no simple non-modifiable hashes.


I know that Lennart had such a hashtable implementation as part of the  
hbcc source tree (so dating back to the late stream age or the very  
very early monad age), though I think it relied upon hbc's LazyArray.


One obvious way to make non-modifiable hash tables useful is to "eat  
your own tail" non-strictly--- aggregate a set of hash table entries,  
construct a hash table from them, and plumb the resulting hash table  
into the original computation by tying the knot.  This works really  
well if you can construct the bucket lists lazily and if you specify  
the table size up front.  You can't make this trick work at all for  
tree-based maps in general, because the structure of the tree depends  
upon all the keys inserted.  You also can't make this trick work if  
you base the size of the hash table on the number of keys inserted,  
maximum bucket load, etc.  Finally, it doesn't work with strict arrays  
at all.


So a nice niche for a small and clever static hash table.

-Jan

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

[Haskell-cafe] Re: [Haskell] Top Level <-

[Adrian Hey]

Ashley Yakeley wrote:

Adrian Hey wrote:

Maybe it would be safest to just say anything with a finaliser can't be
created at the top level.


Do you have an example of something that is correctly ACIO to create, 
but has a problematic finaliser?


Sorry for the delay in getting my attention. I've been looking at
my old ACIO code (which I've largely forgotten the details
of) and dug up the following snippet.

 -- * Weak pointers
 -- | All these functions require that finalisers (if any) are in the
 -- ACIO Monad.
 -- I'm not sure what such a finaliser can usefully do, but it can't be
 -- in the IO Monad and preserve ACIO Monad properties AFAICS.
 mkWeak,mkWeakPtr,mkWeakPair,addFinalizer,mkWeakIORef,

I must admit I can't remember much about any of this, I just worked
my way through the IO libs trying to figure out which actions might
plausibly (if not usefully :-) be regarded as ACIO. There seemed to be
quite a lot at the end of the day.

I also added a few forkIO variants which force the forked thread
to block on certain things (empty MVar,Chan, QSem..) waiting for
some IO monad action to kick them into life.

Regards
--
Adrian Hey

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

Re: [Haskell-cafe] Re: problem with cabal for syb-with-class

[Claus Reinke]

Cabal doesn't have to pass on ghc's messages uninterpreted. That's
a lot like implementing a map as a list and complaining about empty
list instead of element not found.


I see what you're saying, but in practise it's just not possible. GHC
can return a non-zero exit code for a multitude of reasons (most of
which will be genuine errors in your source code). It's just not
practical to parse the error messages that ghc produces and try and
reinterpret them. I fear it'd quite easy to introduce more problems than
are solved this way.


Introducing more problems is quite possible, though changes in error
messages should mostly mean that the rules won't trigger and no
helpful explanation is given. And even that could be cured by having
the collection of rules updateable, separately from Cabal itself. 

And when the forthcoming next base split, and extensible exceptions, 
and Cabal Api changes, and .. are going to introduce new break points,

updating the rules will offer help for those breakages, too.

Given the shakiness of this simplistic approach, one might not want 
to enable it by default, but what about an option '--explain' and a

hint if things go wrong: "if you would like help interpreting common
Cabal package issues, you can try repeating your command with 
our experimental --explain option".


What I don't understand are your "in practise it's just not possible"
and "It's just not practical to parse the error messages that ghc produces 
and try and reinterpret them". I assume you've tried the code I first
sent some 9 months ago, and again this week, and found that it wouldn't 
work for some reasons,but you haven't told me those reasons yet.



If one wanted to take this approach you'd need to have some mode where
error messages are produced in a machine readable format (which is of
course doable if you write a client using the ghc api).

A quicker hack would be to change ghcs error message in this
circumstance, where the -hide-all-packages flag is given.


One would want to have such support depend on an extra option,
'--errors-in-xml' or something equally scary, but I'm afraid the extra
readability/stability would be mostly illusionary. We're talking about
"good enough" hacks to cover "not quite right" left-overs from too
much instability in the Haskell tool chains - as long as the instabilities
remain, there is no "perfect" solution.

Given our limited amount of volunteer developer time I think it's 
much better investing it in proper solutions.


How many times over the last 9 months have you had to explain 
what a script could have told your Cabal users? And how many 
more Cabal/Haskell users have been scared away in that time, 
without even raising their build problems on any of the lists?


"Proper" solutions are alright when we have them. "Good enough"
but hacky is much better than nothing. With an '--explain' option
and a collection of rules, you'd have to explain every error condition
just once, then update the rules/explanations, and let Cabal repeat
the explanation whenever needed. If those canned explanations 
don't work, users can still ask here.


Claus

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