Main Thread Evacuated
I've found a bug in the scheduler: When a main thread finishes (e.g. returning from a ffi callback), the GC might be run before it is removed from the main_threads list. If a major collection happens, the thread will be garbage collected and the GC barfs when it updates the pointers in the main_threads list. This scenario is quite unlikely during normal operation, but when heap-profiling a HOpenGL program it leads to certain death after a few seconds. I don't know how to fix it in a clean way (I have no idea how my changes would affect the threaded rts or the other ways) --- so can someone else please fix this? Cheers, Wolfgang ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Generating docs
What is the approved way of generating and installing docs? I tried (from source) ./configure ... make all make install make html make dvi make ps make install-docs The latter command fails with (as usual with a bit of German :-) --- ==fptools== make install-docs -wr; in /home/ralf/tmp/ghc-5.04.1/libraries/base t Haskell Core Libraries (base package) --no-implicit-prelude -p prologue.txt-h -o html Control/Arrow.raw-hs Control/Concurrent.raw-hs Control/Concurrent/Chan.raw-hs Control/Concurrent/MVar.raw-hs Control/Concurrent/QSem.raw-hs Control/Concurrent/QSemN.raw-hs Control/Concurrent/SampleVar.raw-hs Control/Exception.raw-hs Control/Monad.raw-hs Control/Monad/Cont.raw-hs Control/Monad/Error.raw-hs Control/Monad/Fix.raw-hs Control/Monad/Identity.raw-hs Control/Monad/List.raw-hs Control/Monad/Monoid.raw-hs Control/Monad/RWS.raw-hs Control/Monad/Reader.raw-hs Control/Monad/ST.raw-hs Control/Monad/ST/Lazy.raw-hs Control/Monad/ST/Strict.raw-hs Control/Monad/State.raw-hs Control/Monad/Trans.raw-hs Control/Monad/Writer.raw-hs Control/Parallel.raw-hs Data/Array.raw-hs Data/Array/Base.raw-hs Data/Array/Diff.raw-hs Data/Array/IArray.raw-hs Data/Array/IO.raw-hs Data/Array/MArray.raw-hs Data/Array/ST.raw-hs Data/Array/Storable.raw-hs Data/Array/Unboxed.raw-hs Data/Bits.raw-hs Data/Bool.raw-hs Data/Char.raw-hs Data/Complex.raw-hs Data/Dynamic.raw-hs Data/Either.raw-hs Data/FiniteMap.raw-hs Data/IORef.raw-hs Data/Int.raw-hs Data/Ix.raw-hs Data/List.raw-hs Data/Maybe.raw-hs Data/PackedString.raw-hs Data/Ratio.raw-hs Data/STRef.raw-hs Data/STRef/Lazy.raw-hs Data/STRef/Strict.raw-hs Data/Set.raw-hs Data/Tuple.raw-hs Data/Unique.raw-hs Data/Word.raw-hs Debug/QuickCheck.raw-hs Debug/QuickCheck/Batch.raw-hs Debug/QuickCheck/Poly.raw-hs Debug/QuickCheck/Utils.raw-hs Debug/Trace.raw-hs Foreign.raw-hs Foreign/C.raw-hs Foreign/C/Error.raw-hs Foreign/C/String.raw-hs Foreign/C/Types.raw-hs Foreign/C/TypesISO.raw-hs Foreign/ForeignPtr.raw-hs Foreign/Marshal/Alloc.raw-hs Foreign/Marshal/Array.raw-hs Foreign/Marshal/Error.raw-hs Foreign/Marshal/Utils.raw-hs Foreign/Ptr.raw-hs Foreign/StablePtr.raw-hs Foreign/Storable.raw-hs GHC/Arr.raw-hs GHC/Base.raw-hs GHC/Conc.raw-hs GHC/Enum.raw-hs GHC/Err.raw-hs GHC/Exception.raw-hs GHC/Exts.raw-hs GHC/Float.raw-hs GHC/Handle.raw-hs GHC/IO.raw-hs GHC/IOBase.raw-hs GHC/Int.raw-hs GHC/List.raw-hs GHC/Num.raw-hs GHC/Pack.raw-hs GHC/Posix.raw-hs GHC/PrimopWrappers.raw-hs GHC/Ptr.raw-hs GHC/Read.raw-hs GHC/Real.raw-hs GHC/ST.raw-hs GHC/STRef.raw-hs GHC/Show.raw-hs GHC/Stable.raw-hs GHC/Storable.raw-hs GHC/TopHandler.raw-hs GHC/Weak.raw-hs GHC/Word.raw-hs Numeric.raw-hs Prelude.raw-hs System/CPUTime.raw-hs System/Cmd.raw-hs System/Console/GetOpt.raw-hs System/Directory.raw-hs System/Environment.raw-hs System/Exit.raw-hs System/IO.raw-hs System/IO/Error.raw-hs System/IO/Unsafe.raw-hs System/Info.raw-hs System/Locale.raw-hs System/Mem.raw-hs System/Mem/StableName.raw-hs System/Mem/Weak.raw-hs System/Random.raw-hs System/Time.raw-hs Text/Html.raw-hs Text/Html/BlockTable.raw-hs Text/ParserCombinators/Parsec.raw-hs Text/ParserCombinators/Parsec/Char.raw-hs Text/ParserCombinators/Parsec/Combinator.raw-hs Text/ParserCombinators/Parsec/Error.raw-hs Text/ParserCombinators/Parsec/Expr.raw-hs Text/ParserCombinators/Parsec/Language.raw-hs Text/ParserCombinators/Parsec/Perm.raw-hs Text/ParserCombinators/Parsec/Pos.raw-hs Text/ParserCombinators/Parsec/Prim.raw-hs Text/ParserCombinators/Parsec/Token.raw-hs Text/ParserCombinators/ReadP.raw-hs Text/ParserCombinators/ReadPrec.raw-hs Text/PrettyPrint.raw-hs Text/PrettyPrint/HughesPJ.raw-hs Text/Read.raw-hs Text/Read/Lex.raw-hs Text/Regex.raw-hs Text/Regex/Posix.raw-hs Text/Show.raw-hs Text/Show/Functions.raw-hs \ --dump-interface=base.haddock \ /bin/sh: t: command not found make[2]: [html/index.html] Fehler 127 (ignoriert) /bin/install -c -m 644 -g users html/* /home/ralf/tmp/share/ghc-5.04.1/html/base /bin/install: Aufruf von stat für »html/*« nicht möglich: Datei oder Verzeichnis nicht gefunden make[2]: *** [install-docs] Fehler 1 make[1]: *** [install-docs] Fehler 1 make[1]: Verlassen des Verzeichnisses Verzeichnis »/home/ralf/tmp/ghc-5.04.1/libraries« make: *** [install-docs] Fehler 1 --- It seems that the call is a bit truncated. Cheers, Ralf ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Generating docs
What is the approved way of generating and installing docs? I tried (from source) ./configure ... make all make install make html make dvi make ps make install-docs The latter command fails with (as usual with a bit of German :-) Do you have Haddock installed? Did the configure script detect it? Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: empty field label constructor infelicity
| The report says The expression F {}, where F is a data constructor,
is
| legal whether or not F was declared with record syntax, provided F has
no
| strict fields: it denotes F _|_1 ... _|_n where n is the arity of F.
|
| It unclear to me why there needs to be this provision for records with
| strict fields -- just let them be undefined -- but that
notwithstanding,
| GHC seems to do the wrong thing:
I think the report is quite reasonable here if there is a strict
field then F {} is unconditionally bottom, and you may as well write
'undefined'. Omitting the provided F has no strict fields is
certainly defensible, but it's too late to change.
I agree that GHC does not implement the clause... will fix.
Simon
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Generating docs
What is the approved way of generating and installing docs? I tried (from source) ./configure ... make all make install make html make dvi make ps make install-docs The latter command fails with (as usual with a bit of German :-) Do you have Haddock installed? Did the configure script detect it? Cheers, Simon No, of course not. Thanks. BTW, why did you separate Haddock from GHC? I love these vicious circles: to build GHC with docs you need Haddock, to build Haddock you need GHC ... Cheers, Ralf ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Generating docs
BTW, why did you separate Haddock from GHC? I love these vicious circles: to build GHC with docs you need Haddock, to build Haddock you need GHC ... You can either use an installed Haddock, or use Haddock from the same tree (./configure --enable-src-tree-haddock). It's not really a cyclic dependency: Haddock isn't required to build GHC itself, so you can build GHC, use it to build Haddock, and then build GHC's docs. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Main Thread Evacuated
I've found a bug in the scheduler: When a main thread finishes (e.g. returning from a ffi callback), the GC might be run before it is removed from the main_threads list. If a major collection happens, the thread will be garbage collected and the GC barfs when it updates the pointers in the main_threads list. This scenario is quite unlikely during normal operation, but when heap-profiling a HOpenGL program it leads to certain death after a few seconds. I don't know how to fix it in a clean way (I have no idea how my changes would affect the threaded rts or the other ways) --- so can someone else please fix this? Hmm, yes that looks like a bug. I've put together a patch (enclosed), could you tell me if it helps? Cheers, Simon patch Description: Binary data
Haskell 98
| The report says The expression F {}, where F is a data constructor,
is
| legal whether or not F was declared with record syntax, provided F has
no
| strict fields: it denotes F _|_1 ... _|_n where n is the arity of F.
|
| It unclear to me why there needs to be this provision for records with
| strict fields -- just let them be undefined -- but that
notwithstanding,
| GHC seems to do the wrong thing:
I spoke too soon. Consider
data F = F Int !Int
data S = S { x::Int, y::!Int }
According to the words above
F {} is illegal
but what about this one?
S {}
It would be very odd if that were illegal, because S { x=3 } is
certainly not illegal, and is just as much bottom as S {} is. So it
would be really odd if S {} were illegal. But that's what the words
imply.
This changes the situation from maybe this could be better to there's
an inconsistency here. So we have to fix it somehow.
Solutions:
a) omit the clause provided F has no strict fields
b) make it clear that F {} is always legal if F is declared with
record syntax
regardless of field strictness; but if F was not
declared with record
syntax it's only legal if F has no strict fields
c) make F {} illegal if F has any strict fields, regardless of
how F is declared.
(c) seems stupid, because then S{x=3} is legal but S{} is not.
(b) seems simply grotesque when written out.
So I now propose to adopt (a) as Hal wanted, despite my earlier
reluctance to make any change at all. I don't think this decision is
destablising.
Simon
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Haskell 98
On Wed, Sep 25, 2002 at 12:34:53PM +0100, Simon Peyton-Jones wrote:
I spoke too soon. Consider
data F = F Int !Int
data S = S { x::Int, y::!Int }
According to the words above
F {} is illegal
but what about this one?
S {}
I think the sentence in question (end of 3.15.2) is just a clarification;
the preceding 4 rules are sufficient and clear: F{}, S{} and S{x=3} are
all illegal because they omit a value for a strict field. That is, it's
correct, though not strictly necessary, nor does it cover all the cases.
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Haskell 98
| I think the sentence in question (end of 3.15.2) is just a
clarification;
| the preceding 4 rules are sufficient and clear: F{}, S{} and S{x=3}
are
| all illegal because they omit a value for a strict field. That is,
it's
| correct, though not strictly necessary, nor does it cover all the
cases.
Blargh. Excellent point. I had totally forgotten that. I withdraw all
suggested changes except a cross-ref to the section you mention. Sigh.
My brain is getting soft.
Simon
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Haskell 98
Blargh. Excellent point. I had totally forgotten that. I withdraw all
suggested changes except a cross-ref to the section you mention. Sigh.
My brain is getting soft.
Actually the rules referenced appear immediately above, so no reference is
necessary.
My original message was not suggesting a change to the report (though I
don't know that I agree with it -- i can see arguments in each
direction): I was primarily pointing out an infelicity in GHCs
implementation...
Out of curiousity, it's a bit strange that
data D = D !Int
myD = D {}
in invalid, but
newtype N = N !Int
myN = N {}
is not.
Not that I'm proposing a change...I just think it's od..
- Hal
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
dead link
On http://www.haskell.org/ghc/ the link to the Users' Guide is missing. Cheers Christian GHC Features This is a summary of GHC's main features. They are all described in more detail in the Users' Guide. The requested URL /ghc/docs/latest/html/users_guide/book-users-guide.html was not found on this server. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: uh oh, another bug report :) (it and big computations)
*Foo it ghc-5.04.1: panic! (the `impossible' happened, GHC version 5.04.1): rdrNameModule it Fixed, thanks. Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Newbie building GHC
The reason that this worries me is that Cygwin ld links with libraries from the Cygwin lib directory rather than the Mingw equivalent, regardless of which gcc was used to compile the object files. We only use ld directly when building the GHCi libraries (HSbase.o etc.), and this doesn't use any external libraries, so I think we're ok here. Normal linking of Haskell programs is done using gcc, so we'll get the right version of ld there. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: specifying the name of the executable under Windows
foo.exe, not foo. I'll mention this in the user manual S | -Original Message- | From: Wolfgang Jeltsch [mailto:[EMAIL PROTECTED]] | Sent: 24 September 2002 22:30 | To: The Glasgow Haskell Users Mailing List | Subject: specifying the name of the executable under Windows | | Hi, | | if I enter | ghc -o foo foo.hs | under Windows, is the resulting executable named foo or foo.exe? | | (Please send replies not only to the list as I'm not subscribed to it.) | | Wolfgang | | ___ | Glasgow-haskell-users mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Behaviour of div mod with negative arguments?
Hi, Does Haskell specify how div and mod should behave when given one or both arguments negative? Eg, in hugs we get: div 13 = 0 div (-1) 3 = -1 div 1 (-3) = -1 div (-1) (-3) = 0 and so on. I've had a bit of a look for where div and mod are specified exactly, but I can only find a definition of their type. Are they defined anywhere? And what is the rational behind the negative arguments part of the definition? Thanks, Mark. P.S. I notice in hugs if I type -1 `div` 3 the `div` binds to the 1 and 3 first, and only applies the - at the end. Is there a reason why the unary - has weak binding? -- Dr Mark H Phillips Research Analyst (Mathematician) AUSTRICS - smarter scheduling solutions - www.austrics.com Level 2, 50 Pirie Street, Adelaide SA 5000, Australia Phone +61 8 8226 9850 Fax +61 8 8231 4821 Email [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Behaviour of div mod with negative arguments?
Does Haskell specify how div and mod should behave when given one or both arguments negative? Eg, in hugs we get: div 13 = 0 div (-1) 3 = -1 div 1 (-3) = -1 div (-1) (-3) = 0 and so on. We usually describe div as the version of division that truncates towards negative infinity. What this actually means is that when there are two solutions to a `divMod` b = (d,m) such that d*b + m == a andabs m b div picks the one where d is the closest to minus infinity, and quot picks the one where d is closer to zero. eg. (-1) `divMod` 3 = (-1, 2) or (0, -1) divMod gives you (-1,2), whereas quotRem gives you (0,-1). Hope this helps. Cheers, SImon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: report definition of field names
| Replace: | A datatype declaration may optionally include field labels for some | or all of the components of the type. | With: | A datatype declaration may optionally include field labels. Each | constructor must use either labelled fields or unlabelled fields, | but different constructors of a datatype may use whichever, | independent of the other constructors. Good point. This is in the expressions chapter, and it's all explained quite well in the datatype chapter. So propose to make a simpler change: Replace: A datatype declaration may optionally include field labels for some or all of the components of the type. With: A datatype declaration may optionally define field labels (see Section 4.2.1). Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Behaviour of div mod with negative arguments?
Dr Mark H Phillips wrote: Hi, Does Haskell specify how div and mod should behave when given one or both arguments negative? Yes, section 6.4.2 gives an exact definition. P.S. I notice in hugs if I type -1 `div` 3 the `div` binds to the 1 and 3 first, and only applies the - at the end. Is there a reason why the unary - has weak binding? The rational is that unary `-' has the same precedence as binary `-'. Personally, I think this is counter-intuitive to do it the way Haskell does. -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: empty field label constructor infelicity
| The report says The expression F {}, where F is a data constructor,
is
| legal whether or not F was declared with record syntax, provided F has
no
| strict fields: it denotes F _|_1 ... _|_n where n is the arity of F.
|
| It unclear to me why there needs to be this provision for records with
| strict fields -- just let them be undefined -- but that
notwithstanding,
| GHC seems to do the wrong thing:
I think the report is quite reasonable here if there is a strict
field then F {} is unconditionally bottom, and you may as well write
'undefined'. Omitting the provided F has no strict fields is
certainly defensible, but it's too late to change.
I agree that GHC does not implement the clause... will fix.
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Haskell 98
| The report says The expression F {}, where F is a data constructor,
is
| legal whether or not F was declared with record syntax, provided F has
no
| strict fields: it denotes F _|_1 ... _|_n where n is the arity of F.
|
| It unclear to me why there needs to be this provision for records with
| strict fields -- just let them be undefined -- but that
notwithstanding,
| GHC seems to do the wrong thing:
I spoke too soon. Consider
data F = F Int !Int
data S = S { x::Int, y::!Int }
According to the words above
F {} is illegal
but what about this one?
S {}
It would be very odd if that were illegal, because S { x=3 } is
certainly not illegal, and is just as much bottom as S {} is. So it
would be really odd if S {} were illegal. But that's what the words
imply.
This changes the situation from maybe this could be better to there's
an inconsistency here. So we have to fix it somehow.
Solutions:
a) omit the clause provided F has no strict fields
b) make it clear that F {} is always legal if F is declared with
record syntax
regardless of field strictness; but if F was not
declared with record
syntax it's only legal if F has no strict fields
c) make F {} illegal if F has any strict fields, regardless of
how F is declared.
(c) seems stupid, because then S{x=3} is legal but S{} is not.
(b) seems simply grotesque when written out.
So I now propose to adopt (a) as Hal wanted, despite my earlier
reluctance to make any change at all. I don't think this decision is
destablising.
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: Haskell 98
On Wed, Sep 25, 2002 at 12:34:53PM +0100, Simon Peyton-Jones wrote:
I spoke too soon. Consider
data F = F Int !Int
data S = S { x::Int, y::!Int }
According to the words above
F {} is illegal
but what about this one?
S {}
I think the sentence in question (end of 3.15.2) is just a clarification;
the preceding 4 rules are sufficient and clear: F{}, S{} and S{x=3} are
all illegal because they omit a value for a strict field. That is, it's
correct, though not strictly necessary, nor does it cover all the cases.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
RE: Haskell 98
| I think the sentence in question (end of 3.15.2) is just a
clarification;
| the preceding 4 rules are sufficient and clear: F{}, S{} and S{x=3}
are
| all illegal because they omit a value for a strict field. That is,
it's
| correct, though not strictly necessary, nor does it cover all the
cases.
Blargh. Excellent point. I had totally forgotten that. I withdraw all
suggested changes except a cross-ref to the section you mention. Sigh.
My brain is getting soft.
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
new to haskell-not working for some reason
I am new to haskell. I am trying to do some excersise but i can't make anything work :( This is my code.I replaced spaces with underscores ( _ ) Thanks for any suggestions or correctrions import IO import System import List import Maybe import Char import Numeric type Name=String type Room=Int type Dr=String type PatientTup=(Name,(Room,Dr)) type PatientList=[PatientTup] main=do userText-getText --- getText::IO String getText=do nc-getText ___return (:nc) --- PatientList::[(String,(Int,String))] PatientList=[(Robson, Brian,(2,MJH)), _(Hitchin, Linda,(1,ILR)), _(Reeve, Paul, (2,ILR))] --- getWards::Int getWards PatientList=[Room | (Name,(Room,Dr)) - PatientList, Room==getText] _do putSpc (length Room) _return(RoomLength) --- printFreq::WordList-IO() printFreq wl=do sequence (map putWards wl) _where __putWards::(getWards)-IO() __putWards(w)=do putStr w _putChar '\n' _return(w) ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: new to haskell-not working for some reason
Among other things, please make sure your layout lines up. Also, you cannot have the definition of getText at the same indentation of userText-getText otherwise your compiler will think this is part of the do statement (I believe): main=do userText-getText --- getText::IO String getText=do nc-getText ___return (:nc) these need to be lined up _do putSpc (length Room) _return(RoomLength) It would help if you also posted the error messaage the compiler gave you and the line number and (perhaps) a shorter version of the program. - Hal ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Kanser tedavisi
charset=US-ASCII; charset=US-ASCII; charset=US-ASCII; charset=US-ASCII Reply-To: [EMAIL PROTECTED] Date: Thu, 26 Sep 2002 00:12:08 +0300 X-Priority: 3 X-Library: Indy 9.00.10 X-Mailer: Foxmail Kemoterapinin yan etkileri nedeniyle yorgun ve bitkin düsmüs bir yakininiz mi var? Yanitiniz evetse vakit kaybetmeyin ve CARCTOL'u denemesini saglayin. Genelde ancak klasik tedavinin ise yaramadiginin anlasilmasi, insanlari baska seçenekler aramaya itmektedir, ancak o durumda maalesef yapacak fazla birsey kalmamaktadir. Ayni hatanin yapilmasina izin vermeyin ve hiçbir yan etkisi olmayan, Himalaya Dagi bitkilerinden üretilen Carctol'u denemesini saglayin. CARCTOL, birkaç bin yillik, alternatif Hint Tibbinin (Ayuverda'nin) insanliga sundugu bir umut isigidir. Önceleri vücudu takviye edici tonik olarak kullanilan bu ürün simdi yeni formülüyle kansere karsi etkili bir ilaçtir Lütfen asagidaki siteye ugrayin ve Carctol'u yakindan taniyin. http://www.kanser-tedavisi.com esenlikler dileriz.. Listeden adinizin silinmesini istiyorsaniz [EMAIL PROTECTED] a bos e posta yollayin. Tesekkürler ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Dealing with configuration data
Evening,
I'm trying to write a utility that reads in some user preferences from
a pre-determined file, does some work, and exits. Sounds simple enough.
The problem I'm having is with the preferences: How do I make it
available throughout the entire program? (FWIW, most of the work is
effectively done inside the IO monad.) I could explicitly pass the
record around everywhere, but that seems a trifle inelegant.
My current solution is to use a global ('scuse my terminology, I'm not
sure that's the right word to use here) variable of type IORef Config
obtained through unsafePerformIO. It works, but strikes me as a rather
barbaric solution to a seemingly tame enough problem...
Intuition tells me I should be able to `embed', if you will, the config
record somehow within or alongside the IO state, and retrieve it at
will. (Is this what MonadState is for?) However it also tells me that
this will /probably/ involve lots of needless lifting and rewriting of
the existing code, which makes it even less enticing than passing
everything around explicitly.
Any opinions or suggestions?
Cheers,
/Liyang
--
.--{ Liyang HU }--{ http://nerv.cx/ }--{ Caius@Cam }--{ ICQ: 39391385 }--.
| :: zettai unmei mokusiroku absolute destined apocalypse : |
msg02021/pgp0.pgp
Description: PGP signature
Re: Dealing with configuration data
AFAIK, the global variable (so-called), passing around, and lifting the IO
monad are your only options. I almost always use the global variable
method since I know that in this case the unsafePerformIO is actually
safe, since writing to the variable will always occur before the call to
upIO and that it will only be written once. I don't feel bad about doing
this because GHC does this itself for its own configuration :).
--
Hal Daume III
Computer science is no more about computers| [EMAIL PROTECTED]
than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume
On Thu, 26 Sep 2002, Liyang Hu wrote:
Evening,
I'm trying to write a utility that reads in some user preferences from
a pre-determined file, does some work, and exits. Sounds simple enough.
The problem I'm having is with the preferences: How do I make it
available throughout the entire program? (FWIW, most of the work is
effectively done inside the IO monad.) I could explicitly pass the
record around everywhere, but that seems a trifle inelegant.
My current solution is to use a global ('scuse my terminology, I'm not
sure that's the right word to use here) variable of type IORef Config
obtained through unsafePerformIO. It works, but strikes me as a rather
barbaric solution to a seemingly tame enough problem...
Intuition tells me I should be able to `embed', if you will, the config
record somehow within or alongside the IO state, and retrieve it at
will. (Is this what MonadState is for?) However it also tells me that
this will /probably/ involve lots of needless lifting and rewriting of
the existing code, which makes it even less enticing than passing
everything around explicitly.
Any opinions or suggestions?
Cheers,
/Liyang
--
.--{ Liyang HU }--{ http://nerv.cx/ }--{ Caius@Cam }--{ ICQ: 39391385 }--.
| :: zettai unmei mokusiroku absolute destined apocalypse : |
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Dealing with configuration data
Sorry, I should also mention implicit parameters, if you're willing to use
that extension. I don't like them, though, and my impression from SPJ is
that it's very unclear whether they will get into Haskell 2 or not...
--
Hal Daume III
Computer science is no more about computers| [EMAIL PROTECTED]
than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume
On Wed, 25 Sep 2002, Hal Daume III wrote:
AFAIK, the global variable (so-called), passing around, and lifting the IO
monad are your only options. I almost always use the global variable
method since I know that in this case the unsafePerformIO is actually
safe, since writing to the variable will always occur before the call to
upIO and that it will only be written once. I don't feel bad about doing
this because GHC does this itself for its own configuration :).
--
Hal Daume III
Computer science is no more about computers| [EMAIL PROTECTED]
than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume
On Thu, 26 Sep 2002, Liyang Hu wrote:
Evening,
I'm trying to write a utility that reads in some user preferences from
a pre-determined file, does some work, and exits. Sounds simple enough.
The problem I'm having is with the preferences: How do I make it
available throughout the entire program? (FWIW, most of the work is
effectively done inside the IO monad.) I could explicitly pass the
record around everywhere, but that seems a trifle inelegant.
My current solution is to use a global ('scuse my terminology, I'm not
sure that's the right word to use here) variable of type IORef Config
obtained through unsafePerformIO. It works, but strikes me as a rather
barbaric solution to a seemingly tame enough problem...
Intuition tells me I should be able to `embed', if you will, the config
record somehow within or alongside the IO state, and retrieve it at
will. (Is this what MonadState is for?) However it also tells me that
this will /probably/ involve lots of needless lifting and rewriting of
the existing code, which makes it even less enticing than passing
everything around explicitly.
Any opinions or suggestions?
Cheers,
/Liyang
--
.--{ Liyang HU }--{ http://nerv.cx/ }--{ Caius@Cam }--{ ICQ: 39391385 }--.
| :: zettai unmei mokusiroku absolute destined apocalypse : |
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Dealing with configuration data
On Wed, 25 Sep 2002 16:06:29 -0700 (PDT) Hal Daume III [EMAIL PROTECTED] wrote: I don't feel bad about doing this because GHC does this itself for its own configuration :). I am going to show you that using unsafePerformIO where there really are side effects leads to unpredictable results, and is generally wrong in a lazy language. Don't hate me for this :) Consider this example (supposing that a Config is represented by an Int): storeConfig :: Int - () readConfig :: Int They both are obtained through the use of unsafePerformIO. Now, say I got this code: (storeConfig 0,storeConfig 1,readConfig,storeConfig 0,readConfig) What is this 5-uple supposed to evaluate to? First of all, this depends on order of evaluation. We can't say that all the elements of the tuple will be evaluated, so we can't tell if the fifth readConfig will evaluate to 0 or 1 (if the third storeConfig is never evaluated, readConfig will evaluate to 0, else to 1) This is one of the causes of the use of monads: ensuring correct order of evaluation. Second, suppose we were able to force order of evaluation (which shouldn't be allowed, in a lazy language). We still can't say what the last readConfig would evaluate to, since we don't know if the compiler is substituting equals for equals (I am expecting a lazy functional language to do this). If the compiler does, the last readConfig is equal to the first (in fact, by the use of unsafePerformIO, you have told the compiler that both the functions storeConfig and readConfig are pure, which is not true) and will evaluate to 1, else it will evaluate to 0. And, besides, the compiler should also substitute the second storeConfig 0 with the result of the first occurrence, so it would not evaluate the second storeConfig at all. This is another example of the need for monads: allowing program transformations, first of all substituting equals for equals. This is why (even if, by enough knoweledge of the implementation, we could), by only relying on the semantics of a lazy language, we can not have functions with side effects. If it wasn't so, they would not have invented monads, believe me. I apologize, as always, for my terrible english, and hope I have been clear. Vincenzo Ciancia ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Dealing with configuration data
Evening,
I'm trying to write a utility that reads in some user preferences from
a pre-determined file, does some work, and exits. Sounds simple enough.
The problem I'm having is with the preferences: How do I make it
available throughout the entire program? (FWIW, most of the work is
effectively done inside the IO monad.) I could explicitly pass the
record around everywhere, but that seems a trifle inelegant.
My current solution is to use a global ('scuse my terminology, I'm not
sure that's the right word to use here) variable of type IORef Config
obtained through unsafePerformIO. It works, but strikes me as a rather
barbaric solution to a seemingly tame enough problem...
Intuition tells me I should be able to `embed', if you will, the config
record somehow within or alongside the IO state, and retrieve it at
will. (Is this what MonadState is for?) However it also tells me that
this will /probably/ involve lots of needless lifting and rewriting of
the existing code, which makes it even less enticing than passing
everything around explicitly.
This is how I usually do it:
http://www.mail-archive.com/haskell@haskell.org/msg10565.html
(ignore the last part of the post...)
J.A.
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Dealing with configuration data
I don't mean to troll, but this isn't what I meant. Suppose we have: data Configuration = ... -- config data globalConfig :: IORef Configuration globalConfig = unsafePerformIO (newIORef undefined) Now, we define an unsafe function to read the configuration: getConfig :: Configuration getConfig = unsafePerformIO $ readIORef globalConfig Okay, this is bad but I claim it's okay, iff it is used as in: main = do ...read configuration from file...no calls to getConfig... writeIORef globalConfig configuration doStuff return () now, we have doStuff :: IO a. doStuff is allowed (even in its pure methods) to use getConfig. I claim that this is safe. I could be wrong; this is only a hand-waiving argument. Why? The first reference in the program to globalConfig is through a writeIORef. This means that at this point globalConfig gets evaluated and thus a ref is created. Immediately we put a value in it. Now, when doStuff runs, since it is an action run *after* the call to writeIORef, provided that it doesn't also write to 'globalConfig' (which I mentioned in my original message), any call to getConfig is deterministic. I could be wrong...please correct me if I am. -- Hal Daume III Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume On Thu, 26 Sep 2002, Nick Name wrote: On Wed, 25 Sep 2002 16:06:29 -0700 (PDT) Hal Daume III [EMAIL PROTECTED] wrote: I don't feel bad about doing this because GHC does this itself for its own configuration :). I am going to show you that using unsafePerformIO where there really are side effects leads to unpredictable results, and is generally wrong in a lazy language. Don't hate me for this :) Consider this example (supposing that a Config is represented by an Int): storeConfig :: Int - () readConfig :: Int They both are obtained through the use of unsafePerformIO. Now, say I got this code: (storeConfig 0,storeConfig 1,readConfig,storeConfig 0,readConfig) What is this 5-uple supposed to evaluate to? First of all, this depends on order of evaluation. We can't say that all the elements of the tuple will be evaluated, so we can't tell if the fifth readConfig will evaluate to 0 or 1 (if the third storeConfig is never evaluated, readConfig will evaluate to 0, else to 1) This is one of the causes of the use of monads: ensuring correct order of evaluation. Second, suppose we were able to force order of evaluation (which shouldn't be allowed, in a lazy language). We still can't say what the last readConfig would evaluate to, since we don't know if the compiler is substituting equals for equals (I am expecting a lazy functional language to do this). If the compiler does, the last readConfig is equal to the first (in fact, by the use of unsafePerformIO, you have told the compiler that both the functions storeConfig and readConfig are pure, which is not true) and will evaluate to 1, else it will evaluate to 0. And, besides, the compiler should also substitute the second storeConfig 0 with the result of the first occurrence, so it would not evaluate the second storeConfig at all. This is another example of the need for monads: allowing program transformations, first of all substituting equals for equals. This is why (even if, by enough knoweledge of the implementation, we could), by only relying on the semantics of a lazy language, we can not have functions with side effects. If it wasn't so, they would not have invented monads, believe me. I apologize, as always, for my terrible english, and hope I have been clear. Vincenzo Ciancia ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Low Price Fags
Dear Sir or Madam In the past you have requested information on discounted products. We hope that you find this of interest. If you are not a smoker, and find this email offensive, we sincerely apologise! We will be only too happy to take you off our mailing list. If you are a smoker, however, and are fed up with paying high prices for your cigarettes and tobacco, take a look at what we have to offer by clicking on this link. http://www.smokersassociation.co.uk/?S=15ID=2 We can send you, legally, by registered air mail, direct to your door, 4 cartons of cigarettes or 40 pouches of rolling tobacco (all brands are available) from only 170 Euros - about 105 pounds - fully inclusive of postage and packing. Why pay more? To remove yourself from our mailing list, please click below mailto:[EMAIL PROTECTED] Yours faithfully. Smokers Association http://www.smokersassociation.co.uk/?S=15ID=2 xay5402731y ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Dealing with configuration data
G'day all.
On Thu, Sep 26, 2002 at 12:06:36AM +0100, Liyang Hu wrote:
The problem I'm having is with the preferences: How do I make it
available throughout the entire program? (FWIW, most of the work is
effectively done inside the IO monad.) I could explicitly pass the
record around everywhere, but that seems a trifle inelegant.
My current solution is to use a global ('scuse my terminology, I'm not
sure that's the right word to use here) variable of type IORef Config
obtained through unsafePerformIO. It works, but strikes me as a rather
barbaric solution to a seemingly tame enough problem...
One solution is to do precisely as you suggested, using a state
monad to wrap the IORef. For example:
import Control.Monad.Reader
import Data.IORef
type MyIO a = ReaderT (IORef Config) IO a
main
= do config - readConfigurationStuff
configref - newIORef config
runReaderT configref main'
getConfig :: MyIO Config
getConfig
= do configref - ask
liftIO (readIORef configref)
-- Same as above, but you can supply a projection function.
getsConfig :: (Config - a) - MyIO a
getsConfig f
= do config - getConfig
return (f config)
-- ...and this is where the code REALLY starts.
main' :: MyIO ()
main'
= do config - getConfig
liftIO (putStrLn (show config)) -- etc
You can wrap whole slabs of existing code in liftIO if it uses
IO but does not need to read the configuration.
There's also a much uglier solution which I occasionally use if I
need an ad hoc global variable. Rather than using IORefs, I use
Strings as keys. The code is here:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/hfl/hfl/ioext/
Example of use:
import IOGlobal
main :: IO ()
main
= do writeIOGlobalM foo Foo data
writeIOGlobalM bar (Bar, [data])
foo - readIOGlobalM foo
putStrLn foo
bar - readIOGlobalM bar
putStrLn (show (bar :: (String, [String])))
Cheers,
Andrew Bromage
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
