Re: Threaded runtime error

2006-03-22 Thread Volker Stolz
* Volker Stolz [EMAIL PROTECTED]:
 [EMAIL PROTECTED] [20:17:08] ./timeout 10 /usr/bin/true
 FFatal error '_pq_insert_tail: Already in priority queue' at line 200 in file 
 /usr/src/lib/libpthread/thread/thr_priority_queue.c (errno = 0)

A workaround seems to use another threading library here. Both
libthr and libc_r work at least for this small example.

The error occurs on createOSThread(). I'm not sure where exactly
(ie., for the child or the parent, but I guess the child).
I'll keep on looking.
-- 
http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME
All the excitement lies in pattern matching. (SPJ et al.)

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #729: Build system uses wrong version of include files.

2006-03-22 Thread GHC
#729: Build system uses wrong version of include files.
---+
  Reporter:  guest |  Owner: 
  Type:  bug   | Status:  new
  Priority:  normal|  Milestone: 
 Component:  Build System  |Version:  6.4.1  
  Severity:  normal| Resolution: 
  Keywords:| Os:  MacOS X
Difficulty:  Unknown   |   Architecture:  powerpc
---+
Old description:

 The situation: I am building 6.4.1 using 6.4.1. The installed version was
 by a package installer. Now I want to build a source myself, since I want
 to see if I can change some things. After the usual stuff and doing make
 I obtain this error message:

 utils/PrimPacked.lhs:263:0:
 Warning: foreign declaration uses deprecated non-standard syntax
 In file included from /tmp/ghc25249.hc:5:
 /usr/local/lib/ghc-6.4.1/include/HsUnix.h: In function
 '__hsunix_rtldNext':
 /usr/local/lib/ghc-6.4.1/include/HsUnix.h:103: error: 'RTLD_NEXT'
 undeclared (first use in this function)
 /usr/local/lib/ghc-6.4.1/include/HsUnix.h:103: error: (Each undeclared
 identifier is reported only once
 /usr/local/lib/ghc-6.4.1/include/HsUnix.h:103: error: for each function
 it appears in.)
 /usr/local/lib/ghc-6.4.1/include/HsUnix.h: In function
 '__hsunix_rtldDefault':
 /usr/local/lib/ghc-6.4.1/include/HsUnix.h:107: error: 'RTLD_DEFAULT'
 undeclared (first use in this function)
 ghc: 50080464 bytes, 11 GCs, 1535164/2972296 avg/max bytes residency (2
 samples), 19M in use, 0.13 INIT (0.00 elapsed), 0.51 MUT (1.45 elapsed),
 0.28 GC (0.36 elapsed) :ghc
 make[2]: *** [stage1/utils/PrimPacked.o] Error 1
 make[1]: *** [all] Error 1
 make: *** [build] Error 1

 Having looked at it for a while and discussing the problem with Arthur
 van Leeuwen,
 we decided that the problem is that the build system uses the HsUnix.h
 file of the
 existing distribution, and not the one from the sources. The problem
 arises because
 these two files are different.

New description:

 The situation: I am building 6.4.1 using 6.4.1. The installed version was
 by a package installer. Now I want to build a source myself, since I want
 to see if I can change some things. After the usual stuff and doing make I
 obtain this error message:

 {{{
 utils/PrimPacked.lhs:263:0:
 Warning: foreign declaration uses deprecated non-standard syntax
 In file included from /tmp/ghc25249.hc:5:
 /usr/local/lib/ghc-6.4.1/include/HsUnix.h: In function
 '__hsunix_rtldNext':
 /usr/local/lib/ghc-6.4.1/include/HsUnix.h:103: error: 'RTLD_NEXT'
 undeclared (first use in this function)
 /usr/local/lib/ghc-6.4.1/include/HsUnix.h:103: error: (Each undeclared
 identifier is reported only once
 /usr/local/lib/ghc-6.4.1/include/HsUnix.h:103: error: for each function it
 appears in.)
 /usr/local/lib/ghc-6.4.1/include/HsUnix.h: In function
 '__hsunix_rtldDefault':
 /usr/local/lib/ghc-6.4.1/include/HsUnix.h:107: error: 'RTLD_DEFAULT'
 undeclared (first use in this function)
 ghc: 50080464 bytes, 11 GCs, 1535164/2972296 avg/max bytes residency (2
 samples), 19M in use, 0.13 INIT (0.00 elapsed), 0.51 MUT (1.45 elapsed),
 0.28 GC (0.36 elapsed) :ghc
 make[2]: *** [stage1/utils/PrimPacked.o] Error 1
 make[1]: *** [all] Error 1
 make: *** [build] Error 1
 }}}

 Having looked at it for a while and discussing the problem with Arthur van
 Leeuwen,
 we decided that the problem is that the build system uses the HsUnix.h
 file of the
 existing distribution, and not the one from the sources. The problem
 arises because
 these two files are different.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/729
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: [GHC] #714: inconsistency between handling of class and signature constraints

2006-03-22 Thread GHC
#714: inconsistency between handling of class and signature constraints
--+-
  Reporter:  [EMAIL PROTECTED]  |  Owner: 
  Type:  bug  | Status:  new
  Priority:  normal   |  Milestone: 
 Component:  Compiler (Type checker)  |Version:  6.5
  Severity:  normal   | Resolution: 
  Keywords:   | Os:  Unknown
Difficulty:  Unknown  |   Architecture:  Unknown
--+-
Changes (by [EMAIL PROTECTED]):

  * type:  feature request = bug

Comment:

 (reclassified as bug, let's see whether that evokes any comments?-)

 the problem has now become acute in haskell' list discussions.

 btw, the same problem exists with contexts of data declarations,
 which show an equal unawareness of FDs.

 {{{
 data C a b = D a
 }}}

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/714
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


[GHC] #733: Problem compiling .lhs files with lines that begin with #

2006-03-22 Thread GHC
#733: Problem compiling .lhs files with lines that begin with #
-+--
Reporter:  guest |Owner: 
Type:  bug   |   Status:  new
Priority:  normal|Milestone: 
   Component:  Compiler  |  Version:  6.4.1  
Severity:  normal| Keywords: 
  Os:  Unknown   |   Difficulty:  Unknown
Architecture:  Unknown   |  
-+--
Lines starting with # inside a .lhs make ghc yield lexical error.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/733
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: 6.4.2 release plans

2006-03-22 Thread Simon Marlow

Duncan Coutts wrote:


Chris Parrott found that ghc-6.4.1 doesn't work with gcc 4.1 on amd64,
although it does work on x86.

The error manifests itself as link errors due to undefined symbols:

/var/tmp/portage/ghc-6.4.1-r2/work/ghc-6.4.1/ghc/rts/libHSrts.a(Linker.o):(.data+0x48):
 undefined reference to `StgReturn'
/var/tmp/portage/ghc-6.4.1-r2/work/ghc-6.4.1/ghc/rts/libHSrts.a(RtsStartup.o): 
In function `hs_add_root':
RtsStartup.c:(.text+0x1a8): undefined reference to `StgRun'


Coincidentally, I just upgraded our x86_64 box to FC5, and the nightly 
build fell over with exactly these errors.  It turns out that the HEAD 
already had fixes in some arch's for this, but it was fixed by making 
StgRunIsImplementedInAssembler() non-static.  The attribute fix is 
better, so I've applied it consistently and merged to 6.4.2.


Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: Threaded runtime error

2006-03-22 Thread Simon Marlow

Volker Stolz wrote:

* Volker Stolz [EMAIL PROTECTED]:


[EMAIL PROTECTED] [20:17:08] ./timeout 10 /usr/bin/true
FFatal error '_pq_insert_tail: Already in priority queue' at line 200 in file 
/usr/src/lib/libpthread/thread/thr_priority_queue.c (errno = 0)



A workaround seems to use another threading library here. Both
libthr and libc_r work at least for this small example.

The error occurs on createOSThread(). I'm not sure where exactly
(ie., for the child or the parent, but I guess the child).
I'll keep on looking.


If you can get me a backtrace, that would be most helpful.

Cheers,
Simon

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re[2]: ghc releasing memory during compilation

2006-03-22 Thread Bulat Ziganshin
Hello Ketil,

Wednesday, March 22, 2006, 11:02:49 AM, you wrote:

of course, any complicated algorithm can be a result of long
researches and so we are far from such algorithms. my words is more a
rhetorical point than concrete suggestion. that's real on this moment:

1) tune the ghc algorithm to kill worst cases, especially disk
swapping

2) make the ghc's internal GC tuning features more accessible (it's
really more a question of documenting than adding/changing APIs) so
that anyone who need a specific GC tuning algorithm for his own
program can implement it himself

3) document the GC and GC tuning details

 and moreover, we should perform compaction immediately when swapping grows.
 imagine for example algorithm that had 80 mb residency and runs on a
 machine with 100 mb free. performing compacting GC each time when
 memory usage grows to 100 mb should be better strategy than waiting
 for 160 mb usage. of course, concrete calculation whether to start GC
 or not, is a delicate task, but at least it should be performed on
 each minor GC

 I'd like to urge you to have a go at implementing some of these
 strategies.

KM I must admit that I am slightly skeptical to complicated heuristics
KM here, since it seems actual performance would depend a lot on memory
KM manangement policies of the underlying OS.

KM However, I find that setting GHC to use the equivalent of +RTS -Mxxx
KM where xxx is about 80% of physical RAM generally works well.
KM Currently, I do this through a C file reading values from sysconf(),
KM which is a bit cumbersome.  A way to set these defaults though the ghc
KM command line would be welcome.

KM -k



-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


6.4.1 Bug? getServiceEntry: does not exist (no such service entry)

2006-03-22 Thread S. Alexander Jacobson



I just upgraded to 6.4.1 from 6.4.0 and am now getting this error when 
I run socket code via ghci, but not when I compile the code using ghc. 
Any idea what this is or how to fix?


  getServiceEntry: does not exist (no such service entry)

FYI, I am running WinXP SP2.

-Alex-


__
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Message GHC/PrimopWrappers.hs:133:29: Not in scope: `GHC.Prim.quotInteger2Exp#' building GHC with additional primitive operation

2006-03-22 Thread Thorkil Naur
Hello,

Using the marvelous Haskell language and the equally marvelous GHC 
implementation, I have over the past couple of years revived my old interest 
in integer factorization. The built-in support for multi-precision integer 
arithmetic makes Haskell a fine choice for this kind of computation. And 
working with numbers with several hundreds of decimal digits, I at least hope 
that the (undoubted) overhead of GHC Haskell when compared to, say, direct 
use of C is easily drowned by the time taken by the individual arithmetic 
operations. And Haskell is so much easier to use than C.

(In addition to GHC, I use Hugs.) 

I have come to a point, however, where I wish to squeeze some additional drops 
of performance out of my programs. For that, I would like direct access to 
some selection of gmp functions, in addition to those that are available 
through the use of Integer operators. For example, to experiment with the use 
of Montgomery modular multiplication (Mathematics of Computation, volume 44, 
number 170, April 1985, pages 519-521), I would like access to the 
mpz_tdiv_q_2exp function that divides an integer by a power of 2 by efficient 
shift operations.

I have considered using FFI, but although I have not given up this idea, it 
seems hard to do in a manner that avoids some potentially significant 
additional overhead.  So, the idea that I am currently exploring is to add 
some new primitive operations to Haskell as supported by GHC.

Offhand, I would not have considered it likely that going in this direction 
would be particularly easy. So I was happy to discover that GHC already 
supports certain additional direct gmp calls. For example, the GHC.Num module 
includes the gcdInteger function that more or less directly calls mpz_gcd, 
everything in a seemingly straightforward manner.

Unfortunately, my attempt to mimic this has failed. In detail, this is what I 
have done:

1. I have expanded ghc-6.4.1-src.tar.bz2 and tried to build it (./configure +   
 
make). No errors detected and seemingly, this produced a working GHC
compiler.

2. Then I changed the source as indicated in the following that compares the 
original with my changed version:

  [EMAIL PROTECTED]:~/tn/Haskell/ghc/unpack diff -r original/ . | grep -v 
'^Only 
in \./ghc'
  diff -r 
original/ghc-6.4.1/ghc/compiler/prelude/primops.txt.pp 
./ghc-6.4.1/ghc/compiler/prelude/primops.txt.pp
  6a7
   -- 2006-Mar-20 20.29 / TN: Experiment with additional primitive 
operations
  429a431,435
   primop   IntegerQuot2ExpOp   quotInteger2Exp# GenPrimOp
  Int# - ByteArr# - Int# - (# Int#, ByteArr# #)
  {Rounds towards zero.}
  with out_of_line = True
  
  diff -r 
original/ghc-6.4.1/ghc/includes/StgMiscClosures.h 
./ghc-6.4.1/ghc/includes/StgMiscClosures.h
  10a11,12
* 2006-Mar-21 17.05 / TN: Experiment with additional primitive 
operations
*
  491a494
   RTS_FUN(quotInteger2Expzh_fast);
  diff -r original/ghc-6.4.1/ghc/rts/Linker.c ./ghc-6.4.1/ghc/rts/Linker.c
  6a7,8
* 2006-Mar-21 17.06 / TN: Experiment with additional primitive 
operations
*
  535a538
 SymX(quotInteger2Expzh_fast)\
  diff -r 
original/ghc-6.4.1/ghc/rts/PrimOps.cmm ./ghc-6.4.1/ghc/rts/PrimOps.cmm
  6a7,8
* 2006-03-20 23.50 / TN: Experiment with additional primitive 
operations
*
  29a32,36
   quotInteger2Expzh_fast
   {
   // At this point, the call of mpz_tdiv_q_2exp will eventually be 
inserted
   }
  
  Only in .: original
  Only in .: save
  [EMAIL PROTECTED]:~/tn/Haskell/ghc/unpack

   With these changes, make fails with the error messages

  rm -f GHC/PrimopWrappers.o; if [ ! -d GHC/PrimopWrappers_split ]; then 
mkdir GHC/PrimopWrappers_split; else /usr/bin/find GHC/PrimopWrappers_split 
-name '*.o' -print | xargs rm -f __rm_food; fi;
  ../../ghc/compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude 
-#include HsBase.h -funbox-strict-fields -ignore-package base -O 
-Rghc-timing -fgenerics  -fgenerics -split-objs-c GHC/PrimopWrappers.hs 
-o GHC/PrimopWrappers.o  -ohi GHC/PrimopWrappers.hi

  GHC/PrimopWrappers.hs:133:29: Not in scope: `GHC.Prim.quotInteger2Exp#'
  ghc: 32263284 bytes, 4 GCs, 97412/97412 avg/max bytes residency (1 
samples), 16M in use, 0.00 INIT (0.00 elapsed), 0.12 MUT (0.19 elapsed), 0.02 
GC (0.04 elapsed) :ghc
  make[2]: *** [GHC/PrimopWrappers.o] Error 1
  make[1]: *** [all] Error 1
  make[1]: Leaving directory 
`/home/tn/tn/Haskell/ghc/unpack/ghc-6.4.1/libraries'
  make: *** [build] Error 1

So, evidently, it is not as easy to add new primitive operations as I thought. 
(Or, which is most likely, but embarrasingly, closer to the truth: I am not 
as clever as I thought I was.)

In any case, if someone is able to provide some hint that enables me to 
proceed in this matter, I would be most grateful.

For the 

Re: 6.4.2 release plans

2006-03-22 Thread Jens Petersen
On Tue, 21 Mar 2006 23:31:34 +
Duncan Coutts [EMAIL PROTECTED] wrote:

 Chris found that the problem is that gcc 4.1 is noticing that
 StgRunIsImplementedInAssembler is not actually used anywhere. It is in
 inline assembly in StgRunIsImplementedInAssembler that the global
 symbols StgRun and StgReturn are being defined. This is why it works on
 x86 and not on amd64, because on x86 it uses StgRun rather than
 StgRunIsImplementedInAssembler so the function (and the global syms
 defined therein) are not discarded.
 
 So the solution is to get gcc to not discard the function by using the
 gcc __attribute__((used)). To make this portable we use the existing
 GNUC3_ATTRIBUTE macro, so it's: GNUC3_ATTRIBUTE(used).
 
 The patch we are using in the Gentoo ebuild is here:
 
 http://haskell.org/~gentoo/gentoo-haskell/portage/dev-lang/ghc/files/ghc-6.4.1-gcc41.patch

Thanks a lot for this information, Duncan - finally I managed to rebuild
ghc for FC5 in Fedora Extras with this patch. :)

Jens
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


[Haskell] Re: haskell.org libraries and tools page needs some fixing

2006-03-22 Thread Bulat Ziganshin
Hello Björn,

Wednesday, March 22, 2006, 1:35:42 PM, you wrote:

BB I recently wanted to add some libraries to
BB http://www.haskell.org/haskellwiki/Libraries_and_tools and noticed a 
BB number of problems.

there is also HCAR report. my thoughts is what we should create some
central repository including libs/apps/papers/communities and so on
and replace both this page and HCAR with it. then anyone should
include himself here and edit the info as progress does. i also
created Library/Streams as possible part of this future enciclopedy,
having in mind that Library page will list all libs documented on
haskellwiki. another interesting place which should list libs is
hackage repository

i think that we should discuss this question and develop a common
place where everyone will list his libs/apps/... and document it as
much as he wants

-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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


[Haskell] Re: haskell.org libraries and tools page needs some fixing

2006-03-22 Thread Andres Loeh
 BB I recently wanted to add some libraries to
 BB http://www.haskell.org/haskellwiki/Libraries_and_tools and noticed a 
 BB number of problems.
 
 there is also HCAR report. my thoughts is what we should create some
 central repository including libs/apps/papers/communities and so on
 and replace both this page and HCAR with it. then anyone should
 include himself here and edit the info as progress does. 

Such a proposal comes up every once in a while, and it certainly
sounds like a good idea. But I don't think it will work. From my
experience, getting a HCAR done is not only a lot of fun, but also
quite a bit of work. I think that it is a good thing to have a fixed
point in time when people involved in the Haskell community are
actively approached and asked and pushed to write up what they have
done. In the HCAR, you can see for every single entry if it has been
updated or not (and stuff that is outdated is removed). The result is
archived as a stable point of reference.  With a central repository,
chances are good that no one really feels responsible, and it will be
difficult to reach the same level of breadth and quality. You
certainly can get rid of these advantages by assigning an editor and
some rules ... but why, really, do you want to replace the HCAR with
anything? What do you dislike about it?

Cheers,
  Andres
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell


Re: [Haskell] Haskell as a markup language

2006-03-22 Thread oleg

shelarcy wrote:
 SXML can add useful function for macro, like this;

 (define (M:link keyword url)
`(a (@ (href ,url)) ,keyword))

 (define (M:link_amazon keyword asin)
(M:link keyword
`(http://www.amazon.co.jp/exec/obidos/ASIN/; ,asin /someone_id/)))

 (define (M:book keyword urn)
`((cite ,(M:link keyword `(urn:isbn: ,urn)))
( ,(M:link_amazon Amazon urn) ) ))

 and M:link can use SXML code in its parameter any place;

 ,(M:link `(SXML  (em can write)  this.) http://foo.bar/;)

HSXML can do all this, too (modulo replacement of the round
parentheses with a pair of square ones).

First, we need `Transparent' SPAN: the grouping of SPAN-level
elements.  TSPAN is an administrative element, which is precisely
equivalent to the sequence of SPAN-level elements in its content.  It
is useful as a return value from a function, if a function needs to
return several SPAN-level elements.  The body of TSPAN has the content
Inline, and the TSPAN element itself is in the Inline context.  TSPAN
is the `inline' analogue of TDIV (which works in the block context).

 newtype TSPAN a = TSPAN a deriving Show
 tspan x = build (as_inline . HW . TSPAN . rev'apppend HNil) nil_inline x

 instance RenderInline b = RenderInline (HW CT_inline (TSPAN b)) where
 render_inline f (HW (TSPAN body)) = render_inline f body

We can now write

 link url body = a (attr [href (URL url)]) body

 link_amazon asin = 
link (concat [http://www.amazon.co.jp/exec/obidos/ASIN/,asin,
/someone_id/])

which is the close analogue of the SXML code above, only the 'body'
argument is the last one. That seems to be more consistent, although
tastes may vary.

we can write a simple test
 test1 = as_block (p [[link_amazon 123.456 Amazon book]])

where the body of the link is a simple string. But we can make
it a bit more complex:

 test2 = as_block (p [[link_amazon 123.456 [[tspan Amazon book)

In fact, we can use arbitrary _inline_ markup in the body of the link:

 book urn body = as_block $
 p [[link (urn:isbn: ++ urn) body]]
   ( [[link_amazon urn [[tspan [[em Amazon]] nosp .com )
 test3 = book 123.456 Amazon book

Again, the body of the 'book' doesn't have to be a simple string. We
can use arbitrary _inline_ markup.

 test4 = book 123.456 
 [[tspan HSXML [[em [[strong can]] write]] this, too.]]

But the following leads to the type error
``Couldn't match `CT_inline' against `CT_block'''

-- testb = book 123.456 
--[[h1 HSXML [[em [[strong can]] write]] this, too.]]

Indeed, the h1 element is a block rather than inline element.

Rendering of test4 above

 test4h :: IO () = runHTMLRender $ render test4

gives the expected output.

Perhaps we should move to Cafe for further discussion?

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


RE: Strict tuples

2006-03-22 Thread John Hughes

From: Simon Marlow [EMAIL PROTECTED]

   After some thought, I find myself with a similar view to John. Strict
   tuples are starting to feel like real language bloat, one tiny
   addition
   too much.
   
   Remember, every addition we make to the core syntax is multiplied
   by all
   the parsers for Haskell and tools that have to grok Haskell, and make
   the bar ever-so-slightly higher to producing such tools. There's a
   reason that syntax ends in tax :-)
   


Not to mention all the brains that have to learn it. It seems to me the
gain is small, considering how easy it is to do already.

   By all means have strict tuples in a library somewhere. They don't
   need
   to have special syntax.
   


Agreed.

John

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime


RE: important news: refocusing discussion

2006-03-22 Thread Simon Marlow
On 21 March 2006 23:51, isaac jones wrote:

 Concurrency is summarized here:

http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/Concurrenc
y

I have updated the concurrency page with a skeleton proposal.

Cheers,
Simon
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime


Re: the MPTC Dilemma (please solve)

2006-03-22 Thread Roman Leshchinskiy

On Mon, 20 Mar 2006, Claus Reinke wrote:


variant A: I never understood why parameters of a class declaration
  are limited to variables. the instance parameters just have
  to match the class parameters, so let's assume we didn't
  have that variables-only restriction.

  class Graph (g e v) where
  src :: e - g e v - v
  tgt :: e - g e v - v

  we associate edge and node types with a graph type by
  making them parameters, and extract them by matching.


If I understand correctly, this requires all graphs to be polymorphic in 
the types of edges and vertices. Thus, you cannot (easily) define a graph 
which provides, say, only boolean edges. Moreover, doesn't this require 
higher-order matching?



variant B: I've often wanted type destructors as well as constructors.
  would there be any problem with that?

  type Edge (g e v) = e
  type Vertex (g e v) = v

  class Graph g where
  src :: Edge g - g - Vertex g
  tgt :: Edge g  - g - Vertex g


This suffers from the same problems as the previous variant. It also looks 
a lot like a special form of associated types. Could the AT framework be 
extended to support a similar form of type synonyms (in effect, partial 
type functions outside of classes)? Would


  instance Graph Int
-- methods left undefined

be a type error here?


variant C: the point the paper makes is not so much about the number
  of class parameters, but that the associations for concepts
  should not need to be repeated for every combined concept.
  and, indeed, they need not be

  class Edge g e | g - e
  instance Edge (g e v) e
  class Vertex g v | g - v
  instance Vertex (g e v) v

  class (Edge g e,Vertex g v) = Graph g where
  src :: e - g - v
  tgt :: e - g - v

  (this assumes scoped type variables; also, current GHC,
   contrary to its documentation, does not permit entirely 
FD-determined variables in superclass contexts)


What are the types of src and tgt here? Is it

  src, tgt :: (Edge g e, Vertex g v, Graph g) = e - g - v

This does not seem to be a real improvement to me and, in fact, seems 
quite counterintuitive.


Roman

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime


Re[2]: Strict tuples

2006-03-22 Thread Bulat Ziganshin
Hello Wolfgang,

Wednesday, March 22, 2006, 1:29:24 AM, you wrote:

you said WHAT you think but not said WHY? my motivation is to be able
to use myriads of already implemented algorithms on new datatypes

 as i said, shebang patterns allow only to specify that IMPLEMENTATION
 of some function is strict. this helps only when this function are
 called directly. they can't help when function is passed as parameter
 or enclosed in data structure or a part of class. the same about
 datatypes - i can't declare what some algorithm works only with
 strict lists. i try to find extensions what will allow to specify
 strictness in every case where now we forced to use lazy computations

 the concrete syntax what i propose may be wrong

WJ Well, it's probably nice sometimes to have types which guarantee the 
WJ strictness of certain components.  For example, it might be good to have a
WJ list type where the strictness of the elements is guaranteed.  But I'm sure
WJ that it's wrong to try to achieve this by annotating type arguments like in
WJ [!a].  I think, this approach is wrong, not just the syntax.

WJ Best wishes,
WJ Wolfgang
WJ ___
WJ Haskell-prime mailing list
WJ Haskell-prime@haskell.org
WJ http://haskell.org/mailman/listinfo/haskell-prime



-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime


Ticket #15: add a binary IO interface

2006-03-22 Thread Bulat Ziganshin
Hello ,

about this - i'm almost sure that current widely used libraries
(NewBinary) is not as good as my own one
(http://freearc.narod.ru/Streams.tar.gz) is not ever used and even
still not documented, so it is not easy to make right choice :)

-- 
Best regards,
 Bulat  mailto:[EMAIL PROTECTED]

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime


Re: MonadPlus Reform

2006-03-22 Thread Cale Gibbard
I'd like to put a me too on that one. This part of the class
hierarchy is currently a bit inexpressive. I've been annoyed by the
fact that if I want to express in the type signature of a function
that a monad has a failure mechanism, I'm forced to go all the way up
to MonadPlus, which makes it look like something fully
nondeterministic is happening, when really I'm just possibly failing.

Also, mplus and morelse are quite different things, and it would be
nice to have both even in a monad supporting mplus. For instance, in
the list monad,
mplus = (++)
but
morelse [] ys = ys
morelse (x:xs) ys = (x:xs)

 - Cale

On 21/03/06, Ashley Yakeley [EMAIL PROTECTED] wrote:
 Does this come under the standard libraries topic? I would like to see
 the MonadPlus class disambiguated:

 class Monad m = MonadZero m where
 mzero :: m a
 class MonadZero m = MonadPlus m where
 mplus :: m a - m a - m a
 class MonadZero m = MonadOr m where
 morelse :: m a - m a - m a

 http://haskell.org/haskellwiki/MonadPlus_reform_proposal

 --
 Ashley Yakeley, Seattle WA
 WWED? http://www.cs.utexas.edu/users/EWD/

 ___
 Haskell-prime mailing list
 Haskell-prime@haskell.org
 http://haskell.org/mailman/listinfo/haskell-prime

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime


Re: Re[2]: Strict tuples

2006-03-22 Thread Taral
On 3/22/06, Bulat Ziganshin [EMAIL PROTECTED] wrote:
 ghc uses unboxed tuples just for such sort of optimizations. instead
 of returning possibly-unevaluated pair with possibly-unevaluated
 elements it just return, say, two doubles in registers - a huge win

I have no doubt of this. My comment refers to the idea that somehow
such strictness annotations are (a) required at the type level and (b)
required at all to enable such optimization. I believe the
optimization happens without any annotation from the user, and it
should stay that way.

--
Taral [EMAIL PROTECTED]
You can't prove anything.
-- Gödel's Incompetence Theorem
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime


Re: the MPTC Dilemma (please solve)

2006-03-22 Thread Claus Reinke

  class Graph (g e v) where
  src :: e - g e v - v
  tgt :: e - g e v - v

  we associate edge and node types with a graph type by
  making them parameters, and extract them by matching.


If I understand correctly, this requires all graphs to be polymorphic in 
the types of edges and vertices. Thus, you cannot (easily) define a graph 
which provides, say, only boolean edges. Moreover, doesn't this require 
higher-order matching?


I've already answered the last question. as for polymorphism, all this
requires is for a graph type parameterized by an edge and vertex
type (just as the SML solution, which got full marks in this category,
requires instantiations of the edge and vertex types in the graph structure). 
I already gave an example of a graph instantiated with (Int,Int) edges 
and Int vertices. see below for a translation of the ATC paper examples



variant B: I've often wanted type destructors as well as constructors.
  would there be any problem with that?

  type Edge (g e v) = e
  type Vertex (g e v) = v

  class Graph g where
  src :: Edge g - g - Vertex g
  tgt :: Edge g  - g - Vertex g


This suffers from the same problems as the previous variant. It also looks 
a lot like a special form of associated types. Could the AT framework be 
extended to support a similar form of type synonyms (in effect, partial 
type functions outside of classes)? 


it suffers as little as the previous variant. and it was meant to be a special
form, showing that the full generality of ATs as a separate type class 
extension is not required to solve that paper's issue. and the translation 
from type functions to FDs or ATs is entirely syntactic, I think, so it 
would be nice to have in Haskell', as long as at least one of the two is 
included.



Would

  instance Graph Int
-- methods left undefined

be a type error here?


yes, of course. instances still have to be instances of classes. in variation
A, the type error would be in the instance head, in variation B, it would
be in the method types (although it could backpropagate to the head).


  class Edge g e | g - e
  instance Edge (g e v) e
  class Vertex g v | g - v
  instance Vertex (g e v) v

  class (Edge g e,Vertex g v) = Graph g where
  src :: e - g - v
  tgt :: e - g - v

  (this assumes scoped type variables; also, current GHC,
   contrary to its documentation, does not permit entirely 
FD-determined variables in superclass contexts)


What are the types of src and tgt here? Is it

  src, tgt :: (Edge g e, Vertex g v, Graph g) = e - g - v


yes.

This does not seem to be a real improvement to me and, in fact, seems 
quite counterintuitive.


Roman


you're free to your own opinions, of course!-)

it is, however, probably as close as we can come within current Haskell,
and the shifting of Edge/Vertex to the right of the '=' is a purely syntactic
transformation, even if it is a nice one.

and as you can see from the implementation below (I had to move the 
class methods out of the class to circumvent GHC's current typing problem, 
so no method implementations, only the types), it is sufficient to address the 
problem in that survey paper, and accounting for graphs with specific types 
is no problem (direct translation from ATC paper examples):


   *Main :t \e-src e (undefined::NbmGraph)
   \e-src e (undefined::NbmGraph) :: GE2 - GV2
   *Main :t \e-src e (undefined::AdjGraph)
   \e-src e (undefined::AdjGraph) :: GE1 - GV1

cheers,
claus

{-# OPTIONS_GHC -fglasgow-exts #-}

class Edge g e | g - e
instance Edge (g e v) e 


class Vertex g v | g - v
instance Vertex (g e v) v

class Graph g
-- these should be class methods of Graph..
src, tgt :: (Edge g e,Vertex g v,Graph g) = e - g - v
src = undefined
tgt = undefined

-- adjacency matrix
data G1 e v = G1 [[v]]
data GV1 = GV1 Int
data GE1 = GE1 GV1 GV1
type AdjGraph = G1 GE1 GV1  -- type associations

instance Graph AdjGraph

-- neighbor map
data FiniteMap a b
data G2 e v = G2 (FiniteMap v v) 
data GV2 = GV2 Int

data GE2 = GE2 GV2 GV2
type NbmGraph = G2 GE2 GV2  -- type associations

instance Graph NbmGraph

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime


Re: Strict tuples

2006-03-22 Thread Ben Rudiak-Gould

John Meacham wrote:

ghc's strictness analyzer is pretty darn good, If
something is subtle enough for the compiler not to catch it, then the
programmer probably won't right off the bat either.


Even the best strictness analyzer can't determine that a function is strict 
when it really isn't. The main point of strictness annotations, I think, is 
to actually change the denotational semantics of the program.



strictness does not belong in the type system in general. strictness
annotations are attached to the data components and not type components
in data declarations because they only affect the desugaring of the
constructor, but not the run-time representation or the types in
general. attaching strictness info to types is just the wrong thing to
do in general I think.


Your argument seems circular. Haskell 98 strictness annotations are just 
sugar, but they didn't *have* to be. You can say that f is strict if f _|_ = 
_|_, or you can say it's strict if its domain doesn't include _|_ at all. 
One feels more at home in the value language (seq, ! on constructor fields), 
the other feels more at home in the type language (! on the left of the 
function arrow, more generally ! on types to mean lack of _|_).


-- Ben

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime


Re: Strict tuples

2006-03-22 Thread Ben Rudiak-Gould

Bulat Ziganshin wrote:

Taral wrote:
T I don't see that more optimization follows from the availability
T of information regarding the strictness of a function result's
T subcomponents.

ghc uses unboxed tuples just for such sort of optimizations. instead
of returning possibly-unevaluated pair with possibly-unevaluated
elements it just return, say, two doubles in registers - a huge win


Mmm, not quite. Unboxed tuples are boxed tuples restricted such that they 
never have to be stored on the heap, but this has no effect on semantics at 
all. A function returning (# Double,Double #) may still return two thunks.


-- Ben

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime


Re: Re[2]: Strict tuples

2006-03-22 Thread Manuel M T Chakravarty
Taral:
 On 3/22/06, Bulat Ziganshin [EMAIL PROTECTED] wrote:
  ghc uses unboxed tuples just for such sort of optimizations. instead
  of returning possibly-unevaluated pair with possibly-unevaluated
  elements it just return, say, two doubles in registers - a huge win
 
 I have no doubt of this. My comment refers to the idea that somehow
 such strictness annotations are (a) required at the type level and (b)
 required at all to enable such optimization. I believe the
 optimization happens without any annotation from the user, and it
 should stay that way.

It does happen...sometimes!  The trouble is that for certain types of
programs (eg, numeric intensive ones), you absolutely need that
optimisation to happen.  Without strict tuples, this means, you have to
dump the intermediate code of the compiler and inspect it by hand to see
whether the optimisation happens.  If not, you have to tweak the source
to nudge the compiler into recognising that it can optimise.  Of course,
all your efforts may be wasted when the next version of the compiler is
released or when you have to change your code.

Manuel


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime


Re: Re[2]: Strict tuples

2006-03-22 Thread Taral
On 3/22/06, Manuel M T Chakravarty [EMAIL PROTECTED] wrote:
 It does happen...sometimes!  The trouble is that for certain types of
 programs (eg, numeric intensive ones), you absolutely need that
 optimisation to happen.  Without strict tuples, this means, you have to
 dump the intermediate code of the compiler and inspect it by hand to see
 whether the optimisation happens.  If not, you have to tweak the source
 to nudge the compiler into recognising that it can optimise.  Of course,
 all your efforts may be wasted when the next version of the compiler is
 released or when you have to change your code.

That kind of tweaking isn't required to simulate this. a `seq` b
`seq` (a, b) is perfectly sufficient, and is quite commonly seen in
such programs.

--
Taral [EMAIL PROTECTED]
You can't prove anything.
-- Gödel's Incompetence Theorem
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime


RE: important news: refocusing discussion

2006-03-22 Thread Manuel M T Chakravarty
Simon Marlow:
 On 21 March 2006 23:51, isaac jones wrote:
 
  Concurrency is summarized here:
 
 http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/Concurrenc
 y
 
 I have updated the concurrency page with a skeleton proposal.

Yes, good plan.

Manuel


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime


[Haskell-cafe] Re: Returning a list element?

2006-03-22 Thread Dominic Steinitz
Donald Bruce Stewart dons at cse.unsw.edu.au writes:

  mainMenu =
 sequence_ $ map putStrLn [line1, line2, line3]
 
 I argue if you want to sequence_ a map you should write mapM_:
 
 mapM_ putStrLn [line1, line2, line3]

Nice

 
 mapM is under-appreciated? More under-appreciated are line gaps:
 
 main = putStr line1\n\
   \line2\n\
   \line3\n
 

Or if you don't like hand writing in all the newlines you could use

   putStrLn . concat . intersperse \n
   



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


Re: [Haskell-cafe] Porting GHC to OSX86?

2006-03-22 Thread Thomas Davie


On Mar 21, 2006, at 8:09 PM, Deling Ren wrote:


Hi there,

Has anyone made any attempt to port GHC to Mac OS X on x86?  
Wolfgang Thaller’s binary package runs over Rosetta but slow (not  
surprising). It can not be used to compile a native version either  
(I got some errors related to machine registers).


I tried to do a bootstrap but can't find the .HC files mentioned  
in the manual. They don't seem to be on the download page of GHC.  
Any ideas?


Why not use darwin ports to build it?

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


[Haskell-cafe] Re: strange ghc program behaviour

2006-03-22 Thread Koen . Roelandt
From ghc-6.4, the runtime system no longer flushes open files; it
truncates them instead.  You should close (or flush) the file explicitly
with 'hClose' or 'hFlush' before the program terminates.


I added 'hClose' to processXmlWith in the Wrapper module. That solved the 
problem.
Thank you!
Malcolm, concerning HaXml choking on finding an ampersand (or %) in an 
attribute value (my earlier post): this occurred when the ampersand was 
part of an entity. I solved it by replacing the values for  and % in the 
Lex module (not very elegant, I admit). 

Cheers,

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


Re: [Haskell-cafe] Porting GHC to OSX86?

2006-03-22 Thread Deling Ren

It's not supported on i386 platform yet :(

On Mar 22, 2006, at 12:34 AM, Thomas Davie wrote:



On Mar 21, 2006, at 8:09 PM, Deling Ren wrote:


Hi there,

Has anyone made any attempt to port GHC to Mac OS X on x86?  
Wolfgang Thaller’s binary package runs over Rosetta but slow (not  
surprising). It can not be used to compile a native version either  
(I got some errors related to machine registers).


I tried to do a bootstrap but can't find the .HC files mentioned  
in the manual. They don't seem to be on the download page of GHC.  
Any ideas?


Why not use darwin ports to build it?

Bob


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


[Haskell-cafe] Re: Reading files efficiently

2006-03-22 Thread Simon Marlow

Donald Bruce Stewart wrote:


Well, I know this works:

$ cat A.lhs
#!/usr/bin/env runhaskell
 main = putStrLn gotcha!

$ ./A.lhs 
gotcha!


But for files with no .hs or .lhs extension? Anyone know of a trick?


GHC 6.6 will allow this, because we added the -x flag (works just like 
gcc's -x flag).  eg. ghc -x hs foo.wibble will interpret foo.wibble as 
a .hs file.  I have an uncommitted patch for runghc that uses -x, I need 
to test  commit it.


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


Re: [Haskell-cafe] Porting GHC to OSX86?

2006-03-22 Thread Gregory Wright


Hi,

DP will support the i386 build as soon as Wolfgang makes his
changes available.  As I understand, from earlier messages on one
of the ghc* lists, this is almost done for the pre-6.6 branch, but not
yet backported to the 6.4.x branch.

Also, DP uses a binary bootstrap compiler to build ghc, rather than
starting from the .hc files.  I've been meaning to try it, but I can't
promise any schedule as work and life have distracted me from
code recently.

Best Wishes,
Greg

(darwinports ghc maintainer)


On Mar 22, 2006, at 6:16 AM, Deling Ren wrote:


It's not supported on i386 platform yet :(

On Mar 22, 2006, at 12:34 AM, Thomas Davie wrote:



On Mar 21, 2006, at 8:09 PM, Deling Ren wrote:


Hi there,

Has anyone made any attempt to port GHC to Mac OS X on x86?  
Wolfgang Thaller’s binary package runs over Rosetta but slow (not  
surprising). It can not be used to compile a native version  
either (I got some errors related to machine registers).


I tried to do a bootstrap but can't find the .HC files  
mentioned in the manual. They don't seem to be on the download  
page of GHC. Any ideas?


Why not use darwin ports to build it?

Bob


___
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] planet.haskell.org? for Haskell blogs

2006-03-22 Thread Isaac Jones
I think someone should volunteer to set up Planet Haskell ala Planet
Debian, Planet Gnome, Planet Perl, etc.

These sites are Blog aggregators.  Basically they just collect the
RSS feeds of the community and post their blogs to a web page in a
cute format (the gnome one is especially cute, but you probably could
have guessed that).

There's already software out there for this, so nothing new needs to
be written.  I think we need a volunteer to set this up somewhere?
Preferably someone with their own server, and we'll worry about
setting up the DNS later :)

peace,


  isaac

See:

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


[Haskell-cafe] Wheres this going wrong

2006-03-22 Thread Neil Rutland

Hi there,
Thanks to some advise by one of the other posters i have chosen to try and set up a list that uses lookup to find the values of the elements within it.
However what i have attempted so far has resulted in odd answers or errors. Anyway here it is, i have given each element a string at the start to put the lookup domain in - anyway here it is
type Line = [((String,String),(String,Int),(String,Int),(String,Bool),(String,Bool),(String,Bool),(String,Bool),(String,Bool),(String,Bool),(String,Bool),(String,Bool),(String,Bool))]
vicsLine :: LinevicsLine = [(("a1","Walthamstow Central"),("a2",1),("a3",2),("a4", False), ("a5", True), ("a6", False), ("a7", False), ("a8", False), ("a9", False), ("a10", False), ("a11", False), ("a12", False))]
Anyway when i enter something such as lookup "a1" i get back a load of stuff about Eq.
So the question is - what am i doing wrong. I am hoping that when i enter a1 it should return for me Walthamstow Central.
Cheers everyone - i'm getting there slowly and all your help is much appreciated.
Neil

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


Re: [Haskell-cafe] Wheres this going wrong

2006-03-22 Thread Sebastian Sylvan
On 3/22/06, Neil Rutland [EMAIL PROTECTED] wrote:



 Hi there,

 Thanks to some advise by one of the other posters i have chosen to try and
 set up a list that uses lookup to find the values of the elements within it.

 However what i have attempted so far has resulted in odd answers or errors.
 Anyway here it is, i have given each element a string at the start to put
 the lookup domain in - anyway here it is

 type Line =
 [((String,String),(String,Int),(String,Int),(String,Bool),(String,Bool),(String,Bool),(String,Bool),(String,Bool),(String,Bool),(String,Bool),(String,Bool),(String,Bool))]

 vicsLine :: Line
 vicsLine = [((a1,Walthamstow
 Central),(a2,1),(a3,2),(a4, False), (a5, True),
 (a6, False), (a7, False), (a8, False), (a9, False), (a10, False),
 (a11, False), (a12, False))]

 Anyway when i enter something such as lookup a1 i get back a load of stuff
 about Eq.

 So the question is - what am i doing wrong. I am hoping that when i enter a1
 it should return for me Walthamstow Central.


What shoul happen if you enter a2?
lookup takes a key and  a list of key/value pairs, and maybe returns
the value.
For instance, one list may look like this:
db = [(1,Hello), (2,world)]

If you then use 'lookup 1 db', you'd get 'Just Hello', if you type
'lookup 12 db' you'd get 'Nothing' since there is no pair where 12 is
the first value.

Now, it's important that the list you pass to lookup is of the form: [(a,b)]
In other words it MUST be a list of PAIRS. The second value of the
pair may be of any type (including a complex type with lists and
tuples and what-not) but it must be the SAME type for all the elements
in the list. This isn't just a restriction on lookup, btw, the
elements of a list must always be of the same type:
OK: [(1,hello),(2,bye)]
Not OK: [(2,hello),(2,14)] -- 14 has a different type than hello!

So, what I think you want is something like this:

type Name = String
type Minutes = Int

type StationInfo = [Line] -- maybe something more here?
type Station = (Name,StationInfo)

type LineInfo = [(Minutes, Station)] -- maybe somthing more here?
type Line = (Name,LineInfo)

-- use lookups on these two
-- Its important that both Station, and Line are of the form (a,b)
(and not, say (a,b,c))
type StationDB = [Station]
type LineDB = [Line]

StationInfo would then be a large tuple, perhaps containing a list of
the names of the lines which pass through it (then you could have
another list containing these lines which would map the name of a line
to a LineInfo which would, I suppose, contain a list of station
names).

/S
--
Sebastian Sylvan
+46(0)736-818655
UIN: 44640862
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Wheres this going wrong

2006-03-22 Thread Udo Stenzel
Neil Rutland wrote:
 ttyyppee LLiinnee == 
 [[((((SSttrriinngg,,SSttrriinngg)),,((SSttrriinngg,,IInntt)),,((SSttrriinngg,,IInntt)),,((SSttrriinngg,,BBooooll)),,
 ((SSttrriinngg,,BBooooll)),,((SSttrriinngg,,BBooooll)),,((SSttrriinngg,,BBooooll)),,((SSttrriinngg,,BBooooll)),,((SSttrriinngg,,BBooooll)),,
 ((SSttrriinngg,,BBooooll)),,((SSttrriinngg,,BBooooll)),,((SSttrriinngg,,BBooooll))))]]

What's wrong with a record?

* data Line = Line { a1 :: String, a2 :: Int, ... }

While you're at it, you might want to give the fields sensible names.


 Anyway when i enter something such as lookup a1 i get back a load of stuff
 about Eq.

lookup expects a list of pairs, but you're passing it a tuple.  A list
would have to be homogenous, your tuple isn't, therefore lookup cannot
do what you want.  Just use a record.


Udo.
-- 
Languages shape the way we think, or don't. -- Erik Naggum


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


[Haskell-cafe] Code Review: Sudoku solver

2006-03-22 Thread David F. Place

Hi All,

I really appreciate all the help I received when I asked you to  
critique my PrefixMap module a few weeks ago.  I think I am making  
good progress in correcting the lisp in my Haskell programming.   
I'll be very grateful to anyone who can take a glance at the attached  
short program and say if any unidiomatic usages pop out.  It solves  
sudoku puzzles.  (What pleasure do people get by doing these in their  
heads?!?)


Cheers, David



sudoku.hs
Description: Binary data



David F. Place
mailto:[EMAIL PROTECTED]

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


Re: [Haskell-cafe] Code Review: Sudoku solver

2006-03-22 Thread Jared Updike
On 3/22/06, David F. Place [EMAIL PROTECTED] wrote:
 Hi All,

 I really appreciate all the help I received when I asked you to
 critique my PrefixMap module a few weeks ago.  I think I am making
 good progress in correcting the lisp in my Haskell programming.
 I'll be very grateful to anyone who can take a glance at the attached
 short program and say if any unidiomatic usages pop out

Try

 cellIndex r c = 3*(r `div` 3) + c `div` 3

It's much much shorter and should produce the same results.

 It solves
 sudoku puzzles.  (What pleasure do people get by doing these in their
 heads?!?)


They are probably asking the same question: why take hours to write a
program to do it when with my mad sudoku solving skills I can solve it
in X seconds? My roommate is like this.

Cheers,
   Jared.

--
http://www.updike.org/~jared/
reverse )-:
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Code Review: Sudoku solver

2006-03-22 Thread Robert Dockins


On Mar 22, 2006, at 2:16 PM, David F. Place wrote:


Hi All,

I really appreciate all the help I received when I asked you to  
critique my PrefixMap module a few weeks ago.  I think I am making  
good progress in correcting the lisp in my Haskell programming.   
I'll be very grateful to anyone who can take a glance at the  
attached short program and say if any unidiomatic usages pop out.



sudoku :: Sudoku - IO ()
sudoku s = ((mapM_ putStrLn) . (check s) . (take 1) . solveSudoku) s



check puzzle [] = [showSudoku puzzle,No solutions.]
check puzzle [solution]
  | solution `solves` puzzle =
  [Puzzle:,showSudoku puzzle,Solution:,showSudoku  
solution]

  | otherwise = [Program Error.  Incorrect Solution!]



That '(check s) . (take 1)' bit looks a little odd to me.  I would  
simply have written 'check' to match like:


check puzzle [] = failure case
check puzzle (solution : _ ) = success case


Also, I like to put off doing IO as long as possible, so I'd probably  
have 'sodoku' return a String or [String] and move the putStr into  
main.  Its an easy way to make your code more reusable.


Also, your parser is pretty hackish (but I suspect you knew that  
already).



FYI, solveSudoku has a bug; if you enter an invalid puzzle it will  
return non-solutions.



It solves sudoku puzzles.  (What pleasure do people get by doing  
these in their heads?!?)


I have no idea.


Rob Dockins

Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
  -- TMBG



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


[Haskell-cafe] Bit streams programs in Haskell

2006-03-22 Thread Per Gustafsson


Haskell gurus,

We have made a proposal to extend the Erlang `binary' data type from
being a sequence of bytes (a byte stream) to being a sequence of bits (a
bitstream) with the ability to do pattern matching at the bit level.

This proposal has now been fully implemented all
these at the level of the BEAM virtual machine and in the HiPE
compiler. Most probably, they will be part of the next major
Erlang/OTP open source release. (We write most probably because we
do not really control what Ericsson desides to release as part of its
open source system.)

We wanted to evaluate the performance of our implementation and the
succintness of our syntax, particularly against other `similar'
languages. For this reason, we wrote five reasonably representative
benchmarks, showing the things that one could employ bit stream pattern
matching and bit-level comprehensions for.

The benchmarks (drop3, five11, huffman, uudecode, and uuendode) have
all been written in Erlang, O'Caml and Haskell. For some of them, C
and Java versions exist. They can be found in the following homepage:

  http://bitbenches.infogami.com/

As you will see there, the Haskell numbers are significantly slower
than those of Erlang and O'Caml. We are wondering why this is so.

For each language, we have spent a considerable effort in writing the
benchmarks in -- at least what we feel -- is the most natural and
efficient way one can write them.

The only constraint we impose is that for functional languages, data
structures without any explicit mutation have to be used in the part
of the program for which measurements are taken.

Our experience in writing efficient (and beautiful) Haskell programs is
close to (if not below) zero. Also, perhaps our mind might be suffering
from severe case of strictness and might be completely unable to `think
lazily'. So, we request your help in noticing obvious NO-NOs and stupid
mistakes that we might have made. We even welcome completely different
Haskell programs provided they adhere to the constraint mentioned
above -- no mutation.

Best regards,

Kostis Sagonas and Per Gustafsson


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


Re: [Haskell-cafe] Code Review: Sudoku solver

2006-03-22 Thread Chris Kuklewicz
Robert Dockins wrote:
 
 On Mar 22, 2006, at 2:16 PM, David F. Place wrote:
 
 Hi All,

 I really appreciate all the help I received when I asked you to
 critique my PrefixMap module a few weeks ago.  I think I am making
 good progress in correcting the lisp in my Haskell programming. 

The style of the code and choice of names is good.

 I'll be very grateful to anyone who can take a glance at the attached
 short program and say if any unidiomatic usages pop out.
 
 
 That '(check s) . (take 1)' bit looks a little odd to me.  I would
 simply have written 'check' to match like:
 
 check puzzle [] = failure case
 check puzzle (solution : _ ) = success case
 

A simpler version of replace:

replace :: Sudoku - Int - Int - Int - Sudoku
replace s r c x =
  let (above,row:below) = splitAt r s
  (left,_:right) = splitAt c row
  in above++((left++(x:right)):below)

And a simpler version of toList in keeping with your style:

toList :: Set - [Int]
toList i = concatMap f [9,8..1]
where
  f b = if testBit i b then [b] else []

(The above is also a little less prone to off-by-one errors since testBit is the
opposite of setBit)

 
 Also, I like to put off doing IO as long as possible, so I'd probably
 have 'sodoku' return a String or [String] and move the putStr into
 main.  Its an easy way to make your code more reusable.
 
 Also, your parser is pretty hackish (but I suspect you knew that already).
 
A minimal change to the parser that still does no sanity checking but may be a
little more robust is

import Data.Char

readSudoku :: [String] - String - Sudoku
readSudoku [line] input =
takeBy 9 $ map digitToInt $ filter isDigit $ head $ lines input
readSudoku _ input =
map (map digitToInt . filter isDigit) $ lines input


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


Re: [Haskell-cafe] Bit streams programs in Haskell

2006-03-22 Thread David F. Place
One thing I noticed, is that you are measuring IO in the Haskell  
version of drop3.  hGetContents is lazy.


On Mar 22, 2006, at 4:43 PM, Per Gustafsson wrote:


Also, perhaps our mind might be suffering
from severe case of strictness and might be completely unable to  
`think
lazily'. So, we request your help in noticing obvious NO-NOs and  
stupid

mistakes that we might have made.



David F. Place
mailto:[EMAIL PROTECTED]

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


Re: [Haskell-cafe] Bit streams programs in Haskell

2006-03-22 Thread Chris Kuklewicz
Per Gustafsson wrote:

 Haskell gurus,


I am not a guru, but I'll clean up some of this.

 Our experience in writing efficient (and beautiful) Haskell programs is
 close to (if not below) zero. Also, perhaps our mind might be suffering
 from severe case of strictness and might be completely unable to `think
 lazily'. So, we request your help in noticing obvious NO-NOs and stupid
 mistakes that we might have made. We even welcome completely different
 Haskell programs provided they adhere to the constraint mentioned
 above -- no mutation.

 Best regards,

 Kostis Sagonas and Per Gustafsson


I can't test this, but I have attached a new version of huffman.hs that may
perform a bit better.  I don't know if all the changes I made helped instead of
hurt.  I doubt it was sped up by much.

-- 
Chris Kuklewicz
--module Huffman where
import System.IO
import Data.Bits
import Data.Word
import Data.Array.IO
import Data.Array.Unboxed hiding ((!))
import Data.Array.Base(unsafeAt)
import System(getArgs)
import System.CPUTime(getCPUTime)
import Foreign.Marshal.Array (withArrayLen)
import Control.Exception(bracket)

data HuffTree  = Leaf Word8 | Branch HuffTree HuffTree 

type A = UArray Int Word8

(!) = unsafeAt

iter = 10

{-- the do_iter function repeats a function iter times
 it is not pretty, but it is hard to convince haskell to 
 repeat a computation many times --}

do_iter 1 func input = let x = func input
   in return x
do_iter k func input =  let x = func input
in seq (last x) (do_iter (k-1) func input)

main =
do 
 [arg] - getArgs
 handle - openFile arg ReadMode
 let size = 200
 arrM - newArray (0,pred size) 0 :: IO (IOUArray Int Word8)
 read_size - hGetArray handle arrM size
 -- convert to immutable array
 arr - unsafeFreeze arrM :: IO (UArray Int Word8)
 t0 - getCPUTime
 res - do_iter iter huff arr
 t1 - getCPUTime
 putStr ((show ((fromInteger(t1-t0)::Float)/(1.0::Float
 bracket (openBinaryFile (arg++.haskell) WriteMode)
 hClose
 (\file - withArrayLen res (flip (hPutBuf file)))

huff:: A - [Word8]
huff arr  = let (hufftree, newindex) = build_tree 4 arr 
limit = get_32bit_int newindex arr
in huffdecode ((newindex+4)*8) arr hufftree (limit+((newindex+4)*8))

huffdecode :: Int - A - HuffTree - Int - [Word8]
huffdecode index arr tree limit = helper index tree
  where helper index (Leaf charval) | index == limit = []
| otherwise  = charval : helper index 
tree 
helper index (Branch left right) | index `seq` True = 
helper (index+1) (if get_bit arr index then right else left)

get_bit :: A - Int - Bool
{-# INLINE get_bit #-}
get_bit arr bitoffset =
let byte = arr ! (shiftR bitoffset 3)
in testBit (shiftL byte (bitoffset .. 7)) 7

build_tree :: Int-A-(HuffTree,Int)
build_tree index arr =
let size = get_16_bitint index arr
build_tree_2 index limit
| (limit-index) == 1 = Leaf (arr ! index)
| otherwise  = let left_size = get_16_bitint index arr
   in Branch (build_tree_2 (index+2)   
(index+2+left_size))
 (build_tree_2 (index+4+left_size) 
limit  )
in (build_tree_2 (index+2) (index+2+size)
   ,(index+2+size))

get_16_bitint :: Int - A - Int
{-# INLINE get_16_bitint #-}
get_16_bitint index arr =
(shiftL (fromIntegral (arr ! index)) 8) .|. 
(fromIntegral (arr ! (index+1)))

get_32bit_int :: Int - A - Int
{-# INLINE get_32bit_int #-}
get_32bit_int index arr =
(shiftL (fromIntegral (arr ! index)) 24) .|. 
(shiftL (fromIntegral (arr ! (index+1))) 16) .|.
(shiftL (fromIntegral (arr ! (index+2))) 8) .|. 
(fromIntegral (arr ! (index+3))) 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Bit streams programs in Haskell

2006-03-22 Thread Donald Bruce Stewart
per.gustafsson:
 
 Haskell gurus,
 
 We have made a proposal to extend the Erlang `binary' data type from
 being a sequence of bytes (a byte stream) to being a sequence of bits (a
 bitstream) with the ability to do pattern matching at the bit level.
 
 Our experience in writing efficient (and beautiful) Haskell programs is
 close to (if not below) zero. Also, perhaps our mind might be suffering
 from severe case of strictness and might be completely unable to `think
 lazily'. So, we request your help in noticing obvious NO-NOs and stupid
 mistakes that we might have made. We even welcome completely different
 Haskell programs provided they adhere to the constraint mentioned
 above -- no mutation.

Ok, I rewrote the drop3 program to use packed, unboxed arrays as the
OCaml version does, instead of lazy boxed lists.

It now runs in 3.5s on my linux box, which is around which is around
what the OCaml version does.

$ ghc B.hs
$ ./a.out testdata.drop3
3.617
$ cmp testdata.drop3.haskell testdata.drop3.out

Comparing lazy list IO against packed array IO is a bit silly, so I suggest you
use the same buffer types in your Haskell code as you do in the OCaml code.
Otherwise the comparisons aren't very meaningful.  The problem is not so much
laziness, as you suggest, but that you're using a completely unsuitable data
type: lists, instead of (packed) strings.

You can most likely just translate your other OCaml programs into Haskell as I
have done here, which would be a good basis for a reasonable comparison.

You may also find the Haskell performance resource useful, 
http://www.haskell.org/haskellwiki/Performance

Cheers,
  Don
{-# OPTIONS -O2 #-}
--
-- Translated from the OCaml version.
--

import Control.Monad
import Data.Char
import Data.Array.IO
import Data.Array.Base
import Data.Bits
import Data.Word
import System
import System.CPUTime
import System.IO
import Text.Printf

iter :: Int
iter = 10

main = do
f - getArgs = return . head
(arr,l)   - slurp f 
t0- getCPUTime
(arr',l') - replicateM iter (drop0xx arr (l*8)) = return . head
t1- getCPUTime
printf %.3f\n $ (fromInteger (t1 - t0) :: Float) / (fromInteger 10 ^ 12 
:: Float)
dump f arr' (1 + (snd . bounds) arr')

drop0xx = drop0xx' 0 0 0 []

drop0xx' :: Int - Int - Int - [Int] - Buffer - Int - IO (Buffer,Int)
drop0xx' inoff reg shifts acc str len
| inoff `seq` reg `seq` shifts `seq` acc `seq` str `seq` len `seq` False = 
undefined
| inoff'  len  = makeResult (reverse acc) reg shifts
| otherwise = do
triple - getTriple str inoff
if triple = 4 
then let reg' = (reg `shiftL` 3) .|. triple 
 in if shifts == 7
then drop0xx' inoff' 00  (reg':acc) str len
else drop0xx' inoff' reg' (shifts+1) accstr len
else drop0xx' inoff' reg shifts acc str len

where inoff' = inoff + 3

getTriple :: Buffer - Int - IO Int
getTriple str inoff | str `seq` inoff `seq` False = undefined 
getTriple str inoff = do
b0 - str `unsafeRead` bitind = return . fromIntegral
b1 - str `unsafeRead` (bitind+1) = return . fromIntegral
return $! (if bitoff  6
  then  b0 `shiftR` (5-bitoff)
  else (b0 `shiftL` (bitoff-5)) .|. (b1 `shiftR` (13-bitoff)))
  .. 7

  where bitoff = inoff .. 7
bitind = inoff `shiftR` 3

makeResult :: [Int] - Int - Int - IO (Buffer,Int)
makeResult list0 endpiece shifts = do
arr - newArray_ (0,triplebytesize + endpiecesize-1) :: IO Buffer

let packList (triple:rest) ind = do 
 unsafeWrite arr ind $ fromIntegral $ (triple `shiftR` 16) .. 
255
 unsafeWrite arr (ind+1) $ fromIntegral $ (triple `shiftR`  8) .. 
255
 unsafeWrite arr (ind+2) $ fromIntegral $ triple   .. 
255
 packList rest (ind+3)

packList [] ind = 
let c1 = endpiece `shiftL` ((shifts*3 - 8) .. 255)
s0 = shifts * 3 - 8
in case endpiecesize of
0 - return ()
1 - do unsafeWrite arr ind $ fromIntegral $
  endpiece `shiftL` (s0 .. 255)
2 - do unsafeWrite arr ind $ fromIntegral $
  endpiece `shiftL` (s0 .. 255)
unsafeWrite arr (ind+1) $ fromIntegral $
  endpiece `shiftL` ((s0-8) .. 255)
packList list0 0
return (arr, triplebytesize * 8 + shifts * 3)

where endpiecesize   = getNeededBytes shifts 
  triplebytesize = 3 * length list0

getNeededBytes shifts | shifts  3 = 0
  | shifts  6 = 1
  | otherwise  = 2
  


type Buffer = IOUArray Int Word8

slurp :: FilePath - IO (Buffer, Int)
slurp f = do
h   - openBinaryFile f ReadMode
l   -