[GHC] #3306: Improve syntax for GADT + records
#3306: Improve syntax for GADT + records
---+
Reporter: simonpj | Owner:
Type: feature request | Status: new
Priority: normal| Milestone:
Component: Compiler |Version: 6.10.2
Severity: normal| Keywords:
Difficulty: Unknown | Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
---+
This [http://www.haskell.org/pipermail/glasgow-haskell-
users/2009-June/017391.html email thread] raised the question of defining
data constructors that
* use GADT syntax
* and record syntax
* and have class constraints
This combination isn't supported in GHC 6.10, but it's annoying that it
isn't. The problem is just coming up with a plausible syntax. Probably
the most plausible possibilities are
{{{
(A) data RecContTest a where
Show a = C { showable :: Show a = a } :: RecContTest a
(B) data RecContTest a where
C :: Show a = { showable :: Show a = a } - RecContTest a
}}}
The latter (B) looks best to me. I dislike (A) because part of the type
(the Show a =) occurs before the constructor name C, and part appears
after. On the other hand, (B) has something that looks vaguely like a
type
{{{
{ x::ty, y::ty } - ty
}}}
but that's not really valid type syntax. (Mind you, the ! marks in a
constructor signature aren't part of valid types either, so maybe it's not
so bad to have a special form in constructor declarations.)
But if we were going to adopt (B), then even when there is no class
context we should really say
{{{
(B) data RecTest a where
B :: { arg :: a } - RecTest a
}}}
rather than the current syntax which is
{{{
(A) data RecTest a where
B { arg :: a } :: RecTest a
}}}
[Note the different placement of the double colon and arrow in (B).]
My take on this
* (B) looks nicer, but it would represent a breaking change
* But perhaps not many people use record-style syntax + GADT-style
syntax
* And better to make breaking changes sooner than later
Question for everyone:
* are (A) and (B) the only choices?
* do you agree (B) is best
There are some replies on the above email thread. Please add further
opinions as comments to this ticket.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3306
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] #3298: Add swap to Data.Tuple
#3298: Add swap to Data.Tuple --+- Reporter: r6| Owner: Type: proposal | Status: new Priority: normal| Milestone: Component: libraries/base|Version: 6.10.2 Severity: normal| Resolution: Keywords:| Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple --+- Comment (by MartijnVanSteenbergen): Whichever version is chosen, I think it should be reexported as part of the Prelude, too. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3298#comment:2 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] #3279: Segmentation fault in reactive program
#3279: Segmentation fault in reactive program
---+
Reporter: Baughn |Owner: igloo
Type: merge | Status: new
Priority: high|Milestone: 6.10.4
Component: Runtime System | Version: 6.11
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Os: Unknown/Multiple
Architecture: x86_64 (amd64) |
---+
Changes (by simonmar):
* owner: simonmar = igloo
* type: bug = merge
* milestone: 6.12.1 = 6.10.4
Comment:
Thanks for the testcase!
Fixed
{{{
Tue Jun 16 08:24:55 PDT 2009 Simon Marlow marlo...@gmail.com
* Fix #3279, #3288: fix crash encountered when calling unblock inside
unsafePerformIO
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3279#comment:13
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] #3288: GC assertion failure in reactive program
#3288: GC assertion failure in reactive program -+-- Reporter: Baughn|Owner: simonmar Type: bug | Status: closed Priority: high |Milestone: 6.10.4 Component: Runtime System| Version: 6.11 Severity: normal| Resolution: duplicate Keywords:| Difficulty: Unknown Testcase: crash.hs | Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by simonmar): * status: new = closed * resolution: = duplicate Comment: This bug turns out to be the same as #3288 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3288#comment:4 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] #3288: GC assertion failure in reactive program
#3288: GC assertion failure in reactive program -+-- Reporter: Baughn|Owner: simonmar Type: bug | Status: closed Priority: high |Milestone: 6.10.4 Component: Runtime System| Version: 6.11 Severity: normal| Resolution: duplicate Keywords:| Difficulty: Unknown Testcase: crash.hs | Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Comment (by simonmar): oops, I meant to say the same as #3279 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3288#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: [GHC] #3298: Add swap to Data.Tuple
#3298: Add swap to Data.Tuple
--+-
Reporter: r6| Owner:
Type: proposal | Status: new
Priority: normal| Milestone:
Component: libraries/base|Version: 6.10.2
Severity: normal| Resolution:
Keywords:| Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
--+-
Comment (by YitzGale):
I wrote:
That supports your choice of the lazy version as unprimed.
I now retract that comment, based on discussion in
the thread on haskell-cafe:
http://www.haskell.org/pipermail/haskell-cafe/2009-June/062772.html
I now support the addition of only the strict version:
{{{
swap (a, b) = (b, a)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3298#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] #3298: Add swap to Data.Tuple
#3298: Add swap to Data.Tuple
-+--
Reporter: r6|Owner:
Type: proposal | Status: new
Priority: normal|Milestone:
Component: libraries/base| Version: 6.10.2
Severity: normal| Resolution:
Keywords:| Difficulty: Unknown
Testcase:| Os: Unknown/Multiple
Architecture: Unknown/Multiple |
-+--
Changes (by simonmar):
* difficulty: = Unknown
Comment:
Replying to [comment:1 YitzGale]:
I would usually spell this
{{{
swap = uncurry $ flip (,)
}}}
That supports your choice of the lazy version as unprimed.
I had tongue firmly in cheek when I suggested using this definition on
haskell-cafe a while ago. I am not sure whether to be horrified or amused
that some people would actually prefer to write it that way!
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3298#comment:4
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] #3298: Add swap to Data.Tuple
#3298: Add swap to Data.Tuple -+-- Reporter: r6|Owner: Type: proposal | Status: new Priority: normal|Milestone: Component: libraries/base| Version: 6.10.2 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Comment (by MartijnVanSteenbergen): Maybe a bit of both? :-) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3298#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: [GHC] #3298: Add swap to Data.Tuple
#3298: Add swap to Data.Tuple
-+--
Reporter: r6|Owner:
Type: proposal | Status: new
Priority: normal|Milestone:
Component: libraries/base| Version: 6.10.2
Severity: normal| Resolution:
Keywords:| Difficulty: Unknown
Testcase:| Os: Unknown/Multiple
Architecture: Unknown/Multiple |
-+--
Comment (by YitzGale):
I wrote:
{{{swap = uncurry $ flip (,)}}}
simonmar wrote:
I had tongue firmly in cheek when I suggested using this definition on
haskell-cafe a while ago. I am not sure whether to be horrified or amused
that some people would actually prefer to write it that way!
He he, I didn't even remember that, perhaps I didn't see it.
Anyway, I never meant to suggest that it should actually
be written that way in the libraries.
Just that the laziness of the natural points-free
version is evidence in support of laziness. And I have
retracted even that claim.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3298#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] #3132: x86 code generator generates bad FPU register names
#3132: x86 code generator generates bad FPU register names
---+
Reporter: int-e |Owner: nobody
Type: bug | Status: closed
Priority: high|Milestone: 6.12.1
Component: Compiler (NCG) | Version: 6.11
Severity: normal | Resolution: fixed
Keywords: | Difficulty: Unknown
Testcase: | Os: Unknown/Multiple
Architecture: x86 |
---+
Changes (by simonmar):
* status: new = closed
* resolution: = fixed
Comment:
Fixed:
{{{
Wed Jun 17 14:02:27 BST 2009 Simon Marlow marlo...@gmail.com
* Fix #3132: a case of bogus code generation
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3132#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: [GHC] #3132: x86 code generator generates bad FPU register names
#3132: x86 code generator generates bad FPU register names ---+ Reporter: int-e |Owner: nobody Type: bug | Status: reopened Priority: high|Milestone: 6.12.1 Component: Compiler (NCG) | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | ---+ Changes (by simonmar): * status: closed = reopened * resolution: fixed = Comment: Ah, we need to leave this ticket open, as a reminder to investigate the issue in the new code generator. See comments in `codeGen/CgCase.lhs`, search for `3132`. The test case is in `codeGen/should_compile/3132.hs`. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3132#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] #3306: Improve syntax for GADT + records
#3306: Improve syntax for GADT + records
-+--
Reporter: simonpj |Owner:
Type: feature request | Status: new
Priority: normal|Milestone:
Component: Compiler | Version: 6.10.2
Severity: normal| Resolution:
Keywords:| Difficulty: Unknown
Testcase:| Os: Unknown/Multiple
Architecture: Unknown/Multiple |
-+--
Comment (by isaacdupree):
Who implements GHC's version of the syntax currently? GHC and haskell-src-
exts, I guess. Both well-maintained.
If we choose (B), I guess the current GADT-records syntax can/should be
kept with a 'deprecated' warning for a few releases?
(A) reminds me a little too much of how C tried to make declarations and
uses look the same (e.g. function-pointers) and ended up with something
nearly incomprehensible!
With (A) and (B), I have a silly question.
{{{
data Silly a where
Silly :: a - forall b. b - Silly a
(which would parse like
Silly :: a - (forall b. b - Silly a)
)
}}}
Is that allowed or useful? (interacts with impredicativity, IIRC)...
Because neither records syntax allows you even to attempt that.
-Isaac
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3306#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
Re: [GHC] #3271: New methods for Data.Sequence
#3271: New methods for Data.Sequence ---+ Reporter: LouisWasserman | Owner: LouisWasserman Type: proposal | Status: new Priority: normal | Milestone: Component: libraries (other) |Version: 6.10.2 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ---+ Changes (by LouisWasserman): * owner: = LouisWasserman -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3271#comment:4 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] #367: Infinite loops can hang Concurrent Haskell
#367: Infinite loops can hang Concurrent Haskell -+-- Reporter: simonpj |Owner: nobody Type: bug | Status: assigned Priority: lowest|Milestone: _|_ Component: Compiler | Version: 6.4.1 Severity: normal| Resolution: None Keywords: scheduler allocation | Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Comment (by SamB): According to CapabilitiesAndScheduling: We do have a time-slice mechanism: the timer interrupt (see Timer.c) sets the context_switch flag, which causes the running thread to return to the scheduler the next time a heap check fails (at the end of the current nursery block). When a heap check fails, the thread doesn't necessarily always return to the scheduler: as long as the context_switch flag isn't set, and there is another block in the nursery, it resets Hp and HpLim? to point to the new block, and continues. To fix this bug, we need a way for the timer signal handler to *force* the Haskell code to stop in bounded time. Two ways that come to mind for the handler to force a stop are: 1. insert a breakpoint (or a special jump?) at some pre-arranged point in any arbitrarily-long allocation-free loop, such that the breakpoint signal handler can safely enter the schedular 2. use some sort of instruction-by-instruction Call Frame Information, something like that of DWARF 2 and up, to figure out the innermost frame's stack layout. Approach 1 is kind of icky insofar as it might cause spurious stops in other threads, or worse! For those unfamiliar with it: DWARF's CFI represents a function of type (IP value × register name) → Maybe (how to find the value of that register in the caller), where Nothing means that register got clobbered. Obviously, we would also need information about which of the interrupted code's registers and stack slots represented pointers that should be followed by the garbage collector for approach 2 to work. Any other ideas about how the timer handler can guarantee re-entering the scheduler in bounded time? There *is* the obvious check every time around a non-allocating loop approach, but it seems obvious that that would cost far too much where we can least afford it. (Is this actually true? So many things that seem obvious aren't...) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/367#comment:10 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] #3306: Improve syntax for GADT + records
#3306: Improve syntax for GADT + records
-+--
Reporter: simonpj |Owner:
Type: feature request | Status: new
Priority: normal|Milestone:
Component: Compiler | Version: 6.10.2
Severity: normal| Resolution:
Keywords:| Difficulty: Unknown
Testcase:| Os: Unknown/Multiple
Architecture: Unknown/Multiple |
-+--
Old description:
This [http://www.haskell.org/pipermail/glasgow-haskell-
users/2009-June/017391.html email thread] raised the question of defining
data constructors that
* use GADT syntax
* and record syntax
* and have class constraints
This combination isn't supported in GHC 6.10, but it's annoying that it
isn't. The problem is just coming up with a plausible syntax. Probably
the most plausible possibilities are
{{{
(A) data RecContTest a where
Show a = C { showable :: Show a = a } :: RecContTest a
(B) data RecContTest a where
C :: Show a = { showable :: Show a = a } - RecContTest a
}}}
The latter (B) looks best to me. I dislike (A) because part of the type
(the Show a =) occurs before the constructor name C, and part appears
after. On the other hand, (B) has something that looks vaguely like a
type
{{{
{ x::ty, y::ty } - ty
}}}
but that's not really valid type syntax. (Mind you, the ! marks in a
constructor signature aren't part of valid types either, so maybe it's
not so bad to have a special form in constructor declarations.)
But if we were going to adopt (B), then even when there is no class
context we should really say
{{{
(B) data RecTest a where
B :: { arg :: a } - RecTest a
}}}
rather than the current syntax which is
{{{
(A) data RecTest a where
B { arg :: a } :: RecTest a
}}}
[Note the different placement of the double colon and arrow in (B).]
My take on this
* (B) looks nicer, but it would represent a breaking change
* But perhaps not many people use record-style syntax + GADT-style
syntax
* And better to make breaking changes sooner than later
Question for everyone:
* are (A) and (B) the only choices?
* do you agree (B) is best
There are some replies on the above email thread. Please add further
opinions as comments to this ticket.
New description:
This [http://www.haskell.org/pipermail/glasgow-haskell-
users/2009-June/017391.html email thread] raised the question of defining
data constructors that
* use GADT syntax
* and record syntax
* and have class constraints
This combination isn't supported in GHC 6.10, but it's annoying that it
isn't. The problem is just coming up with a plausible syntax. Probably
the most plausible possibilities are
{{{
(A) data RecContTest a where
Show a = C { showable :: a } :: RecContTest a
(B) data RecContTest a where
C :: Show a = { showable :: a } - RecContTest a
}}}
The latter (B) looks best to me. I dislike (A) because part of the type
(the Show a =) occurs before the constructor name C, and part appears
after. On the other hand, (B) has something that looks vaguely like a
type
{{{
{ x::ty, y::ty } - ty
}}}
but that's not really valid type syntax. (Mind you, the ! marks in a
constructor signature aren't part of valid types either, so maybe it's not
so bad to have a special form in constructor declarations.)
But if we were going to adopt (B), then even when there is no class
context we should really say
{{{
(B) data RecTest a where
B :: { arg :: a } - RecTest a
}}}
rather than the current syntax which is
{{{
(A) data RecTest a where
B { arg :: a } :: RecTest a
}}}
[Note the different placement of the double colon and arrow in (B).]
My take on this
* (B) looks nicer, but it would represent a breaking change
* But perhaps not many people use record-style syntax + GADT-style
syntax
* And better to make breaking changes sooner than later
Question for everyone:
* are (A) and (B) the only choices?
* do you agree (B) is best
There are some replies on the above email thread. Please add further
opinions as comments to this ticket.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3306#comment:2
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] #3300: System.IO and System.Directory functions not Unicode-aware under Windows
#3300: System.IO and System.Directory functions not Unicode-aware under Windows -+-- Reporter: shu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/directory |Version: 6.11 Severity: major| Resolution: Keywords: unicode | Testcase: Os: Windows | Architecture: Unknown/Multiple -+-- Changes (by YitzGale): * keywords: = unicode * cc: YitzGale (added) * version: 6.10.3 = 6.11 * os: Unknown/Multiple = Windows * summary: System.Directory.getDirectoryContents not unicode-aware under Windows = System.IO and System.Directory functions not Unicode-aware under Windows Comment: This is a more general problem - summary changed to reflect that. See detailed discussion in this thread: http://www.haskell.org/pipermail /haskell-cafe/2009-June/062795.html Besides getDirectoryContents, at least the following functions also need to be fixed, because they are ACP-only: openFile c_stat c_chmod c_SearchPath c_SHGetFolderPath -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3300#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] #3307: System.IO and System.Directory functions not Unicode-aware under Unix
#3307: System.IO and System.Directory functions not Unicode-aware under Unix --+- Reporter: YitzGale | Owner: Type: bug| Status: new Priority: normal | Component: libraries/base Version: 6.11 | Severity: normal Keywords: directory unicode | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple --+- Under Unix, file paths are represented as raw bytes in a String. That is not user-friendly, because a String is supposed to be decoded Unicode, and it is conventional in Unix to view those raw bytes as encoded according to the current locale. In addition, this is not consistent with Windows, where file paths are natively Unicode and represented as such in the String. (Well, they will be consistently once #3300 is completed.) On the other hand, this raises various complications (what about encoding errors, and what if encode.decode is not the identity due to normalisation, etc.) The following cases ought to work consistently for all file operations in System.IO and System.Directory: * A !FilePath from getArgs * A !FilePath from getDirectoryContents * A !FilePath in Unicode from a String literal, * A !FilePath read from a Handle and decoded into Unicode See discussion in the thread http://www.haskell.org/pipermail/haskell- cafe/2009-June/062795.html -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3307 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] #3308: getArgs should return Unicode on Windows
#3308: getArgs should return Unicode on Windows -+-- Reporter: YitzGale | Owner: Type: bug | Status: new Priority: normal| Component: libraries/base Version: 6.11 | Severity: normal Keywords: unicode | Testcase: Os: Windows | Architecture: Unknown/Multiple -+-- This is what is expected, and it is needed for file paths read from the command-line to work (once #3300 is completed). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3308 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] #3309: getArgs should return Unicode on Unix
#3309: getArgs should return Unicode on Unix
-+--
Reporter: YitzGale | Owner:
Type: bug | Status: new
Priority: normal| Component: libraries/base
Version: 6.11 | Severity: normal
Keywords: unicode | Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
-+--
The raw bytes of args should be decoded according to the current locale.
An additional function should be added:
{{{
getArgsBytes :: IO [Word8]
}}}
to provide access to the raw bytes.
This change needs to be coordinated with #3007 so that it will still
work to read a file name from the command line args and use it
to access a file.
This change should also be made on Windows: #3008
See the discussion at http://www.haskell.org/pipermail/haskell-
cafe/2009-June/062795.html
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3309
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] #3300: System.IO and System.Directory functions not Unicode-aware under Windows
#3300: System.IO and System.Directory functions not Unicode-aware under Windows -+-- Reporter: shu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/directory |Version: 6.11 Severity: major| Resolution: Keywords: unicode | Testcase: Os: Windows | Architecture: Unknown/Multiple -+-- Comment (by YitzGale): This change needs to be coordinated with #3308 (getArgs should return Unicode on Windows) so that it will still work to read a file path from the command line and use it to access files. See also #3307 (System.IO and System.Directory functions not Unicode- aware under Unix). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3300#comment:2 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] #3307: System.IO and System.Directory functions not Unicode-aware under Unix
#3307: System.IO and System.Directory functions not Unicode-aware under Unix ---+ Reporter: YitzGale | Owner: Type: bug| Status: new Priority: normal | Milestone: Component: libraries/base |Version: 6.11 Severity: normal | Resolution: Keywords: directory unicode | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ---+ Comment (by YitzGale): This change needs to be coordinated with #3309 (getArgs should return Unicode on Unix) so that it will still work to read a file paths from the command line and use them to access files. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3307#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
Re: [GHC] #3308: getArgs should return Unicode on Windows
#3308: getArgs should return Unicode on Windows +--- Reporter: YitzGale| Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base |Version: 6.11 Severity: normal | Resolution: Keywords: unicode | Testcase: Os: Windows | Architecture: Unknown/Multiple +--- Comment (by YitzGale): See also: #3309 (getArgs should return Unicode on Unix). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3308#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
better generation of vi ctags in ghci
Hi GHC and VI users, I got frustrated with vi tags not working after some unrelated code is edited in a source file. Moreover non-exported top level declarations were not available in vi tags file. Here is an attempt to fix it: http://www.hck.sk/users/peter/pub/ghc/betterCTags.patch Why would you want the new implementation of :ctags ghci command? * Tags are searched based on the line content. This is what Exuberant Ctags do for other languages and it is the other posix way to do it. This makes the positioning to work well even when the source code was edited (on places unrelated to the tag location). More complicated Ex statements can be used to improve it even more but then it does not work well with :tselect (it screws up tag kinds, at least with my version of vim 7.2.65). * All top level symbols defined in a module are added to the tags file. Even the non-exported ones. These are marked as static (file:) so the default tag selection (Ctrl-]) works fine based on the file you started the search from. * Tags get kinds added so you can select whether you want to get to a type constructor or a data constructor (that is if you share names between the two). * In general it is a nice addition to vim haskellmode. If you search for help on symbols in libraries then opening haddock is cool. If you search for help on a symbol in your project then opening the tag in a preview window (Ctrl-W} or ptselect) is cool. Problems: * It needs somebody to check that emacs tags were not broken. I'm not an emacs user but some tag generation code is shared for vim and emacs. I tried to keep emacs tags exactly the way they were (only the exported symbols, original file format). * If your code happens to have definitions on lines which happen to exist more times in one source file then it may put you at an incorrect location. I doubt it will ever happen but if anybody thinks it is really bad we can keep the original format of vim tags too. Then e.g. :ctags would generate tags with line numbers and :ctags! would generate tags with search expressions. If there is any support for this and ghc team decides to merge it I can provide darcs patch. I can do changes needed to get it merged. Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GADT record syntax and contexts
From the perspective of someone who doesn't use GADT's much, I find (B) to be more clear. John Lato SPJ wrote: Question for everyone: * are (A) and (B) the only choices? * do you agree (B) is best ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: better generation of vi ctags in ghci
Claus Reinke wrote:
Haskell isn't like other languages. If you search on source lines of
definitions, that'll break every time you change a pattern, parameter
name, parameter order, clause order, ..
This is what I do. The whole line is searched to avoid as much of false
positives as possible. So far I did not get any false positive in my
code with this approach.
; if you search on less than the full line, you get additional
misleading matches, especially because you
can only search forward or backward, not both (also, the fallback of
/^tag/ won't work for infix operators, classes, data, ..).
Ideally, one (well, I at least;-) would like a mixed approach: start with
source line, figure out if the line is right, if yes, done, if not,
then search
(starting from the old position). But that seemed to be beyond posix
tags, so I stuck with line numbers.
I tried some form of that (set position before the expected loction
before searching). It could be done better but then the tag file would
get big (inline all the code for each tag, or we would need some
functions defined outside of the tags file). Anyway the reason I dropped
this was that my vim did not parse this file correctly and tag kinds (as
defined in the vim tags file) were not shown in the :tselect list. So I
decided it is not worth it for now. It would be cool to have something
better but I do not know whether it is possible aside from just writing
an interactive compiler (something like yi people are trying - I do not
know how far did they get).
* All top level symbols defined in a module are added to the tags
file. Even the non-exported ones. These are marked as static (file:)
so the default tag selection (Ctrl-]) works fine based on the file
you started the search from.
Thanks, I had meant to do this, don't know why I didn't (you use the new
static tag format, not the old, I assume?).
I use the latest format:
{tagname} {TAB} {tagfile} {TAB} {tagaddress} {term} {field} ..
Where {tagaddress} is a search expression looking for whole lines.
* Tags get kinds added so you can select whether you want to get to a
type constructor or a data constructor (that is if you share names
between the two).
You mean 'kind' in the tags file sense, using it to record namespace,
similar to haddock's t/v distinction?
I mean kind in the tags file sense. I do not know about haddock's t/v
distinction so I cannot compare to it.
So far I use:
* v (varId),
* t (typeCon),
* d (dataCon),
* c (class).
* In general it is a nice addition to vim haskellmode. If you search
for help on symbols in libraries then opening haddock is cool. If you
search for help on a symbol in your project then opening the tag in a
preview window (Ctrl-W} or ptselect) is cool.
That's why I suggested the addition in the first place!-) Thanks for
taking it further.
NP, it is great! I did not know there is at least one more person
wanting better tags. I did not even know about ghctags. Otherwise I
would probably just use them if they are any good (generate non-exported
symbols too and use search patterns instead of the line numbers ... so
they are at least a bit useful after some edits). Ok, the reason I care
about tags to be useful after some edits is that for some of my files it
takes some time to compile them in ghci. And I don't want to think
about regenerating them regularly. Now I need to regenerate them only
when the tag cannot be located or it found an incorrect place (which did
not happen to me yet).
for GHC's sources, which GHCi :ctags couldn't, last time I tried). A
secondary issue was what to do with non-interpreted modules
(probably: just skip, and rely on them having their own tags files).
Skipping is fine with me.
* If your code happens to have definitions on lines which happen to
exist more times in one source file then it may put you at an
incorrect location. I doubt it will ever happen but if anybody thinks
it is really bad we can keep the original format of vim tags too.
Then e.g. :ctags would generate tags with line numbers and :ctags!
would generate tags with search expressions.
See above for other things that can go wrong with search-based tags,
so I'd prefer to have both options.
Ok, I can add it. Generating line numbers instead of search patterns
will be quicker too. For big projects, the time difference may be
noticeable.
So what about UI? :ctags would generate tags with line numbers and
:ctags! would generate tags with search patterns? Or will we add an
argument to :ctags to specify what kind of tags we want? This option
would break ghci UI backward compatibility.
Peter.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: --out-implib when linking shared libraries
Hi Following up on a slightly old thread, it seems that the use of --out-implib is unnecessary for my purposes and generates 50Mb of .dll.a files. I'm also concerned that the generation of these .dll.a files may be taking considerable time (in the range of minutes). I'd like to disable the flags, using things such as -optl, but can't figure out how. The best I've come up with is: -optl=-Wl,--opt-implib=nul When doing this is generates the implib to nul, instead of to a file. That saves me 10 seconds and 50Mb of disk space, but I suspect if I could properly eliminate the opt-implib flag I'd save a significant chunk more time. Is there any way to override implib so it doesn't even try to generate it? Given Krasimir's comments, could this bug changed in a future version of GHC? Thanks, Neil On Sat, May 16, 2009 at 1:22 PM, Krasimir Angelovkr.ange...@gmail.com wrote: I remember that the .dll.a libraries that GCC produces are not always compatible with MSVC. Sometimes it works if you rename them to .lib but sometimes it doesn't. It is much more realiable to create .lib from .def file via some of the MS tools. If GCC can link dynamic libraries without using the static library then it might be good idea not to build the import libraries at all. Regards, Krasimir On Sat, May 16, 2009 at 1:26 PM, Duncan Coutts duncan.cou...@worc.ox.ac.uk wrote: On Sat, 2009-05-16 at 11:07 +0100, Neil Mitchell wrote: I don't, although having that option wouldn't be a bad thing - having a minimal .lib is perfectly reasonable as a default. Having a massive .lib seems crazy. (The fact that .lib is named .dll.a isn't too much of an issue) It's possible to create a minimal import lib via a .def file (which lists the exports). I think the dlltool helps with that. So my suggestion is remove it, if you're linking using gcc it should work. I'm not linking the .dll at all, only using dynamic linking, which works without the .lib. But I don't really want to start removing files - doing that in a build system seems like a bad idea. Sure, so at least you don't have to install them. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Three patches for cabal
On Wed, 2009-06-03 at 16:41 +0200, Niklas Broberg wrote: Second there's the constructor NoMonoPatBinds, which actually describes the default Haskell 98 behavior, even if GHC has a different default. It's GHC's behavior that is the extension, so the constructor in cabal should really be named MonoPatBinds. Also, the PatternSignatures constructor has been deprecated in GHC and superceded by ScopedTypeVariables. The attached patches (three in one file) adds the proposed new constructors, deprecates the old ones, and adds documentation. Can someone please comment on these two proposed changes. I agree with Niklas but I'm a bit reluctant to apply the patches without at least some sign of agreement from someone else. Deprecating PatternSignatures seems uncontroversial, but the NoMonoPatBinds is potentially controversial. GHC essentially uses -XMonoPatBinds by default, even in H98 mode, and the user can use -XNoMonoPatBinds to restore H98 behaviour. Niklas's and my point is that the list of language extensions in Language.Haskell.Exceptions are differences from H98 so it should be MonoPatBinds to get the difference not NoMonoPatBinds to restore H98. In practise, since ghc uses MonoPatBinds by default it'd mean that people who want to get back to H98 would need to use: ghc-options: -XNoMonoPatBinds Because the extensions field is additive, not subtractive. Using the name MonoPatBinds allows other compilers to implement it without it having to be the default. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] Re: Top Level
Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote: The Yampa people and I (the Grapefruit maintainer) already agreed to introduce a top-level FRP namespace instead of putting FRP under Control or whatever. The problem with a top-level namespace like FRP is that it is a cryptic acronym: it means nothing to a novice, and may be easily confused with other acronyms by an expert. I believe top-level names should _at_the_ _very_least_ be minimally descriptive of the category of things that live in it. So, I'd be fine with Control.Reactive.FRP, Control.Reactive.Yampa, etc, or even just Reactive.Yampa etc. I do understand that hierarchical classification is inherently problematic, and will never quite fit the ways we think of our modules. But the alternative being proposed here is neither more descriptive, nor more logical. In fact, it is an abandonment of description, in favour of arbitrary naming. A package called foo-1.0 containing a module hierarchy rooted at Foo. tells me precisely nothing about its contents. It it were rooted at Military.Secret.Foo, at least I would have some clue about what it does, even if the category is inadequate or slightly misleading in certain circumstances. You may argue that only novices are disadvantaged by arbitrary names - once you learn the referent of the name, it is no longer confusing. However, I strongly believe that even experienced users are helped by the continuous re-inforcement of visual links between name and concept. After all, if you are collaboratively building a software artifact that depends on large numbers of library packages, it may not be so easy to keep your internal dictionary of the mapping between names and functionality up-to-date, and in sync with your colleagues. Being just a little bit more explicit in the hierarchy is a one-time cost at time of writing, that reaps perceptual benefits long into the future for yourself, and those maintainers who will follow you. Regards, Malcolm ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Top Level
Malcolm Wallace wrote: Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote: The Yampa people and I (the Grapefruit maintainer) already agreed to introduce a top-level FRP namespace instead of putting FRP under Control or whatever. The problem with a top-level namespace like FRP is that it is a cryptic acronym: it means nothing to a novice, and may be easily confused with other acronyms by an expert. I believe top-level names should _at_the_ _very_least_ be minimally descriptive of the category of things that live in it. So, I'd be fine with Control.Reactive.FRP, Control.Reactive.Yampa, etc, or even just Reactive.Yampa etc. Besides, it hardly seems necessary to emphasize Functional and Programming in the Haskell context... ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANN: haskell-src-exts 1.0.0 rc1 (aka 0.5.2)
On Jun 17, 2009, at 12:43 AM, Niklas Broberg wrote: Testing it is really easy, four simple steps: cabal install haskell-src-exts [...] ghci [...] Prelude :m Language.Haskell.Exts Prelude Language.Haskell.Exts parseFile YourFileHere.(l)hs This script may even simplify testing of large code bases: --- #! /usr/bin/env runhaskell import System import System.IO import Data.Char import Language.Haskell.Exts import Prelude hiding ( catch ) import Control.Exception ( catch, SomeException ) main = getArgs = mapM_ parse where parse file = do hSetBuffering stdout NoBuffering putStr $ file ++ : catch (parseFile file = putStr . check) $ \e - print (e :: SomeException) where check (ParseOk _) = replicate (2+length file) '\b' check (ParseFailed loc msg) = unlines [err] where err = msg ++ at ++ show (srcLine loc) ++ : ++ show (srcColumn loc) --- After making it executable you can run it as shell script and pass names of Haskell files -- (something like) this will check all Haskell files (literate or not) in your home directory: find ~ -name *hs | xargs parse-haskell.lhs Cheers, Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.) ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANN: haskell-src-exts 1.0.0 rc1 (aka 0.5.2)
Hi Sebastian, This script may even simplify testing of large code bases: Thanks a lot, very useful! I'll add that to the darcs repository if you don't mind. :-) Cheers, /Niklas ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Re: [Haskell] ANN: haskell-src-exts 1.0.0 rc1 (aka 0.5.2)
On Jun 17, 2009, at 1:00 PM, Niklas Broberg wrote: Thanks a lot, very useful! I'll add that to the darcs repository if you don't mind. :-) feel free! Here is a cleaned-up and updated version that can also read from stdin: #! /usr/bin/env runhaskell import Language.Haskell.Exts import System( getArgs ) import System.IO ( hGetContents, stdin ) import Prelude hiding( catch ) import Control.Exception ( catch, SomeException ) main :: IO () main = do args - getArgs input - hGetContents stdin mapM_ parse (args ++ lines input) where parse file = catch (parseFile file = check) $ \e - putStrLn $ file ++ : ++ show (e::SomeException) check :: ParseResult a - IO () check (ParseOk _) = return () check (ParseFailed loc msg) = putStrLn err where err = srcFilename loc ++ : ++ msg ++ at ++ show (srcLine loc) ++ : ++ show (srcColumn loc) -- Underestimating the novelty of the future is a time-honored tradition. (D.G.) PGP.sig Description: This is a digitally signed message part ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [HOpenGL] Re: [Haskell] ANNOUNCE: OpenGLRaw 1.0.0.0
On Fri, Jun 12, 2009 at 2:24 AM, Sven Panne sven.pa...@aedion.de wrote: A few final remarks: Leaving out Graphics. completely would be a very bad idea, the naming hierarchy should reflect the underlying conceptual hierarchy. The only problem with hierarchies in general is that sometimes the position in it is not very clear. Clay Shirky's points in include that this sometimes is more like nearly always, and that the heart of the problem is the in the position (in a hierarchy). This problem and others discussed at http://www.shirky.com/writings/ontology_overrated.html . I have e.g. never fully understood why Monad and Applicative are below Control, but Foldable is below Data... Monoid as well. Type classes in general cut across distinctions like Control and Data, so I don't think we'll ever have a comfortable place to put them in the existing hierarchy. If anything, I recommend the top-level name Class. - Conal ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: ANN: haskell-src-exts 1.0.0 rc1 (aka 0.5.2)
Hi all,
This means I feel ready to take that scary leap that means to drop the
safe 0.x version numbering (experimental) and finally make the first
stable release, version 1.0.0. But before I take that leap I want the
library to be thoroughly tested, so I can with confidence say that it
truly *is* stable. Therefore, I hereby announce the release on hackage
of haskell-src-exts-0.5.2, which I consider (almost) a release
candidate for 1.0.0.
I have just uploaded haskell-src-exts-0.5.4 to hackage, which is 1.0.0
rc2. Thanks a lot to those who tested the previous version, and please
continue to test and report!
Changes in 0.5.4:
==
Three fixed bugs:
* BangPatterns are now parsed correctly in function bindings.
* Single-item class contexts are now accepted with parenthesis around
them (doh!).
* The haddock documentation (paltry as it is) can now be built. Thanks
a lot to Brian Lewis for the patch, which rearranges my commented
guard clause. Haddock apparently didn't like the '{- | guard = ...'
line...
One new feature:
* The parseFileX family of functions now all recognize and act on
LANGUAGE pragmas (previously only parseFile did). There is now also an
extra field in the ParseMode called 'ignoreLanguagePragmas', which
defaults to False. Set it to True if you really want parseFile et al
to disregard LANGUAGE pragmas. (Note that you can always use the
simple 'parse' function that doesn't try to be clever at all.)
Cheers,
/Niklas
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Performance of functional priority queues
Richard O'Keefe wrote: There's a current thread in the Erlang mailing list about priority queues. I'm aware of, for example, the Brodal/Okasaki paper and the David King paper. I'm also aware of James Cook's priority queue package in Hackage, have my own copy of Okasaki's book, and have just spent an hour searching the web. One of the correspondents in that thread claims that it is provably impossible to have an efficient priority queue implementation without mutability. I think he's cuckoo. But I'd like to have some numbers to back me up. Sounds cuckoo to me until I see a proof otherwise. I've seen a few proof sketches indicating that immutable approaches can always be no worse than a O(log n) multiple of imperative ones (by simulating main memory with your O(log n) map of choice). Between this and the provable asymptotic optimality of skewed binomial heap prioqueues, the argument sounds untenable. Though it really comes down to what they mean by efficient. Asymptotic complexity is the name of the game for most folks in algorithms and datastructures, but that seems not to be what they're after. Shrinking the constant factors is frequently a game that can go on forever, or rather can seldom be proved not to, so the claim seems unlikely to be meaningful in this arena either (you'd have to prove you've found the smallest possible constant factor for any immutable approach, and then find a smaller one for some mutable approach). Also proofs about constant factors beyond basic thresholds aren't useful in practice due to hardware barriers like cache size and disk access times. There's also the difference between compilers that are designed to optimize immutable patterns, vs ones which aren't. For example, in certain circumstances and with suitable annotations Clean will take the immutable approach and convert it into a mutable variant for you, thus saving on allocation/collection/cache-miss overheads while maintaining the spirit of immutability. Is compiled code like this considered mutable or immutable? It all depends on the spirit of the question. Can anyone point me to some actual benchmark results comparing priority queue performance *with* mutation and priority queue performance *without* mutation, in the same functional or mostly-functional language? I'm always curious to see datastructure benchmarks though :) -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Android and Haskell
Vasili I. Galchin wrote: I was just reading a Linux Mag article on Android and scripting. The underlying OS is Linux? Yes, as is the OS for the new Palm Pre. Python is one of the scripting languages. http://code.google.com/p/android-scripting/ ... Is Python one of the supported languages simply because it (I think) has JVM bindings? There is something called Jython which is Python on the JVM, but I don't think its widely used in comparison to standard Python which has its own VM written on C. I would be somewhat suprised if Python on andriod was Jython rather than native Python. My bottom line question is what is preventing Haskell98 from running on Android if Python can? Well if the android phones have a JVM then something like OpenQuark should do the trick. http://openquark.org/Open_Quark/Welcome.html Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need some help with an infinite list
Reid Barton wrote: I'm surprised everyone is giving clever recursive solutions rather than concatMap (\n - replicateM n ['a'..'z']) [1..] Regards, Reid Well, you've lost efficient sharing with respect to my previous solution and one other. But it's a fair call, so... tail $ concat $ iterate (map (:) ['a'..'z'] *) [[]] Regards, Matthew ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Catering for similar operations with and without state
Hi Phil, On Mon, Jun 15, 2009 at 5:23 PM, Phil p...@beadling.co.uk wrote: Hi, I'm trying to think around a problem which is causing me some difficulty in Haskell. I'm representing a stateful computation using a State Transform - which works fine. Problem is in order to add flexibility to my program I want to performs the same operation using different techniques - most of which require no state. My program at the moment is a stack of state monads/transforms. I have a random number generator as a state monad (seed=state), feeding a Box Muller (normal) generator implemented as a state transform (state is 'maybe' normal, so it only spits out 1 normal at a time), which in turn feeds another state machine. This all works fine, but I want to add flexibility so that I can chop and change the Box Muller algorithm with any number of other normal generators. Problem is most of them do not need to carry around state at all. This leaves me with a messy solution of implementing lots of state monads that don't actually have a state, if I want to maintain the current paradigm. This strikes me as really messy - so I'm hoping someone can point me in the direction of a more sensible approach? I'm interested in how you solve this, but I didn't see any replies yet so I thought I would toss in my thoughts. Currently I have my Box Muller implemented as below - this works: class NormalClass myType where generateNormal :: myType Double This type class might be at the heart of your difficulties. I think it requires myType to have kind * - * and it doesn't specify what the input to generateNormal should be. I also notice you're not using it later in the example code which is another warning sign. type BoxMullerStateT = StateT (Maybe Double) type BoxMullerRandomStateStack = BoxMullerStateT MyRngState You used 'type' here, but I bet you want 'newtype' with the newtype deriving feature/extension. Otherwise, this nice neat stack of transformers that you have is fixed to just one instance of NormalClass, but I suspet you may have multiple ways to generateNormal that use the same stack of transformers. instance NormalClass BoxMullerRandomStateStack where generateNormal = StateT $ \s - case s of Just d - return (d,Nothing) Nothing - do qrnBaseList - nextRand let (norm1,norm2) = boxMuller (head qrnBaseList) (head $ tail qrnBaseList) return (norm1,Just norm2) But say I have another instance of my NormalClass that doesn't need to be stateful, that is generateNormal() is a pure function. How can I represent this without breaking my whole stack? I've pretty much backed myself into a corner here as my main() code expects to evalStateT on my NormalClass: main = do let sumOfPayOffs = evalState normalState (1,[3,5]) -- (ranq1Init 981110) where mcState = execStateT (do replicateM_ iterations mc) 0 normalState = evalStateT mcState Nothing If it is useful to define generateNormal, then why don't you use it here? What if we go back to your NormalClass type class and redesign it? If we add a parameter to the type class which depends on the way you implement generateNormal I think we'd be most of the way there. I'm also going to remove the explicit 'Double', and let that be part of the type of 'myType'. Untested, but I think this is the syntax for using multiparameter type classes and functional dependencies: class NormalClass seed myType | myType - seed where generateNormal :: seed - myType type Seed = ... -- Whatever type the seed has currently instance NormalClass Seed (Maybe Double) where generateNormal seed = evalState (StateT $ \s - case s of Just d - return (d,Nothing) Nothing - do qrnBaseList - nextRand let (norm1,norm2) = boxMuller (head qrnBaseList) (head $ tail qrnBaseList) return (norm1,Just norm2)) seed -- An arbitrary 'pure' example instance NormalClass () Double where generateNormal () = 1.0 Ah, now I see a problem with this approach. You'll end up putting a newtype on the return value of generateNormal just to allow different instances. I sort of feel like the way things are designed we are assuming we have subtyping, but Haskell doesn't have that. If it wasn't for this I was thinking about implementing the IdentityT transformer to provide a more elegant pass-through. I've never tried designing my own Monad from scratch but this crossed my mind as another possibillity - i.e. a Monad that either has a state of maybe double, or has no state at all? I have a feeling I'd just 'return' the pure computations into the state monad. My example code above seems weird and heavy weight to me. I'd love to see what you figure you. Jason
Re: [Haskell-cafe] Android and Haskell
On Wed, Jun 17, 2009 at 4:31 PM, Erik de Castro Lopo mle...@mega-nerd.commle%2...@mega-nerd.com wrote: Well if the android phones have a JVM then something like OpenQuark should do the trick. The Android phones actually have a different VM which essentially takes compiled/translated java bytecode. http://en.wikipedia.org/wiki/Dalvik_virtual_machine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Wiki user accounts
On Wed, Jun 17, 2009 at 4:36 AM, Ashley Yakeleyash...@semantic.org wrote: OK, the people listed here have been given the ability to create accounts: http://haskell.org/haskellwiki/?title=Special%3AListusersgroup=createaccount Thanks! If you want to let people know that you can do this for them, add your email address here: http://haskell.org/haskellwiki/HaskellWiki:New_accounts I've added my name on that page (and re-arranged it a little). /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Android and Haskell
Right now you're best bet if you want to program Android in a functional style is to use Scala which has an Android target. ___ 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] slow code
brian bri...@aracnet.com writes: However, I would like to reiterate that it's the double - string which is really the time/memory sink. I verified this by printing a simple string based on the value (to make sure the value was evaluated) and it runs fast enough for me. Is there an efficient way to output double - binary ? Not as far as I know. I had the same problem, and ended up building a array of float representations: farray :: Array Int ByteString farray = listArray (0,) [B.pack (showFFloat (Just 2) i ) | i - [0,0.01..99.99::Double]] and using a lookup function to show the floats: fi :: Int - ByteString fi f | f = f = 0 = farray!f | otherwise = error (Can't show a value of ++show f) This works for me, since I have a very limited range of Doubles to deal with (stored as fixed-precision Ints). Still, a fast and general way to output primitive data types would be quite welcome. -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] Re: Unicode workaround for getDirectoryContents under Windows?
On 16/06/2009 21:19, Bulat Ziganshin wrote: Hello Simon, Tuesday, June 16, 2009, 5:02:43 PM, you wrote: I don't know how getArgs fits in here - should we be decoding argv using the ACP? myGetArgs = do alloca $ \p_argc - do p_argv_w- commandLineToArgvW getCommandLineW p_argc argc- peek p_argc argv_w- peekArray (i argc) p_argv_w mapM peekTString argv_w= return.tail foreign import stdcall unsafe windows.h GetCommandLineW getCommandLineW :: LPTSTR foreign import stdcall unsafe windows.h CommandLineToArgvW commandLineToArgvW :: LPCWSTR - Ptr CInt - IO (Ptr LPWSTR) Right, so getArgs is already fine. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Unicode workaround for getDirectoryContents under Windows?
On 16/06/2009 17:06, Bulat Ziganshin wrote: Hello Simon, Tuesday, June 16, 2009, 7:54:02 PM, you wrote: In fact there's not a lot left to convert in System.Directory, as you'll see if you look at the code. Feel like helping? these functions used there are ACP-only: c_stat c_chmod System.Win32.getFullPathName c_SearchPath c_SHGetFolderPath Yes, except for getFullPathName: foreign import stdcall unsafe GetFullPathNameW c_GetFullPathName :: LPCTSTR - DWORD - LPTSTR - Ptr LPTSTR - IO DWORD plus may be some more functions from System.Win32 package - i don't looked into it System.Win32 is using the wide-char APIs exclusively (ok, I haven't checked, but I don't know of any System.Win32 functions still using narrow strings). So as you can see, there's not much left to do. I'll fix openFile. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
Thomas Davie wrote: Not at all, as discussed, there are legitimate uses for a lazy sum, and haskell is a lazy language by default. Haskell is lazy by default, and we have found that to be a big win in most cases. So we don't need to be embarrassed to use strictness when that is the right thing to do. While there are indeed certain very rare situations in which you want foldr or foldl for sum, they are both joltingly wrong as the default for typical usage. In practice, I find this to be a small annoyance that occurs so often that it becomes a major one. Can we please fix it already? Let it be noted that this discussion also applies to product. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re: Unicode workaround for getDirectoryContents under Windows?
Hello Simon, Wednesday, June 17, 2009, 11:55:15 AM, you wrote: Right, so getArgs is already fine. it's what i've found in Jun15 sources: #ifdef __GLASGOW_HASKELL__ getArgs :: IO [String] getArgs = alloca $ \ p_argc - alloca $ \ p_argv - do getProgArgv p_argc p_argv p- fromIntegral `liftM` peek p_argc argv - peek p_argv peekArray (p - 1) (advancePtr argv 1) = mapM peekCString foreign import ccall unsafe getProgArgv getProgArgv :: Ptr CInt - Ptr (Ptr CString) - IO () it uses peekCString so by any means it cannot produce unicode chars -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Unicode workaround for getDirectoryContents under Windows?
On 17/06/2009 09:38, Bulat Ziganshin wrote: Hello Simon, Wednesday, June 17, 2009, 11:55:15 AM, you wrote: Right, so getArgs is already fine. it's what i've found in Jun15 sources: #ifdef __GLASGOW_HASKELL__ getArgs :: IO [String] getArgs = alloca $ \ p_argc - alloca $ \ p_argv - do getProgArgv p_argc p_argv p- fromIntegral `liftM` peek p_argc argv- peek p_argv peekArray (p - 1) (advancePtr argv 1)= mapM peekCString foreign import ccall unsafe getProgArgv getProgArgv :: Ptr CInt - Ptr (Ptr CString) - IO () it uses peekCString so by any means it cannot produce unicode chars I see, so you were previously quoting code from some other source. Where did the GetCommandLineW version come from? Do you know of any issues that would prevent us using it in GHC? Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re: Unicode workaround for getDirectoryContents under Windows?
Hello Simon, Wednesday, June 17, 2009, 12:01:11 PM, you wrote: foreign import stdcall unsafe GetFullPathNameW c_GetFullPathName :: LPCTSTR - DWORD - LPTSTR - Ptr LPTSTR - IO DWORD you are right, i was troubled by unused GetFullPathNameA import in System.Directory: #if defined(mingw32_HOST_OS) foreign import stdcall unsafe GetFullPathNameA c_GetFullPathName :: CString - CInt - CString - Ptr CString - IO CInt #else foreign import ccall unsafe realpath c_realpath :: CString - CString - IO CString #endif So as you can see, there's not much left to do. I'll fix openFile. c_stat is widely used here and there. it may be that half of System.Directory functions is broken due to direct or indirect calls to this function -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re: Unicode workaround for getDirectoryContents under Windows?
Hello Simon, Wednesday, June 17, 2009, 12:46:49 PM, you wrote: I see, so you were previously quoting code from some other source. from my program Where did the GetCommandLineW version come from? Do you know of any issues that would prevent us using it in GHC? it should be as fine as any other *W calls. the only thing is that we may prefer to include in into Win32 package as other routines and then call from there -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need some help with an infinite list
On Wed, 17 Jun 2009, Richard O'Keefe wrote: On 17 Jun 2009, at 2:01 pm, Richard O'Keefe wrote: On second thoughts, let strings = : [pref++[last] | pref - strings, last - ['a'..'z']] in tail strings last:pref instead of pref++[last] should do more sharing. You can also write it this way: let strings = : Monad.liftM2 (flip (:)) strings ['a'..'z'] in tail strings ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] (fwd) Haskell logo fail
On Tue, 16 Jun 2009 14:06:42 -0700 (PDT), in comp.lang.haskell Robert Hicks sigz...@gmail.com wrote: http://blog.plover.com/prog/haskell/logo.html From the site referenced at the above-mentioned URL: Tue, 16 Jun 2009 Haskell logo fail The Haskell folks have chosen a new logo. image of new Haskell logo image of Amtrak logo ouch The two logos do look disturbingly similar -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 Furuike ya, kawazu tobikomu mizu no oto. -- Matsuo Basho^ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need some help with an infinite list
On Wed, 17 Jun 2009, Matthew Brecknell wrote: Reid Barton wrote: I'm surprised everyone is giving clever recursive solutions rather than concatMap (\n - replicateM n ['a'..'z']) [1..] Regards, Reid Well, you've lost efficient sharing with respect to my previous solution and one other. But it's a fair call, so... tail $ concat $ iterate (map (:) ['a'..'z'] *) [[]] cool ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (fwd) Haskell logo fail
Benjamin L.Russell wrote: image of new Haskell logo image of Amtrak logo ouch The two logos do look disturbingly similar This is nothing new. From [1]: Amtrak changed their logo in 2000; the old logo looked like =. Martijn. [1] http://www.mail-archive.com/haskell-cafe@haskell.org/msg56376.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Which windowing toolkit to use?
Hi all, I intend to start coding the UI of the heap profiling toolkit I'm working on [1] soon. I'd be happy to get some advice on choosing the right windowing toolkit for this task. The main requirements are: - portability and native look feel if possible - easy to distribute executables under Windows - relatively slow code rot - sane interface that doesn't need wild workarounds even if what I'm doing is not trivial or elementary - trouble-free source installation in case someone wants to contribute As I see, at the moment there's no serious alternative besides GTK and wx, so my question is which do you think is better suited to this task? I have absolutely no development experience with GTK, and while I used a bit of wx in the past (in C++), I'm not really familiar with it either, especially not the Haskell bindings. I noticed that installing the wx binding with user rights doesn't seem to work directly from hackage (doesn't pass --user to ghc-pkg?), but it looks like a problem that can be solved with some hand editing. I'm a bit more afraid of setting up a development environment under Windows; is there any major pain involved with either of these libraries if I use MinGW? And how about their interface? Is there any significant difference? I'd especially like to hear the opinion of someone who's reasonably familiar with both. Thanks, Gergely [1] http://code.google.com/p/hp2any/ -- http://www.fastmail.fm - Or how I learned to stop worrying and love email again ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANN: haskell-src-exts 1.0.0 rc1 (aka 0.5.2)
On Jun 17, 2009, at 12:43 AM, Niklas Broberg wrote: Testing it is really easy, four simple steps: cabal install haskell-src-exts [...] ghci [...] Prelude :m Language.Haskell.Exts Prelude Language.Haskell.Exts parseFile YourFileHere.(l)hs This script may even simplify testing of large code bases: --- #! /usr/bin/env runhaskell import System import System.IO import Data.Char import Language.Haskell.Exts import Prelude hiding ( catch ) import Control.Exception ( catch, SomeException ) main = getArgs = mapM_ parse where parse file = do hSetBuffering stdout NoBuffering putStr $ file ++ : catch (parseFile file = putStr . check) $ \e - print (e :: SomeException) where check (ParseOk _) = replicate (2+length file) '\b' check (ParseFailed loc msg) = unlines [err] where err = msg ++ at ++ show (srcLine loc) ++ : ++ show (srcColumn loc) --- After making it executable you can run it as shell script and pass names of Haskell files -- (something like) this will check all Haskell files (literate or not) in your home directory: find ~ -name *hs | xargs parse-haskell.lhs Cheers, Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Runtime strictness analysis for polymorphic HOFs?
Dear Paul,
This thread as well as your blog post is very interesting. Hopefully I
can add something more or less valuable to it.
On your blog, you mention that your scheme for run-time strictness
analysis doesn't work out because it'll have you force a function
first before you can find out about its strictness. I guess this can
be easily overcome by separating the function from the strictness
information it carries.
One way to do this, would be by storing strictness information in the
type of a function. Actually, this is exactly what type-based
approaches to strictness analyses do. So, for example, an extended
type of the function const,
const :: a - b - a
const x y = x
could read
a - {S} - b -{L} a
Here, we have annotated the function-space constructor (-) with
information about whether the corresponding function is strict or lazy
in its argument. Indeed, const is lazy in its first argument and lazy
in its second. (Note that this is very simple take on storing
strictness information in types: there is plenty more to say about it,
but I will refrain from that.)
An annotated type like the one above can be easily inferred by a
strictness analyser. But what exactly is type inference? Well, one way
to look at it is a means to reconstruct typing information that was
left out from the program. For example, if we infer the type a - b -
a for the const function in Haskell, we are effectively completing the
definition of const with explicit type information. This information
can then be stored in the program. Using Java-like syntax:
const a b (x :: a) (y :: b) = x
So, now const takes two extra arguments, both of which are types
rather than values. When, calling a polymorphic function, type
inference then computes the type arguments for a specific
instantiation of the polymorphic function:
const 2 'x'
becomes
const Int Char 2 'x'
While typing information can proof valuable to have around at compile
type, we don't actually want types to be passed around at run time.
Luckily, in Haskell no run-time decisions can be made based on these
type arguments, so all these extra abstractions and applications can
be erased when generating code for a program.
Pretty much the same holds for the strictness annotations that are
inferred by a strictness analyser. Inferring strictness can be thought
of as decorating the program. For instance, for const we get something
like:
const a b (x :: a{S}) (y :: b{L}) = x
where a {S} indicates strictness and {L} laziness.
Viewing strictness annotations as types, a natural step is to allow
functions to be polymorphic in their strictness annotations as well.
This is especially useful for higher-order functions. The function
apply, for example,
apply :: (a - b) - a - b
apply f x = f x
is supposed to work on both strict and lazy functions. Moreover,
depending on whether we pass it a strict or a lazy function as its
first argument, it becomes, respectively, strict or lazy in its second
argument. This insight can be captured quite nicely by means of a type
that is polymorphic in its strictness annotations:
(a -{i} b) -{S} -{i} b
Here, i is a strictness variable that is to be instantiated with
either S or L. Decorating the definition of apply may now yield
something like
apply a b {i} (f :: (a -{i} b){S}) (x :: a{i})
Of course, just as with ordinary types, strictness annotations don't
have to be passed around at run-time: they can be erased from the
program and all that are made based on strictness information can then
be made at compile time.
But what if we don't erase these annotations? Then we can use
strictness information to participate in run-time decisions as well---
just as you proposed. Let's explore that idea.
Performing strictness analysis on foldl,
foldl :: (b - a - b) - b - [a] - b
foldl f e [] = e
foldl f e (x : xs) = foldl f (f e x) xs
we find the annotated type
(b -{i} -{j} b) -{L} b -{i} [a] -{S} - b
Indeed, whether foldl is strict in its second argument depends on
wether its first argument is strict in its own first argument. Let's
decorate the definition of foldl accordingly:
foldl a b {i} {j} (f :: (b -{i} -{j} b){L}) (e :: b{i}) (l ::
[a]{S}) =
case l of
[] - e
x : xs - foldl a b {i} {j} f (f e x) xs
Allright, that's messy, but bear with me. (At this point, we could
erase the type arguments and only keep the strictness arguments for we
only want the latter to play a role at run time, but let's keep them
both, just to be uniform.)
Now, let's apply the foldl to (+), 0, and [1 .. 100] assuming that
(+) is strict in both its arguments and specialised to Int,
(+) :: Int -{S} Int -{S} Int
and let's pass in the arguments in three steps. First we pass in the
type arguments:
foldl Int Int :: (Int -{i} Int -{j} Int) -{L} Int -{i}
[Int] -{S} Int
Then the strictness
Re: [Haskell-cafe] Which windowing toolkit to use?
Web - HTML 2009/6/17 Patai Gergely patai_gerg...@fastmail.fm Hi all, I intend to start coding the UI of the heap profiling toolkit I'm working on [1] soon. I'd be happy to get some advice on choosing the right windowing toolkit for this task. The main requirements are: - portability and native look feel if possible - easy to distribute executables under Windows - relatively slow code rot - sane interface that doesn't need wild workarounds even if what I'm doing is not trivial or elementary - trouble-free source installation in case someone wants to contribute As I see, at the moment there's no serious alternative besides GTK and wx, so my question is which do you think is better suited to this task? I have absolutely no development experience with GTK, and while I used a bit of wx in the past (in C++), I'm not really familiar with it either, especially not the Haskell bindings. I noticed that installing the wx binding with user rights doesn't seem to work directly from hackage (doesn't pass --user to ghc-pkg?), but it looks like a problem that can be solved with some hand editing. I'm a bit more afraid of setting up a development environment under Windows; is there any major pain involved with either of these libraries if I use MinGW? And how about their interface? Is there any significant difference? I'd especially like to hear the opinion of someone who's reasonably familiar with both. Thanks, Gergely [1] http://code.google.com/p/hp2any/ -- http://www.fastmail.fm - Or how I learned to stop worrying and love email again ___ 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] Which windowing toolkit to use?
2009/6/17 Alberto G. Corona agocor...@gmail.com: Web - HTML I'd agree with that. It would be really nice for X-platform. Maybe it's possible to use JQuery (or Flapjax) to get some nice dynamic/interacitivity? /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Which windowing toolkit to use?
2009/6/17 Magnus Therning mag...@therning.org: 2009/6/17 Alberto G. Corona agocor...@gmail.com: Web - HTML I'd agree with that. It would be really nice for X-platform. Maybe it's possible to use JQuery (or Flapjax) to get some nice dynamic/interacitivity? Does someone know if it possible to make an application which embed webkit with: - webkit used for rendering and running javascript - javascript function calling haskell code ? Cheers, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANN: haskell-src-exts 1.0.0 rc1 (aka 0.5.2)
Hi Sebastian, This script may even simplify testing of large code bases: Thanks a lot, very useful! I'll add that to the darcs repository if you don't mind. :-) Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
On Wed, 17 Jun 2009 10:38:23 +0200, Yitzchak Gale g...@sefer.org wrote: While there are indeed certain very rare situations in which you want foldr or foldl for sum, they are both joltingly wrong as the default for typical usage. In practice, I find this to be a small annoyance that occurs so often that it becomes a major one. Can we please fix it already? Let it be noted that this discussion also applies to product. Thanks, Yitz I have done some research on functions in the base libraries, whether they can handle large lists; I didn't check them all, because there are so many of them. sum and product are certainly not the only ones having problems. For example: Hugs reverse [1 .. 99] ERROR - C stack overflow An improved reverse function: reverse' = foldl' (flip (:)) [] There is no need for reverse to be lazy, so this one could replace the original one. reverse' is not too strict: Data.List let reverse' = foldl' (flip (:)) [] in head $ reverse' [undefined, 1] 1 Some of the other functions that have problems with large lists are: foldM maximum minimum scanl scanr scanr1 iterate take(in GHCi, not in Hugs) drop(in GHCi, not in Hugs) splitAt (in GHCi, not in Hugs) inits By the way, sum and product are implemented with foldl' in Hugs. -- Met vriendelijke groet, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] curious about sum
Hello Henk-Jan, Wednesday, June 17, 2009, 3:07:41 PM, you wrote: I have done some research on functions in the base libraries, whether they can handle large lists long time ago i had problems with filterM, may be it's still fails -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
On Wed, Jun 17, 2009 at 1:07 PM, Henk-Jan van Tuylhjgt...@chello.nl wrote: On Wed, 17 Jun 2009 10:38:23 +0200, Yitzchak Gale g...@sefer.org wrote: An improved reverse function: reverse' = foldl' (flip (:)) [] There is no need for reverse to be lazy, so this one could replace the original one. reverse' is not too strict: Data.List let reverse' = foldl' (flip (:)) [] in head $ reverse' [undefined, 1] 1 Since reverse' is polymorphic in the type of list elements, the only way it could be strict in the *elements* is if it applied seq to them. --Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Need some help with an infinite list - Ouch
Hi all, you have come up with so many solutions it's embarrassing to admit that I didn't come up with even one. Günther Günther Schmidt schrieb: Hi guys, I'd like to generate an infinite list, like [a, b, c .. z, aa, ab, ac .. az, ba, bb, bc .. bz, ca ...] When I had set out to do this I thought, oh yeah no prob, in a heartbeat. Uhm. Help, pls! Günther PS: I know this should be a no-brainer, sry ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
Henk-Jan van Tuyl wrote: reverse maximum minimum Oh yes, please fix those also! scanl scanr scanr1 iterate take drop splitAt inits Hmm, I use those all the time with large lists. They are lazy as expected, and seem to work fine. Do you have examples of problems with them? foldM fliterM (Bulat) No opinion, I hardly use those. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Wiki user accounts
On Tue, 2009-06-16 at 19:57 -0400, Gwern Branwen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, Jun 16, 2009 at 7:16 PM, Ashley Yakeley wrote: Anyone else? Gwern? Philippa? As usual, I am User:Gwern. On the side-topic of a mailing list - I really think that is too heavy-weight. We want people to create a login (for the ML) and go through the ML, just to get wiki access? Who said anything about creating mailing list logins? Probably the easiest-for-user thing us a form that sends the mail for them. -- Philippa Cowderoy fli...@flippac.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Which windowing toolkit to use?
Web - HTML I'd agree with that. It would be really nice for X-platform. Maybe it's possible to use JQuery (or Flapjax) to get some nice dynamic/interacitivity? I'm not sure if a web interface is really a good fit here, but I'll think about it. Gergely -- http://www.fastmail.fm - Access all of your messages and folders wherever you are ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Unicode workaround for getDirectoryContents under Windows?
I wrote: I think the most important use cases that should not break are: o open/read/write a FilePath from getArgs o open/read/write a FilePath from getDirectoryContents Simon Marlow wrote: The following cases are currently broken: * Calling openFile on a literal Unicode FilePath (note, not ACP-encoded, just Unicode). * Reading a Unicode FilePath from a text file and then calling openFile on it I propose to fix these (on Windows). It will mean that your second case above will be broken, until someone fixes getDirectoryContents. Why only on Windows? I don't know how getArgs fits in here - should we be decoding argv using the ACP? And why not also on Unix? On any platform, the expected behavior should be that you type a file path at the command line, read it using getArgs, and open the file using that. For comparison, Python works that way, even though the variable is called argv there. The current behavior on Unix of returning, say, UTF-8 encoding characters in a String as if they were individual Unicode characters, is queer. Given your fantastic work so far to rid System.IO of those kinds of oddities, perhaps now is the time to finish the job. If you think we really need to provide access to the raw argv bytes, we could add another platform-independent function that does that. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Which windowing toolkit to use?
I use Haskell server pages and HJScript. HJScript includes ajax capabilities. and embed haskell code in HTML much like ASP and JSP embed VB and Java. The client side haskell code is converted to javascript and with ajax you can call Haskell server code. 2009/6/17 minh thu not...@gmail.com 2009/6/17 Magnus Therning mag...@therning.org: 2009/6/17 Alberto G. Corona agocor...@gmail.com: Web - HTML I'd agree with that. It would be really nice for X-platform. Maybe it's possible to use JQuery (or Flapjax) to get some nice dynamic/interacitivity? Does someone know if it possible to make an application which embed webkit with: - webkit used for rendering and running javascript - javascript function calling haskell code ? Cheers, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANN: haskell-src-exts 1.0.0 rc1 (aka 0.5.2)
On Jun 17, 2009, at 1:00 PM, Niklas Broberg wrote: Thanks a lot, very useful! I'll add that to the darcs repository if you don't mind. :-) feel free! Here is a cleaned-up and updated version that can also read from stdin: #! /usr/bin/env runhaskell import Language.Haskell.Exts import System( getArgs ) import System.IO ( hGetContents, stdin ) import Prelude hiding( catch ) import Control.Exception ( catch, SomeException ) main :: IO () main = do args - getArgs input - hGetContents stdin mapM_ parse (args ++ lines input) where parse file = catch (parseFile file = check) $ \e - putStrLn $ file ++ : ++ show (e::SomeException) check :: ParseResult a - IO () check (ParseOk _) = return () check (ParseFailed loc msg) = putStrLn err where err = srcFilename loc ++ : ++ msg ++ at ++ show (srcLine loc) ++ : ++ show (srcColumn loc) -- Underestimating the novelty of the future is a time-honored tradition. (D.G.) PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Unicode workaround for getDirectoryContents under Windows?
On 17/06/2009 13:21, Yitzchak Gale wrote: I wrote: I think the most important use cases that should not break are: o open/read/write a FilePath from getArgs o open/read/write a FilePath from getDirectoryContents Simon Marlow wrote: The following cases are currently broken: * Calling openFile on a literal Unicode FilePath (note, not ACP-encoded, just Unicode). * Reading a Unicode FilePath from a text file and then calling openFile on it I propose to fix these (on Windows). It will mean that your second case above will be broken, until someone fixes getDirectoryContents. Why only on Windows? Just because it's a lot easier on Windows - all the OS APIs take Unicode file paths, so it's obvious what to do. In contrast on Unix I don't have a clear idea of how to proceed. On Unix, all file APIs take [Word8] rather than [Char]. By convention, the [Word8] is usually assumed to be a string in the locale encoding, but that's only a user-space convention. So we should probably be converting from FilePath to [Word8] by encoding using the current locale. This raises various complications (what about encoding errors, and what if encode.decode is not the identity due to normalisation, etc.). But you don't have to wait for me to fix this stuff (I'm feeling a bit Unicoded-out right now :) If someone else has a good understanding of what needs done, please wade in. I don't know how getArgs fits in here - should we be decoding argv using the ACP? And why not also on Unix? On any platform, the expected behavior should be that you type a file path at the command line, read it using getArgs, and open the file using that. Right. On Unix it works at the moment because we neither decode argv nor encode FilePaths, so the bytes get passed through unchanged. Same with getDirectoryContents. But I agree it's broken and needs to be fixed. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Unicode workaround for getDirectoryContents under Windows?
Simon Marlow marlo...@gmail.com writes: Why only on Windows? Just because it's a lot easier on Windows - all the OS APIs take Unicode file paths, so it's obvious what to do. In contrast on Unix I don't have a clear idea of how to proceed. On Unix, all file APIs take [Word8] rather than [Char]. By convention, the [Word8] is usually assumed to be a string in the locale encoding, but that's only a user-space convention. If we want to incorporate a translation layer, I think it's fair to only support UTF-8 (ignoring locales), but provide a workaround for invalid characters. From http://en.wikipedia.org/wiki/UTF-8: | Therefore many modern UTF-8 converters translate errors to | something safe. Only one byte is changed into the error | replacement and parsing starts again at the next byte, otherwise | concatenating strings could change good characters into | errors. Popular replacements for each byte are: | |* nothing (the bytes vanish) |* '?' or '�' |* The replacement character (U+FFFD) |* The byte from ISO-8859-1 or CP1252 |* An invalid Unicode code point, usually U+DCxx where xx is the byte's value How about using the last one? This would allow 'readFile' to work on FilePaths provided by 'getDirectoryContents', while allowing for real Unicode string literals. -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] Re: Unicode workaround for getDirectoryContents under Windows?
Simon Marlow wrote: The following cases are currently broken... I propose to fix these (on Windows). It will mean that your second case above will be broken, until someone fixes getDirectoryContents... ...it's a lot easier on Windows... on Unix I don't have a clear idea of how to proceed... If someone else has a good understanding of what needs done, please wade in. I don't know how getArgs fits in here... I agree it's broken and needs to be fixed. OK, would you like me to reflect this discussion in tickets? Let's see, so far we have #3300, I don't see anything else. Do you want two tickets, one each for WIndows/Unix? Or four, separating the FilePath and getArgs issues? On Unix, all file APIs take [Word8]... So we should probably be converting from FilePath to [Word8] by encoding using the current locale... what about encoding errors, Where relevant, we should emulate what the common shells do. In general, I don't see why they should be different than any other file operation error. and what if encode.decode is not the identity due to normalisation Well, is it common for people using typical input methods and common shells to create file paths containing text that decodes to non-normalized Unicode? I'm guessing not. If that's the case, then we don't really have to worry about it. People who went out of their way to create a weird file name will have the same troubles they have always had with that in Unix. But perhaps a better solution would be to make the underlying type of FilePath platform-dependent - e.g., String on Windows and [Word8] on Unix - and let it support platform- independent methods such as to/from String, to/from Bytes, setEncoding (defaulting to the current locale). That way, pass-through file paths will always work flawlessly on any platform, and applications have complete flexibility to deal with any other scenario however they choose. It's a breaking change though. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Unicode workaround for getDirectoryContents under Windows?
Ketil Malde wrote: If we want to incorporate a translation layer, I think it's fair to only support UTF-8 (ignoring locales), but provide a workaround for invalid characters. I disagree. Shells and GUI dialogs use the current locale. I think most other modern programming languages do too, but correct me if I am wrong. Still, your ideas about dealing with decoding errors sound useful. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Tree Semantics and efficiency
Hi everyone. I would like to confirm the following semantics. I want a tree which can be traversed both downwards and upwards. To do this i need to store the following for each node: o) a reference to the parent node (so we can traverse up the tree). This must be a reference as i dont want to copy the parent node each time) o) a list of child nodes that belong to this node. It is important to store only a reference to the parent and not a copy of the entire parent for efficiency. How would one write this in Haskell so that it has the above mentioned semantics. Or does GHC do that automatically for me so I don't need to do it explicitly? I am thinking of writing something like this (naive implementation) : Tree = TreeNode String Tree [Tree] -- TreeNode data ParentReference ChildNodes OR (implementation using IORef for parentNode reference) Tree = TreeNode String (IORef Tree) [Tree] -- TreeNode data ParentReference ChildNodes Thanks in advance Rouan. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Unicode workaround for getDirectoryContents under Windows?
On 17/06/2009 15:03, Yitzchak Gale wrote: Simon Marlow wrote: The following cases are currently broken... I propose to fix these (on Windows). It will mean that your second case above will be broken, until someone fixes getDirectoryContents... ...it's a lot easier on Windows... on Unix I don't have a clear idea of how to proceed... If someone else has a good understanding of what needs done, please wade in. I don't know how getArgs fits in here... I agree it's broken and needs to be fixed. OK, would you like me to reflect this discussion in tickets? Let's see, so far we have #3300, I don't see anything else. Do you want two tickets, one each for WIndows/Unix? Or four, separating the FilePath and getArgs issues? One for each issue is usually better, so four. Thanks! On Unix, all file APIs take [Word8]... So we should probably be converting from FilePath to [Word8] by encoding using the current locale... what about encoding errors, Where relevant, we should emulate what the common shells do. In general, I don't see why they should be different than any other file operation error. and what if encode.decode is not the identity due to normalisation Well, is it common for people using typical input methods and common shells to create file paths containing text that decodes to non-normalized Unicode? I'm guessing not. If that's the case, then we don't really have to worry about it. People who went out of their way to create a weird file name will have the same troubles they have always had with that in Unix. But perhaps a better solution would be to make the underlying type of FilePath platform-dependent - e.g., String on Windows and [Word8] on Unix - and let it support platform- independent methods such as to/from String, to/from Bytes, setEncoding (defaulting to the current locale). That way, pass-through file paths will always work flawlessly on any platform, and applications have complete flexibility to deal with any other scenario however they choose. It's a breaking change though. Yes, we coud do a lot better if FilePath was an abstract type, but sadly it is not, and we can't change that without breaking Haskell 98 compatibility, not to mention tons of existing code. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tree Semantics and efficiency
You can use the standart tying the knot-technique. For example: data Tree = TreeNode String (Maybe Tree) [Tree] -- what's the parent of the root node? test :: Tree test = let parent = TreeNode I'm parent Nothing [child1, child2] child1 = TreeNode I'm child1 (Just parent) [] child2 = TreeNode I'm child2 (Just parent) [] in parent But there are other possibilities worth considering. Zippers, for example, would be likely useful. IORefs are most certainly an overkill. Rouan van Dalen wrote on 17.06.2009 18:15: Hi everyone. I would like to confirm the following semantics. I want a tree which can be traversed both downwards and upwards. To do this i need to store the following for each node: o) a reference to the parent node (so we can traverse up the tree). This must be a reference as i dont want to copy the parent node each time) o) a list of child nodes that belong to this node. It is important to store only a reference to the parent and not a copy of the entire parent for efficiency. How would one write this in Haskell so that it has the above mentioned semantics. Or does GHC do that automatically for me so I don't need to do it explicitly? I am thinking of writing something like this (naive implementation) : Tree = TreeNode String Tree [Tree] -- TreeNode data ParentReference ChildNodes OR (implementation using IORef for parentNode reference) Tree = TreeNode String (IORef Tree) [Tree] -- TreeNode data ParentReference ChildNodes Thanks in advance Rouan. ___ 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] Tree Semantics and efficiency
On Wed, Jun 17, 2009 at 9:24 AM, Miguel Mitrofanovmiguelim...@yandex.ru wrote: You can use the standart tying the knot-technique. For example: data Tree = TreeNode String (Maybe Tree) [Tree] -- what's the parent of the root node? test :: Tree test = let parent = TreeNode I'm parent Nothing [child1, child2] child1 = TreeNode I'm child1 (Just parent) [] child2 = TreeNode I'm child2 (Just parent) [] in parent But there are other possibilities worth considering. Zippers, for example, would be likely useful. The advantage zippers have over knot-tying is that I can create updates of zipper-viewed data structures. It looks like there's already something on HAckage for this: http://hackage.haskell.org/packages/archive/rosezipper/0.1/doc/html/Data-Tree-Zipper.html The idea is that you can use the following function to created the zipper-view of your tree: fromTree :: Tree a - TreeLoc a and then use the functions on 'TreeLoc' types to traverse and modify the tree, and then call toTree :: TreeLoc a - Tree a to go back to the 'Tree a' representation of your data. Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tree Semantics and efficiency
Rouan van Dalen wrote: It is important to store only a reference to the parent and not a copy of the entire parent for efficiency. Others have already recommended the rosezipper package, which gives you what you want, but I want to address one thing. foo = stuff bar = foo In most implementations (including GHC, which I assume you are using), `bar` will *not* be an actual copy of `foo`. In fact, GHC will not make a deep copy of a structure unless you pattern match all the way down and reconstruct it all the way back up yourself. If you use a zipper, like Data.Tree.Zipper mentioned already, moving around will not create and destroy tons of data. It will only create and destroy the spine of the tree local to the current pointer into the tree, which is not a lot of data. If you are holding on to older versions of the zipper, of course, they won't even be destroyed. - Jake ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] slow code
Still, a fast and general way to output primitive data types would be quite welcome. Naive question: Can't we just ask C to do it for us? (With a foreign function call.) Matthias. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
On 17 Jun 2009, at 13:32, Yitzchak Gale wrote: Henk-Jan van Tuyl wrote: reverse maximum minimum Oh yes, please fix those also! import Prelude.Strict? Honestly, these functions are ones that I've *deffinately* used lazy versions of, in fact, in the cases of minimum/maximum I've even used ones that are super-lazy and parallel using unamb. It would be extremely odd to randomly decide most people would want this to be strict based on no knowledge of what they're actually doing. Instead, why don't we stand by the fact that haskell is a lazy language, and that the functions we get by default are lazy, and then write a strict prelude as I suggest above to complement the lazy version. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] slow code
matthias.goergens: Still, a fast and general way to output primitive data types would be quite welcome. Data.Binary is the way (though it doesn't yet use direct output for float and double bits) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Wiki user accounts
I'm hearing reports of people having difficulty obtaining accounts on the Haskell wiki, (...) Maybe OpenID could help with spam problems without the need for manual intervention: I doubt it - I know LiveJournal has a problem with spambots gaining free accounts, and it provides OpenID. They may not be exploited for the OpenID account yet, but I imagine they will be sooner rather than later - OpenID is more useful to tie in people's existing identities. I would sugest that Haskell wiki only accepts OpenIDs, without providing then itself. So spammers would have to use domains, and I (naively?) believe those are costly to obtain and easy to block. Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANNOUNCE: clock 0.1 released
clock http://hackage.haskell.org/package/clock (...) I like the way you use Unicode on operators. It was implemented in response to a haskell-cafe discussion: http://www.mail-archive.com/haskell-cafe@haskell.org/msg51244.html Since I started that, I have to say thanks! Any suggestions for improvement, bug-fixes, joint-development offers are most welcome *^o^*!! Joint-development? Here is a sugestion, although it's really not glamourous :) I'm working on this 'bindings-common' (and other 'bindings-*') packages. It already provides the foreign code you used for 'clock', so you could link to it and help me expand its coverage. But it's really not something one would like to do for fun, although I believe it's going to be usefull. Best, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Android and Haskell
toby.hutton: On Wed, Jun 17, 2009 at 4:31 PM, Erik de Castro Lopo mle...@mega-nerd.com wrote: Well if the android phones have a JVM then something like OpenQuark should do the trick. The Android phones actually have a different VM which essentially takes compiled/translated java bytecode. http://en.wikipedia.org/wiki/Dalvik_virtual_machine EDSL time! -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] About the Monad Transformers
On page 141 of Yet another Haskell Tutorial (9.7 Monad Transformers) mapTreeM action (Leaf a) = do lift (putStrLn (Leaf ++ show a)) b - action a return (Leaf b) mapTreeM :: (MonadTrans t, Monad (t IO), Show a) = (a - t IO a1) - Tree a - t IO (Tree a1) Why does the type signature of mapTreeM look like this? And what does it mean by The lift tell us that we're going to be executing a command in an enclosed monad. In this case the enclosed monad is IO? Why does the author put lift here? How does the lift work? I have no idea about the explanation in the book...is there anyone can give me some hints about this? Thank you in advance! _ Messenger10年嘉年华，礼品大奖等你拿！ http://10.msn.com.cn___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ghc does not link after compiling
hi I wanted to compile my little test programm so it can take advantage of a multicore system. But when i call the compiler with ghc -O2 --make Benchmark.hs -threaded it just produces a acouple of .hi and .o files but no executable. But in the documantation was written that i just need to call ghc like that and it will produce my desired executable. My version of ghc is 6.10.3 regards ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
On Wed, 17 Jun 2009 13:32:40 +0200, Yitzchak Gale g...@sefer.org wrote: Henk-Jan van Tuyl wrote: reverse maximum minimum Oh yes, please fix those also! maximum' = foldl' max 0 [1 .. 99] minimum' = foldl' min 0 [1 .. 99] scanl scanr scanr1 iterate take drop splitAt inits Hmm, I use those all the time with large lists. They are lazy as expected, and seem to work fine. Do you have examples of problems with them? A hugs (version: Sep 2006) session: Hugs last $ scanl const 0 [0 .. 10 ^ 6] ERROR - C stack overflow Hugs head $ scanr (+) 0 [1 .. 10 ^ 6] ERROR - C stack overflow Hugs head $ scanr1 (+) [1 .. 10 ^ 6] ERROR - C stack overflow Hugs iterate (+ 1) 0 !! (10 ^ 6) ERROR - C stack overflow Hugs last $ take (10 ^ 6) [1 ..] 100 Hugs head $ drop (10 ^ 6) [1 ..] 101 Hugs head . snd $ splitAt (10 ^ 6) [1 ..] 101 Data.List last $ last $ inits [1 .. 10 ^ 6] ERROR - C stack overflow A GHCi 6.10.1 session: Prelude last $ scanl const 0 [0 .. 10 ^ 6] 0 Prelude head $ scanr (+) 0 [1 .. 10 ^ 6] *** Exception: stack overflow Prelude head $ scanr1 (+) [1 .. 10 ^ 6] *** Exception: stack overflow Prelude iterate (+ 1) 0 !! (10 ^ 6) *** Exception: stack overflow Prelude last $ take (10 ^ 6) [1 ..] 100 Prelude head $ drop (10 ^ 6) [1 ..] 101 Prelude head . snd $ splitAt (10 ^ 6) [1 ..] 101 Prelude :m Data.List Prelude Data.List last $ last $ inits [1 .. 10 ^ 6] ??? (not finished yet) take, drop and splitAt seem to work fine now, but when I did these tests the first time, GHCi generated a stack overflow exception (I think it was GHCi 6.8.3). foldM filterM (Bulat) foldM' f a (x:xs) = do a' - f a x a' `seq` foldM' f a' xs -- Met vriendelijke groet, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghc does not link after compiling
2009/6/17 Nico Rolle nro...@web.de: hi I wanted to compile my little test programm so it can take advantage of a multicore system. But when i call the compiler with ghc -O2 --make Benchmark.hs -threaded it just produces a acouple of .hi and .o files but no executable. But in the documantation was written that i just need to call ghc like that and it will produce my desired executable. My version of ghc is 6.10.3 regards ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Is the module name Main? -- Deniz Dogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghc does not link after compiling
Am Mittwoch 17 Juni 2009 18:18:01 schrieb Nico Rolle: hi I wanted to compile my little test programm so it can take advantage of a multicore system. But when i call the compiler with ghc -O2 --make Benchmark.hs -threaded If your module name is not Main, you need the -main-is flag: ghc -O2 -threaded -main-is Benchmark --make Benchmark or ghc -O2 -threaded -main-is Benchmark.main --make Benchmark it just produces a acouple of .hi and .o files but no executable. But in the documantation was written that i just need to call ghc like that and it will produce my desired executable. My version of ghc is 6.10.3 regards ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghc does not link after compiling
oh sry now it works thank you 2009/6/17 Deniz Dogan deniz.a.m.do...@gmail.com: 2009/6/17 Nico Rolle nro...@web.de: hi I wanted to compile my little test programm so it can take advantage of a multicore system. But when i call the compiler with ghc -O2 --make Benchmark.hs -threaded it just produces a acouple of .hi and .o files but no executable. But in the documantation was written that i just need to call ghc like that and it will produce my desired executable. My version of ghc is 6.10.3 regards ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Is the module name Main? -- Deniz Dogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] About the Monad Transformers
On 17 Jun 2009, at 19:54, .shawn wrote: Why does the type signature of mapTreeM look like this? Why not? I can't think of any other possibility. And what does it mean by The lift tell us that we're going to be executing a command in an enclosed monad. In this case the enclosed monad is IO? Wild guess: I think they mean exactly what they said. Literally. Why does the author put lift here? Because he wanted to work in a more general setting than just IO monad. He needed IO, of course, because of putStrLn, but he wanted to give the user of this function an opportunity to do something besides just IO. How does the lift work? lift is defined in the MonadTrans type class, so it works differently depending on what transformer you use. You can even define your own one and lift would work as you write it. The only thing we know for sure is that whichever transformer you use, lift would have the type m x - t m x, where t is a transformer in question. So, it would be OK to apply it to, say, something of type IO a, and you'd have something of type t IO a as a result. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] About the Monad Transformers
.shawn wrote: On page 141 of Yet another Haskell Tutorial (9.7 Monad Transformers) mapTreeM action (Leaf a) = do lift (putStrLn (Leaf ++ show a)) b - action a return (Leaf b) mapTreeM :: (MonadTrans t, Monad (t IO), Show a) = (a - t IO a1) - Tree a - t IO (Tree a1) Why does the type signature of mapTreeM look like this? And what does it mean by The lift tell us that we're going to be executing a command in an enclosed monad. In this case the enclosed monad is IO? Why does the author put lift here? How does the lift work? The idea of a monad transformer is to add a second monad (the transformer) onto a first (I find thatoften, as in this case, IO is involved). The type parameter t (standing for the monad transformer) takes two arguments: the first is the monad being added to (IO) and the second is the normal monadic return value. For example, with the StateT transformer using a state with type Int, the type signature becomes: mapTreeM :: (MonadTrans (StateT Int), Monad (StateT Int IO), Show a) = (a - StateT Int IO a1) - Tree a - StateT Int IO (Tree a1) So it takes a function from a to a1 in our combined StateT Int IO monad, a Tree of a, and gives you back a Tree of a1 in the monad, by transforming each value in the tree monadically. When you write the do block, you are writing in the StateT Int IO monad (or whatever transformer you happen to be using). Thus, the compiler expects the statements of the do block to be of this type. putStrLn gives back something in the IO monad, and there is no support in the language/type-system for automatically turning an IO thing into a StateT Int IO thing. Hence where lift comes in. lift is used to make something of the inside monad (IO) become something of the transformed monad (StateT Int IO). The call of action does not need lift, because its result is already in the StateT Int IO monad. The times where lift becomes particularly important is when you end up with two state monads (or two writer monads, or whatever) in a stack. If you had the nasty construction StateT Int (StateT Int IO) as your monad, you'd need a lift to access the inner state, but you'd leave off the lift to access the outer state. Hope that helps, Neil. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Start to Finish C2HS guide
Hey List, I was experimenting a bit with binding RPM in Haskell and i figured i would document the process a bit. The link below sums up from start to finish in tutorial fashion how to write bindings. http://loupgaroublond.blogspot.com/2009/06/haskell-bindings-to-c-from-start-to.html Perhaps would it be possible to include some of this kind of information with C2HS documentation in the future? -Yaakov Nemoy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
On Wed, 17 Jun 2009 18:22:51 +0200, Henk-Jan van Tuyl hjgt...@chello.nl wrote: On Wed, 17 Jun 2009 13:32:40 +0200, Yitzchak Gale g...@sefer.org wrote: Henk-Jan van Tuyl wrote: reverse maximum minimum Oh yes, please fix those also! maximum' = foldl' max 0 [1 .. 99] minimum' = foldl' min 0 [1 .. 99] Of course I meant: maximum' xs = foldl1' max xs minimum' xs = foldl1' min xs -- Met vriendelijke groet, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] measuring time differences between functions
Hi everyone. I made parallel versions of my functions projection selection and sort and i wanted to test the difference in runtime. But he only printed 0.00 twice. Maybe hes just too fast? Or is it because of lazy evaluation? or is there a better way to mesure performance in execution time? regards main = do xs - readCSV dataconvert/lineitem.tbl '|' start - getCurrentTime let pnp = projection [5] xs let snp = selection (\x - (x!!0) (Int 17000)) pnp let sortnp = sort [0] [ASC] snp end - getCurrentTime putStrLn $ show (end `diffUTCTime` start) start2 - getCurrentTime let pp = pProjection [5] xs let sp = pSelection (\x - (x!!0) (Int 17000)) pp let sortp = pSort [0] [ASC] sp end2 - getCurrentTime putStrLn $ show (end2 `diffUTCTime` start2) return snp ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Wiki user accounts
On Wed, Jun 17, 2009 at 8:23 AM, Mauríciobriqueabra...@yahoo.com wrote: I would sugest that Haskell wiki only accepts OpenIDs, without providing then itself. So spammers would have to use domains, and I (naively?) believe those are costly to obtain and easy to block. It's easy for a spammer to obtain an OpenID without having to obtain a domain. Unfortunately, OpenID by itself is not a sufficient mechanism for preventing spam. Josh ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] measuring time differences between functions
Am Mittwoch 17 Juni 2009 20:25:08 schrieb Nico Rolle: Hi everyone. I made parallel versions of my functions projection selection and sort and i wanted to test the difference in runtime. But he only printed 0.00 twice. Maybe hes just too fast? Or is it because of lazy evaluation? or is there a better way to mesure performance in execution time? regards main = do xs - readCSV dataconvert/lineitem.tbl '|' start - getCurrentTime let pnp = projection [5] xs let snp = selection (\x - (x!!0) (Int 17000)) pnp let sortnp = sort [0] [ASC] snp end - getCurrentTime putStrLn $ show (end `diffUTCTime` start) start2 - getCurrentTime let pp = pProjection [5] xs let sp = pSelection (\x - (x!!0) (Int 17000)) pp let sortp = pSort [0] [ASC] sp end2 - getCurrentTime putStrLn $ show (end2 `diffUTCTime` start2) return snp The let bindings do not cause any computation because of laziness, all they do is bind the names to a thunk that says how to calculate the value if it is needed. Regardless of how long the computation would take, binding the names to a thunk takes only a few nanoseconds. To measure the time needed for the computations, you must force them to be carried out between the two calls to getCurrentTime. Probably inserting print $ last snp before end - getCurrentTime (and likewise for the second) would be enough (if the sorting doesn't require the values in snp to be fully evaluated, you would have to do more forcing). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] measuring time differences between functions
Am Mittwoch 17 Juni 2009 20:25:08 schrieb Nico Rolle: or is there a better way to mesure performance in execution time? I think System.CPUTime provides more reliable timings if the work takes long enough for the scheduler to kick in. And there are several benchmarking packages on Hackage, e.g. maybench, microbench, benchpress, StrictBench. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
Haskell's numeric literals are strict. You wouldn't want that to change right? It seems to me that having sum and product be strict is consistent with this. -Keith On Wed, Jun 17, 2009 at 11:15 AM, Thomas Davietom.da...@gmail.com wrote: On 17 Jun 2009, at 13:32, Yitzchak Gale wrote: Henk-Jan van Tuyl wrote: reverse maximum minimum Oh yes, please fix those also! import Prelude.Strict? Honestly, these functions are ones that I've *deffinately* used lazy versions of, in fact, in the cases of minimum/maximum I've even used ones that are super-lazy and parallel using unamb. It would be extremely odd to randomly decide most people would want this to be strict based on no knowledge of what they're actually doing. Instead, why don't we stand by the fact that haskell is a lazy language, and that the functions we get by default are lazy, and then write a strict prelude as I suggest above to complement the lazy version. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- keithsheppard.name ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
