External Core front-end in GHC 5.03

2002-05-03 Thread Kirsten Chevalier

Hi,
I just downloaded and built the latest version of GHC from the CVS repository
yesterday and tried to use it to compile an external Core file, which caused
the compiler to crash:

$ ghc -fext-core -fno-code hello.hs
$ ghc hello.hcr
Segmentation fault

I know that the external Core feature is still a work in progress, but is
there something I should be doing differently or is it totally broken? Here
are the relevant details:

$ uname -a
Linux puma 2.4.7-10smp #1 SMP Thu Sep 6 17:09:31 EDT 2001 i686 unknown

$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-98)

and the results of compiling with -v:
$ ghc -v hello.hcr
Glasgow Haskell Compiler, Version 5.03, for Haskell 98, compiled by GHC version 5.02.1
Using package config file: 
/home/crete/lumberjacks3/krc/ghc/fptools-build/ghc/driver/package.conf.inplace

 Packages 
package stuff snipped

Hsc static flags: -static -fignore-interface-pragmas -fomit-interface-pragmas 
-fdo-lambda-eta-expansion -flet-no-escape
*** Checking old interface for hs = Just hello.hcr, hspp = Just hello.hcr:
*** Renamer:
Segmentation fault

The program I'm trying to compile is just:

main = putStr Hello world!

Thanks,
Kirsten

-- 
Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs



infix type constructors

2002-05-03 Thread Okasaki, C. DR EECS

I'm not sure how long this has been implemented in GHC,
but I just noticed that infix type constructors are allowed,
as in

  data a :- b = ...

The syntactic asymmetry between type constructors and
data contructors has bothered me for a while, so this
is a welcome change!  However, this syntax seems to
be supported for data and newtype declarations,
but not for type declarations.  For example,

  type a :- b = ...

does not seem to be allowed.  Is there a reason for this?
Or was it just an oversight?

-- Chris
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



What's the '0' for in the version number?

2002-05-03 Thread Ashley Yakeley

Why is it GHC 5.02.2, 5.03 etc.? Wouldn't it be easier with 5.2.2, 
5.3?

-- 
Ashley Yakeley, Seattle WA

___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



SAS'02 -- DEADLINE EXTENSION -- MAY 10

2002-05-03 Thread SAS2002


  (Apologies for multiple postings)

Due to numerous requests, the submission deadline for SAS'02 has been
extended to:**Friday MAY 10** 
--
   CALL FOR PAPERS (SAS'02)

The 9th International Static Analysis Symposium 
 September 17 - 20 2002, Madrid, Spain
http://clip.dia.fi.upm.es/SAS02

  New submission deadline: May 10, 2002
--

   Static Analysis  is increasingly  recognized as a  fundamental tool
for  high  performance  implementations  and verification  systems  of
high-level  programming  languages.  The  series  of  Static  Analysis
Symposia  has  served  as   the  primary  venue  for  presentation  of
theoretical, practical, and application advances in the area.

   The Ninth International Static  Analysis Symposium (SAS'02) will be
held  at   the  Technical   University  of  Madrid,   co-located  with
Logic-based Program Development and Transformation (LOPSTR'02) and the
APPIA-GULP-PRODE   Joint   Conference   on   Declarative   Programming
(AGP'02). Previous symposia were held in Paris, Santa Barbara, Venice,
Pisa, Paris, Aachen, Glasgow and Namur.

   The technical program for  SAS'02 will consist of invited lectures,
tutorials,  panels,  presentations of  refereed  papers, and  software
demonstrations.  Contributions are  welcome on  all aspects  of Static
Analysis, including, but not limited to:

 * abstract interpretation,   * data flow analysis,
 * verification systems,  * program specialization,
 * abstract domains,  * optimizing compilers,
 * theoretical frameworks,* type inference,
 * abstract model checking,   * complexity analysis,
 * abstract testing,  * security analysis.

   Submissions  can   address  any  programming   paradigm,  including
concurrent,constraint,   functional,imperative,logic   and
object-oriented programming.   Survey papers that  present some aspect
of the above topics with a new coherence are also welcome.

Papers must  describe original work,  be written and  presented in
English, and must not substantially overlap with papers that have been
published  or that  are simultaneously  submitted  to a  journal or  a
conference with refereed proceedings.

Submission Instructions
---

Allsubmissions   mustbe   performedelectronically   at
http://clip.dia.fi.upm.es/SAS02/submission.html.Submitted   papers
should  be at  most 15  pages excluding  bibliography  and well-marked
appendices.  Program  committee members are  not required to  read the
appendices, and thus papers  should be intelligible without them.  The
proceedings will be published  by Springer-Verlag in the Lecture Notes
in   Computer   Science  series   (see
http://www.springer.de/comp/lncs/authors.html  for   the  LNCS  author
instructions). Thus, adhering to  that style already in the submission
is  strongly  encouraged.   Papers   should  be  submitted  either  in
PostScript  or  PDF  format   and  they  should  be  interpretable  by
Ghostscript or Acrobat  Reader. Papers must be printable  on either A4
paper or US letter, and preferably on both.

Important Dates
---
May 10, 2002  Extended submission deadline (hard)
June10, 2002  Notification 
June30, 2002  Final version
Sept 17-20, 2002  SAS'02

Program Committee 
-
Manuel Hermenegildo (Chair) Technical University of Madrid, Spain
German Puebla(Co-chair) Technical University of Madrid, Spain
Radhia Cousot   Ecole Polytechnique, France
Saumya Debray   The University of Arizona, USA
Manuel FahndrichMicrosoft Research, USA
Roberto Giacobazzi  Univerity of Verona, Italy
Chris HankinImperial College, UK
Giorgio LeviUniverity of Pisa, Italy
Kim MarriottMonash University, Australia
Alan MycroftCambridge University, United Kingdom
Ganesan Ramalingam  IBM T.J. Watson Research Center, USA
Martin Rinard   Massachusetts Institute of Technology, USA
Shmuel SagivTel-Aviv Univerisity, Israel
Reinhard WilhelmUniversitat des Saarlandes, Germany

Contact Info

Email: [EMAIL PROTECTED]
Fax:   + 34 91 352 4819 
Phone: + 34 91 336 7448
Post:  
   Manuel Hermenegildo (Ref.: SAS'02)
   Facultad de Informatica
   Universidad Politecnica de Madrid
   28660 Boadilla del Monte
   Madrid, Spain

--
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell



tricky instance declarations

2002-05-03 Thread Warrick Gray

Hi all,

I'm not very current on the latest wonders of haskell typing, but I feel 
that something like the following should be possible:

data ConnError = ...

-- error propagating monad:
instance Monad (Either ConnError) where
(Left e) = _ = Left e
(Right v) = f = f v
return = Right

-- combined IO  error propagating monads
instance Monad (IO (Either ConnError a)) where
-- (=) :: IO (Either ConnError a)
--   - (a - IO (Either ConnError b))
--   - IO (Either ConnError b)
m = f =  m = \e - e = f
return  =  return . return

I know the first declaration works with GHC compiler flag -fglasgow-exts, 
but something about the line Monad (IO (Either ConnError a)) makes me (and 
the compiler) very nervous.  How should I be expressing this?

Yours expectantly, Warrick.





_
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell



Re: tricky instance declarations

2002-05-03 Thread Alastair Reid


Warrick Gray [EMAIL PROTECTED] writes:
 data ConnError = ...
 
 -- error propagating monad:
 instance Monad (Either ConnError) where

 -- combined IO  error propagating monads
 instance Monad (IO (Either ConnError a)) where

 I know the first declaration works with GHC compiler flag
 -fglasgow-exts, but something about the line Monad (IO (Either
 ConnError a)) makes me (and the compiler) very nervous.  How should I
 be expressing this?

You're probably seeing problems because Monad is a constructor class
(i.e., expects an argument of kind * - *) not a type class (which
would expect an argument of kind *).  You used Monad correctly in the
first instance declaration (i.e., there's no mention of 'a') but not
in the second (you did mention the 'a').

Unfortunately, the fix is slightly awkward.  What you want to write is
something like:

 instance Monad (IO . Either ConnError) where

but you can't use . to compose type constructors the way you can
compose functions so that doesn't work.  What you have to do is:

 newtype IOE a = MkIOE (IO (Either ConnError a))
 unIOE (MkIOE x) = x
 instance Monad IOE where ...

or, generalizing slightly so that you only have to go through the pain
of this once:

 newtype IOF m a = MkIOF (IO (m a))
 unIOF (MkIOF x) = x
 instance Monad (IOF (Either ConnError)) where ...


Of course, the easiest fix is to use the fact that the IO monad has
error propagation built into it.  If you can encode your errors as
strings, you're all set (or you could use the GHC Dynamic extensions
if non-portability doesn't disturb).


Hope this helps,

Alastair Reid
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell



CFP: JFP Special Issue on Functional Pearls

2002-05-03 Thread Ralf Hinze

Apologies if you receive multiple copies...



   CALL FOR PAPERS

  Special Issue on Functional Pearls

http://www.informatik.uni-bonn.de/~ralf/necklace.html

  [Deadline: 31 August 2002]



   Wer die Perle in Händen hält,
   fragt nicht nach der Muschel.
  - Peter Benary


A special issue of the Journal of Functional Programming will be
devoted to Functional Pearls. The submission deadline is 31 August
2002.

Scope
-

Do you have a paper that is small, rounded and enjoyable to read?
Please consider submitting it to the Special Issue on Functional
Pearls, as we intend to string a shiny necklace. If you don't have a
pearl, write one today! Papers can be on any subject connected to
functional programming. A pearl is typically around 8 pages, though
there is no strict page limit. The special issue also welcomes
tutorial or educational papers in a broad sense.

Submission details
--

Manuscripts should be unpublished works and not submitted elsewhere.
Revised and polished versions of papers published in conference
proceedings that have not appeared in archival journals are eligible
for submission. All submissions will be reviewed according to the
usual standards of scholarship and judged by elegance of development
and clarity of expression. One of the main reviewers will be Richard
Bird, the editor of JFP's regular Functional Pearls column.

Deadline for submission:   31 August 2002
Notification of acceptance or rejection:   30 November 2002
Revised version due:   31 January 2003

Submissions should be sent to the Guest Editor (see address below),
with a copy to Nasreen Ahmad ([EMAIL PROTECTED]). Submitted
articles should be sent in PDF or Postscript format, preferably
gzipped and uuencoded. The use of the JFP style files is strongly
recommended. In addition, please send, as plain text, title, abstract
(if any), and contact information. The submission deadline is 31
August 2002.  Authors will be notified of acceptance or rejection by
30 November 2002. Revised versions are due on 31 January 2003. For
other submission details, please consult an issue of the Journal of
Functional Programming or see the Journal's web page at
http://www.dcs.gla.ac.uk/jfp/.

Guest Editor


Ralf Hinze
Institut für Informatik III
Universität Bonn
Römerstraße 164
53117 Bonn, Germany
Telephone: +49 (2 28) 73 - 45 35
Fax: +49 (2 28) 73 - 43 82
Email: [EMAIL PROTECTED]
WWW: http://www.informatik.uni-bonn.de/~ralf/




___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell



Syntax highlighting for KDE's Kate

2002-05-03 Thread Ralf Hinze

Dear KDE users,

I've hacked syntax highlighting files for Kate, KDE's editor.
Feel free to use or to modify them.

http://www.informatik.uni-bonn.de/~ralf/software.html#syntax

Cheers, Ralf
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell



duplicate instance declarations

2002-05-03 Thread Hal Daume III

Why is this a duplicate instance declaration:

 class C a
 class D b
 data T a b
 instance (C (T a b), C a) = D b
 instance (C (T a b), C b) = D a

These are symmetric, but not duplicate, as I see it.

--
Hal Daume III

 Computer science is no more about computers| [EMAIL PROTECTED]
  than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell



Re: duplicate instance declarations

2002-05-03 Thread C T McBride

Hi

 Why is this a duplicate instance declaration:
 
  class C a
  class D b
  data T a b
  instance (C (T a b), C a) = D b
  instance (C (T a b), C b) = D a
 
 These are symmetric, but not duplicate, as I see it.

Suppose we add

  instance C ()
  instance C (T () ())

Now there are two ways to build an instance of D (). The class mechanism
is based on an open world assumption, hence declarations must be rejected
if they can subsequently be made to overlap. If two instance `conclusions'
unify, as (D a) and (D b) do, we can make them overlap by ensuring that
both sets of `premises' hold.

In general, instance inference amounts to proof search, or the execution
of a logic program. It requires quite serious restrictions to ensure that
a given set of instance declarations will always result in terminating and
deterministic search. Relaxing those restrictions, as in ghc
-fdont-tell-my-mum, leaves us able to write nonterminating compile-time
programs. Indeed, we even find the compiler `deriving' them for us. By the
way, critics of Cayenne should note that the only reason its typechecking
is undecidable is that you can execute non-terminating programs at
compile-time.  Funny-type-class Haskell is just as bad. 

Just as I argue with respect to the type system (type-lambda etc), I'd
suggest that extending the expressivity of the class system does no harm,
provided we cease to presume that instance inference must always be fully
automatic. If there is a way to give the construction of an instance
explicitly, then we can always make clear those things the machine can't
figure out for itself. Just like typechecking, instance-finding is a
partnership between people and machines: the machines should figure out as
much as possible, but the people should always be able to help.

Cheers

Conor


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell



Re: Syntax highlighting for KDE's Kate

2002-05-03 Thread Brian Huffman

On Friday 03 May 2002 06:29 am, Ralf Hinze wrote:
 Dear KDE users,

 I've hacked syntax highlighting files for Kate, KDE's editor.
 Feel free to use or to modify them.

   http://www.informatik.uni-bonn.de/~ralf/software.html#syntax

 Cheers, Ralf

Attached here is another syntax highlighting file for Kate that I wrote; it 
closely follows the haskell report for things like character literals and the 
maximal-munch rule for comments. I haven't gotten around to writing a version 
for literate haskell files, but maybe someone else could try to adapt it. 

Feel free to try it out. Even if you don't use Kate for editing, you can still 
use the highlighting file with the embedded text viewer in Konqueror.

- Brian Huffman

?xml version=1.0 encoding=UTF-8?
!DOCTYPE language SYSTEM language.dtd
language name=Haskell version=1.00 kateversion=2.0 section=Sources extensions=*.hs mimetype=text/x-haskell
  highlighting
list name=reservedid
  item case /item
  item class /item
  item data /item
  item default /item
  item deriving /item
  item do /item
  item else /item
  item if /item
  item import /item
  item in /item
  item infix /item
  item infixl /item
  item infixr /item
  item instance /item
  item let /item
  item module /item
  item newtype /item
  item of /item
  item primitive /item
  item then /item
  item type /item
  item where /item
/list
contexts
  context attribute=0 lineEndContext=#stay name=Normal
keyword attribute=1 context=#stay String=reservedid/
RegExpr attribute=2 context=#stay String=[A-Z][a-zA-Z0-9_']*/
RegExpr attribute=3 context=#stay String=[a-z_][a-zA-Z0-9_']*/
RegExpr attribute=3 context=#stay String=-*[!#$%amp;*+./:lt;=gt;?@\\^|~]-*/
Detect2Chars attribute=4 context=1 char=- char1=-/
Detect2Chars attribute=4 context=2 char={ char1=-/
DetectChar attribute=5 context=3 char=quot;/
RegExpr attribute=6 context=#stay String='[^'\\]'/
RegExpr attribute=6 context=#stay String='\\[abfnrtv\quot;\'\\]'/
RegExpr attribute=6 context=#stay String='\\\^[A-Z@\[\]\\^_]'/
RegExpr attribute=6 context=#stay String='\\([0-9]+|o[0-7]+|x[0-9a-fA-F]+)'/
RegExpr attribute=6 context=#stay String='\\(S(OH?|UB|YN|TX|I|P)|E(NQ|OT|SC|TB|TX|M)|DC[1234]|[BFGRU]S|[BD]EL|ACK|CAN|CR|DLE|FF|FL|HT|NAK|NUL|VT)'/
RegExpr attribute=7 context=#stay String=[0-9]+\.[0-9]+([eE][-+]?[0-9]+)?/
RegExpr attribute=8 context=#stay String=0([oO][0-7]+|[xX][0-9a-fA-F]+)/
RegExpr attribute=9 context=#stay String=[0-9]+/
  /context
  context attribute=4 lineEndContext=#pop name=Comment 1/
  context attribute=4 lineEndContext=#stay name=Comment 2
Detect2Chars attribute=4 context=2 char={ char1=-/
Detect2Chars attribute=4 context=#pop char=- char1=}/
  /context
  context attribute=5 lineEndContext=#pop name=String
LineContinue attribute=6 context=#stay/
RegExpr attribute=6 context=#stay String=\\[abfnrtv\quot;\'\\amp;]/
RegExpr attribute=6 context=#stay String=\\\^[A-Z@\[\]\\^_]/
RegExpr attribute=6 context=#stay String=\\([0-9]+|o[0-7]+|x[0-9a-fA-F]+)/
RegExpr attribute=6 context=#stay String=\\(S(OH?|UB|YN|TX|I|P)|E(NQ|OT|SC|TB|TX|M)|DC[1234]|[BFGRU]S|[BD]EL|ACK|CAN|CR|DLE|FF|FL|HT|NAK|NUL|VT)/
DetectChar attribute=5 context=#pop char=quot;/
  /context
/contexts
itemDatas
  itemData name=Normal Text defStyleNum=dsNormal/
  itemData name=Keyword defStyleNum=dsKeyword/
  itemData name=TyCon   defStyleNum=dsDataType/
  itemData name=Identifier  defStyleNum=dsNormal/
  itemData name=Comment defStyleNum=dsComment/
  itemData name=String  defStyleNum=dsString/
  itemData name=ChardefStyleNum=dsChar/
  itemData name=Float   defStyleNum=dsFloat/
  itemData name=HexOctaldefStyleNum=dsBaseN/
  itemData name=Integer defStyleNum=dsDecVal/
/itemDatas
  /highlighting
  general
comments
  comment name=singleLine start=--/
  comment name=multiLine start={- end=-}/
/comments
keywords casesensitive=1/
  /general
/language



Deforestration harmful?

2002-05-03 Thread Shin-Cheng Mu

Hi all,

We encountered a case where elimination of intermediate data
structure seeems to have a bad impact on the overall performance
and we were wondering why.

Relationally, our program would be as simple as:

 f . g

where g :: Seed - Tree1 and f :: Tree1 - Tree2. Basically g
generate some kind of tree via an unfold and f map a Tree1 to
some (usually 3 or 4) Tree2. In reality we have to implement
relations as set (or list) valued functions, so it becomes

concat . map f. g

where g looks like

g seed = [ z | (s1, s2) - split seed,
x - g s1, y - g s2, z - join x y ]

The relation f was almost as simple as a replacing each
constructor in Tree1 with one or more coresponding constructors in
Tree2. They two can be fused together and becomes

   fg seed = [ z | (s1, s2) - split seed,
x - fg s1, y - fg s2, z - join' x y ]

The intermediate datatype Tree1 was thus eliminated.

The problem was: the fused program ran slower than the
original one! At least if you measure the total running
time (either via the UNIX time command or use the CPUTime
module). The time reported in the GHC time profile indeed
showed that the fused program is faster, though, if GC time
is excluded.

We were quite curious why and my guess was: since f maps a
Tree1 to more than one Tree2, in the two list comprehensions,
the list produced by (fg s2) is much longer than (g s2).
The fused program thus has to keep a longer list in memory.
Worse heap residency results in more GCs. (Luckily GHC did not
attempt to automatically perform the fusion for us! :) )

An obvious thing to try was to increase the heap size.
Again we were surprised. Indeed the GC time decreased
but the running time in the profile (excluding the GC time)
increased a bit. Our guess was that it might have something
to do with the way GHC allocates new memory cells such that
larger heap results in longer allocation time. It was quite
tricky to find the best heap size at which the program
runs at maximal speed.

Are the above guesses are plausible? Is it a known phenomena?

Thank you very much.

sincerely,
Shin-Cheng Mu

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell



Re: ANNOUNCE: Haddock version 0.1, a Haskell documentation tool

2002-05-03 Thread Ashley Yakeley

At 2002-05-01 04:48, Simon Marlow wrote:

I'm pleased to announce version 0.1 of Haddock, a documentation
generation tool for Haskell source code.

I take it this is the standard Haskell documentation tool now, that 
implementations of the standard libraries will use? I've been waiting for 
something like this.

-- 
Ashley Yakeley, Seattle WA

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell