[ ghc-Bugs-940226 ] ghci failure using .ghci to define macro
Bugs item #940226, was opened at 2004-04-22 18:40 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=940226group_id=8032 Category: Runtime System Group: 5.04.3 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: ghci failure using .ghci to define macro Initial Comment: [EMAIL PROTECTED] Windows 2000 I have defined a macro that I adore (it runs quick check on all properties within a file). Manually, when I run ghci, I type the following to set up that macro: :load OdmQuickCheck :def checkAll checkAll I then proceed to the meat of my GHCI session, knowing I can now type something like: :checkAll IntersectionTest and receive immediate feedback as to whether my latest optimization actually broke the algorithm. Okay. That's all background. So, I put the two lines above into a .gchi file: :load OdmQuickCheck :def checkAll checkAll Then, I invoked ghci with a different module from the command line: ghci IntersectionTest I'm hoping, then, to be able to directly use the macro: :checkAll IntersectionTest After all the tests have run, something bad happens, and I see the following: C:\ghc\GHC-50~1.3\bin\ghc.exe: fatal error: scavenge_stack: weird activation record found on stack: 0 I think this may have something to do with the compiled/interpreted state of the modules involved, and whether the module itself imports OdmQuickCheck, but I've been unable to so far to isolate these dependencies. I'm hoping that you'll know right off... that it has something to do with the :def command not fully binding the macro... but if you have no idea, let me know and I can provide more data, sample code, more data points, etc. Don't hesitate to let me know what you need. Thanks! oriel -- Comment By: Simon Marlow (simonmar) Date: 2004-04-23 08:37 Message: Logged In: YES user_id=48280 This is a new one on me. Could you provide enough instructions to reproduce the problem please? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=940226group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-940294 ] Language.Haskell.Pretty misformats
Bugs item #940294, was opened at 2004-04-22 15:16
Message generated for change (Comment added) made by jcast
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=940294group_id=8032
Category: libraries (other)
Group: 6.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Jon Cast (jcast)
Assigned to: Nobody/Anonymous (nobody)
Summary: Language.Haskell.Pretty misformats
Initial Comment:
ghci gives the following results:
$ ghci -fglasgow-exts
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version
6.2.1, for Haskell 98.
/ /_\/ __ / /___| | http://www.haskell.org/ghc/
\/\/ /_/\/|_| Type :? for help.
Loading package base ... linking ... done.
Prelude :m + Language.Haskell.Syntax
Prelude Language.Haskell.Syntax :m +
Language.Haskell.Pretty Prelude Language.Haskell.Syntax
Language.Haskell.Pretty putStrLn $ prettyPrint $
HsInfixApp (HsDo [HsQualifier (HsVar (UnQual (HsIdent
undefined))), HsQualifier (HsVar (UnQual (HsIdent
undefined)))]) (HsQVarOp (UnQual (HsSymbol |)))
(HsDo [HsQualifier (HsVar (UnQual (HsIdent undefined)))])
Loading package haskell98 ... linking ... done.
Loading package haskell-src ... linking ... done.
do undefined
undefined
| do undefined
Prelude Language.Haskell.Pretty
Language.Haskell.Syntax putStrLn $ prettyPrint $ HsApp
(HsVar (UnQual (HsIdent foo))) $ HsApp (HsVar (UnQual
(HsIdent bar))) $ HsVar (UnQual (HsIdent baz))
foo bar baz
In other words, it mis-indents infix applications and
does /not/ parenthesize nested applications. There may
be other mis-formatting issues, but these are the ones
that have me stopped atm.
--
Comment By: Jon Cast (jcast)
Date: 2004-04-23 17:14
Message:
Logged In: YES
user_id=762054
Patterson: Well, the first one is more of a QOI issue (and
possibly debatable, although I can't imagine who'd want that
behavior). As for the second issue: are you saying that
(HsApp foo (HsApp bar baz)) is simply illegal or in
some way wrong? That doesn't seem to be documented, and
seems like a bad idea to me anyway. IMHO, it's the most
natural use from the POV of someone reading the Haddock
documentation HsParen is very hard to find, and it's not at
all obvious that it is /required/ whenever the Haskell
syntax requires parentheses.
But, I was inspired to report the first issue by the
following (more complex) test case, which I'm going to
report in full here as it's not too long and definitely
shows incorrect behavior:
putStrLn $ prettyPrintStyleMode style (PPHsMode 2 2 2 2 2 2
True PPOffsideRule False False) $ (HsInfixApp (HsDo
[HsQualifier (HsApp (HsVar (UnQual (HsIdent reserved)))
(HsLit (HsString LineTo))), HsGenerator (SrcLoc
{srcFilename = stdin, srcLine = 1, srcColumn = 1}) (HsPVar
(HsIdent curveSegmentEndPoint)) (HsVar (UnQual
(HsIdentparse))), HsQualifier (HsApp (HsVar (UnQual
(HsIdent return))) (HsApp (HsCon (UnQual (HsIdent
CurveLineTo))) (HsVar (UnQual (HsIdent
curveSegmentEndPoint)]) (HsQVarOp (UnQual (HsSymbol
|))) (HsDo [HsQualifier (HsApp (HsVar (UnQual (HsIdent
reserved))) (HsLit (HsString LineAlong))),HsGenerator
(SrcLoc {srcFilename = stdin, srcLine = 1, srcColumn = 1})
(HsPVar (HsIdent curveSegmentAlong)) (HsVar (UnQual
(HsIdent parse))),HsQualifier (HsApp (HsVar (UnQual
(HsIdent return))) (HsApp (HsCon (UnQual (HsIdent
CurveAlong))) (HsVar (UnQual (HsIdent
curveSegmentAlong)]))
do
reserved LineTo
curveSegmentEndPoint - parse
return CurveLineTo curveSegmentEndPoint
|
do
reserved LineAlong
curveSegmentAlong - parse
return CurveAlong curveSegmentAlong
Note that the operator here is indented by /two/ spaces,
same as the statements in the first do expression.
This behavior can, oddly enough, be fixed by using
defaultMode instead of an explicit PPHsMode constructor, but
I can't find any other work-around.
--
Comment By: Nobody/Anonymous (nobody)
Date: 2004-04-22 18:10
Message:
Logged In: NO
I don't see the problem with the first one: | must be
indented less
than the do body to force a }, but not so much that it
forces a ; in an
outer layout context.
Regarding the second one, prettyPrint never inserts
parentheses in
expressions. You have to use HsParen, and the parser leaves
those
in the parse tree. If you're generating source, you'll need
to add it.
Maybe it should be smarter than that, but it would still be
limited,
since there's no information about operator fixity.
-- Ross Paterson
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=940294group_id=8032
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-940294 ] Language.Haskell.Pretty misformats
Bugs item #940294, was opened at 2004-04-22 13:16
Message generated for change (Comment added) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=940294group_id=8032
Category: libraries (other)
Group: 6.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Jon Cast (jcast)
Assigned to: Nobody/Anonymous (nobody)
Summary: Language.Haskell.Pretty misformats
Initial Comment:
ghci gives the following results:
$ ghci -fglasgow-exts
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version
6.2.1, for Haskell 98.
/ /_\/ __ / /___| | http://www.haskell.org/ghc/
\/\/ /_/\/|_| Type :? for help.
Loading package base ... linking ... done.
Prelude :m + Language.Haskell.Syntax
Prelude Language.Haskell.Syntax :m +
Language.Haskell.Pretty Prelude Language.Haskell.Syntax
Language.Haskell.Pretty putStrLn $ prettyPrint $
HsInfixApp (HsDo [HsQualifier (HsVar (UnQual (HsIdent
undefined))), HsQualifier (HsVar (UnQual (HsIdent
undefined)))]) (HsQVarOp (UnQual (HsSymbol |)))
(HsDo [HsQualifier (HsVar (UnQual (HsIdent undefined)))])
Loading package haskell98 ... linking ... done.
Loading package haskell-src ... linking ... done.
do undefined
undefined
| do undefined
Prelude Language.Haskell.Pretty
Language.Haskell.Syntax putStrLn $ prettyPrint $ HsApp
(HsVar (UnQual (HsIdent foo))) $ HsApp (HsVar (UnQual
(HsIdent bar))) $ HsVar (UnQual (HsIdent baz))
foo bar baz
In other words, it mis-indents infix applications and
does /not/ parenthesize nested applications. There may
be other mis-formatting issues, but these are the ones
that have me stopped atm.
--
Comment By: Nobody/Anonymous (nobody)
Date: 2004-04-23 16:55
Message:
Logged In: NO
I'm not clear on what behaviour you want for the original
example. It must indent the |, because the do might itself
be a statement of another do expression. In the bigger one,
you've explicitly asked for an onsideIndent that's the same
as the doIndent, when it should always be smaller. I'll add
this and similar preconditions to the documentation.
The documentation is also lacking in relation to HsParen.
I'm reluctant to improve pretty by adding parentheses,
partly because it's work, and partly because it's only a
partial solution and it's not clear how infix operators
should be handled.
-- Ross
--
Comment By: Jon Cast (jcast)
Date: 2004-04-23 15:14
Message:
Logged In: YES
user_id=762054
Patterson: Well, the first one is more of a QOI issue (and
possibly debatable, although I can't imagine who'd want that
behavior). As for the second issue: are you saying that
(HsApp foo (HsApp bar baz)) is simply illegal or in
some way wrong? That doesn't seem to be documented, and
seems like a bad idea to me anyway. IMHO, it's the most
natural use from the POV of someone reading the Haddock
documentation HsParen is very hard to find, and it's not at
all obvious that it is /required/ whenever the Haskell
syntax requires parentheses.
But, I was inspired to report the first issue by the
following (more complex) test case, which I'm going to
report in full here as it's not too long and definitely
shows incorrect behavior:
putStrLn $ prettyPrintStyleMode style (PPHsMode 2 2 2 2 2 2
True PPOffsideRule False False) $ (HsInfixApp (HsDo
[HsQualifier (HsApp (HsVar (UnQual (HsIdent reserved)))
(HsLit (HsString LineTo))), HsGenerator (SrcLoc
{srcFilename = stdin, srcLine = 1, srcColumn = 1}) (HsPVar
(HsIdent curveSegmentEndPoint)) (HsVar (UnQual
(HsIdentparse))), HsQualifier (HsApp (HsVar (UnQual
(HsIdent return))) (HsApp (HsCon (UnQual (HsIdent
CurveLineTo))) (HsVar (UnQual (HsIdent
curveSegmentEndPoint)]) (HsQVarOp (UnQual (HsSymbol
|))) (HsDo [HsQualifier (HsApp (HsVar (UnQual (HsIdent
reserved))) (HsLit (HsString LineAlong))),HsGenerator
(SrcLoc {srcFilename = stdin, srcLine = 1, srcColumn = 1})
(HsPVar (HsIdent curveSegmentAlong)) (HsVar (UnQual
(HsIdent parse))),HsQualifier (HsApp (HsVar (UnQual
(HsIdent return))) (HsApp (HsCon (UnQual (HsIdent
CurveAlong))) (HsVar (UnQual (HsIdent
curveSegmentAlong)]))
do
reserved LineTo
curveSegmentEndPoint - parse
return CurveLineTo curveSegmentEndPoint
|
do
reserved LineAlong
curveSegmentAlong - parse
return CurveAlong curveSegmentAlong
Note that the operator here is indented by /two/ spaces,
same as the statements in the first do expression.
This behavior can, oddly enough, be fixed by using
defaultMode instead of an explicit PPHsMode constructor, but
I can't find any other work-around.
--
Comment By: Nobody/Anonymous (nobody)
Date: 2004-04-22 16:10
Message:
Logged In: NO
I don't see the problem with the first one: | must be
indented less
than the do body to force a }, but not so much that it
forces a ;
Re: [Haskell] evaluate function as a string
On Fri, Apr 23, 2004 at 03:32:54AM +0200, Sebastian Sylvan wrote: First you need to parse the expression into a Haskell data type. For this I would recommend Parsec (see Haskell.org). The Haskell data type would be something like data Expr = AtomD Double | AtomI Integer | Add Expr Expr | Mul Expr Expr | Sub Expr Expr | There is no need to introduce a datatype - for one parameter functions you can parse text directly to a (Double - Double) function. Of course if you want to do more things with your functions than just evaluation (like printing, symbolic differentiation), introducing a datatype is a good idea. Best regards, Tom -- .signature: Too many levels of symbolic links ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Correct interpretation of the curry-howard isomorphism
Hi, --- Bruno Oliveira [EMAIL PROTECTED] wrote: coerce :: a - b coerce x = undefined As an obvious consequence, Haskell type system would be unsound. Actually, in the isomrphism, undefined is a proof that any theorem is correct. Somehow it can represent an assumption that a subtheorem is true (in place of a real proof -- another function). Of course, this makes corece = undefined rather uninteresting as a proof. So, I assumed that this would be a wrong interpretation. Would the following be more correct? -- if we can write a function: coerce :: a - b without calling any other function or primitive (that is, just with making use of the type system), then this would mean that the type system is unsound. I'd say, check what any primitive 'proves' before using it. Besides that, calling other functions is ok. Cheers, JP. __ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25¢ http://photos.yahoo.com/ph/print_splash ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Correct interpretation of the curry-howard isomorphism
JP Bernardy wrote: I'd say, check what any primitive 'proves' before using it. Besides that, calling other functions is ok. Except for general recursion. coerce :: a - b coerce = coerce -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Correct interpretation of the curry-howard isomorphism
Hi! Thanks Connor, I enjoyed your answer, it was very illustrative. but then, it would be too easy to write this in haskell: coerce :: a - b coerce x = undefined As an obvious consequence, Haskell type system would be unsound. So, I assumed that this would be a wrong interpretation. This is the part of your email which frightens me the most. Of course Haskell's type system is unsound! What factors lead you to this kind of assumption? Clearly a misconception of mine. Is it a good excuse that people told me that (or I misunderstood them) :) ? The type system does not become a logic until you populate some of the types (hopefully only those corresponding to true propositions) with the terms which describe the construction of proofs. You can't pretend that Haskell is sound just by hoping that Curry and Howard (when properly interpreted) won't be able to see the broken bits. It's nonetheless an interesting question which bits you need to throw away to get a sound language. You'll have to get rid of y :: (p - p) - p unJust :: Maybe wmd - wmd and hence the programming language features which enable them to be constructed, in particular, pattern matching with incomplete coverings, and general recursion. Yes, I thought about those implications, that's why I also thought (incorrectly) that it would be too limiting and therefore probably wrongly interpreted. It is also, not too hard to see, as you said, that general recursion would validate that interpretation (even without using any other primitives or functions): coerce :: a - b coerce = coerce or even coerce :: a - b coerce x = let y = y in y Then, even if we ignored the primitives, Haskell would still be unsound! Moreover, we could then say that most of the functional languages (which have a similar type system) are unsound. Right ? Is it Charity an exception on this? There's an interesting paper `Elementary Strong Functional Programming' by David Turner, in which he proposes such a language. He suggests that, at least for paedagogical purposes, a functional language which gave up completeness for consistency might be no bad thing. I'm inclined to agree with him. I will take a look on it. So I won't make any foolish and portentous pronouncements about dependent types being the only way to save us from damnation. I'll merely observe that we often use the unsound parts of programming languages as the best approximations available to the programs we really mean: we don't intend recursion to loop infinitely, we just have no means to explain in the program why it doesn't; we don't intend to apply unJust to Nothing, we just have no means to explain in the program why this can't happen. Dependent types support a higher level of articulacy about what is really going on, reducing, but not removing entirely the need to work outside the consistent fragment of the language. They do not save us from Satan but from Wittgenstein. Whereon you know something, thereon speak! Dependent types definitely seem an advance to me. I saw recently a presentation of a very impressive tool (epigram - I wonder if you have heard about it :P). I'll be definitely take a better look on it as soon as I finish some work with more priority. Best Regards, Bruno ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] evaluate function as a string
Tomasz Zielonka wrote: On Fri, Apr 23, 2004 at 03:32:54AM +0200, Sebastian Sylvan wrote: First you need to parse the expression into a Haskell data type. For this I would recommend Parsec (see Haskell.org). The Haskell data type would be something like data Expr = AtomD Double | AtomI Integer | Add Expr Expr | Mul Expr Expr | Sub Expr Expr | There is no need to introduce a datatype - for one parameter functions you can parse text directly to a (Double - Double) function. Of course if you want to do more things with your functions than just evaluation (like printing, symbolic differentiation), introducing a datatype is a good idea. The original poster used the term equation which to me indicated that he might have things like unknown variables in stuff. In other words: He would have to do some form of manipulation of the expression in order to get the result. /S -- Clothes make the man. Naked people have little or no influence on society. - Mark Twain ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Correct interpretation of the curry-howard isomorphism
On 23/04/2004, at 10:56 PM, Bruno Oliveira wrote: but then, it would be too easy to write this in haskell: coerce :: a - b coerce x = undefined As an obvious consequence, Haskell type system would be unsound. So, I assumed that this would be a wrong interpretation. This is the part of your email which frightens me the most. Of course Haskell's type system is unsound! What factors lead you to this kind of assumption? Clearly a misconception of mine. Is it a good excuse that people told me that (or I misunderstood them) :) ? I'm no expert on this, but I would think that 'undefined' is a property of the dynamic semantics, not static semantics: i.e. although you will get a run-time error when you run the thing, it is still sound with respect to the type system. This is probably the same situation as if you had: coerce :: a - b coerce x = error Foo Both error (i.e. _|_) and undefined are not ill-typed here, but IANATT[1]. 1. I Am Not A Type Theorist -- % Andre Pang : trust.in.love.to.save ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] Why is newChan in the IO Monad?
Yes, that makes sense, but I'm ok with passing in an identity. I'd like a function like this: newChanSafe::Identity - Chan a type Identity = Double -- or whatever -Alex- _ S. Alexander Jacobson mailto:[EMAIL PROTECTED] tel:917-770-6565 http://alexjacobson.com On Fri, 23 Apr 2004, Nick Benton wrote: Channels have identity, so allocating a new one is a side effecting operation. Having it outside the IO monad would require (for example): (newChan, newChan) = (let x = newChan in (x,x)) which is wrong. If you wrap newChan in unsafePerformIO then the compiler will feel free to apply rewrites like the above, which is unlikely to be what you wanted. Nick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of S. Alexander Jacobson Sent: 23 April 2004 19:22 To: Haskell Mailing List Subject: [Haskell] Why is newChan in the IO Monad? Nothing actually happens when newChan is called except construction of a new datastructure. It would be nice to have non IO monad code be able to create a new Chan that gets passed to IO code that uses it somewhere else. Alternatively, is there a way to create a Chan outside the IO monad? -Alex- _ S. Alexander Jacobson mailto:[EMAIL PROTECTED] tel:917-770-6565 http://alexjacobson.com ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] AFP 2004 - Call for Participation
[Early registration deadline: 14 May 2004.] Call for Participation AFP 2004 5th International Summer School on Advanced Functional Programming Tartu, Estonia 14-21 August 2004 http://www.cs.ut.ee/afp04 AFP is a series of international summer schools which aims to bring computer scientist, in particular young researchers and programmers, up to date with the latest advances in practical functional programming. The main focus of the school is on the interface between results presented at programming conferences and the programming in the real world. This is the fifth event in the series organized by the Department of Computer Science of the University of Tartu in conjuction with the Centre for Dependable Computing. The previous schools were held in Båstad (Sweden, 1995), Olympia (Washington, USA, 1996), Braga (Portugal, 1998) and Oxford (UK, 2002). PROGRAMME The scientific programme of AFP'04 consists of short courses by renowned experts of the field and a student session. The school offers eight main courses, each composed of lectures and accompanied by lab sessions. The course list is the following: John Hughes (Chalmers University of Technology): Arrows Conor McBride (University of Durham): Epigram: dependent types for practical programming Alberto Pardo (Universidad de la Republica, Montevideo): Combining datatypes and effects Rinus Plasmeijer (University of Nijmegen): Generic programming techniques for the construction of graphical user interfaces A strongly typed functional operating system based on dynamics Bernie Pope (University of Melbourne): Declarative debugging with Buddha Doaitse Swierstra (Utrecht University) and Atze Dijkstra (Utrecht University): Typing Haskell with an Attribute Grammar Peter Thiemann (University of Freiburg): Server-side Web programming in WASH Simon Thompson (University of Kent): Refactoring Functional Programs In addition, there will be some introductory and intermediate functional programming courses serving as a preparation for the advanced courses. The purpose of the student session is to give students an opportunity to present their work and get feedback. Everyone intending to give a presentation should submit an extended abstract (max 10 pp) along with the registration form. VENUE Tartu, with 100,000 inhabitants, is the second largest city in Estonia, situated 180 km south-east from Tallinn. Tartu University, founded 1632, is one of the oldest universities in Northern Europe. The school will be held in the new building of the Faculty of Mathematics and Computer Science. Tartu is accessible from Tallinn by coach. The coaches run very frequently (1-2 departures per hour) and the ride takes 2-2.5 hrs. Tallinn, with 400,000 inhabitants, is the capital city of Estonia, that used to be a member of the Hansa League. Tallinn's medieval Old Town is on the UNESCO World Heritage List. There are direct flights to Tallinn from London, Paris, Amsterdam, Frankfurt, Hamburg, Munich, Berlin, Prague, Warsaw, Moscow, Copenhagen, Oslo, Stockholm, Helsinki. IMPORTANT DATES May 14, 2004Early registration deadline July 9, 2004Late registration deadline REGISTRATION AND COST The registration is done through internet (http://www.cs.ut.ee/afp04/submreg.ht ml). The deadline for registration is July 9, 2004 and the registration fee is 330 EUR. For early registrants, until May 14, there is a reduced registration fee 280 EUR. The registration fee includes course materials distributed during the school, revised lecture notes published by Springer after the school, lunches, refreshments for coffee breaks and conference dinner. AFP'04 is an APPSEM II affiliated event, hence APPSEM II sites can use the project funds to support their students' participation in the school. PROGRAMME COMMITTEE / ORGANIZING COMMITTEE Varmo Vene University of Tartu Tarmo Uustalu Institute of Cybernetics Johan Jeuring Utrecht University SPONSORS Ministry of Education and Research (via the centres of excellence in research programme) APPSEM II - FP5 IST thematic network Applied Semantics II CONTACT [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] Why is newChan in the IO Monad?
Double is a pretty poor choice of whatever (just thinking about equality of floating point numbers puts one in a state of sin :-)). Worse still, your newChanSafe would be type-unsafe if you gave it that polymorphic type (think about it). So let's assume channels aren't polymorphic and that we were were going to use ints or strings or something as identities. Then since your newChan has got to be injective, you could just identify chan with int and be done with it. Even then, there's still quite a lot going on: Firstly, of course, the equation I wrote *does* actually hold in Haskell with the current definitions. But it would fail to hold if newchan were a non-normal form, each evaluation of which returned a new name, which was what was intended. Secondly, if you manage your own channel identities you'll end up carrying around a current identity/name supply and having an operation which takes a supply and gives you a fresh name and a new supply. That's just another monad (TX = supply-X*supply, gensym : Tname). If the type you use for names isn't abstract (e.g. you just use int) then the resulting equational theory will be weak (because contexts can supply all the names). A more refined treatment is possible. If (and only if) you make the type of names and their operations more abstract then there is a very nice monad just for name generation, which you could separate from the monad for actually sending and receiving values. One advantage of doing that is that the dynamic allocation monad satisfies more equations than the IO monad (it's commutative, for example). Then there's a monad morphism that lets you lift new name generation into the IO monad when you want to use the channels (IO is definitely not commutative). If you want to do fancy program transformations then this extra refinement is helpful. If you don't, having two monads instead of one just makes life even more complicated. Now, giving newChan a non-monadic type amounts to making this new name monad *implicit* - allowing divergence and/or name-generation to happen during evaluation without reflecting either possibility in the types. As I said, this breaks the equational theory of the language. But other people have taken the position that maybe it doesn't break it all that badly, and that one can make sure that the compiler's transformations respect the weaker theory [1]. This is what happens in observable sharing, which was suggested precisely because others, like you, found doing gensym monadically in Haskell to be a bit tedious: K. Claessen and D. Sands. Observable sharing for functional circuit description. In ASIAN'99, volume 1742 of Lecture Notes in Computer Science, pages 62--73. Springer-Verlag, 1999. Names in circuit descriptions are used to express the sharing which distinguishes cyclic circuits from infinite ones. In the case of channels, however, you don't just compare the names for equality - all non-trivial uses of them are going to involve sends and receives and hence put you into the IO monad anyway. So messing up the theory of the whole language just to to have a few fewer IOs doesn't seem a good tradeoff. If you're interested in the theory, there's a big (and rapidly growing!) literature on the semantics of name generation - see the work of Pitts Stark on the \nu-calculus, for example. To summarize the above ramble: it's an excellent question, but you almost certainly want to leave newChan where it is. Nick [1] arguably, including strict constructs (pattern matching, strict sequencing) is already a step down this road. But the Haskell/Miranda war of the bottoms was all a long time ago... -Original Message- From: S. Alexander Jacobson [mailto:[EMAIL PROTECTED] Sent: 23 April 2004 20:05 To: Nick Benton Cc: Haskell Mailing List Subject: RE: [Haskell] Why is newChan in the IO Monad? Yes, that makes sense, but I'm ok with passing in an identity. I'd like a function like this: newChanSafe::Identity - Chan a type Identity = Double -- or whatever -Alex- _ S. Alexander Jacobson mailto:[EMAIL PROTECTED] tel:917-770-6565 http://alexjacobson.com On Fri, 23 Apr 2004, Nick Benton wrote: Channels have identity, so allocating a new one is a side effecting operation. Having it outside the IO monad would require (for example): (newChan, newChan) = (let x = newChan in (x,x)) which is wrong. If you wrap newChan in unsafePerformIO then the compiler will feel free to apply rewrites like the above, which is unlikely to be what you wanted. Nick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of S. Alexander Jacobson Sent: 23 April 2004 19:22 To: Haskell Mailing List Subject: [Haskell] Why is newChan in the IO Monad? Nothing actually happens when newChan is called except construction of a new datastructure. It would be nice to have non IO monad code be
Re: [Haskell-cafe] Syntax for modifying nested product types
On Fri, Apr 23, 2004 at 10:11:40AM +0100, Malcolm Wallace wrote:
If the pattern is very common, how about just naming it?
perhaps cond f field = if cond then f field else field
foo { bar = perhaps cond0 f (bar foo)
, wib = perhaps cond1 g (wib foo) }
Good idea, but I think that name like 'applyIf' or 'condApply' would be
better.
Best regards,
Tom
--
.signature: Too many levels of symbolic links
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Syntax for modifying nested product types
Malcolm Wallace wrote:
perhaps cond f field = if cond then f field else field
foo { bar = perhaps cond0 f (bar foo)
, wib = perhaps cond1 g (wib foo) }
I tend to write functions:
upd_bar f x = x { bar = f (bar x) }
upd_wib f x = x { wib = f (wib x) }
in order to avoid mentioning the field names twice later on. Does it
cost much if I sometimes supply id as update argument?
It would be nice if such update functions could be generated or if there
were another special update syntax. Does it exist in other languages?
Cheers Christian
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Syntax for modifying nested product types
I would just do:
f' = if cond0 then f else id
g' = if cond1 then g else id
foo { bar = f' (bar foo) , wib = g' (wib foo) }
I like seeing the record updated, rather than hiding it
in a function.
Regards,
Keean.
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Syntax for modifying nested product types
At 18:18 22/04/04 -0400, Mark Carroll wrote:
I have data objects where each component is a labelled field through which
I access or modify it.
Wading into the labelled field debate...
I have found that using the labelled field update syntax can lead to
difficulties in changing the underlying implementation of a type.
I found this in particular when re-implementing the Network.URI module: I
found that I needed to change the internal representation of the URI type
in order to satisfy the recently clarified URI specification. The knock-on
effect of this was mitigated to some extent by implementing the original
field names as functions to extract values corresponding to the original
components. But I found when porting the HXml Toolbox and/or HTTP code to
use this new implementation that while field references would still work as
intended, occurrences of the field update syntax had to be re-coded; there
remained external dependencies on the internal structure of URI that could
not be shimmed away with new functions.
This leads me to ask, if new syntax approaches for labelled fields are
being considered, if it would be possible to adopt an approach in which the
field name works like a function for both access *and* updating of a field
record.
A clumsy example of this might be a field name used as a query-and-set
function:
data record { field :: atype, ... }
yields
field :: record - (atype - atype) - (record,atype)
then
arecord :: record
arecord = ...
fval = snd field arecord id -- returns value of field
rval = fst field arecord (const newval) -- returns updated record
(this is to illustrate a desideratum, not a serious suggestion. Something
is tickling the back of my mind about possibly doing this with a Monad.)
With a field name working as a function (the same function) for both access
and update, it is then possible to change the internal structure of a
record yet retain the possibility of presenting a backwards-compatible
interface.
#g
Graham Klyne
For email:
http://www.ninebynine.org/#Contact
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Splitting a list
On Wed, 21 Apr 2004 14:57:57 +0100, you wrote: How about implementing a directly recursive solution? Simply accumulate the sum so far, together with the list elements you have already peeled off. Once the sum plus the next element would exceed the threshold, emit the accumulated elements, and reset the sum to zero. splitlist threshold xs = split 0 [] xs where split n acc [] = reverse acc: [] split n acc (x:xs) | x = threshold = error (show x++ exceeds threshold ) | n+x threshold = reverse acc : split 0 [] (x:xs) | otherwise = split (n+x) (x:acc) xs Thanks. Apart from a small off-by-one problem (the x = threshold test needs to be x threshold instead), it works fine. I had actually started along those lines, but got bogged down in the details of passing the accumulator around, and ended up painting myself into a corner, so I abandoned that approach (prematurely, as it turns out). And thanks to everyone else who replied--I don't want to clutter the list with a lot of individual replies. As you can probably tell, I've only recently begun playing with Haskell, and the process of reconfiguring my neurons into recursive loops has not yet been completed. -Steve ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Syntax for modifying nested product types
Graham Klyne [EMAIL PROTECTED] writes: At 18:18 22/04/04 -0400, Mark Carroll wrote: I have data objects where each component is a labelled field through which I access or modify it. Wading into the labelled field debate... I have found that using the labelled field update syntax can lead to difficulties in changing the underlying implementation of a type. Yeah, interesting this topic came up exactly when I got mad with record updates. I'd like to fill in a record from a file which contains labels and values. I'd like to give the gist of this operation as a list of pairs: [(label1, label1), (label2, label2), ...] and abstract away the operation of updating the field. I couldn't find a way. Basically, I couldn't write an update function parametrized by the field name. Is it possible at all? -- Feri. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] FiniteMap, Map, FiniteSet, Set
Here's a really elementary question: Why does the library have [FiniteMap and Set] instead of [FiniteMap and FiniteSet] or just [Map and Set]? Is there some reason for this inconsistency? Thanks, James ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FiniteMap, Map, FiniteSet, Set
On Fri, Apr 23, 2004 at 08:02:47PM -0500, [EMAIL PROTECTED] wrote: Why does the library have [FiniteMap and Set] instead of [FiniteMap and FiniteSet] or just [Map and Set]? Is there some reason for this inconsistency? Historical accident mainly. There is discussion going on in the haskell library list about rectifying this using a variation of daan's excelent DData collections. http://www.cs.uu.nl/~daan/ddata.html -- John Meacham - repetae.netjohn ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
