Re: [GHC] #2085: cabal uses haddock from hard-coded location

2008-02-10 Thread GHC
#2085: cabal uses haddock from hard-coded location
-+--
Reporter:  Frederik  |Owner: 
Type:  bug   |   Status:  closed 
Priority:  normal|Milestone: 
   Component:  Build System  |  Version:  6.8.2  
Severity:  normal|   Resolution:  wontfix
Keywords:| Testcase: 
Architecture:  Unknown   |   Os:  Unknown
-+--
Changes (by duncan):

  * status:  new = closed
  * resolution:  = wontfix

Comment:

 If someone specifies a non-standard location using --happy-prog= then we
 have to remember that in the configuration somewhere. Even if the program
 is on the path we have to check that it does indeed exist, so that
 involves finding it and often running it to check its version. Then the
 choice is between remembering the unqualified or fully qualified path.
 There does not seem to be much to choose between the two, we somewhat
 arbitrarily pick the qualified path.

 I think other systems do this too, eg you'll see many build systems
 running /usr/bin/gcc even though they were only looking for gcc on the
 path at configure time. For example autoconf saves the path info in the
 Makefile, generated by ./configure.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2085#comment:3
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] #2081: On a strained PPC Mac OS X 10.4, GHC reports internal error: stg_ap_v_ret

2008-02-10 Thread GHC
#2081: On a strained PPC Mac OS X 10.4, GHC reports internal error: stg_ap_v_ret
-+--
 Reporter:  thorkilnaur  |  Owner: 
 Type:  bug  | Status:  new
 Priority:  normal   |  Milestone:  6.10 branch
Component:  Compiler |Version:  6.9
 Severity:  normal   | Resolution: 
 Keywords:   | Difficulty:  Unknown
 Testcase:   |   Architecture:  powerpc
   Os:  MacOS X  |  
-+--
Changes (by igloo):

  * difficulty:  = Unknown
  * milestone:  = 6.10 branch

Comment:

 May not be OS X specific: I just got this on amd64/Linux while validating
 the HEAD:
 {{{
  Running ./boxy/all.T
 = Base1(normal)
 cd ./boxy  '/home/ian/ghc/darcs/val/compiler/stage2/ghc-inplace' -no-
 recomp -dcore-lint -dcmm-lint -Dx86_64_unknown_linux  -c Base1.hs
 Base1.comp.stderr 21
 /bin/sh: line 1: 19152 Aborted
 '/home/ian/ghc/darcs/val/compiler/stage2/ghc-inplace' -no-recomp -dcore-
 lint -dcmm-lint -Dx86_64_unknown_linux -c Base1.hs Base1.comp.stderr 21
 Compile failed (status 34304) errors were:
 ghc-6.9.20080210: internal error: stg_ap_v_ret
 (GHC version 6.9.20080210 for x86_64_unknown_linux)
 Please report this as a GHC bug:
 http://www.haskell.org/ghc/reportabug

 *** unexpected failure for Base1(normal)
 }}}
 Running the test again a couple of times didn't reproduce the error.

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


[GHC] #2087: On a PPC Mac OS X 10.4, the RTS reports Memory leak detected running a program compiled with -debug -threaded -fhpc

2008-02-10 Thread GHC
#2087: On a PPC Mac OS X 10.4, the RTS reports Memory leak detected running a
program compiled with -debug -threaded -fhpc
+---
Reporter:  thorkilnaur  |   Owner:
Type:  bug  |  Status:  new   
Priority:  normal   |   Component:  Runtime System
 Version:  6.9  |Severity:  normal
Keywords:   |Testcase:
Architecture:  powerpc  |  Os:  MacOS X   
+---
 On a PPC Mac OS X 10.4, the RTS reports Memory leak detected running a
 program compiled with -debug, -threaded, and -fhpc. Here is a sample
 session:
 {{{
 $ cat T1.hs
 main = putStrLn Memory leak?
 $ rm T1.o
 $ /Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-complete-for-pulling-
 and-copying-20070713_1212/ghc/compiler/stage2/ghc-inplace T1.hs -o T1
 -debug -threaded -fhpc
 $ ./T1
 Memory leak detected
   gen 0 blocks :2
   gen 1 blocks :1
   nursery  :  128
   retainer :0
   arena blocks :0
   exec :0
   free :  119
   total:  250

   in system:  254
 T1: internal error: ASSERTION FAILED: file sm/Storage.c, line 1179

 (GHC version 6.9.20080203 for powerpc_apple_darwin)
 Please report this as a GHC bug:
 http://www.haskell.org/ghc/reportabug
 $ ./T1
 Memory leak?
 $
 }}}
 Running the program usually fails the first time and succeeds on the
 second and subsequent attempts. The GHC version used is the HEAD from
 around 2008-Feb-03.

 Similar behaviour has been observed for the test cases
 {{{
 ffi002(threaded1)
 hpc001(threaded1)
 hpc_fork(threaded1)
 tough(threaded1)
 }}}
 for both the stable and head tnaur PPC OSX builders. The last three are
 all hpc test cases that use the same set of flags (-debug -threaded -fhpc)
 used in the above sample. ffi002 is different, it is an example of a C
 program that sets up the GHC runtime environment and calls some Haskell
 code. The ffi002 test case has been failing for a while
 (c.f. http://haskell.org/pipermail/cvs-ghc/2007-June/036013.html).

 The memory leak is detected by this code in {{{rts/sm/Storage.c}}}:
 {{{
   if (live_blocks + free_blocks != mblocks_allocated * BLOCKS_PER_MBLOCK)
   {
   debugBelch(Memory leak detected\n);
   for (g = 0; g  RtsFlags.GcFlags.generations; g++) {
   debugBelch(  gen %d blocks : %4lu\n, g, gen_blocks[g]);
   }
   debugBelch(  nursery  : %4lu\n, nursery_blocks);
   debugBelch(  retainer : %4lu\n, retainer_blocks);
   debugBelch(  arena blocks : %4lu\n, arena_blocks);
   debugBelch(  exec : %4lu\n, exec_blocks);
   debugBelch(  free : %4lu\n, free_blocks);
   debugBelch(  total: %4lu\n\n, live_blocks + free_blocks);
   debugBelch(  in system: %4lu\n, mblocks_allocated *
 BLOCKS_PER_MBLOCK);
   ASSERT(0);
   }
 }}}
 I have tried to move the printing of counters outside the condition and
 got the following result:
 {{{
 $ rm T1.o
 $ /Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-complete-for-pulling-
 and-copying-20070713_1212/ghc/compiler/stage2/ghc-inplace T1.hs -o T1
 -debug -threaded -fhpc
 $ ./T1
 memInventory:
   gen 0 blocks :2
   gen 1 blocks :1
   nursery  :  128
   retainer :0
   arena blocks :0
   exec :0
   free :  119
   total:  250

   in system:  254
 Memory leak detected
 T1: internal error: ASSERTION FAILED: file sm/Storage.c, line 1181

 (GHC version 6.9.20080203 for powerpc_apple_darwin)
 Please report this as a GHC bug:
 http://www.haskell.org/ghc/reportabug
 $ ./T1
 Memory leak?
 memInventory:
   gen 0 blocks :2
   gen 1 blocks :1
   nursery  :  128
   retainer :0
   arena blocks :0
   exec :0
   free :  123
   total:  254

   in system:  254
 memInventory:
   gen 0 blocks :4
   gen 1 blocks :4
   nursery  :  128
   retainer :0
   arena blocks :0
   exec :0
   free :  118
   total:  254

   in system:  254
 $
 }}}
 Suggestions for further lines of investigation are most welcome.

 Best regards
 Thorkil

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2087
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] #1767: :show setting does not conform to documented specification

2008-02-10 Thread GHC
#1767: :show setting does not conform to documented specification
-+--
 Reporter:  guest|  Owner:  igloo  
 Type:  merge| Status:  closed 
 Priority:  normal   |  Milestone:  6.8.3  
Component:  GHCi |Version:  6.9
 Severity:  normal   | Resolution:  fixed  
 Keywords:   | Difficulty:  Unknown
 Testcase:   |   Architecture:  Unknown
   Os:  Unknown  |  
-+--
Changes (by igloo):

  * status:  new = closed
  * resolution:  = fixed

Comment:

 Merged

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1767#comment:6
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] #1771: hFileSize gives negative values

2008-02-10 Thread GHC
#1771: hFileSize gives negative values
+---
 Reporter:  guest   |  Owner:  igloo  
 Type:  merge   | Status:  closed 
 Priority:  normal  |  Milestone:  6.8.3  
Component:  libraries/base  |Version:  6.6.1  
 Severity:  normal  | Resolution:  fixed  
 Keywords:  hFileSize 2gb  | Difficulty:  Unknown
 Testcase:  |   Architecture:  x86
   Os:  Windows |  
+---
Changes (by igloo):

  * status:  new = closed
  * resolution:  = fixed

Comment:

 Merged

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1771#comment:6
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] #1750: ghc-pkg stack overflow when mutually dependent packages installed

2008-02-10 Thread GHC
#1750: ghc-pkg stack overflow when mutually dependent packages installed
--+-
 Reporter:  greenrd   |  Owner:  igloo  
 Type:  merge | Status:  closed 
 Priority:  normal|  Milestone:  6.8.3  
Component:  Compiler  |Version:  6.7
 Severity:  normal| Resolution:  fixed  
 Keywords:| Difficulty:  Easy (1 hr)
 Testcase:|   Architecture:  Multiple   
   Os:  Multiple  |  
--+-
Changes (by igloo):

  * status:  new = closed
  * resolution:  = fixed

Comment:

 All 3 merged.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1750#comment:5
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: Some problems writing a threaded program

2008-02-10 Thread Don Stewart
jpvogel1:
I am running my program in WinXP with ghc 2.6.8
 
If you install netstat and change the parameters it should still work in
linux.
 
Why does thread # 3 dominate over the over threads int the output?
Why does thread # 4 never seem to run?
 
I can't use the sleep function in System.Process.Win32 since it puts all
the
threads asleep at the same time.  Is there a way to put only one thread
asleep?
 
That would allow more of a chance for thread #4 to run.

There is 'threadDelay' and 'yield' if you need to either sleep a thread,
or explicitly trigger a scheduler event.

http://haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html#4
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Some problems writing a threaded program

2008-02-10 Thread John Vogel
I am running my program in WinXP with ghc 2.6.8

If you install netstat and change the parameters it should still work in
linux.


Why does thread # 3 dominate over the over threads int the output?
Why does thread # 4 never seem to run?

I can't use the sleep function in System.Process.Win32 since it puts all the

threads asleep at the same time.  Is there a way to put only one thread
asleep?

That would allow more of a chance for thread #4 to run.



The simplified program:
---


module Main where

import Data.IORef
import Data.List
import System.IO
import System.Process

import Control.Concurrent
import Control.Concurrent.Chan


data Connection = Null | Last | Active deriving (Eq)

instance Show Connection where
show Null = Null
show Last = Last
show Active = Active

instance Read Connection where
readsPrec _ s = case take 5 s of
 UDP - [(Active, )]
 TCP - [(Active, )]
Last - [(Last,)]
_ - [(Null,)]


-- ptrints one 0 and 1
main = do
stop - newIORef False
cbuffer - newChan :: IO (Chan Connection)
putStr 0
(_,output,_,ph) - runInteractiveCommand netstat -noa 5
sequence $ map forkIO $ [(processConnections ph output cbuffer),
(stopNetstat ph stop False), (printChan cbuffer),(checkStop stop )]
putStr 1
_ - waitForProcess ph
--mapM killThread ts
putStrLn \nDone

-- thread # 2
processConnections :: ProcessHandle - Handle - (Chan Connection) - IO ()
processConnections ph hout chan = do
h - hReady hout
e - getProcessExitCode ph
putStr 2
if (not h  e /= Nothing) then do writeChan chan Last  return () else do
if h then do readConnection hout = writeChan chan else do
processConnections ph hout chan


readConnection :: Handle - IO Connection
readConnection hout = do
l - hGetLine hout
let c = (read l :: Connection)
if (c == Null)
then do (readConnection hout)
else do (return c)

-- thread number 3
stopNetstat :: ProcessHandle - (IORef Bool) - Bool - IO ()
stopNetstat netstat _ True = terminateProcess netstat
stopNetstat netstat gref False = putStr 3  yield  readIORef gref =
stopNetstat netstat gref


--thread 4
printChan :: (Chan Connection) - IO ()
printChan chan = do
putStr 4
c - readChan chan
printConnection c
printChan chan


checkStop :: (IORef Bool) - String - IO ()
checkStop ref s = do
if (take 4 s == stop)
then do (writeIORef ref True)
else do (getChar = (\x - checkStop ref ((tail s) ++ [x])))

printConnection :: Connection - IO ()
printConnection c = case c of
Null - putStr N
Last - putStr L
_ - putStr A
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: [Haskell] RE: Extensible records: Static duck typing

2008-02-10 Thread Barney Hilken
What about just implementing the cheapest solution that still gets  
us most

of the way?


(3) If it is as cheap (to implement) as advertised then there is no  
great

risk involved. If it turns out the missing features are a great
show-stopper for some people (which I don't believe) then let them  
present
their case afterwards, with good examples at hand. We can still  
decide to

aim for a higher goal in the long term.



If in doubt, chose the solution that is easier to implement.


Since this paper, there have been several proposals which can be 90%  
implemented as libraries, using either functional dependencies or  
associated types. These all have much more expressive type systems  
than the SPJ paper, yet need very little compiler support. The  
question is, which one (if any) should get this small but necessary  
support?


Barney.

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


Re: [Haskell] Extensible records: Static duck typing

2008-02-10 Thread Jason Dusek
On Feb 5, 2008 2:28 AM, Bulat Ziganshin [EMAIL PROTECTED] wrote:
 this principle allows to build programs in quick and easy way: we just
 add to objects implementations of all the methods required:

 e = new Entry {label := Hi,
color := blue,
getValue := getEntryValue,
setValue := setEntryValue}

 e.display  -- uses color/label properties
 e.saveToFile   -- uses getValue property

I'm new to all this -- I can't figure out why we want to put
methods inside of records. Why don't we define a module instead?

module EntryModule where

data Entry = Entry String Color

display (Entry s c) = do someIOMagic

saveToFile (Entry s c) = do someOtherIOMagic

If we want a more generic approach -- where a function excepts
one of many kinds of data -- than is a type class not suitable?

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


Re: [Haskell] Extensible records: Static duck typing

2008-02-10 Thread Jason Dusek
On Feb 5, 2008 4:24 AM, John Meacham [EMAIL PROTECTED] wrote:
 now when it came to record selection I was deciding between a couple.

   ...snip.../

 ...declare that any identifier that _begins_ with ' always
 refers to a label selection function

 'x point

Say we go with 'x and allow it to pick the x field out of
records. All records. Then we have implicitly defined a function
'x that accepts things in the HasAnX class. This class is also
implicitly defined -- and things are added to it implicitly,
too, by giving them an x.

So, in a way, this is cool -- it's like structs but way less
verbose. On the other hand, it seems awfully like something that
could be handled as a templating thing. Since we already have
templates, couldn't we just add a few default ones to GHC and be
done with it?

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


[Haskell] Haskell Weekly News - February 10, 2008

2008-02-10 Thread Don Stewart
 as a
   bell. My code's behavior on unit tests: virtually
   indistinguishable from random.

 * SuperGrade: Haskell kind of herds you into functional programming.
   There are advantages to this manner of coding, and I'm getting to
   thinking you should attempt code this way almost all of the time,
   regardless of language.

 * Berlin Brown: Haskell is readable, fast, and expressive. I like it.

 * Yaakov Nemoy: Changing the type of a function in Python will lead
   to strange runtime errors that take some work to debug, whereas,
   when I tinker with a program in Haskell, I already know it will
   work once it compiles.

 * Michael Reid: Learning Haskell has completely reversed my feeling
   that static typing is an old outdated idea. The power of Haskell's
   type system makes it feel like you are programming in a dynamic
   language to some degree, yet all of it is type-checked, and that
   is just *really* cool.

 * weavejester: I've come across many parser generators that are a
   dream to work with in comparison to lex and yacc. The best one
   I've found so far is Haskell's Parsec.

 * David Roundy: What's the good of having a haskell-programming
   computational linguist on board if we can't get static
   compile-time guarantees of grammatical correctness?

 * Bulat Ziganshin: When FP just pass all the functions and data
   required for specialization of generic algorithm, OOP provides
   interfaces, virtual functions, anonymous classes, delegates and
   lots of other interesting ways to hide the fact of lack of
   first-class functions :)

 * [Douglas] Adams: was interested in computing --- I think his
   reaction to being told about functional programming was to wonder
   what non-functional programming might be.

 * ezekiel: I find Haskell to be like Lisp and APL and Python all put
   together in a way that leads me quickly to a solid result. Other
   languages work, but the road to the result is bumpier.

 * AlanYx: I've found that Haskell's uber-strong, static type system
   does help me be productive, because it increases the class of bugs
   that can be found at compile time, forces thinking at a higher
   level, and can help avoid edits to existing code breaking things
   elsewhere in the code

 * anonymous: Closures in today's world are a 'language geek'
   feature. Unless done extremely carefully and in a way that
   supports the various skill levels of developers, they end up being
   unusable and unsupportable by anything less than computer language
   savants. In their inherent obscurity and complexity, 'language
   geek' style closures are about as anti-Java as you can get.

 * anonymous: I work in a Smalltalk shop, where we extend and
   maintain an application that has been around over a decade. During
   the maintenance part of our job, it would be really nice to have
   type declarations on variables. For maintenance, the more
   dependable information we have, the better! The fewer things that
   can escape as runtime exceptions, the better!

 * consultant barbie: Languages are hard. Let's write web frameworks
   and go shopping!

About the Haskell Weekly News

   New editions are posted to [223]the Haskell mailing list as well as to
   [224]the Haskell Sequence and [225]Planet Haskell. [226]RSS is also
   available, and headlines appear on [227]haskell.org. Headlines are
   available as [228]PDF.

   To help create new editions of this newsletter, please see the
   [229]contributing information. Send stories to dons at galois.com. The
   darcs repository is available at darcs get
   [230]http://code.haskell.org/~dons/code/hwn/

 223. http://www.haskell.org/mailman/listinfo/haskell
 224. http://sequence.complete.org/
 225. http://planet.haskell.org/
 226. http://sequence.complete.org/node/feed
 227. http://haskell.org/
 228. http://code.haskell.org/~dons/code/hwn/archives/20080210.pdf
 229. http://haskell.org/haskellwiki/HWN
 230. http://code.haskell.org/~dons/code/hwn/
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell


[Haskell-cafe] Re: Datatypes - Haskell

2008-02-10 Thread Mattes Simeon
Thanks for your help. It was very useful. 

Though in comparison with C or C++ I can't figure out so clear the syntax. 
Maybe it has to do with the syntactic Sugar of each Language. I 'll give you a
similar example I saw in a book for Haskel

The following program just returns the value of the position of a datatype Tuple
which can hold one or two elements.

data Tuple a b = One a | Two a b 
tuple1 (One a)= Just a
tuple1 (Two a b) = Just a

tuple2 (One a) = Nothing
tuple2 (Two a b) = Just b

The corresponding Version in C++, which seems to be more appropriate, would be
templateclass A, class B
struct Tuple
{
   enum (One, Two) tag;
   union
   {
  A either_one;
  struct nOne
  {
A either_two
B two;
  };
   };
}

Am I wrong. If not, how can I use it in the corresponding function in  C++? 
I seems realy strange, and I'm confused. 

Surely a solution to this would be to use the standard types of Haskel for
tuples and check out each time if I have just a number or a tuple. But this 
is how somebody thinks in imperative languages. Functional programming is
something more, isn't it?

Sorry for beeing so naive, but although unions, enum, structure are just 
some tools in C, surely something more in C++, in Haskell they are seem to be a
standard.

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


Re: [Haskell-cafe] Re: Datatypes - Haskell

2008-02-10 Thread Victor Nazarov
On Feb 10, 2008 3:40 PM, Mattes Simeon [EMAIL PROTECTED] wrote:
 Thanks for your help. It was very useful.

 Though in comparison with C or C++ I can't figure out so clear the syntax.
 Maybe it has to do with the syntactic Sugar of each Language. I 'll give you a
 similar example I saw in a book for Haskel

 The following program just returns the value of the position of a datatype 
 Tuple
 which can hold one or two elements.

 data Tuple a b = One a | Two a b
 tuple1 (One a)= Just a
 tuple1 (Two a b) = Just a

 tuple2 (One a) = Nothing
 tuple2 (Two a b) = Just b

 The corresponding Version in C++, which seems to be more appropriate, would be

I think this is the most native way to do it in C++:
template class A, class B
class Tuple {
public:
static TupleA, B *One (A *a) { return new One (a); }
static TupleA, B *Two (A *a, B *b) { return new Two (a, b); }
virtual A *tuple1 () = 0;
virtual B *tuple2 () = 0;
};

template class A, class B
class One : TupleA, B
{
public:
  One (A *a) { this-a = a; }
  A *tuple1 () { return a; }
  B *tuple2 () { return NULL; }
private:
  A *a;
}

template class A, class B
class Two: TupleA, B
{
public:
  Two (A *a, B *b) { this-a = a; this-b = b}
  A *tuple1 () { return a; }
  B *tuple2 () { return b; }
private:
  A *a;
  B *b;
}



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


[Haskell-cafe] Embedded Functions in Algebraic Data Types?

2008-02-10 Thread Michael Feathers

On a lark, I loaded this into Hugs this morning, and it didn't complain:


data Thing = Thing (Integer - Integer)



But, I've never seen that sort of construct in an example.  Do people 
ever embed functions in ADTs?



Michael

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


Re: [Haskell-cafe] Embedded Functions in Algebraic Data Types?

2008-02-10 Thread Chaddaï Fouché
2008/2/10, Michael Feathers [EMAIL PROTECTED]:
 On a lark, I loaded this into Hugs this morning, and it didn't complain:


 data Thing = Thing (Integer - Integer)



 But, I've never seen that sort of construct in an example.  Do people
 ever embed functions in ADTs?

Yes, anyway you can embed function in Maybe a or Either a b for
example, since they're polymorphic. Embedding functions in ADT
purposefully happens quite often too, just look at the State Monad,
the functionnal references proposal and so on...
Recently I embedded functions into a denotational semantic ADT for a
tiny DSL, there's plenty of use cases.

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


Re: [Haskell-cafe] Embedded Functions in Algebraic Data Types?

2008-02-10 Thread Sebastian Sylvan
On Feb 10, 2008 1:34 PM, Michael Feathers [EMAIL PROTECTED] wrote:

 On a lark, I loaded this into Hugs this morning, and it didn't complain:


 data Thing = Thing (Integer - Integer)



 But, I've never seen that sort of construct in an example.  Do people
 ever embed functions in ADTs?


Yes, this is quite common. Here's a quick example (untested):

data MyMap key value = M (key - Maybe value)

lookup (M m) key = m key
insert (M m) key value = M (\key' - if key' == key then Just value else m
key')

This is a naive data structure for storing a map as a function from the key
to the value. Not very efficient, perhaps, but you use similar concepts in
more useful scenarios (e.g. the State monad).

-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Embedded Functions in Algebraic Data Types?

2008-02-10 Thread Luke Palmer
Quite frequently.

Here are a few examples from my own code:

For functional references (representing a bidirectional function
from a data type to a part of itself (for example the first element of
a pair)).

 data Accessor s a
 = Accessor { get :: s - a
, set :: a - s - s
}

My quantum computation arrow (really in the realm of concrete, useful
things, huh? :-)

 data Operator b c
 = Op (forall d. QStateVec (b,d) - IO (QStateVec (c,d)))
 | ...

The ubiquitous FRP Behavior, comprising a current value and a function
which takes a timestep and returns the next value.

 data Behavior a
= Behavior a (Double - Behavior a)

The suspend monad, representing a computation which can either
finish now with a value of type a, or suspends to request a value of
type v before continuing.

 data Suspend v a
 = Return a
 | Suspend (v - Suspend v a)

It seems that most frequently, functions in ADTs are used when
implementing monads or arrows, but that doens't need to be the case.
A lot of times a function is the best way to represent a particular
part of a data structure :-)

Luke

On Feb 10, 2008 1:34 PM, Michael Feathers [EMAIL PROTECTED] wrote:
 On a lark, I loaded this into Hugs this morning, and it didn't complain:


 data Thing = Thing (Integer - Integer)



 But, I've never seen that sort of construct in an example.  Do people
 ever embed functions in ADTs?


 Michael

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

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


Re: [Haskell-cafe] Embedded Functions in Algebraic Data Types?

2008-02-10 Thread Sebastian Sylvan
On Feb 10, 2008 1:42 PM, Sebastian Sylvan [EMAIL PROTECTED]
wrote:



 On Feb 10, 2008 1:34 PM, Michael Feathers [EMAIL PROTECTED]
 wrote:

  On a lark, I loaded this into Hugs this morning, and it didn't complain:
 
 
  data Thing = Thing (Integer - Integer)
 
 
 
  But, I've never seen that sort of construct in an example.  Do people
  ever embed functions in ADTs?


 Yes, this is quite common. Here's a quick example (untested):

 data MyMap key value = M (key - Maybe value)

 lookup (M m) key = m key
 insert (M m) key value = M (\key' - if key' == key then Just value else m
 key')

 This is a naive data structure for storing a map as a function from the
 key to the value. Not very efficient, perhaps, but you use similar concepts
 in more useful scenarios (e.g. the State monad).


Perhaps I should add an empty MyMap too:

empty = M (\_- Nothing )

-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Embedded Functions in Algebraic Data Types?

2008-02-10 Thread Michael Feathers


Great. Thanks to everyone!

Michael

Luke Palmer wrote:

Quite frequently.

Here are a few examples from my own code:

For functional references (representing a bidirectional function
from a data type to a part of itself (for example the first element of
a pair)).

  

data Accessor s a
= Accessor { get :: s - a
   , set :: a - s - s
   }



My quantum computation arrow (really in the realm of concrete, useful
things, huh? :-)

  

data Operator b c
= Op (forall d. QStateVec (b,d) - IO (QStateVec (c,d)))
| ...



The ubiquitous FRP Behavior, comprising a current value and a function
which takes a timestep and returns the next value.

  

data Behavior a
   = Behavior a (Double - Behavior a)



The suspend monad, representing a computation which can either
finish now with a value of type a, or suspends to request a value of
type v before continuing.

  

data Suspend v a
= Return a
| Suspend (v - Suspend v a)



It seems that most frequently, functions in ADTs are used when
implementing monads or arrows, but that doens't need to be the case.
A lot of times a function is the best way to represent a particular
part of a data structure :-)

Luke

On Feb 10, 2008 1:34 PM, Michael Feathers [EMAIL PROTECTED] wrote:
  

On a lark, I loaded this into Hugs this morning, and it didn't complain:


data Thing = Thing (Integer - Integer)



But, I've never seen that sort of construct in an example.  Do people
ever embed functions in ADTs?


Michael

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




  


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


Re: [Haskell-cafe] nub vs. find + (:) Is this abysmal code?

2008-02-10 Thread Chaddaï Fouché
2008/2/10, Michael Feathers [EMAIL PROTECTED]:

 How bad is this:

 addProduct :: [Product] - Product - [Product]
 addProduct inventory product = nub (product : inventory)


This is pretty terrible, if the list is consumed afterward (which we
assume it will be) we should have something like a O(n^3)
complexity... Since nub is O(n^2).


 compared to this:

 addProduct :: [Product] - Product - [Product]
 addProduct inventory p
 | isNothing (find (==p) inventory)= p : inventory
 | otherwise= inventory


This is much better, though probably better writed :
 addProduct :: [Product] - Product - [Product]
 addProduct inventory p
 | elem p inventory = p : inventory
 | otherwise   = inventory

and probably even better with a Set instead of a List...

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


Re: [Haskell-cafe] nub vs. find + (:) Is this abysmal code?

2008-02-10 Thread Felipe Lessa
On Feb 10, 2008 1:14 PM, Chaddaï Fouché [EMAIL PROTECTED] wrote:
 This is much better, though probably better writed :
  addProduct :: [Product] - Product - [Product]
  addProduct inventory p
  | elem p inventory = p : inventory
  | otherwise   = inventory

Maybe

addProduct :: [Product] - Product - [Product]
addProduct inventory p = p : delete p inventory

 and probably even better with a Set instead of a List...

import qualified Data.Set as S

addProduct :: S.Set Product - Product - S.Set Product
addProduct = flip S.insert


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


Re: [Haskell-cafe] nub vs. find + (:) Is this abysmal code?

2008-02-10 Thread Felipe Lessa
On Feb 10, 2008 1:07 PM, Michael Feathers [EMAIL PROTECTED] wrote:
 How bad is this:

 addProduct :: [Product] - Product - [Product]
 addProduct inventory product = nub (product : inventory)


O(n²) as is nub.

 compared to this:

 addProduct :: [Product] - Product - [Product]
 addProduct inventory p
 | isNothing (find (==p) inventory)= p : inventory
 | otherwise= inventory

O(n) as is find.

 My guess is that the latter is more efficient, but then when I think
 about laziness, I wonder whether the first is a fair trade.

I don't think so =). Still, you should be using Data.Set which will
take you to O(log n).

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


[Haskell-cafe] nub vs. find + (:) Is this abysmal code?

2008-02-10 Thread Michael Feathers


How bad is this:

addProduct :: [Product] - Product - [Product]
addProduct inventory product = nub (product : inventory)


compared to this:

addProduct :: [Product] - Product - [Product]
addProduct inventory p
   | isNothing (find (==p) inventory)= p : inventory
   | otherwise= inventory


My guess is that the latter is more efficient, but then when I think 
about laziness, I wonder whether the first is a fair trade.


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


Re: [Haskell-cafe] nub vs. find + (:) Is this abysmal code?

2008-02-10 Thread Felipe Lessa
On Feb 10, 2008 1:20 PM, Felipe Lessa [EMAIL PROTECTED] wrote:
 Maybe

 addProduct :: [Product] - Product - [Product]
 addProduct inventory p = p : delete p inventory

Oh, forget this, it will keep rewriting the tail of the list, which is
a Bad Thing (TM).

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


Re: [Haskell-cafe] Embedded Functions in Algebraic Data Types?

2008-02-10 Thread Henning Thielemann

On Sun, 10 Feb 2008, Henning Thielemann wrote:

 On Sun, 10 Feb 2008, Luke Palmer wrote:

  Quite frequently.
 
  Here are a few examples from my own code:
 
  For functional references (representing a bidirectional function
  from a data type to a part of itself (for example the first element of
  a pair)).
 
   data Accessor s a
   = Accessor { get :: s - a
  , set :: a - s - s
  }
 
  My quantum computation arrow (really in the realm of concrete, useful
  things, huh? :-)

 The pattern seems to be common enough to be turned into a package.

 http://www.haskell.org/haskellwiki/?title=Record_accessaction=history

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


Re: [Haskell-cafe] Embedded Functions in Algebraic Data Types?

2008-02-10 Thread Henning Thielemann

On Sun, 10 Feb 2008, Luke Palmer wrote:

 Quite frequently.

 Here are a few examples from my own code:

 For functional references (representing a bidirectional function
 from a data type to a part of itself (for example the first element of
 a pair)).

  data Accessor s a
  = Accessor { get :: s - a
 , set :: a - s - s
 }

 My quantum computation arrow (really in the realm of concrete, useful
 things, huh? :-)

The pattern seems to be common enough to be turned into a package.

http://www.haskell.org/haskellwiki/?title=Record_accessaction=history
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)

2008-02-10 Thread Wolfgang Jeltsch
Am Sonntag, 10. Februar 2008 05:14 schrieben Sie:
 […]

 Now some functions which I wasn't able to define

 Concat function. This would be the naive implementation, but it fails
 to compile.

 (+) :: Add s1 s2 s3 = FSVec s1 a - FSVec s2 a - FSVec s3 a
 NullV  + ys  = ys
 (x:xs) + ys = x : (xs + ys)

Hmm, we would have to find a way to implement lemmas.  In this case, the lemma 
that succ (x + y) = succ x + y.  At the moment, I’ve no good idea how to do 
that.

 Tail function, which is also incorrect.

 tailV :: Succ s' s = FSVec s a - FSVec s' a
 tailV (x : xs) = xs

Maybe this problem is similar to the one I came across earlier.  See my mail 
on http://www.haskell.org/pipermail/haskell/2007-September/019757.html and 
the replies to it.

 And finally, vector, which is supposed to build a fixed-sized vector
 out of a list.

 The ideal type for the function would be:

 vector :: [a] - FSVec s a

 But there is no apparent way in which to obtain s based on the length
 of the input list.

 [1] shows a way in which to create vector using CPS style and a
 reification function:

 reifyInt :: Int - (forall s . Nat s = FSVect s a - w) - w

 The result would be a function with the following type:

 vector :: [a] - (forall s . Nat s = FSVec s a - w) - w

 Nevertheless, I'm not fully satisfied by it.

I suppose, it’s the best we can get without having dependent types.  Others 
might correct me.

 […]

Some remark concerning spelling: Would it be possible to drop the V at the end 
of the function names?  I think the fact that those functions are 
about “vectors” is better expressed by qualification:

import Data.List as List
import Data.TypeLevel.Vector as Vector

-- Usage: Vector.last, List.last, …

Compare this to the functions in Data.Map, Data.Set, etc.  They also use 
insert, etc. instead of insertM, insertS, etc.  Note that the latter would 
quickly lead to ambiguities because insertM would stand for map insertion as 
well as for multiset insertion.  Similar with sets and sequences.

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


Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)

2008-02-10 Thread Wolfgang Jeltsch
Am Samstag, 9. Februar 2008 23:33 schrieben Sie:
 On Feb 8, 2008 4:10 PM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote:
  Am Donnerstag, 7. Februar 2008 16:31 schrieben Sie:
   Even if () would be preferred from the programmers point of view (I'm
   not sure how much we could reduce the number of instances though), it
   makes the representation less attractive on the user-side. Anyone
   using the library would find it annoying and would wonder why is it
   neccessary.
 
  I wouldn't wonder.  Leaving out the () :* part just works because our
  type-level values are not typed, i.e., there aren't different kinds
  Digit and Number but only kind *.  If :+ would be a data constructor (on
  the value level), it would take a number and a digit argument which would
  forbid using a digit as its left argument.

 Well, the fact is that :+ (or :* as it is called now) is not a value
 constructor but a type constructor as you said, so I don't think your
 example really applies here. Besides, you should be regarded :* as (,)
 and not as a constructor which would take a number and a digit
 argument which would forbid using a digit as its left argument.
 Indeed, :* exists as a value-level constructor too and works exactly
 like that.

 Furthermore, you probably consider using () as natural and logical
 because you are still thinking from the implementation side. If you
 forget the implementation details and think as a user who barely wants
 to write type-level numerical literals, :* is simply an ugly syntactic
 requirement which we cannot get rid of (I would be happy to find
 another representation closer to a literal, but I couldn't until now).
 That is not the case for (), since, as shown in the initial
 implementation, can be avoided.

 So, for me, it's just a matter of usability and syntax, the closer the
 representation can be to literals, the better. I don't see the
 semantic implications of :* as a valid argument. For me, :* is just an
 unavoidable ugly syntactical token without meaning. Imagine that for
 some reason, adding () as a prefix in every numerical literal made the
 implementation of a compiler slightly easier/faster. I bet users would
 rant about it till exhaustion :)

 If the argument was that,  for some reason, () was proven to speed up
 the implementation or make a big maintainability difference (I still
 have my doubts) it would maybe make more sense (I still wouldn't be
 sure if it pays off though). Maybe it would be a good idea to create a
 patch and see what happens :)

 As a side note, I think that type-value digits actually are typed
 (metatyped maybe is a nicer term?). Class constraints take the role of
 types in this case.

 After all (sorry if the definition is imprecise), a type establishes a
 set of valid values. Nat n = n does exactly that. For example, it
 forces type-level naturals to be normalized (i.e. numerals with
 leading zeros don't satisfy the Nat constraint)

  So I consider using a digit on the left
  as unclean.  It's similar to using a number as the second part of a
  cons cell in LISP.

 Again, the comparisson is based on semantical implications of the
 implementation which shouldn't be visible for, or at least not taken
 into consideration by,  the final user.

My arguments were not so much about implementation, I think.  I’d see a 
type-level number as a list of digits, and a list has the form

x1 : (x2 : (… : (xn : [])…))

or

((…([] `Snoc` x1) `Snoc` …) `Snoc` x(n-1)) `Snoc` xn.

From this point of view, it’s reasonable to have the extra () :*.

On the other hand, it might be sensible to give the user the illusion that :* 
is part of a special syntax while it’s actually an operator.  I’m not really 
sure what the better approach is.

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


Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)

2008-02-10 Thread Dan Licata
  And finally, vector, which is supposed to build a fixed-sized vector
  out of a list.
 
  The ideal type for the function would be:
 
  vector :: [a] - FSVec s a
 
  But there is no apparent way in which to obtain s based on the length
  of the input list.
 
  [1] shows a way in which to create vector using CPS style and a
  reification function:
 
  reifyInt :: Int - (forall s . Nat s = FSVect s a - w) - w
 
  The result would be a function with the following type:
 
  vector :: [a] - (forall s . Nat s = FSVec s a - w) - w
 
  Nevertheless, I'm not fully satisfied by it.
 
 I suppose, it’s the best we can get without having dependent types.  Others 
 might correct me.

The type 

vector :: [a] - FSVec s a

doesn't make sense here: because s is universally quantified at the
outside, this says for all lengths s, given a list, I can produce a
vector of length s.

And indeed, in the second version, it looks like you're using the
continuation to curry an existential:

vector :: [a] - (forall s . Nat s = FSVec s a - w) - w

is the same as

vector :: [a] - ((exists s . Nat s and FSVec s a) - w) - w

So why not just do

vector :: [a] - (exists s . Nat s and FSVec s a)

I.e.

data UnknownLengthVec a where
  U :: Nat s = FsVec s a - UnknownLengthVec a

vector :: [a] - UnknownLengthVec a

I haven't tried, but I'd be surprised if you couldn't write this
function by recuring on the list.

Of course, this type does not relate the size of the vector to the
output of the length function on lists; it just says you get a vector
some size.  But maybe that's good enough for many uses?

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


Re: [Haskell-cafe] I love purity, but it's killing me.

2008-02-10 Thread Matthew Naylor
Hi Tom,

 So is the general strategy with observable sharing to use
 unsafePerformIO with Data.Unique to label expressions at
 construction?

something like that, yes.  Basically, you just need:

  {-# NOINLINE ref #-}
  ref x = unsafePerformIO (newIORef x)

and you can write expressions like

  ref False == ref False

and

  let x = ref False in x == x

However, while referential equality is enough for sharing detection, I
*suspect* it's simpler to use the fact that refs are IORefs and you
can read and write them (in the IO monad).  So a very simple Lava
might look like

  module Lava (Bit,Netlist,low,high,nand2,netlist) where

  import Data.IORef
  import System.IO.Unsafe

  {-# NOINLINE ref #-}
  ref x = unsafePerformIO (newIORef x)

  type Ref = IORef (Maybe Int)

  data Bit = Gate String Ref [Bit]

  type Netlist = [(String,   Int, [Int])]
  --   gate, output,  inputs

  low = Gate low (ref Nothing) []
  high = Gate high (ref Nothing) []
  nand2 (a, b) = Gate nand2 (ref Nothing) [a, b]

  netlist :: Bit - IO Netlist
  netlist x = do i - newIORef (0 :: Int) ; f i x
where
  f i (Gate str r xs) =
do val - readIORef r
   num - readIORef i
   case val of
 Nothing - do writeIORef r (Just num)
   writeIORef i (num+1)
   rest - mapM (f i) xs
   let is = map ((\(g,o,is) - o) . head) rest
   return ((str,num,is):concat rest)
 Just j - return [(indirection,j,[])]  -- explicit sharing!

Indirections can be filtered out at the end, they don't actually give
the netlist any information.

 Of course, now that you have me reading up on Yhc.Core, option #5 is
 looking considerably more fun.

Yeah, I think Yhc.Core is pretty nifty too.  Thank Neil!

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


[Haskell-cafe] ANN: highlighting-kate-0.2

2008-02-10 Thread John MacFarlane
I've just uploaded highlighting-kate-0.2 to HackageDB. highlighting-kate
is a source code syntax highlighting library, based on syntax
description files from the Kate editor (http://kate-editor.org/).

Currently, the following languages are supported:

AdaAlert Asp Awk Bash   
Bibtex C Cmake   Coldfusion  Commonlisp 
CppCss   D   Djangotemplate  Doxygen
DtdEiffelErlang  Fortran Haskell
Html   Java  Javadoc Javascript  Json   
Latex  Lex   LiterateHaskell Lua Makefile   
Matlab Mediawiki Modula3 NasmObjectivec 
Ocaml  PascalPerlPhp Postscript 
Prolog PythonRhtml   RubyScala  
Scheme Sgml  Sql SqlMysqlSqlPostgresql  
TclTexinfo   Xml XsltYacc   

The tarball includes a utility for generating new syntax highlighting
modules from XML syntax descriptions.  It also includes the source code
for a command-line syntax highlighting program, Highlight.

Please send bug reports and suggestions my way.

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


[Haskell-cafe] Proper exception handling

2008-02-10 Thread Thomas DuBuisson
Cafe,
Fact 1: ghc{,i} does not crash when executing this code.
Fact 2: I do not want this to crash.
Question: Is there some theoretical window between the 'catchDyn' exception 
handling and the recursive call to 'catchThatDamnError' that could result in an 
unhandled exception? (of type 'DynError', of coarse)

I suppose I am looking for an answer to this question from a language 
standpoint as well as a compiler pov.

As an aside: I see at least one way to be certain of the safty by wrapping the 
call to forkIO in 'catchDyn', reforking if an exception is caught, and passing 
the new ThreadId to throwConstantly via shared mutable state - I'd like to 
avoid all this if my current example is safe.

Thomas

 import Control.Exception (catchDyn, throwDynTo)
 import Control.Concurrent (forkIO, threadDelay)
 import Control.Monad (forever)
 import Data.Dynamic

 main = do
 tid - forkIO catchThatDamnError
 forever $ throwConstantly tid

 catchThatDamnError = catchDyn start (\DynError - catchThatDamnError)

 start = do
 threadDelay 5000
 start

 throwConstantly tid = do
 throwDynTo tid DynError 

 data DynError = DynError deriving (Eq, Ord, Show, Typeable)

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


Re: [Haskell-cafe] Proper exception handling

2008-02-10 Thread Stefan O'Rear
On Sun, Feb 10, 2008 at 02:49:39PM -0500, Thomas DuBuisson wrote:
 Cafe,
 Fact 1: ghc{,i} does not crash when executing this code.
 Fact 2: I do not want this to crash.
 Question: Is there some theoretical window between the 'catchDyn' exception 
 handling and the recursive call to 'catchThatDamnError' that could result in 
 an unhandled exception? (of type 'DynError', of coarse)
 
 I suppose I am looking for an answer to this question from a language 
 standpoint as well as a compiler pov.
 
 As an aside: I see at least one way to be certain of the safty by wrapping 
 the call to forkIO in 'catchDyn', reforking if an exception is caught, and 
 passing the new ThreadId to throwConstantly via shared mutable state - I'd 
 like to avoid all this if my current example is safe.
 
 Thomas

Asynchronous exceptions are blocked in handlers, so there is no window -
infact all exceptions after the first won't be delivered at all.
However, you could be unlucky enough to throw the first error before the
first catchDyn, so more synchronisation might be needed.

Stefan

 
  import Control.Exception (catchDyn, throwDynTo)
  import Control.Concurrent (forkIO, threadDelay)
  import Control.Monad (forever)
  import Data.Dynamic
 
  main = do
  tid - forkIO catchThatDamnError
  forever $ throwConstantly tid
 
  catchThatDamnError = catchDyn start (\DynError - catchThatDamnError)
 
  start = do
  threadDelay 5000
  start
 
  throwConstantly tid = do
  throwDynTo tid DynError 
 
  data DynError = DynError deriving (Eq, Ord, Show, Typeable)


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


Re: [Haskell-cafe] Re: Datatypes - Haskell

2008-02-10 Thread ajb

G'day all.

On Feb 10, 2008 3:40 PM, Mattes Simeon [EMAIL PROTECTED] wrote:


Though in comparison with C or C++ I can't figure out so clear the syntax.


Quoting Victor Nazarov [EMAIL PROTECTED]:


I think this is the most native way to do it in C++:


Herb Sutter and Andrei Alexandrescu will find you and beat you up if
you write this.  This is considered more appropriate.  (Warning: untested
code follows.)

#include boost/variant.hpp

templatetypename A, typename B
class Tuple : public boost::variantA, std::pairA,B 
{
private:
typedef std::pairA,B pair_type;
typedef boost::variantA, pair_type base_type;

struct visitor_A : public boost::static_visitorconst A*
{
const A* operator()(const A a) { return a; }
const A* operator()(const pair_type p) { return p.first; }
};

public:

Tuple(const A a)
: base_type(a)
{
}

Tuple(const A a, const B b)
: base_type(pair_type(a,b))
{
}

const A* tuple1() const
{
return boost::apply_visitor(visitor_A(), *this);
}

const B* tuple2() const
{
const pair_type* p = boost::getpair_type(*this);
return p ? p-second : 0;
}
};

But in this specific case, this might be more appropriate:

templatetypename A,typename B
class Tuple
{
A m_a;
boost::optionalB m_b;
// etc
};

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


Re: [Haskell-cafe] using the writer monad to better understand foldl and foldr, and haskell debugging techniques in general

2008-02-10 Thread Thomas Hartman
same behavior with

myfoldrD (:) [] [1..] -- uses Debug.Trace.trace

So, I would say this proves my main point, which was that you could
accomplish the same thing using the writer monad that you could do
using the more ad hoc trace function from Debug.Trace.

It's good that you point this out though, because understanding that
foldr can take an infinite list and foldl not is a very key point.


 2008/2/10, Felipe Lessa [EMAIL PROTECTED]:
  On Feb 10, 2008 9:33 PM, Thomas Hartman [EMAIL PROTECTED] wrote:
   -- using writer monad
   -- Nothing unsafe here, pure referrentially transparent goodness
   myfoldrW f z [] =  return z
   myfoldrW f z (x:xs) = do
   r - (myfoldrW f z xs)
   tell (x,r:  ++ (show (x,r)) ++ \n )
   return $ x `f` r
 
  *Main foldr const 0 [1..]
  1
  *Main putStrLn $ snd $ runWriter $ myfoldrW const 0 [1..]
  Interrupted.
 
  One of the good things from foldr is the possibility of
  short-circuiting, so to speak. However I don't know if it is
  possible to show this using the writer monad, as is would involve
  observing if the function is strict or not in its second argument.
 
  Cheers,
 
  --
  Felipe.
 

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


Re: [Haskell-cafe] using the writer monad to better understand foldl and foldr, and haskell debugging techniques in general

2008-02-10 Thread Felipe Lessa
On Feb 10, 2008 9:33 PM, Thomas Hartman [EMAIL PROTECTED] wrote:
 -- using writer monad
 -- Nothing unsafe here, pure referrentially transparent goodness
 myfoldrW f z [] =  return z
 myfoldrW f z (x:xs) = do
 r - (myfoldrW f z xs)
 tell (x,r:  ++ (show (x,r)) ++ \n )
 return $ x `f` r

*Main foldr const 0 [1..]
1
*Main putStrLn $ snd $ runWriter $ myfoldrW const 0 [1..]
Interrupted.

One of the good things from foldr is the possibility of
short-circuiting, so to speak. However I don't know if it is
possible to show this using the writer monad, as is would involve
observing if the function is strict or not in its second argument.

Cheers,

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


[Haskell-cafe] using the writer monad to better understand foldl and foldr, and haskell debugging techniques in general

2008-02-10 Thread Thomas Hartman
The following is a simple introduction to debugging techniques in
haskell, illustrated with a canonical use of foldr and foldl.

Comments welcome.

import Control.Monad.Writer
import Debug.Trace
-- We use the writer monad to better understand foldl and foldr
-- and show a debugging technique in haskell
-- you could get similar output using Debug.Trace, but this relies on
unsafePerformIO
-- ... 
http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/Debug-Trace.html
-- which is Ugly.
-- Though ugly, trace isn't really unsafe as far as my understanding
goes. But still, I find it nice
-- that there's a way to accomplish the exact same thing by using the
writer or debugger monad
-- which is pure as pure can get

-- In this particular example, it doesn't matter if you use
Debug.Trace or the writer monad.
-- However, I am fidding around in another scenario (debugging a
series of graphs using Data.Graph.Inductive)
-- which seems not to lend itself well to trace. If I can find a nice
way to explain what I am doing and why
-- I may do a follow-up to this post describing that.

-- same as prelude, I think
myfoldr f z [] =  z
myfoldr f z (x:xs) =  x `f` r
  where r = (myfoldr f z xs)
myfoldl f z [] = z
myfoldl f z (x:xs) = myfoldl f l xs
  where l = z `f` x

-- canonical uses of fold, no debug output
tfr = myfoldr (:) [] [1..10] -- copy a list
tfl = myfoldl (flip (:)) [] [1..10] -- reverse a list

-- debugging output using Debug.Trace (unsafePerfomIO)
-- (Not really unsafe, but unsafePerformIO (which is used in the trace
function) sounds kind of scary)
myfoldrD f z [] =  z
myfoldrD f z (x:xs) | trace (x,r:  ++ (show (x,r))) True =  x `f` r
  where r = (myfoldrD f z xs)
myfoldlD f z [] = z
myfoldlD f z (x:xs) | trace ((z,x) ++ (show (z,x))) True= myfoldlD f l xs
  where l = z `f` x

-- run these to see the functions with debug output from trace
tfrD = myfoldrD (:) [] [1..10] -- copy a list
tflD = myfoldlD (flip (:)) [] [1..10] -- reverse a list

-- using writer monad
-- Nothing unsafe here, pure referrentially transparent goodness
myfoldrW f z [] =  return z
myfoldrW f z (x:xs) = do
r - (myfoldrW f z xs)
tell (x,r:  ++ (show (x,r)) ++ \n )
return $ x `f` r

myfoldlW f z [] = return z
myfoldlW f z (x:xs) = do
  tell (z,x):  ++ (show (z,x)) ++ \n)
  l - return $ (z `f` x)
  myfoldlW f l xs

-- display the debug output from the writer monad
tfrW = putStrLn $ snd $ runWriter $ myfoldrW (:) [] [1..10]
tflW = putStrLn $ snd $ runWriter $ myfoldlW (flip (:)) [] [1..10]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] GHC + interactive input/output

2008-02-10 Thread Richard A. O'Keefe


On 9 Feb 2008, at 2:29 pm, Philip Weaver wrote:

GHC certain *could* do this, but it's arguably not the right thing  
to do.



I have reminded the GHC maintainers before that the Haskell  
specification
*REQUIRES* a Haskell system to support this; there is an example that  
makes
no sense whatever without it.  (And the other Haskell systems I use  
get it

right.)

I note that David Bacon's SETL implementation has explicit support for
tying an input stream and an output stream together so that any time  
input

is done on the input stream the output stream is flushed; this is done
automatically for sockets and is *seriously* useful in avoiding  
mistakes.


Note that this should make essentially no difference to performance  
because
(a) the flushing is only needed when the input buffer is exhausted,  
which

happens once per line,
(b) the kinds of streams where you want it (terminals, STREAMs, sockets,
serial ports, c) generally have other costs so high you won't be
able to measure this one,
(c) it *only* applies to bidirectional streams or to explicitly coupled
streams, so I/O to disc files or memory sticks or other high speed
block devices should never be affected at all (unless someone  
chooses
to do it explicitly, in which case it's still going to be faster  
than

anything they could have done by hand).


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


[Haskell-cafe] Haskell Weekly News - February 10, 2008

2008-02-10 Thread Don Stewart
 as a
   bell. My code's behavior on unit tests: virtually
   indistinguishable from random.

 * SuperGrade: Haskell kind of herds you into functional programming.
   There are advantages to this manner of coding, and I'm getting to
   thinking you should attempt code this way almost all of the time,
   regardless of language.

 * Berlin Brown: Haskell is readable, fast, and expressive. I like it.

 * Yaakov Nemoy: Changing the type of a function in Python will lead
   to strange runtime errors that take some work to debug, whereas,
   when I tinker with a program in Haskell, I already know it will
   work once it compiles.

 * Michael Reid: Learning Haskell has completely reversed my feeling
   that static typing is an old outdated idea. The power of Haskell's
   type system makes it feel like you are programming in a dynamic
   language to some degree, yet all of it is type-checked, and that
   is just *really* cool.

 * weavejester: I've come across many parser generators that are a
   dream to work with in comparison to lex and yacc. The best one
   I've found so far is Haskell's Parsec.

 * David Roundy: What's the good of having a haskell-programming
   computational linguist on board if we can't get static
   compile-time guarantees of grammatical correctness?

 * Bulat Ziganshin: When FP just pass all the functions and data
   required for specialization of generic algorithm, OOP provides
   interfaces, virtual functions, anonymous classes, delegates and
   lots of other interesting ways to hide the fact of lack of
   first-class functions :)

 * [Douglas] Adams: was interested in computing --- I think his
   reaction to being told about functional programming was to wonder
   what non-functional programming might be.

 * ezekiel: I find Haskell to be like Lisp and APL and Python all put
   together in a way that leads me quickly to a solid result. Other
   languages work, but the road to the result is bumpier.

 * AlanYx: I've found that Haskell's uber-strong, static type system
   does help me be productive, because it increases the class of bugs
   that can be found at compile time, forces thinking at a higher
   level, and can help avoid edits to existing code breaking things
   elsewhere in the code

 * anonymous: Closures in today's world are a 'language geek'
   feature. Unless done extremely carefully and in a way that
   supports the various skill levels of developers, they end up being
   unusable and unsupportable by anything less than computer language
   savants. In their inherent obscurity and complexity, 'language
   geek' style closures are about as anti-Java as you can get.

 * anonymous: I work in a Smalltalk shop, where we extend and
   maintain an application that has been around over a decade. During
   the maintenance part of our job, it would be really nice to have
   type declarations on variables. For maintenance, the more
   dependable information we have, the better! The fewer things that
   can escape as runtime exceptions, the better!

 * consultant barbie: Languages are hard. Let's write web frameworks
   and go shopping!

About the Haskell Weekly News

   New editions are posted to [223]the Haskell mailing list as well as to
   [224]the Haskell Sequence and [225]Planet Haskell. [226]RSS is also
   available, and headlines appear on [227]haskell.org. Headlines are
   available as [228]PDF.

   To help create new editions of this newsletter, please see the
   [229]contributing information. Send stories to dons at galois.com. The
   darcs repository is available at darcs get
   [230]http://code.haskell.org/~dons/code/hwn/

 223. http://www.haskell.org/mailman/listinfo/haskell
 224. http://sequence.complete.org/
 225. http://planet.haskell.org/
 226. http://sequence.complete.org/node/feed
 227. http://haskell.org/
 228. http://code.haskell.org/~dons/code/hwn/archives/20080210.pdf
 229. http://haskell.org/haskellwiki/HWN
 230. http://code.haskell.org/~dons/code/hwn/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Proper exception handling

2008-02-10 Thread Ryan Ingram
If you want to guarantee safety, you can use an MVar () to force
serialization; put something in the MVar inside of catchDyn, and take
from it immediately after starting the thread  after throwing each
exception.

  -- ryan


On Feb 10, 2008 11:49 AM, Thomas DuBuisson [EMAIL PROTECTED] wrote:
 Cafe,
 Fact 1: ghc{,i} does not crash when executing this code.
 Fact 2: I do not want this to crash.
 Question: Is there some theoretical window between the 'catchDyn' exception 
 handling and the recursive call to 'catchThatDamnError' that could result in 
 an unhandled exception? (of type 'DynError', of coarse)

 I suppose I am looking for an answer to this question from a language 
 standpoint as well as a compiler pov.

 As an aside: I see at least one way to be certain of the safty by wrapping 
 the call to forkIO in 'catchDyn', reforking if an exception is caught, and 
 passing the new ThreadId to throwConstantly via shared mutable state - I'd 
 like to avoid all this if my current example is safe.

 Thomas

  import Control.Exception (catchDyn, throwDynTo)
  import Control.Concurrent (forkIO, threadDelay)
  import Control.Monad (forever)
  import Data.Dynamic
 
  main = do
  tid - forkIO catchThatDamnError
  forever $ throwConstantly tid
 
  catchThatDamnError = catchDyn start (\DynError - catchThatDamnError)
 
  start = do
  threadDelay 5000
  start
 
  throwConstantly tid = do
  throwDynTo tid DynError
 
  data DynError = DynError deriving (Eq, Ord, Show, Typeable)

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

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


Re: [Haskell-cafe] Re: Datatypes - Haskell

2008-02-10 Thread Jason Dusek
Mattes Simeon [EMAIL PROTECTED] wrote:
 Though in comparison with C or C++ I can't figure out so clear
 the syntax...I seems realy strange, and I'm confused.

 Surely a solution to this would be to use the standard types
 of Haskel for tuples and check out each time if I have just a
 number or a tuple. But this is how somebody thinks in
 imperative languages. Functional programming is something
 more...

The data declarations in Haskell are well-suited to pattern
matching -- you have a compact way to express each alternative,
so you can match on that alternative. The C++ way offers a
*uniform* interface to every alternative, so you can do if-tests
that will type check. The do an if test at runtime way is very
general, but basically unoptimizable; whereas pattern matching
is very specific, and can be optimized (see page 5 of Luca
Cardelli's [Compiling ML]).


 Sorry for beeing so naive, but although unions, enum,
 structure are just some tools in C, surely something more in
 C++, in Haskell they are seem to be a standard.

It's certainly true that Haskell elevates certain common data
structures to the level of 'native citizens', providing short
cut syntax and so forth. Personally, I think C's approach is an
example of neglect in this domain, not sparseness; however, at
the time C was introduced, I would not have said the same thing
at all.

-- 
_jsn


[Compiling ML]: http://lucacardelli.name/Papers/CompilingML.pdf
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] fast integer base-2 log function?

2008-02-10 Thread Uwe Hollerbach
Hello, haskellers,

Is there a fast integer base-2 log function anywhere in the standard
libraries? I wandered through the index, but didn't find anything that
looked right. I need something that's more robust than logBase, it
needs to handle numbers with a few to many thousands of digits. I
found a thread from a couple of years ago that suggested there was no
such routine, and that simply doing length (show n) might be the
best. That seems kind of... less than elegant. I've come up with a
routine, shown below, that seems reasonably fast (a few seconds of CPU
time for a million-bit number, likely adequate for my purposes), but
it seems that something with privileged access to the innards of an
Integer ought to be even much faster -- it's just a simple walk along
a list (array?) after all. Any pointers? Thanks!

Uwe

 powi :: Integer - Integer - Integer
 powi b e | e == 0= 1
  | e  0 = error negative exponent in powi
  | even e= powi (b*b) (e `quot` 2)
  | otherwise = b * (powi b (e - 1))

 ilog2 :: Integer - Integer
 ilog2 n | n  0  = ilog2 (- n)
 | n  2  = 1
 | otherwise  = up n (1 :: Integer)
   where up n a = if n  (powi 2 a)
 then bin (quot a 2) a
 else up n (2*a)
 bin lo hi = if (hi - lo) = 1
then hi
else let av = quot (lo + hi) 2
 in if n  (powi 2 av)
   then bin lo av
   else bin av hi

(This was all properly aligned when I cut'n'pasted; proportional fonts
might be messing it up here.)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] fast integer base-2 log function?

2008-02-10 Thread Thorkil Naur
Hello,

If the standard libraries provide such a function, I haven't found it. I must 
admit that I haven't studied your code in detail. I usually do as follows for 
integer logarithms, shamelessly stolen from the Haskell report:

   -- Integer log base (c.f. Haskell report 14.4):

   imLog :: Integer-Integer-Integer
   imLog b x
 = if x  b then
 0
   else
 let
   l = 2 * imLog (b*b) x
   doDiv x l = if x  b then l else doDiv (x`div`b) (l+1)
 in
   doDiv (x`div`(b^l)) l

Best regards
Thorkil


On Monday 11 February 2008 07:15, Uwe Hollerbach wrote:
 Hello, haskellers,
 
 Is there a fast integer base-2 log function anywhere in the standard
 libraries? I wandered through the index, but didn't find anything that
 looked right. I need something that's more robust than logBase, it
 needs to handle numbers with a few to many thousands of digits. I
 found a thread from a couple of years ago that suggested there was no
 such routine, and that simply doing length (show n) might be the
 best. That seems kind of... less than elegant. I've come up with a
 routine, shown below, that seems reasonably fast (a few seconds of CPU
 time for a million-bit number, likely adequate for my purposes), but
 it seems that something with privileged access to the innards of an
 Integer ought to be even much faster -- it's just a simple walk along
 a list (array?) after all. Any pointers? Thanks!
 
 Uwe
 
  powi :: Integer - Integer - Integer
  powi b e | e == 0= 1
   | e  0 = error negative exponent in powi
   | even e= powi (b*b) (e `quot` 2)
   | otherwise = b * (powi b (e - 1))
 
  ilog2 :: Integer - Integer
  ilog2 n | n  0  = ilog2 (- n)
  | n  2  = 1
  | otherwise  = up n (1 :: Integer)
where up n a = if n  (powi 2 a)
  then bin (quot a 2) a
  else up n (2*a)
  bin lo hi = if (hi - lo) = 1
 then hi
 else let av = quot (lo + hi) 2
  in if n  (powi 2 av)
then bin lo av
else bin av hi
 
 (This was all properly aligned when I cut'n'pasted; proportional fonts
 might be messing it up here.)
 ___
 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