Re: mkdirhier fails on Ubuntu Hardy i686 with dash shell
On 25/10/2009 19:34, Ian Lynagh wrote: On Mon, Oct 19, 2009 at 12:49:44PM -0600, Zooko Wilcox-O'Hearn wrote: Replacing the contents of mkdirhier and mkdirhier.sh with mkdir -p $* works-around the problem. Does anyone know why we don't just call mkdir -p normally? Are there portability problems with it? I believe 'mkdir -p' was not supported by some old unices, but AFAICT it seems to be supported by everything we build on these days. It probably wouldn't hurt to use it instead of mkdirhier. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #3632: lift restrictions on records with existential fields, especially in the presence of class constraints
#3632: lift restrictions on records with existential fields, especially in the
presence of class constraints
+---
Reporter: eflister | Owner:
Type: feature request | Status: new
Priority: normal | Component: Compiler
Version: 6.10.4 | Severity: normal
Keywords: existential records accessor update | Testcase:
Os: Unknown/Multiple | Architecture:
Unknown/Multiple
+---
the attached file demos the use of a record with an existential field with
a class constraint. it shows several cases where lifting the current
restrictions on accessing and updating this field would be both well-
defined and useful.
here is the record definition; the dur field is existential, but
constrained to be in class NoteDur.
{{{
data Note = forall x . NoteDur x = Note {
midiNum :: Int -- 0-255
, vel :: Int -- 0-255
, chan:: Int -- 0-15
, measure :: Integral a = a
, beat:: Int
, subdiv :: RealFrac a = a -- % of beat
, dur :: x
}
}}}
here is a walk through of places in the code where the current
restrictions are unnecessary and intrusive:
lines 64-95 -- these functions wouldn't be necessary if record update
syntax were enabled for both existential and non-existential fields. i
know 6.12 introduces it for non-existentials, but i don't see why it isn't
also possible for existential fields (even without a class constraint).
lines 33-35 and 60 show how much nicer it is to use regular updater syntax
in this case.
the same is true for existential accessors when there is a class
constraint -- there's no need to restrict this situation because the
accessor can have type:
fieldName :: (SomeClass x) = Record - x
line 142 shows a case where this would be very nice to have.
line 100 + 107 -- the foralls could be implicit (maybe offer an extention
that would allow them to be implicit)
lines 134-136 compared to 138-139 show how additional factoring could be
achieved if one were allowed to pattern match on the type of an
existential with class constraints.
lines 124-127 show how it would be nice to have existential classes
lastly, allow curried updater functions:
(rec {field = }) 5
instead of
(\x - (rec {field = x})) 5
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3632
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] #3632: lift restrictions on records with existential fields, especially in the presence of class constraints
#3632: lift restrictions on records with existential fields, especially in the presence of class constraints -+-- Reporter: eflister | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler |Version: 6.10.4 Severity: normal | Resolution: Keywords: existential records accessor update | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -+-- Changes (by eflister): * cc: erik.flis...@gmail.com (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3632#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] #3630: Suggested algorithm to control upper bound of space leaks
#3630: Suggested algorithm to control upper bound of space leaks --+- Reporter: shelbymoore3 | Owner: Type: proposal | Status: new Priority: normal| Milestone: Component: Compiler |Version: 6.10.4 Severity: normal| Resolution: Keywords:| Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple --+- Comment (by shelbymoore3): Simon Marlow replied and I replied with more thoughts: http://www.haskell.org/pipermail/cvs-ghc/2009-November/050946.html And here: http://www.haskell.org/pipermail/haskell-cafe/2009-November/068436.html -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3630#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
[GHC] #3634: Add traceM, traceShowM and withTrace
#3634: Add traceM, traceShowM and withTrace
--+-
Reporter: MartijnVanSteenbergen | Owner:
Type: proposal | Status: new
Priority: normal | Component: libraries/base
Version: 6.10.4 | Severity: normal
Keywords: | Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
--+-
On haskell-libraries we have
[http://thread.gmane.org/gmane.comp.lang.haskell.libraries/12019
discussed] the addition of the following three functions to module
Debug.Trace:
{{{
withTrace :: Show a = String - a - a
withTrace msg x = trace (msg ++ show x) x
traceM :: Monad m = String - m ()
traceM msg = trace msg (return ())
traceShowM :: (Show a, Monad m) = a - m ()
traceShowM = traceM . show
}}}
The current documentation for that module is a little terse so we have
also added an example to clarify the use of trace.
The following people have participated in the discussion and all expressed
interest, agreement or concerns (but always with constructive comments) in
or over the new functions: Philip Hölzenspies, pepe, Lennart Augustsson,
Felipe Lessa, Evan !LaForge, Joachim Breitner, Twan van Laarhoven, Ben
Franksen, Ian Lynagh, Sean Leather. Please see the thread for more detail.
I have attached a diff that can be applied to the module. Could one of the
GHC developers check it and apply it?
Thanks,
Martijn.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3634
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
