Re: [GHC] #470: build fails on Linux/sparc (genprimopcode: parse error at)

2006-03-01 Thread GHC
#470: build fails on Linux/sparc (genprimopcode: parse error at)
---+
  Reporter:  arekm |  Owner:  nobody  
  Type:  bug   | Status:  assigned
  Priority:  normal|  Milestone:  6.4.2   
 Component:  Compiler  |Version:  6.4.1   
  Severity:  normal| Resolution:  None
  Keywords:| Os:  Linux   
Difficulty:  Unknown   |   Architecture:  sparc   
---+
Changes (by simonmar):

  * difficulty:  = Unknown
  * milestone:  = 6.4.2

Comment:

 See also:

 http://www.haskell.org//pipermail/glasgow-haskell-users/2006-
 March/009765.html

-- 
Ticket URL: http://cvs.haskell.org/trac/ghc/ticket/470
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] #696: segmentation fault in ./genprimopcode (x86_64)

2006-03-01 Thread GHC
#696: segmentation fault in ./genprimopcode (x86_64)
-+--
  Reporter:  taral   |  Owner:  simonmar  
  Type:  bug | Status:  new   
  Priority:  normal  |  Milestone:  6.4.2 
 Component:  Compiler (NCG)  |Version:  6.4.1 
  Severity:  normal  | Resolution:
  Keywords:  | Os:  Linux 
Difficulty:  Unknown |   Architecture:  x86_64 (amd64)
-+--
Comment (by simonmar):

 taral - does the -fasm version of the null program crash for you?

-- 
Ticket URL: http://cvs.haskell.org/trac/ghc/ticket/696
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] #696: segmentation fault in ./genprimopcode (x86_64)

2006-03-01 Thread GHC
#696: segmentation fault in ./genprimopcode (x86_64)
-+--
  Reporter:  taral   |  Owner:  simonmar  
  Type:  bug | Status:  new   
  Priority:  normal  |  Milestone:  6.4.2 
 Component:  Compiler (NCG)  |Version:  6.4.1 
  Severity:  normal  | Resolution:
  Keywords:  | Os:  Linux 
Difficulty:  Unknown |   Architecture:  x86_64 (amd64)
-+--
Comment (by simonmar):

 null.s looks like it is unregisterised, whereas null.fasm.s is
 registerised.  This would explain the crash: if the default RTS is
 unregisterised, linking registerised code against it will fail.

 So I guess your Debian build of GHC 6.4.1 is unregisterised.  This is
 something you should probably look into - there's no reason to have an
 unregisterised build of 6.4.1 for x86_64, registerised works fine and is a
 lot faster (and -fasm works).

 It is usual to disable the native code generator for a registerised build.
 I guess the Debian folks didn't do this.  I'll look into providing more
 safety checks in GHC to make sure you get a sensible error message rather
 than a crash in the future.

-- 
Ticket URL: http://cvs.haskell.org/trac/ghc/ticket/696
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] #637: Ctrl-Break handler doesn't work in forked threads in -threaded RTS

2006-03-01 Thread GHC
#637: Ctrl-Break handler doesn't work in forked threads in -threaded RTS
+---
  Reporter:  [EMAIL PROTECTED]  |  Owner:  simonmar
  Type:  bug| Status:  new 
  Priority:  normal |  Milestone:  6.6 
 Component:  Runtime System |Version:  6.4.1   
  Severity:  normal | Resolution:  
  Keywords: | Os:  Windows 
Difficulty:  Moderate (1 day)   |   Architecture:  Unknown 
+---
Changes (by guest):

  * cc:  = [EMAIL PROTECTED]

-- 
Ticket URL: http://cvs.haskell.org/trac/ghc/ticket/637
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: Problem building on sparc/Linux

2006-03-01 Thread Dinko Tenev
Something to do with Parsec, maybe?

For what it's worth, the darcs repo version of genprimopcodes compiled
with GHC 6.4 does parse the attached vore-primops.txt.

On 3/1/06, Ian Lynagh [EMAIL PROTECTED] wrote:
[ ... ]
 ../utils/genprimopcode/genprimopcode --data-decl   
 prelude/primops.txt  primop-data-decl.hs-incl
 genprimopcode: parse error at (line 579, column 1):
 unexpected \t
 expecting primop, section or thats_all_folks
[ ... ]

--

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


RE: GHC 6.4.1 crash on Windows XP

2006-03-01 Thread Simon Marlow
Can you tell which process is crashing?  Is it the GHC process that is
interpreting Setup.hs, or the process invoked by Setup.hs to build the
package?

One thing you could try is compiling Setup.hs to a binary, and running
that instead.

Also, if you could run Setup like this and send us the output:

  $ ./setup build -v

(or the runhaskell version, if that's the only one that crashes)

Cheers,
Simon

On 28 February 2006 10:57, Cyril Schmidt wrote:

 Simon Marlow wrote:
 
 Does it always crash in the same way?
 
 Yes, as far as I can see. Unfortunately, most of the context is
 already lost when the error message pops up. The error code is
 always the same.
 
 Can you fire up GHCi and perform a small evaluation or two?
 
 Yes, this works just fine.
 
 Can you compile small programs, do they run?
 
 Also works fine.
 
 
 Please send us the complete output from commands that crash: eg. add
 -v to the build command above. 
 
 
 I attach the stderr and stdout from
 runhaskell -v5 Setup.hs build
 
 I could also send the sources of the package being compiled, but I do
 not think they are relevant here: it crashes on *any* package.
 
 BTW, I had installed Cabal-1-1.3, but it did not help, so I reverted
 to the version of Cabal that came with the compiler.
 
 It is strange that the same version of GHC works fine on my PC and
 breaks on that of my colleague. To the best of my knowledge, these
 two PCs are not different from each other in any special way. I did
 have some strange crashes on my PC as well, but these were cured by
 upgrading from 6.4 to 
 6.4.1.
 
 Cheers,
 
 Cyril
 
 
 Cyril Schmidt wrote:
 A freshly installed GHC 6.4.1 on my colleague's PC crashes when I
 try to build a package: 
 
 runhaskell Setup.hs build
 
 The effect is easily reproduceable (it shows up on *any* package
 that I try to build). 
 
 Does anyone have any idea of what might be wrong here?

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


Re: factorial: let's get ahead of jhc! :)

2006-03-01 Thread Simon Marlow
FWIW, here's the inner loop of the accumulating parameter factorial 
compiled with yesterday's HEAD on x86_64, via C:


Fac_zdwfac_info:
movq%rsi, %rax
testq   %rsi, %rsi
jne .L4
movq%rdi, %rbx
jmp *(%rbp)
.L4:
leaq-1(%rsi), %rsi
imulq   %rax, %rdi
jmp Fac_zdwfac_info

It's not perfect, but note the absence of memory operations.

The NCG version is similar, but has a couple of extra reg-to-reg moves 
(we need to beef up the NCG optimisations a bit).


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


Re: Missing Folder in ghc?

2006-03-01 Thread Simon Marlow

Ashley Yakeley wrote:

Lemmih wrote:


Did you run 'sh darcs-all get'?



Oh, that wasn't in the README. Thanks. But now I get this:

/usr/bin/ghc -H16m -O -I. -Iinclude -Rghc-timing  -I../../../libraries 
-fglasgow-exts -no-recomp-c System/Directory/Internals.hs -o 
System/Directory/Internals.o  -ohi System/Directory/Internals.hi


System/Directory/Internals.hs:1:0:
Module `System.Directory.Internals' is a member of package base-1.0.
To compile this module, please use -ignore-package base-1.0.

I'm using GHC 6.4.


The configure script has mis-detected your GHC version somehow.  Could 
you look through the output of configure, and see what it says about 
GHC?  Also look in mk/config.mk, at the value of GhcCanonVersion.


Maybe you switched GHC versions but didn't reconfigure?

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


Re: Problem building on sparc/Linux

2006-03-01 Thread Ian Lynagh
On Wed, Mar 01, 2006 at 12:24:17PM +, Simon Marlow wrote:
 
 There's a ticket open on this one:
 
   http://cvs.haskell.org/trac/ghc/ticket/470
 
 The ticket does give more info (isSpace isn't working correctly).  If 
 you could track this down further, that would be great.

Looks like a (fixed) gcc bug:

[EMAIL PROTECTED]:/scratch/igloo/space$ rm *.o *.hi foo; ghc -Wall -O foo.hs -o 
foo  ./foo
[True,False,True,True,False,True]
[EMAIL PROTECTED]:/scratch/igloo/space$ rm *.o *.hi foo; ghc -Wall -O foo.hs -o 
foo -pgmc /usr/bin/gcc-4.0  ./foo
[True,True,True,True,True,True]
[EMAIL PROTECTED]:/scratch/igloo/space$ gcc --version
gcc (GCC) 3.3.6 (Debian 1:3.3.6-12)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[EMAIL PROTECTED]:/scratch/igloo/space$ /usr/bin/gcc-4.0 --version
gcc-4.0 (GCC) 4.0.3 20060212 (prerelease) (Debian 4.0.2-9)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


I'll get the default gcc upgraded and try the build again.


Thanks
Ian

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


Re: Building Win32 DLLs: Manual is not up-to-date

2006-03-01 Thread Simon Marlow

Michael Marte wrote:


I am trying to turn a prototype written in Haskell into something
I can call from a Visual Studio C++ 6.0 program. (The prototype is
so clean and fast that there is no point in recoding everything.)
So I followed the instructions in section 11.5 of the ghc manual
(Building and using Win32 DLLs) and ended up as follows:

$ ghc -c dllMain.c
dllMain.c:4: warning: type defaults to `int' in declaration of `EXTFUN'
dllMain.c:4: warning: parameter names (without types) in function 
declaration

dllMain.c:4: warning: data definition has no type or storage class
dllMain.c: In function `DllMain':
dllMain.c:18: error: `__stginit_Adder' undeclared (first use in this
function)
dllMain.c:18: error: (Each undeclared identifier is reported only once
dllMain.c:18: error: for each function it appears in.)

Section 8.2 proposes to add

extern void __stginit_Adder(void)

which actually works.


docs fixed, thanks.

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


Re: Problem building on sparc/Linux

2006-03-01 Thread Duncan Coutts
On Wed, 2006-03-01 at 12:59 +, Ian Lynagh wrote:
 On Wed, Mar 01, 2006 at 12:24:17PM +, Simon Marlow wrote:
  
  There's a ticket open on this one:
  
http://cvs.haskell.org/trac/ghc/ticket/470
  
  The ticket does give more info (isSpace isn't working correctly).  If 
  you could track this down further, that would be great.
 
 Looks like a (fixed) gcc bug:

That might explain why it seems to be working perfectly well on
Gentoo :-)

We do a registerised sparc build and it builds itself and things like
darcs  gtk2hs ok.

Duncan

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


Re: Problem building on sparc/Linux

2006-03-01 Thread Simon Marlow

Ian Lynagh wrote:

On Wed, Mar 01, 2006 at 12:24:17PM +, Simon Marlow wrote:


There's a ticket open on this one:

 http://cvs.haskell.org/trac/ghc/ticket/470

The ticket does give more info (isSpace isn't working correctly).  If 
you could track this down further, that would be great.



Looks like a (fixed) gcc bug:

[EMAIL PROTECTED]:/scratch/igloo/space$ rm *.o *.hi foo; ghc -Wall -O foo.hs -o foo 
 ./foo
[True,False,True,True,False,True]
[EMAIL PROTECTED]:/scratch/igloo/space$ rm *.o *.hi foo; ghc -Wall -O foo.hs -o foo 
-pgmc /usr/bin/gcc-4.0  ./foo
[True,True,True,True,True,True]
[EMAIL PROTECTED]:/scratch/igloo/space$ gcc --version
gcc (GCC) 3.3.6 (Debian 1:3.3.6-12)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[EMAIL PROTECTED]:/scratch/igloo/space$ /usr/bin/gcc-4.0 --version
gcc-4.0 (GCC) 4.0.3 20060212 (prerelease) (Debian 4.0.2-9)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


It could be a gcc bug, or it could be that GHC is relying on undefined C 
semantics.  If you feel inclined, I'd be really interested to know which 
code fragment is responsible (you'd need to replace fragments of the .s 
file in a binary search to find the right spot).  If you can't be 
bothered, that's fine too :-)  I'll close the bug.


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


RE: GHC 6.4.1 crash on Windows XP

2006-03-01 Thread Cyril Schmidt
 Can you tell which process is crashing?  Is it the GHC process that is
 interpreting Setup.hs, or the process invoked by Setup.hs to build the
 package?

I suspect it is the GHC process that is invoked by Setup.hs, but I do not
have any hard evidence to support this.

 One thing you could try is compiling Setup.hs to a binary, and running
 that instead.

That worked!
I think this counts as evidence for the above.


 Also, if you could run Setup like this and send us the output:

   $ ./setup build -v

 (or the runhaskell version, if that's the only one that crashes)

I did it via runhaskell:

runhaskell Setup.hs build -v
Preprocessing library Vasicek-0.3...
Building Vasicek-0.3...

This is all what it said before the crash...


Just about 15 minutes ago I fixed the problem (at least I hope I did)
by installing the snapshot of GHC 6.4.2 of February 27 (BTW, the
cc1.exe is missing from the tar file).

I also found at least one difference between the PC where the problem
showed up and the one where it did not. Both PCs had Cygwin installed.
On the PC where the problem did not show up, the Cygwin executables
shadowed the Windows programs with the same name: e.g. if I type
'find' in Windows command prompt, I get the UNIX find. On the PC where
the problem did show up, it was the other way: I get the Windows find
(of course, from the bash shell I always get the UNIX find).

I do not know, though, if this is linked in any way to the GHC problem.
I spent some time playing with PATH to try to make the two PCs behave
the same, but I could not (I do not have Admin priviledges). The GHC
was always started from the Windows prompt, never from bash.


Anyway, as the problem is solved by moving from 6.4.1 to 6.4.2, we can
conclude that it was caused by one of the bugs fixed after 6.4.1, and
close the issue for now.  If you, however, would like to continue
investigation, please let me know -- I can easily reproduce
the problem, and I'll be happy to get any extra information for you
(once I know how to get it). I will keep version 6.4.1 for the time being.

Thank you very much for the help.

Cheers,

Cyril



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


GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?

2006-03-01 Thread Michael Marte

Hello *,

before filing a bug report, I want others to comment on my problem. 
Maybe it's my fault, not ghc's.


I wrapped up some Haskell modules in a Win32 DLL.
Loading the DLL dynamically (with LoadLibrary) works fine. However, 
whether I actually use the library or not, the program (an application 
with MFC GUI) crashes upon termination.
To find the reason for the crash, I added a new function for unloading 
the DLL using FreeLibrary. FreeLibrary works fine, however the program 
crashes when it returns to the main event loop. Interestingly, when I 
reload the library (FreeLibrary followed by LoadLibrary) the program 
continues working. However, every reload cycle causes the virtual size 
of the process to increase by about 300K and the fourth reload fails 
with the error message getMBlock: VirtualAlloc failed with: 8 (appears 
in a message window) accompanied by many repetitions of the message 
Timer proc: wait failed -- error code: 6 (appears on stderr) and 
followed by the message getMBlocks: misaligned block returned (again 
in a message window). Then the programm crashes.


Development takes place on Windows XP Professional using MS Visual 
Studio 6.0 SP 5 and ghc 6.4.1. There are no references from the C++ side 
to the Haskell heap. I build the DLL using the command


ghc --mk-dll -optdll--def -optdllFoo.def -o Foo.dll Foo.o Foo_stub.o 
dllMain.c


dllMain.c looks as follows:

#include windows.h
#include Rts.h

extern void __stginit_EUzu3820zu85(void);

static char* args[] = { ghcDll, NULL };
  /* N.B. argv arrays must end with NULL */
BOOL
STDCALL
DllMain(HANDLE hModule, DWORD reason, void* reserved) {
   if (reason == DLL_PROCESS_ATTACH) {
   /* By now, the RTS DLL should have been hoisted in, but we need 
to start it up. */

   startupHaskell(1, args, __stginit_Foo);
   return TRUE;
   } else if (reason == DLL_PROCESS_DETACH) {
   shutdownHaskell();
   }
   return TRUE;
}

I played around with hs_exit instead of shutdownHaskell, I moved 
initialization and clean-up from DllMain to my library loader, nothing 
helps. Even doing no clean-up whatsoever does not change the behaviour.


Any ideas?
Michael

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


Re: Missing Folder in ghc?

2006-03-01 Thread Ashley Yakeley

Simon Marlow wrote:
The configure script has mis-detected your GHC version somehow.  Could 
you look through the output of configure, and see what it says about 
GHC?


Nothing special:

checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
Canonicalised to: i386-unknown-linux
checking for path to top of build tree... 
/home/ashley/Projects/Collected/Haskell/ghc

checking for ghc... /usr/bin/ghc
checking version of ghc... 6.4
checking for nhc... no
checking for nhc98... no
checking for hbc... no


Also look in mk/config.mk, at the value of GhcCanonVersion.


GHC = /usr/bin/ghc
GhcDir  = $(dir $(GHC))
GhcVersion  = 6.4
GhcMajVersion   = 6
GhcMinVersion   = 4
GhcPatchLevel   = 0

# Canonicalised ghc version number, used for easy (integer) version
# comparisons.  We must expand $(GhcMinVersion) to two digits by
# adding a leading zero if necessary:
ifneq $(findstring $(GhcMinVersion), 0 1 2 3 4 5 6 7 8 9) 
GhcCanonVersion = $(GhcMajVersion)0$(GhcMinVersion)
else
GhcCanonVersion = $(GhcMajVersion)$(GhcMinVersion)
endif


Maybe you switched GHC versions but didn't reconfigure?


I think the problem is that I called autoconf etc. before I called 
darcs-all get, but not after. Calling autoreconf fixed the problem.


--
Ashley Yakeley

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


[Haskell] Haskell as a markup language

2006-03-01 Thread oleg

We demonstrate that Haskell as it is, with no TH or other
pre-processors, can rather concisely represent semi-structured
documents and the rules of their processing. In short, Haskell can
implement SXML (ssax.sourceforge.net), right in its syntax and with
the *open* and extensible set of `tags'. The benefit of Haskell is of
course in static type guarantees, such as prohibiting an H1 element to
appear in the character content of other elements. It also seems that
the specification of various pre-post-order and context-sensitive
traversals is more concise in Haskell compared to Scheme. Again, we
are talking about the existing Haskell, i.e., Haskell98 plus common
extensions. No Template Haskell or even overlapping instances are
required.

The features of our framework are:

- extensibility: at any time the user can add new `tags' and
new transformation/traversal modes.

- static safety: there are no dynamics, and no variant data
types for elements or attributes, and thus no possibility of a run-time
pattern-match failure.

- static guarantees: the framework statically ensures that a
`block-level element' cannot appear in the inline (i.e., character)
content and that a character-content entity cannot appear in a pure
element content. Some entities (e.g., `title') may be either element
or attribute. OTH, many other entities may not occur in the attribute
context. Thus the generated XML or HTML document will not only be
well-formed: it would also satisfy some validity constraints. More
validity constraints can be added to the framework.

- flexibility of the traversal: the same document can be
transformed in pre-, post-, accumulating or other ways, even within
the same session. A document can be processed in a pure function, or
in a monadic action, including an IO action. In the latter case, we
can, e.g., verify URLs as we generate an HTML document.
A `tag' can be transformed depending of the transformation modes and
tag's context: e.g., the same `(title title)' expression may appear as
an attribute or an element -- and it will be rendered differently by
the (X)HMTL serializer.

   - pleasant syntax, which closely resembles SXML. We can write
(p string string1 br string3) without unnecessary commas and
other syntactic distractions. We take polyvariadic functions to the
new level (pun intended). We also exploit functional dependencies on a
per-instance level -- which is a very useful but, alas, rarely used
technique.


We introduce two frameworks for representing semi-structured data in
Haskell. In one, semi-structured data is truly a heterogeneous
structure -- and so can be showed, stored, written and read. In the
second approach, semi-structured data are represented as a monadic
value, polymorphic over the rendering monad. Different choices of the
monad give different views of data. In GHC, this amounts to
representing semi-structured data by linked dictionaries; in JHC, both
approaches are probably equivalent. The first representation is quite
reminiscent of HList; the second has clear SYB3 (``Scratch your
boilerplate with class'') overtones, although the realization is quite
different. In particular, there is no need for recursive instances.

Because of the amount of code involved (to describe common HTML tags
and their constraints), this message is not the complete code. The
code is available from

 http://pobox.com/~oleg/ftp/Haskell/HSXML.tar.gz

Please see the files HSXML.hs, HSXML_HTML.hs and the sample code
sample1c.hs for the data-centric framework. The monad-centric
framework is in one self-contained file CSXML.hs.  The first framework
is more in line with SXML, and so will be considered here.

Our running example, inspired by the Haskell.org web site, is:

test_haskell =
(document
 (head
  [title Haskell longdash HaskellWiki]
  [meta_tag [description All about the language br Haskell]])
(body
 [h1 Haskell]
 [div (attr [title titleline])
  [p
   [[a (attr [href (FileURL /haskellwiki/Image:Haskelllogo.jpg)])
 Haskell br A purely functional language]]
   br
  ]
  [p Haskell is a general purpose, 
   [[em [[strong purely]] functional]] programming language]]))


We should point out the absence of commas.  The [[x]] syntax can be
replaced with a simple [x], but that would require overlapping
instances. So far, we have avoided overlapping instances.
Incidentally, in many Scheme systems (and, reputedly, in R6RS) square
brackets are taken to be synonymous to the round ones.


We see that the |br| can be used in various contexts: in the character
content of an element and of an attribute (cf. `description' for the
latter). However, if we try to replace Haskell within the
`description' attribute with [[em Haskell]] we get an error that
Couldn't match `CT_attr' against `CT_inline'
  Expected type: CT_attr
  Inferred type: CT_inline

OTH, the string Haskell that appears within |h1| element may be

Re: [Haskell] translating Haskell into theorem provers

2006-03-01 Thread Till Mossakowski

There is a prototype translation of Haskell to Isabelle/HOL and
Isabelle/HOLCF written by Paolo Torrini. Unlike the Programatica
translation, it uses a shallow encoding of the type system. Constructor
classes (not available in Isabelle) are translated using theory
morphisms. Programatica is used for parsing and type checking.

The translation is part of the heterogeneous tool set (Hets) [1],
but currently works only in a standalone version, called h2hf. You can
compile h2hf from the Hets sources with make h2hf. Since there is
interest, we will provide a website with binaries, explanation and
examples soon.

Greetings,
Till

[1] http://www.tzi.de/cofi/hets

Gerwin Klein wrote:

Hi,

is any of you aware of activities that aim to translate Haskell into 
interactive theorem provers like PVS or Isabelle/HOL? (automatically or 
manually).


We know about the Programatica project and Brian Huffman's work, but turned 
up little else.


Cheers,
Gerwin

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



--
Till Mossakowski   Phone +49-421-218-4683
Dept. of Computer Science  Fax +49-421-218-3054
University of Bremen   [EMAIL PROTECTED]
P.O.Box 330440, D-28334 Bremen http://www.tzi.de/~till
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell


[Haskell] Re: Implicit Parameters

2006-03-01 Thread Simon Marlow

Ashley Yakeley wrote:

Simon Marlow wrote:

Simon  I have discussed doing some form of thread-local state, which 
covers many uses of implicit parameters and is much preferable IMO. 
Thread-local state doesn't change your types, and it doesn't require 
passing any extra parameters at runtime.  It works perfectly well for 
the OS example you give, for example.



Interesting. What would that look like in code?


No concrete plans yet.  There have been proposals for thread-local 
variables in the past on this list and haskell-cafe, and other languages 
have similar features (eg. Scheme's support for dynamic scoping).  Doing 
something along these lines is likely to be quite straightforward to 
implement, won't require any changes to the type system, and gives you a 
useful form of implicit parameters without any of the drawbacks.


The main difference from implicit parameters would be that thread-local 
variables would be restricted to the IO monad.


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


Re: [Haskell] translating Haskell into theorem provers

2006-03-01 Thread S.J.Thompson



Gerwin - I did some work on this a number of years ago for the related
language Miranda.  This builds on logical renderings of Haskell (and also
Miranda). The translations are reported in

A Logic for Miranda, Revisited. Simon Thompson. Formal Aspects of
Computing, (7), March 1995.

Simon Thompson: Formulating Haskell. in John Launchbury, Patrick M. Sansom
(Eds.): Functional Programming, Glasgow 1992, Proceedings of the 1992
Glasgow Workshop on Functional Programming, Ayr, Scotland, 6-8 July 1992.
Workshops in Computing Springer 1993, ISBN 3-540-19820-2


The work on Isabelle is reported in

Miranda in Isabelle. Steve Hill and Simon Thompson. In Lawrence C.
Paulson, editor, Preceedings of the first Isabelle Users Workshop, number
397 in University Of Cambridge Computer Laboratory Technical Reports
Series, pages 122-135, September 1995


Regards

Simon




On Wed, 1 Mar 2006, Gerwin Klein wrote:

 Hi,

 is any of you aware of activities that aim to translate Haskell into
 interactive theorem provers like PVS or Isabelle/HOL? (automatically or
 manually).

 We know about the Programatica project and Brian Huffman's work, but turned
 up little else.

 Cheers,
 Gerwin

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

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


[Haskell] Re: Visual Haskell: Could not find module `Control.Monad.Writer'

2006-03-01 Thread Ben Rudiak-Gould

Replying to an old thread...

Bernd Holzmüller wrote:

Could not find module `Control.Monad.Writer':   use -v to see a list
of the files searched for


I just installed Visual Haskell and ran into the same problem, and the 
solution I found was to right click on References in the project and add 
the mtl package.


I also had to add the haskell98 package to get Happy-produced source code to 
work (even though Happy was called with --ghc).


-- Ben

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


Re: [Haskell] translating Haskell into theorem provers

2006-03-01 Thread Gerwin Klein
Thanks for all the replies I got, they have been helpful!

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


Re: instance Functor Set, was: Re: Export lists in modules

2006-03-01 Thread Johannes Waldmann
Jim Apple wrote:

 class MyMap f a b where
 myMap :: (a - b) - f a - f b
 instance (Functor f) = MyMap f a b where
 myMap = fmap
 instance (Ord a, Ord b) = MyMap Data.Set.Set a b where
 myMap = Data.Set.map

OK (I guess).

But my point was that I want to use
do notation for Sets (in fact, for any kind of collection)
so I'd need the original Functor and Monad.

I couldn't use ghc's Rebindable Syntax feature
because the types for (=) would not match?
http://www.haskell.org/ghc/docs/6.4/html/users_guide/syntax-extns.html#rebindable-syntax

Best regards,
-- 
-- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 --
 http://www.imn.htwk-leipzig.de/~waldmann/ ---

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


RE: relaxed instance rules spec (was: the MPTC Dilemma (please solve))

2006-03-01 Thread Simon Peyton-Jones
Claus,

I urge you to read our paper Understanding functional dependencies via
Constraint Handling Rules, which you can find here
http://research.microsoft.com/%7Esimonpj/papers/fd%2Dchr/.

It will tell you more than you want to know about why relaxing
apparently-conservative rules is entirely non-trivial.   It's one of
those areas in which it is easy to suggest a plausible-sounding
alternative, but much harder to either prove or disprove whether the
alternative a sound one.

The paper describes rules we are reasonably sure of.   It would be great
to relax those rules.  But you do need to have a proof that the
relaxation preserves the properties we want.  Go right ahead!  The paper
provides a good framework for such work, I think.

Simon

| -Original Message-
| From: Claus Reinke [mailto:[EMAIL PROTECTED]
| Sent: 28 February 2006 19:54
| To: Simon Peyton-Jones; haskell-prime@haskell.org
| Subject: relaxed instance rules spec (was: the MPTC Dilemma (please
solve))
| 
| The specification is here:
|
http://www.haskell.org/ghc/dist/current/docs/users_guide/type-extension
s.html#instance-decls
| 
| two questions/suggestions about this:
| 
| 1. there are other termination criteria one migh think of, though
| many will be out because they are not easy to specify. but here
| is an annoyingly simple example that doesn't fit the current rules
| even though it is clearly terminating (it's not even recursive):
| 
| class Fail all -- no instances!
| 
| class TypeNotEq a b
| instance Fail a = TypeNotEq a a
| instance TypeNotEq a b
| 
| class Test a b where test :: a - b - Bool
| instance TypeNotEq a b = Test a b where test _ _ = False
| instance Test a a where test _ _ = True
| 
| main = print $ (test True 'c', test True False)
| 
| never mind the overlap, the point here is that we redirect from
| Test a b to TypeNotEq a b, and ghc informs us that the
| Constraint is no smaller than the instance head.
| 
| it is true that the parameters don't get smaller (same number,
| same number of constructors, etc.), but they are passed to a
| smaller predicate (in terms of call-graph reachability: there
| are fewer predicates reachable from TypeNotEq than from
| Test - in particular, Test is not reachable from TypeNotEq).
| 
| this is a non-local criterion, but a fairly simple one. and it
seems
| very strange to invoke undecidable instances for this example
| (or is there anything undecidable about it?).
| 
| 2. the coverage condition only refers to the instance head. this
| excludes programs such as good old record selection (which
| should terminate because it recurses over finite types, and is
| confluent -in fact deterministic- because of best-fit overlap
| resolution):
| 
| -- | field selection
| infixl #?
| 
| class Select label val rec | label rec - val where
|   (#?) :: rec - label - val
| 
| instance Select label val ((label,val),r) where
|   ((_,val),_) #? label = val
| 
| instance Select label val r = Select label val (l,r) where
|   (_,r)   #? label = r #? label
| 
| now, it is true that in the second instance declaration, val is
| not covered in {label,(l,r)}. however, it is covered in the
recursive
| call, subject to the very same FD, if that recursive call complies
| with the (recursive) coverage criterion. in fact, for this
particular
| task, that is the only place where it could be covered.
| 
| would it be terribly difficult to take such indirect coverage (via
| the instance constraints) into account? there'd be no search
| involved (the usual argument against looking at the constraints),
| and it seems strange to exclude such straightforward consume
| a type recursions, doesn't it?
| 
| cheers,
| claus

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


Re: Keep the present Haskell record system!

2006-03-01 Thread Malcolm Wallace
Ross Paterson [EMAIL PROTECTED] wrote:

 On Wed, Mar 01, 2006 at 08:26:14AM +, Henrik Nilsson wrote:
  I'm increasingly convinced that the records should be left alone for
  Haskell', possibly modulo some minor tweaks to polish the system.
 
 Yes, no alternative candidate is available (specified, implemented,
 used).

Well, there _are_ some alternatives that have been specified and
implemented e.g. TREX in Hugs, and experimental languages like Daan
Leijen's Morrow.

But the main reason I can see for there being little use of these
candidates, is that they are not compatible with current Haskell.

Thus, although I agree that none is ready for inclusion in
Haskell-prime, I think we do need some mechanism for experimental
records to be tried out in real Haskell implementations before the
Haskell-double-prime committee starts its work.

Perhaps, taking the extensions-layering idea, we could say that the
current named-fields are encapsulated as an extension that is part of
the standard.  Implementations could then introduce a flag to switch
off this particular extension (current records) in conjunction with
flags to switch on experimental replacements.  This would give a certain
flexibility for users to play with different systems, and the breaking
of compatibility would be explicitly notated, either by the build
options, or using a proposal like ticket #94.

My suggestion is that we separate out everything from the Report to do
with named-field records into something like a self-contained addendum.
Whilst still an official part of the language standard, it might also be
marked as a possibility for future removal.  This would make it clear
what parts of the language could be changed (or re-used without conflict)
in an alternative records system.

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


RE: realToFrac issues

2006-03-01 Thread Simon Marlow
On 28 February 2006 18:42, Jacques Carette wrote:

 What *problem* are you actually trying to solve here?

The problem that 'realToFrac (0/0 :: Float) :: Double' doesn't give you
NaN, and similarly for the other special float values.

 If it is
 conversion between floating point types, then there are other
 solutions that do not need to ``pollute'' exact arithmetic.  I did not
 see any tickets on this -- did I miss it/them?  This is one issue
 where I should go and contribute, as I've been part of a team that
 has done just this to a programming language before, so at least I
 can claim to know the pitfalls to avoid!

Please go ahead and create a ticket.  

I don't claim to know a great deal about floating point, but Cale
Gibbard's suggestion (use encodeFloat.decodeFloat) looks reasonable to
me.  I have an old item on my GHC ToDo list that says make
encodeFloat.decodeFloat work for NaN :-)

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


Re: instance Functor Set, was: Re: Export lists in modules

2006-03-01 Thread Jim Apple
On 3/1/06, Johannes Waldmann [EMAIL PROTECTED] wrote:
 But my point was that I want to use
 do notation for Sets (in fact, for any kind of collection)
 so I'd need the original Functor and Monad.

I understand this for Monad. Why not just redefine Functor, Oleg-style?

 I couldn't use ghc's Rebindable Syntax feature
 because the types for (=) would not match?
 http://www.haskell.org/ghc/docs/6.4/html/users_guide/syntax-extns.html#rebindable-syntax

Good news, everyone!

http://www.haskell.org/ghc/dist/current/docs/users_guide/syntax-extns.html#rebindable-syntax

That looks good to me!

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


Re: overlapping instances and constraints

2006-03-01 Thread Ben Rudiak-Gould

Niklas Broberg wrote:

Ben Rudiak-Gould wrote:

Are there uses of overlapping
instances for which this isn't flexible enough?


Certainly!


Hmm... well, what about at least permitting intra-module overlap in Haskell' 
(and in GHC without -foverlapping-instances)? It's good enough for many 
things, and it's relatively well-behaved.



instance (Show a) = IsXML a where
 toXML = toXML . show

The intention of the latter is to be a default instance unless another
instance is specified.


I can see how this is useful, but I'm surprised that it's robust. None of 
the extensions people have suggested to avoid overlap would help here, clearly.


Are there uses of overlapping instances for which the single-module 
restriction isn't flexible enough, but extensions that avoid overlap are 
flexible enough?


-- Ben

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


Re: overlapping instances and constraints

2006-03-01 Thread Ashley Yakeley

Ben Rudiak-Gould wrote:

I think all of these problems would go away if overlap was permitted 
within a module but forbidden across modules. Are there uses of 
overlapping instances for which this isn't flexible enough?


I dislike this on principle. I like the idea that modules can be 
refactored easily.


But I'm not a big fan of overlapping instances anyway, and don't turn on 
the option. This makes it easier to reason about instances, as they 
always apply to their complete domains.


I'm much more interested in allowing non-overlapping instances such as:

  class C a
  instance C Bool
  instance (Num a) = C a

However, I'm aware this is hard for the type-checker. In general, I 
think there's a consensus on what the type-checker should allow in a 
perfect world (assuming one has made a decision on whether to allow 
overlapping instances etc.). It seems the problem is how much of 
perfection can be implemented. It might be worth collecting examples of 
things that don't compile but should on a HaskellWiki page.


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


Re: the MPTC Dilemma (please solve)

2006-03-01 Thread John Meacham
On Tue, Feb 28, 2006 at 07:12:28PM -, Claus Reinke wrote:
 Anyway, there is already a ticket for overlapping instances, I think --
 why don't you just add to that.
 
 that might work. apart from the fact that I really, really hate the 
 braindead wiki markup processor, especially when editing through
 that tiny ticket change field instead of loading up text. I went through
 that experience once, when Isaac suggested the same for my labels
 proposal - I don't want to have to do that again.
 

MozEX is your friend:
  http://mozex.mozdev.org/

it lets you click on any text field on the web and say 'edit in vim' (or
whatever editor you choose)

John

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


Re: relaxed instance rules spec (was: the MPTC Dilemma (please solve))

2006-03-01 Thread Claus Reinke

I urge you to read our paper Understanding functional dependencies via
Constraint Handling Rules, which you can find here
http://research.microsoft.com/%7Esimonpj/papers/fd%2Dchr/.


Simon,

I had already read that paper briefly, but had moved on to scan some 
of the other publications in that area (ats, ..), because I was unhappy 
with its limitations, omissions, and what I perceived as overly quick 
conclusions. I have now returned to it, and although I still haven't 
read it in full, I see that my misgivings were mostly the result of 
impatience - it may not be the final word, but, together with:


   P. J. Stuckey and M. Sulzmann. A theory of overloading. ACM 
   Transactions on Programming Languages and Systems (TOPLAS), 
   27(6):1-54, 2005.


it does provide a good, and necessary start, and a useful basis for 
discussions. 


[may I suggest a reference section on the main Haskell' page, listing
these and other important inputs to difficult Haskell' issues?]


It will tell you more than you want to know about why relaxing
apparently-conservative rules is entirely non-trivial.   It's one of
those areas in which it is easy to suggest a plausible-sounding
alternative, but much harder to either prove or disprove whether the
alternative a sound one.


what I've read so far tells me less than I want to know, exactly
because I think more relaxations are necessary, but are left for 
future work. also, while it is true that plausible-sounding variations 
may lead to surprising results, it is unfortunately also true that the 
first explanation of such surprises isn't always the best one.


case in point: you replied to my suggestion to relax the coverage
condition to a recursive coverage condition, and the paper you
refer to contains an example which seems to demonstrate that
this wouldn't be safe (example 6):

   class Mul a b c | a b - c where..
   instance Mul Int Int Int where ..
   instance Mul a b c = Mul a (Vec b) (Vec c) where ..

this looks terminating, because it recurses down a finite type in
its second parameter, but it violates the coverage condition in
the second instance, where c is not in {a,b}. as I've argued
in my message, I'd like to think of recursive coverage here,
because c is covered via the FD in the recursive call.

now, the paper presents an example expression that leads
to the following constraint, with a non-terminating inference:

   Mul a (Vec b) b --{b=Vec c}-- Mul a (Vec c)  c

and the paper claims that this is a direct consequence of the
violation of the coverage condition!

so, one of us is wrong, either my plausibility argument for
recursive coverage, or the paper's claim that recursive coverage
(or, for that matter, any relaxation of coverage that would 
permit that instance declaration) leads to non-termination.


but note that the paper says direct consequence, not 
necessary consequence, and whether or not my informal 
argument can be proven, if you just read it side by side with 
the non-terminating inference in question, you'll see 
immediately that the paper is jumping to conclusions here

(or at least leading the reader to such jumps..):

- Mul recurses down a type in its second parameter
- types in Haskell are finite
- there is a non-terminating Mul inference

the problem is that we have somehow conjured up an infinite
type for Mul to recurse on without end! Normally, such infinite
types are ruled out by occurs-checks (unless you are working
with Prolog III;-), so someone forgot to do that here. why?
where? how?

well, there is that functional dependency that says that parameters
a and b are inputs and parameter c is an output of Mul, and there 
is that initial constraint that says that b contains c! we have managed

to write a (non-productive) cyclic program at the type-level, and
while each recursive step strips one layer of its second input, it
also refines it to include an extra layer, via the output and cycle! 


imho, the instance is okay, but the constraint should be rejected
because if we write the FD as a function call with result 
(c=FD-Mul a b), then the constraint asks for:


   b=FD-Mul a (Vec b))

which should trigger a (generalised, conservative) occurs-check 
error (pending more refined tests).


for the purposes of termination in this kind of example, the 
non-recursive coverage condition appears to be an (overly 
conservative) approximation. in fact, even the generalised occurs-
check may be overly conservative (a functional dependency is 
not a type constructor, so the result of FD-C a b may not even

include both a and b).

the paper does discuss this as the (refined) weak coverage 
condition, with stronger constraints for confluence (fulfilled here), 
and under assumption of other termination proofs (theorem 2). 
unfortunately, it still assumes that example 6 is non-terminating, 
whereas I think that generalising the standard occurs-check to 
account for FDs gives a simple way to dispell that myth.


so, I'll stick to my suggestion, on the 

Re: relaxed instance rules spec (was: the MPTC Dilemma (please solve))

2006-03-01 Thread John Meacham
On Thu, Mar 02, 2006 at 03:53:45AM -, Claus Reinke wrote:
 - Mul recurses down a type in its second parameter
 - types in Haskell are finite
 - there is a non-terminating Mul inference
 
 the problem is that we have somehow conjured up an infinite
 type for Mul to recurse on without end! Normally, such infinite
 types are ruled out by occurs-checks (unless you are working
 with Prolog III;-), so someone forgot to do that here. why?
 where? how?

Polymorphic recursion allows the construction of infinite types if I
understand what you mean. if you are clever (or unlucky) you can get
jhcs middle end to go into an infinite loop by using them.

 -- an infinite binary tree
 data Bin a = Bin a (Bin (a,a))


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


Re: [Haskell-cafe] mediawiki syntax highlighting plugins

2006-03-01 Thread Jason Dagit
On 2/28/06, Johannes Ahlmann [EMAIL PROTECTED] wrote:
 hi,

 i've noted that the new haskellwiki has dropped syntax highlighting
 support for haskell code fragments. while i think that full highlighting
 might be overkill, at least different color markup of code and comments
 would certainly be nice.

 investigating the options for syntax highlighting in mediawiki i found
 the following two extensions using GNU enscript:

 http://www.wickle.com/wiki/index.php/Syntax_Highlight_extension

I'm no fan of enscript.  I tried it in the past and found it to be lacking.

 http://www.milab.is.tsukuba.ac.jp/~bushuhui/index.php?title=Enhanced_syntax_highlight_extension_for_MediaWiki

 where the second is an alteration of the first, with haskell support
 already added.

 an alternative would be geshi (http://qbnz.com/highlighter/) for which a
 mediawiki plugin also exists
 (http://meta.wikimedia.org/wiki/GeSHiHighlight), but it says on the
 geshi site GeSHi supports PHP5 and Windows. and i'm not clear whether
 they mean it _also_ supports those options or exclusively.

It works in linux with php4 I know this because my website uses it:
http://codersbase.com/index.php/Geshi_haskell

I haven't gotten around to sending a copy to the geshi devs.  Feel
free to hackup the version I have, replace my name in the comments,
send it in the geshi devs or whatever :)   I just hope someone finds
it useful.  It's probably a bit buggy.  For one thing, I have a bug
that prevents symbols from getting highlighted correctly.

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


Re: [Haskell-cafe] Layout rule (was Re: PrefixMap: code review request)

2006-03-01 Thread Benjamin Franksen
On Wednesday 01 March 2006 02:36, Brian Hulley wrote:
 Ben Rudiak-Gould wrote:
  Brian Hulley wrote:
  Here is my proposed layout rule:
 
  1) All layout keywords (where, of, let, do) must either be
  followed by a single element of the corresponding block type, and
  explicit block introduced by '{', or a layout block whose first
  line starts on the *next* line
 
  I wouldn't have much trouble adapting to that.
 
  and whose indentation is accomplished *only* by tabs
 
  You can't be serious. This would cause far more problems than the
  current rule.

 Why? Surely typing one tab is better than having to hit the spacebar
 4 (or 8) times?

What kind of editor are you using? Notepad?

I am used to hitting TAB key and get the correct number of spaces, 
according to how I configured my editor (NEdit) for the current 
language mode.

TAB characters in program text should be forbidden by law. As well as 
editors that by default insert a tab char instead of spaces.

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


Re: [Haskell-cafe] Help with Type Class

2006-03-01 Thread Bulat Ziganshin
Hello Alson,

Wednesday, March 1, 2006, 3:26:44 AM, you wrote:

AK   class CollectionClass c e where

this works with -fglasgow-exts :

class CollectionClass c e where
  toList :: c e - [e]

data Array i e = Array i i

instance CollectionClass (Array i) e where
  toList a = []


btw, see chapter 7.1.1 in the
http://cvs.haskell.org/Hugs/pages/hugsman/exts.html
  

-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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


[Haskell-cafe] Re: haskell programming guidelines

2006-03-01 Thread Christian Maeder

[EMAIL PROTECTED] wrote:

I suggested:

   f . g $ h x

or
   f $ g $ h x



[..]

The second is just plain wrong.  My reasoning is here for those who care:

http://permalink.gmane.org/gmane.comp.lang.haskell.cafe/11256


If you want a left-associative operator, you're free to define it 
(though single ascii symbols are rare).


In a more realistic example, the current dollars help to improve 
readability, I think, and that is my argument why $ should be right- 
associative:


map (+ 1) $ filter (/= 0) $ Set.toList l

An additional $ before the final argument ( $ l) looks stupid to me.
I also find additional parentheses instead of the dollars more 
confusing, because of the other parts in parentheses.


For a function definition, I recommend to simply change the dollars into 
dots and omit the last argument (if that is possible):


  myfun = map (+ 1) . filter (/= 0) . Set.toList

That should correspond to your taste as well, although someone (ie. 
S.M.) proposed to disallow the dot as operator in haskell'.


So, I don't know if either . or $ may be changed in the future and 
what other symbols may be used instead of these user-definable functions.


However, if the argument cannot be omitted, I suggest to only change the 
last dot back into a dollar:


myfun l = map (+ sum l) . filter (/= 0) $ Set.toList l

I've no solution (ie. operator) for omitting two elements in:

  f x y = g $ h $ i x y

apart from omitting only the first:

  f x = g . h . i x

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


Re: [Haskell-cafe] Layout rule (was Re: PrefixMap: code reviewrequest)

2006-03-01 Thread Brian Hulley

Benjamin Franksen wrote:

[snip]
I am used to hitting TAB key and get the correct number of spaces,
according to how I configured my editor (NEdit) for the current
language mode.


The only thing then is what happens when you type backspace or left arrow to 
get back out to a previous indentation? If the TAB character inserts spaces, 
there's no problem going from left to right but it would seem more 
complicated to go back out again ie without having to type backspace 4 times 
and try to hope when outdenting more that I haven't typed backspace 23 times 
instead of 24 times by mistake thus not getting to the column I expected.


This is my only reason for wanting to keep tab characters in the text, and 
certainly it does give some disadvantages when trying to line up '|' '=' etc 
vertically - at the moment I admit my layouts do end up a bit contrived as I 
have to use more newlines to ensure I can use tabs only to accomplish the 
line-up...


So any solutions welcome :-)

Regards, Brian.




... flee from the Hall of Learning. This Hall is dangerous in its
perfidious beauty, is needed but for thy probation. Beware, Lanoo, lest
dazzled by illusive radiance thy soul should linger and be caught in its
deceptive light.
  -- Voice of the Silence
stanza 33

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


Re: [Haskell-cafe] Re: haskell programming guidelines

2006-03-01 Thread Ketil Malde
Christian Maeder [EMAIL PROTECTED] writes:

 That should correspond to your taste as well, although someone
 (ie. S.M.) proposed to disallow the dot as operator in haskell'.

From http://hackage.haskell.org/trac/haskell-prime/wiki/CompositionAsDot:

| We lose . as composition. Mostly this doesn't matter as $ is
| probably more common in reality anyway.

While I don't agree, this has been left standing for a long time and
has survived several edits.

-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] Layout rule (was Re: PrefixMap: code reviewrequest)

2006-03-01 Thread Benjamin Franksen
On Wednesday 01 March 2006 13:35, Brian Hulley wrote:
 Benjamin Franksen wrote:
  [snip]
  I am used to hitting TAB key and get the correct number of spaces,
  according to how I configured my editor (NEdit) for the current
  language mode.

 The only thing then is what happens when you type backspace or left
 arrow to get back out to a previous indentation? If the TAB character
 inserts spaces, there's no problem going from left to right but it
 would seem more complicated to go back out again ie without having to
 type backspace 4 times and try to hope when outdenting more that I
 haven't typed backspace 23 times instead of 24 times by mistake thus
 not getting to the column I expected.

With NEdit, hitting backspace /right after/ hitting the tab key deletes 
all the whitespace that were inserted, be it a tab character or 
multiple spaces. (This works also if the line was auto-indented to the 
same indentation depth as the previous one. That is, hit enter and then 
backspace, and you are at previous indentation level minus one.) If, 
however, you press any other key (e.g. any arrow keys), subsequent 
backspace will only delete a single space. Other behaviors can be 
easily implemented by writing a macro and binding it to the backspace 
key. The same is most probably true for emacs.

The upshot is: Any decent modern text editor allows to map keys like tab 
and backspace to almost any action desired, depending on context, 
language mode, whatever.

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


Re: [Haskell-cafe] Help with Type Class

2006-03-01 Thread Daniel Fischer
Am Mittwoch, 1. März 2006 01:26 schrieb Alson Kemp:
   Although the discussion about Array refactoring died
 down quickly on the Haskell' mailing list, I've been
 noodling on refactoring the various Collections in
 Haskell.  In doing so, I've bumped into a problem with
 type classes that I can't resolve.  The issue is as
 follows:

   I'm designing a Collections class heirarchy that is
 a blend between that of Java and of Haskell. The
 problem is that, whereas in OOP it is easy to do so,
 Haskell class mechanism seems to make it difficult to
 add *new* member variable to subclasses.

   Simple goal: create a top-level Collection with an
 *indexed* Array subclass (and various other
 subclasses).  The problem I'm running into is
 Collection has no need of an index variable and I
 can't seem to figure out how to add an index to
 Array when subclassing from Collection  Mock up:

 --
   class CollectionClass c e where
 -- every Collection supports toList...
 toList :: c e - [e]

   class (CollectionClass a e)= ArrayClass a e where
 ...

   data Array i e = Array i i
   ^^
shouldn't the element type appear here? 

   instance CollectionClass Array e where
 -- Since Array is a Collection
 -- toList :: c e - [e]
 -- but with an Array the type would be
 -- toList :: a i e - [e]
 toList = ...

Well, the parameter c of CollectionClass has kind (* - *), Array has kind 
(* - * - *), so it must be

instance CollectionClass (Array i) e where ...

But the element type doesn't really belong in the class, wouldn't 

class Collection c where
toList :: c e - [e]

instance Collection [] where
toList = id

instance Collection (Array i) where
  -- or rather instance Ix i = Collection (Array i),
  -- if we use Data.Array
toList = elems -- or whatever we'd use for another implementation

class Collection (a i) = ArrayC a i where
 item :: i - a i e - Maybe e

-- or perhaps, better
class Collection c = ArrayLike c i | c - i where
look :: Monad m = i - c e - m e


be preferable? 
 -- 

  I think that the problem goes away if:
class CollectionClass c x e where ...
  with x used an index for Array or a key for Map or
 () for Set, but it doesn't seem clean to scatter
 member variables in the parent class in case the
 subclass requires them...

  Another possible solution that I couldn't get to
 work would be to use (Array i) as the type for c in

I can't imagine why that wouldn't work (apart from the typo above).
It compiles, and if we have a more appropriate Array type, we'd get a decent 
toList-function.

 Collection c:
  instance CollectionClass (Array i) e where
 toList = ... -- (Array i) e - [e] ?

   This seems clean because it says the Collection
 holds es and is organized by an (Array i). 
 Similarly, Set would be a Collection of es organized
 by Set and Map would be a Collection of es organized
 by (Map k).

  Undoubtedly, I've missspoken some crucial aspect of
 the type/kind/class/instance magical incantation. 
 Help!

  - Alson

HTH,
Daniel
-- 

In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt.
-- Blair P. Houghton

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


Re: [Haskell-cafe] Layout rule (was Re: PrefixMap: code review request)

2006-03-01 Thread Daniel Fischer
Am Mittwoch, 1. März 2006 11:57 schrieb Benjamin Franksen:
 TAB characters in program text should be forbidden by law. As well as
 editors that by default insert a tab char instead of spaces.

As founding member of the church of The only good Tabbing involves Michaela,
I wholeheartedly agree.

Cheers,
Daniel

-- 

In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt.
-- Blair P. Houghton

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


[Haskell-cafe] Hacking Hawk

2006-03-01 Thread [EMAIL PROTECTED]
Hawk didn't updated from GHC v4.04. It does contain dependencies on 
functions that are present in my current (6.04) GHC distribution, but 
they are not documented.


Those functions and constructors are (just a error log from ghc):
---
AQ.lhs:17:16: Not in scope: type constructor or class `STArray'

AQ.lhs:82:14: Not in scope: `newSTArray'

AQ.lhs:92:21: Not in scope: `writeSTArray'

AQ.lhs:258:27: Not in scope: `readSTArray'

AQ.lhs:262:27: Not in scope: `writeSTArray'
---

They are in GHC.Arr module now. I found that googling for their name.

They also changed their types so that they are not compatible with 
Control.Monad.ST (previous versions were compatible with LazyST).


What does they do?

Is it possible to rewrite them for current version of ghc?

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


Re: [Haskell-cafe] enforcing strictness on arbitrary subexpressions

2006-03-01 Thread Nils Anders Danielsson
On Thu, 16 Feb 2006, Udo Stenzel [EMAIL PROTECTED] wrote:

 hPutStr stdout $ foldr seq veryLongString veryLongString

 There is no primitive to do this for arbitrary data types, but the
 DeepSeq type class comes close.  You can find DeepSeq and some more
 hints on strict evaluation at
 http://users.aber.ac.uk/afc/stricthaskell.html.

You can also use Control.Parallel.Strategies:

Prelude Control.Parallel.Strategies take 2 (repeat 'x')
xx
Prelude Control.Parallel.Strategies take 2 (repeat 'x' `using` rnf)


(No more output.)

-- 
/NAD

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


Re: [Haskell-cafe] module for probability distributions

2006-03-01 Thread Nils Anders Danielsson
On Thu, 16 Feb 2006, Matthias Fischmann [EMAIL PROTECTED] wrote:

 I wrote a module for sampling arbitrary probability distribution, so
 far including normal (gaussian) and uniform.

   - There is probably a better implementation out there already.
 Please point me to it.

Martin Erwig and Steve Kollmansberger have written a library for
manipulating probability distributions, accompanied by a JFP article.
The code seems to have a BSD-style license, but isn't Cabalised.

  http://web.engr.oregonstate.edu/~erwig/pfp/

-- 
/NAD

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


Re: [Haskell-cafe] Help with Type Class

2006-03-01 Thread Alson Kemp
Bulat,

BZAK   class CollectionClass c e where
BZthis works with -fglasgow-exts :
Yup.  Figured that out shortly after I e-mailed... 
Thank you for providing the extra detail, though. 
-fglasgow-exts fixed the problem, but I didn't have a
good idea why the problem went away.


Daniel,

data Array i e = Array i i
 shouldn't the element type appear here? 
Typo: data Array i e = Array i i [e] --mockup with
list

 Well, the parameter c of CollectionClass has kind (*
 - *), Array has kind 
 (* - * - *), so it must be
 instance CollectionClass (Array i) e where ...
... which (I think) was breaking until -fglasgow-exts.
 Once that was fixed, this seems to be the preferred
way to implement this function.

 But the element type doesn't really belong in the
 class, wouldn't class Collection c where
 toList :: c e - [e]
Hmmm...  For example, implementing Array and UArray as
subclasses of Collection:
  class Collection c where
toList :: c e - [e]
  instance Collection (Array i) where
toList a = ...
  instance Collection (UArray i) where
toList a = ...

If Collection is not parameterized on e, then there
is no way to make sure that the e in Collection
(UArray i):toList is actually unboxable.  As with
the current IArray implementation, the following works
and isn't particularly limiting in flexibility:
  class Collection c e where
toList :: c e - [e]
  instance Collection (Array i) e where
toList a = ...
  instance Collection (UArray i) Int where --note the
Int
toList a = ...

I understand trying to make Collection as general as
possible by removing e, but it look as if doing so
makes useful subclasses difficult to implement?  

 -- or perhaps, better
 class Collection c = ArrayLike c i | c - i where
 look :: Monad m = i - c e - m e
 be preferable? 
ermm...  Need to read up on Functional Dependencies...
 brb...

Thanks for the help.

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


Re: [Haskell-cafe] Hacking Hawk

2006-03-01 Thread Iavor Diatchki
Hello,
I am not familiar with the details of Hawk, but you can find STArray
in Data.Array.ST,
and the functions to read, write, and create them are 'readArray',
'writeArray', and 'newArray' (see Data.Array.MArray).
-Iavor

On 3/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 Hawk didn't updated from GHC v4.04. It does contain dependencies on
 functions that are present in my current (6.04) GHC distribution, but
 they are not documented.

 Those functions and constructors are (just a error log from ghc):
 ---
 AQ.lhs:17:16: Not in scope: type constructor or class `STArray'

 AQ.lhs:82:14: Not in scope: `newSTArray'

 AQ.lhs:92:21: Not in scope: `writeSTArray'

 AQ.lhs:258:27: Not in scope: `readSTArray'

 AQ.lhs:262:27: Not in scope: `writeSTArray'
 ---

 They are in GHC.Arr module now. I found that googling for their name.

 They also changed their types so that they are not compatible with
 Control.Monad.ST (previous versions were compatible with LazyST).

 What does they do?

 Is it possible to rewrite them for current version of ghc?

 ___
 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: Layout rule (was Re: PrefixMap: code review request)

2006-03-01 Thread Ben Rudiak-Gould

Duncan Coutts wrote:

hIDE and Visual Haskell use the ghc lexer and get near-instantaneous
syntax highlighting.


Hmm... I just installed Visual Haskell 0.1, and when I type in the editor, 
CPU usage rises to about 70% and there's a noticeable delay before each 
character appears on the screen. This is a very short module (~100 lines) 
and a Pentium M 1600 CPU. Am I doing something wrong?


-- Ben

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


[Haskell-cafe] Re: Layout rule (was Re: PrefixMap: code review request)

2006-03-01 Thread Ben Rudiak-Gould

Benjamin Franksen wrote:

TAB characters in program text should be forbidden by law.


Well... they are quite useful for lining things up if you're using a 
proportional font, and I don't think proportionally-spaced code is a bad 
idea. I want them to be optional. But it would be nice if parsers would warn 
about (or even reject) programs whose meaning depends on tab width.


-- Ben

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


[Haskell-cafe] Re: Layout rule

2006-03-01 Thread Ben Rudiak-Gould

Ketil Malde wrote:

Multi line comments are nice for commenting out blocks of code.


They're also nice for comments within a line. E.g. haskell-src-exts contains 
the declaration


  data HsQualConDecl
  = HsQualConDecl SrcLoc
  {- forall -} [HsName] {- . -} HsContext {- = -} HsConDecl

Probably half of my uses of {- -} begin and end on the same line.

-- Ben

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


Re: [Haskell-cafe] Re: Layout rule (was Re: PrefixMap: code review request)

2006-03-01 Thread Duncan Coutts
On Wed, 2006-03-01 at 22:58 +, Ben Rudiak-Gould wrote:
 Duncan Coutts wrote:
  hIDE and Visual Haskell use the ghc lexer and get near-instantaneous
  syntax highlighting.
 
 Hmm... I just installed Visual Haskell 0.1, and when I type in the editor, 
 CPU usage rises to about 70% and there's a noticeable delay before each 
 character appears on the screen. This is a very short module (~100 lines) 
 and a Pentium M 1600 CPU. Am I doing something wrong?

I can't say too much about the internals of VH since I've not see the
code, only the description.

Perhaps that's because they're starting the parser immediately after
every keystroke and/or not killing the parser when the user types
another key. I've been using hIDE on a Pentium M 1600 laptop and on the
size of modules I've tried so far it's quick. The syntax highlighting
updates immediately and the type checker shows up errors a second or so
after I stop typing (which is because we wait about that long before
starting the parser).

Duncan

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


Re: [Haskell-cafe] Layout rule (was Re: PrefixMap: code reviewreque st)

2006-03-01 Thread Steve Schafer
On Wed, 1 Mar 2006 12:35:44 -, Brian Hulley [EMAIL PROTECTED]
wrote:

The only thing then is what happens when you type backspace or left
arrow to get back out to a previous indentation?

The Borland IDEs have long supported various smart indentation
features, which can each be individually turned on or off (see the third
one for the answer to your specific question):

* Auto indent mode - Positions the cursor under the first nonblank
  character of the preceding nonblank line when you press ENTER in
  the Code Editor.

* Smart tab - Tabs to the first non-whitespace character in the
  preceding line. If Use tab character is enabled, this option
  is off.

* Backspace unindents - Aligns the insertion point to the previous
  indentation level (outdents it) when you press BACKSPACE, if the
  cursor is on the first nonblank character of a line.

There are a number of other tab-related options as well.

Steve Schafer
Fenestra Technologies Corp.
http://www.fenestra.com/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Template haskell instance checking

2006-03-01 Thread heatsink
Is there a way, in template haskell, to find out what instance declarations 
exist?  I'm not trying to accomplish anything specific right now, but I can 
see two potential uses for this.  One is to emit compile-time error messages 
from TH code which would be more informative than the typechecker's output.  
The other is to produce TH functions that conditionally generate code 
depending on the instances satisfied by their arguments.


I offer the following as a motivational example.  Suppose you want to write 
an extensible library to handle files for, e.g., image data:


class FileFormat a where
formatName :: a - String
read :: Handle - IO a
write :: Handle - a - IO ()

instance FileFormat TheStandardFormat where 

class (FileFormat a, FileFormat b) = Convert a b where
convert :: a - b

Now it would be nice to generate instances of (Convert a TheStandardFormat, 
Convert TheStandardFormat b) = Convert a b _except_ where there is an 
explicit definition for (Convert a b).  AFAIK, there's no way to do this at 
present, but it seems like something that could be computed in TH.


--heatsink


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