RE: Changes made by GADT commit conflict with -O2 flag
Excellent point. It exposes an infelicity in the handling of
substitutions. I'm ruminating on it
S
| -Original Message-
| From: Sean Seefried [mailto:[EMAIL PROTECTED]
| Sent: 12 October 2004 08:27
| To: [EMAIL PROTECTED]
| Cc: Simon Peyton-Jones
| Subject: Changes made by GADT commit conflict with -O2 flag
|
| ---
| ---
| The last 30 lines of
| /Users/sseefried/cvs-ghc/HEAD/logs/HEAD-cmis-stage2 are
| ---
| ---
|
| utils/PrimPacked.lhs:244:0:
| Warning: foreign declaration uses deprecated non-standard syntax
|
| utils/PrimPacked.lhs:248:0:
| Warning: foreign declaration uses deprecated non-standard syntax
|
| utils/PrimPacked.lhs:251:0:
| Warning: foreign declaration uses deprecated non-standard syntax
|
| utils/PrimPacked.lhs:254:0:
| Warning: foreign declaration uses deprecated non-standard syntax
|
| utils/PrimPacked.lhs:257:0:
| Warning: foreign declaration uses deprecated non-standard syntax
| ghc-6.3: panic! (the `impossible' happened, GHC version 6.3):
| app_match: unbound tpl s{tv a1E9}
|
| Hi all,
|
| Believe it or not I've been compiling the GHC HEAD stage 2 compiler
| with the -O2 flag and it doesn't seem to be playing very nicely with
| the changes recently committed for the GADT feature. This panic is
| emitted by specialise/Rules.lhs
|
| If I use the flag the -O utils/PrimPacked.lhs will still compile.
|
| Sean
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: -ddump-minimal-imports and -hidir / -odir
On 12 October 2004 18:06, Peter Simons wrote: is it possible that GHC doesn't process the -hidir and -odir command-line options correctly when -ddump-minimal-imports is given as well? I have had this problem right now and removing the -(hi|o)dir flags fixed it, so I figured I'd better say something. ;-) A quick test doesn't show up anything obviously wrong. Can you give more details? Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Mutually recursive modules and derived instances of Data
| If I have two modules which are mutually recursive; | | module A where | import B | data TA = TA TB deriving (Data, Typeable) | | module B where | import A | data TB = TB TA deriving (Data, Typeable) | | How do I go about writing a hi-boot that will work in GHC? Good question. At the moment, GHC does not let you put instance declarations in hi-boot files, mainly because instances (being anonymous) are a bit weird. Usually this is OK -- just put the instances outside the loop. But if you want to derive the instances (which is Jolly Convenient) you can't do that. At the moment all you can do is write the instances by hand; sorry. (-ddump-deriv will show you the code GHC itself generates, which you can more or less cut and paste) Two fixes suggest themselves 1. Separate 'deriving' from the data type decl, so you can say derive( Data TA, Typeable TA ) anywhere. People sometimes ask for this for other reasons. 2. Allow instances in hi-boot files You might say both would be useful, but I'd be interested in people's opinions about which of (1) or (2) would be preferable if you could only have one or t'other. Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Mutually recursive modules and derived instances of Data
On Wed, 13 Oct 2004 13:21:26 +0100, Simon Peyton-Jones [EMAIL PROTECTED] wrote: 1. Separate 'deriving' from the data type decl, so you can say derive( Data TA, Typeable TA ) anywhere. People sometimes ask for this for other reasons. 2. Allow instances in hi-boot files You might say both would be useful, but I'd be interested in people's opinions about which of (1) or (2) would be preferable if you could only have one or t'other. 1! As you say, people sometimes ask for this for other reasons. I'm one of them, though I'm not sure if I've actually asked about it on the list. Separating deriving from the declaration would be incredibly useful. /Martin ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
deriving...
What is the situation with deriving?
Some instances can be derived automatically for both data/newtype (built in)?
Some instances cen be derived automatically for newtype (any)?
You used to be able to define functions useing {|+|} and {|*|} (or similar)
that could be derived for both data and newtype.
What is the current status, which methods are supported, and will be
supported going forward.
I ask this because looking at the code in the compiler it seems very
difficault to extend. It would be to specify how to derive new instances
once and for all...
Keean.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: deriving...
(I assume you mean GHC.)
Don't look at the compiler, look at the user manual. That describes
what's supported. I have no current plans to withdraw any of the
current support.
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of MR K P SCHUPKE
| Sent: 13 October 2004 14:06
| To: [EMAIL PROTECTED]
| Subject: deriving...
|
|
| What is the situation with deriving?
|
| Some instances can be derived automatically for both data/newtype
(built in)?
|
| Some instances cen be derived automatically for newtype (any)?
|
| You used to be able to define functions useing {|+|} and {|*|} (or
similar)
| that could be derived for both data and newtype.
|
| What is the current status, which methods are supported, and will be
| supported going forward.
|
| I ask this because looking at the code in the compiler it seems very
| difficault to extend. It would be to specify how to derive new
instances
| once and for all...
|
| Keean.
| ___
| 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
Re: Mutually recursive modules and derived instances of Data
Hi Simon! On Wed, Oct 13, 2004 at 01:21:26PM +0100, Simon Peyton-Jones wrote: Two fixes suggest themselves 1. Separate 'deriving' from the data type decl, so you can say derive( Data TA, Typeable TA ) anywhere. People sometimes ask for this for other reasons. Good thing. Plus, allow to hook in Template Haskell at some point, so that import DeriveMyClass derive(MyClass TA) is equivalent to import DeriveMyClass $( deriveMyClass (reifyDecl TA) ) (or whatever the TH-syntax will be at that point :-) Then data TA = ... deriving (MyClass) should also be possible. The advantage would be that only the module defining the deriving would have to know about TH, not the one using it. On other systems, the deriving could then be realized via a pre-processor or similar means. Greetings, Carsten -- Carsten Schultz (2:38, 33:47), FB Mathematik, FU Berlin http://carsten.codimi.de/ PGP/GPG key on the pgp.net key servers, fingerprint on my home page. pgpqfms1mBHHr.pgp Description: PGP signature ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: deriving...
look at the user manual. Okay, I see the Generic type class stuff does not support multi parameter type classes. I guess I am stuck - any suggestions as to how best do this? I wish to be able to derive type level labels for datatypes, like the following: data Fred a = Fred a deriving TTypeable generates the instance: instance TTypeable a al = TTypeable (Fred a) (NCons (N3 (N4 (N5 Nil))) (TCons al Nil)) where (N3 (N4 (N5 Nil))) is the result of a hash function on the name Fred. I have looked at TcDeriv but I don't know enough of the compiler internals to see how this would be added to the current implementation... Can you give me some pointers on how to do this? Keean. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: deriving...
On 13/10/2004, at 10:02 AM, MR K P SCHUPKE wrote: Okay, I see the Generic type class stuff does not support multi parameter type classes. I guess I am stuck - any suggestions as to how best do this? I wish to be able to derive type level labels for datatypes, like the following: data Fred a = Fred a deriving TTypeable generates the instance: instance TTypeable a al = TTypeable (Fred a) (NCons (N3 (N4 (N5 Nil))) (TCons al Nil)) If you are happy to live on the edge a bit (which you seem to be happy with, considering that you're playing with GHC CVS ;), Template Haskell might be one way to do it. See Template Haskell: A Report from the Field, a paper where Ian Lynagh does exactly what you're trying to do: http://www.haskell.org/th/papers.html -- % Andre Pang : trust.in.love.to.save ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: deriving...
Yes, I could quite easily write the generator in TemplateHaskell (have played with it before) _but_ I don't like the $(xxx) syntax... Perhaps if Simon could be persuaded to allow deriving clauses to be defined in TH? data X x = X x $(deriveMyClass (reify X)) could perhaps be defined from data X x = X x deriving MyClass I saw the same suggestion earlier today on the Haskell list... Keean. Andre Pang wrote: On 13/10/2004, at 10:02 AM, MR K P SCHUPKE wrote: Okay, I see the Generic type class stuff does not support multi parameter type classes. I guess I am stuck - any suggestions as to how best do this? I wish to be able to derive type level labels for datatypes, like the following: data Fred a = Fred a deriving TTypeable generates the instance: instance TTypeable a al = TTypeable (Fred a) (NCons (N3 (N4 (N5 Nil))) (TCons al Nil)) If you are happy to live on the edge a bit (which you seem to be happy with, considering that you're playing with GHC CVS ;), Template Haskell might be one way to do it. See Template Haskell: A Report from the Field, a paper where Ian Lynagh does exactly what you're trying to do: http://www.haskell.org/th/papers.html ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
x86_64: odd success
So my AMD64 books have been burning a hole in my bookshelf for so long, I finally went out and got a athlon 64 and installed fedora core 2. much to my dismay, ghc does not seem to work out of the box. I took the following steps. ; yum install gmp.i386 readline.i386 now a rpm -U of the ghc rpms works great. ghci works properly, and ghc seems to almost work when compiling. the expected happens when I try to compile directly. ;ghc Main.hs -o main # ~/tmp/x-03 10:26PM [EMAIL PROTECTED] /usr/bin/ld: skipping incompatible /usr/lib/ghc-6.2.1/libHShaskell98.a when searching for -lHShaskell98 /usr/bin/ld: cannot find -lHShaskell98 collect2: ld returned 1 exit status however, what I expected to work, doesn't. ;ghc -optl-m32 -opta-m32 -optc-m32 Main.hs -o main # ~/tmp/x-03 10:36PM [EMAIL PROTECTED] 1 compilation IS NOT required /usr/bin/ld: skipping incompatible /usr/lib64/libgmp.so when searching for -lgmp /usr/bin/ld: skipping incompatible /usr/lib64/libgmp.a when searching for -lgmp /usr/bin/ld: cannot find -lgmp collect2: ld returned 1 exit status everything seems to work perfectly however, if I take the gcc command that ghc would have run (gotten via ghc -v) and simply replace -lgmp with /usr/lib/libgmp.so.3 so, any idea what the problem is? in -m32 mode linux seems to get everything else right, but it can't seem to find that gmp without help. Also, it would be nice if ghc automatically passed -m32 when it was in x86_64 mode and wanted to create i386 code, once this happens, (and the gmp thing is worked out) then x86_64 should work perfectly when creating i386 binaries and I can get started on what I really want to do, which is create a native x86_64 ghc :) It would also be quite important for ghc to support a -m32 flag itself, so I can continue to create i386 and x86_64 builds from the same ghc binary. but one problem at a time.. John -- John Meacham - repetae.netjohn ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] Global Variables and IO initializers: A proposal and semantics
On 12 Oct 2004, at 23:33, John Meacham wrote: and via the FFI just a foreign import global_var :: Ptr Int note that we do not need any foregin code, just an object which allocates the space in the bss for global_var, the fact we can access and work with such space from haskell, but have no way to allocate it is quite telling that there is something missing in the language. Yes, that's weird, isn't it? The basic idea is that your entire program behaves as if in a giant 'mdo' block, ordered in module dependency order. I wondered if something like that could work, but I wasn't sure that mdo allowed recursion in its let-bindings... Jules ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] threading mutable state through callbacks
Wolfgang Thaller [EMAIL PROTECTED] schrieb am 13.10.04 04:36:43: 2) Evaluation order. That's what everyone has been fighting about. So what are our options? a) unsafePerformIO - like. b) Some predetermined order, with semantics like mdo: c) same as b) plus unsafeInterleaveIO In fact, I think a specified order for side-effecting initialisation is a good thing. Initialisation should happen in order of declaration and in order of module dependecies. An initialisation that is to be performed lazily is simply wrapped in unsafeInterleaveIO. Anything wrong with that aproach? Regards, Udo. Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193 ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] lazy constructors
Question 2 -- How to arrange the above `lazy' output? Your function addToSPair addToSPair :: Char - (String, String) - (String, String) addToSPairc (xs, ys) = (c:xs, ys) does a strict pattern match on the pair constructor. It needs to know that its second argument is a pair before it produces anything of its result. If you use a lazy pattern match addToSPair :: Char - (String, String) - (String, String) addToSPairc ~(xs, ys) = (c:xs, ys) instead, it doesn't need to evaluate this argument immediately. Regards, Sander ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] lazy constructors
You can only return a list of pair's lazily, not a pair of lists. If the two strings are independant, then generate each in a separate function, and pair off the results lazily. Keean. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Global Variables and IO initializers: A proposal and semantics
On Wed, Oct 13, 2004 at 07:20:06AM +0100, Jules Bean wrote: On 12 Oct 2004, at 23:33, John Meacham wrote: and via the FFI just a foreign import global_var :: Ptr Int note that we do not need any foregin code, just an object which allocates the space in the bss for global_var, the fact we can access and work with such space from haskell, but have no way to allocate it is quite telling that there is something missing in the language. Yes, that's weird, isn't it? Yeah, I noticed this oddity when I found I could create very fast global variables via this trick and peeks and pokes to read/write them. but the stub C file with just a 'int var;' was sort of silly, especially when I knew that didn't generate any code at all, just some allocated space. The basic idea is that your entire program behaves as if in a giant 'mdo' block, ordered in module dependency order. I wondered if something like that could work, but I wasn't sure that mdo allowed recursion in its let-bindings... The mdo implementation in ghc does not actually, but that is mainly to simplify some odd cases when a variable will appear monomorphic in one place and polymorphic in another and is not actually a restriction of recursive monads in general nor does it change the semantics of the fixpoint operations on them, which is the main item I was trying to leverage from those papers. In section 3.2 of the mdo paper, an alternate translation of mdo is given which does allow polymorphic let bindings and that is the translation which should be used if you were to actually implement the program transformation I described. Note that since we 'push' all the normal declarations of a module above all monadic bindings, we don't run into the polymorphic problem described in the paper, as our polymorphic normal declarations scope over the entire expression in which they may be used. John -- John Meacham - repetae.netjohn ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] threading mutable state through callbacks
On Wed, Oct 13, 2004 at 10:01:08AM +0100, Adrian Hey wrote: On Wednesday 13 Oct 2004 3:36 am, Wolfgang Thaller wrote: b) Some predetermined order, with semantics like mdo: John Meacham wrote: The basic idea is that your entire program behaves as if in a giant 'mdo' block, ordered in module dependency order. What is module dependency order? There's no such thing when there are circular dependencies, and when there aren't any, it might still depend on the order of import directives, which is probably not something I want program semantics to depend on. I feel that In a large program, you'll probably get more surprises from this. The good thing is that you can always use unsafeInterleaveIO to get the other semantics back, so we should probably investigate this further. Yes, this is something I wasn't too clear about, largely because I'm not too certain about the precise semantics of mdo (never actually used it). John's proposal seemed like a good formalisation of what a compiler might do in reality to implement this. But if it means imposing some order on things (other than the dependency on demand ordering that we currently get with the unsafePerformIO hack) I'm not sure that's a good idea. I would rather have the order unspecified and make it the programmers responsibility to control this, if significant. Having the correctness of programs dependent on ordering of top level definitions or imports is not a discipline Haskellers are used to. If this is the case with John's proposal, it seems like it could cause trouble in the long run :-( Yeah, there actually is not a real need to formalize the order, since the top-level bindings are going to be recursive and lazy, A specific order doesn't matter much more than what order you allocate your CAFs in. However, since IO actions can have side effects and enforce evaluation, one may specifically write code which will be able to observe the order. This doesn't seem like that big of a deal, since the result of an IO action is allowed in some sense to depend on implementation or undefined behavior and it certainly shouldn't be a problem for the common cases of IORefs, MVars and global Channels. I would be perfectly happy with just specifying an unknown order, or just that all the bindings in a single module be ordered in the same way as they appear in the module, but intramodule orders be unspecified. the method I posted happens to execute the actions in dependency order, but there is no need to guarentee that. John -- John Meacham - repetae.netjohn ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Global Variables and IO initializers: A proposal and semantics
On 13 Oct 2004, at 00:04, Greg Buchholz wrote: John Meacham wrote: I have put some thought, some time ago, into the 'global initializers' problem in haskell but for various reasons never wrote up my conclusions. I'm not really qualified to answer, but does anyone think that this paper might have a solution? http://www.eecs.harvard.edu/~ccshan/prepose/prepose.pdf Yes, that is a solution to an instance of the problem. The discussions here are looking for a different one... possibly a more general one. Jules ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] threading mutable state through callbacks
On 12 Oct 2004, at 22:49, MR K P SCHUPKE wrote: All we really need is a 'unique value monad' to give us unique values This sounds a lot like Clean's unique-types? No, that's a confusion of terminology. 'Unique types' are type which have only one member. 'RealWorld' in haskell is rather like one of these (IO a == ST RealWorld a). They are a way of enforcing threading (sequential computation) which is lighter-weight in some sense than monads. 'A unique value monad' is just a monad whose job it is to dole out fresh values: do a - fresh b - fresh insertDBRecord(a,Bean) insertDBRecord(b,Schupke) ..such as you might for record identifiers, or whatever. It's trivial to implement one in haskell. What I meant by saying that its almost commutative is that, for any implementation, if you reverse 'a - fresh' and 'b - fresh' you probably do get different answers, but it doesn't matter, because the specification is merely that they be different from each other. The algorithm which generates the numbers is opaque to the consumer anyway. The IO monad is a whole lot more than a unique value monad, but the 'newIORef' command is a much like 'fresh' above. My point was just that for global variables, we don't necessarily need a top-level IO monad (which gives you ordering concerns) just a top-level fresh value monad (which is essentially commutative, so you don't have ordering concerns). Jules ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] threading mutable state through callbacks
its almost commutative Does that have something to do with splitting the supply? newIORef why not use 'newSTRef' and use the ST monad... Keean. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] threading mutable state through callbacks
On 13 Oct 2004, at 13:14, MR K P SCHUPKE wrote:
its almost commutative
Does that have something to do with splitting the supply?
That is an approach to getting unique values, I think.
newIORef
why not use 'newSTRef' and use the ST monad...
In the context of my original question, the answer is that the control
flow of the program passes through external libraries ('C' code, if you
like to think of it that way), and the callbacks in question have
signature IO(), so they are constrained to store all their state in the
IO monad.
Were it not for this problem, the ST monad would indeed seem more
elegant. And some explicit state monad with a nicely designed set of
state for your application is probably more elegant still... but
unfortunately that isn't possibly. Unless its possible to arrange
haskell FFI bindings to have types in MonadIO rather than IO... (a
question which I asked earlier but no one has answered).
Juels
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] threading mutable state through callbacks
There are stToIO and ioToST sunctions though (ioToST is unsafe)...
Keean
Jules Bean wrote:
On 13 Oct 2004, at 13:14, MR K P SCHUPKE wrote:
its almost commutative
Does that have something to do with splitting the supply?
That is an approach to getting unique values, I think.
newIORef
why not use 'newSTRef' and use the ST monad...
In the context of my original question, the answer is that the control
flow of the program passes through external libraries ('C' code, if
you like to think of it that way), and the callbacks in question have
signature IO(), so they are constrained to store all their state in
the IO monad.
Were it not for this problem, the ST monad would indeed seem more
elegant. And some explicit state monad with a nicely designed set of
state for your application is probably more elegant still... but
unfortunately that isn't possibly. Unless its possible to arrange
haskell FFI bindings to have types in MonadIO rather than IO... (a
question which I asked earlier but no one has answered).
Juels
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] is $ a no-op?
In a *lot* of places in my programs, I am using notation f $ g $ h x in favour of f (g (h x)) (that's the '$' as defined in the Prelude: right-associating infix application operator) as it avoids parentheses, and makes the code more manageable (you can write (upward) pipes with one $ f per line, etc) I liked to think of it as just a syntactical convention (for years ...) but is it really at no cost? It does introduce extra function calls, that is, extra closures etc.? Can these be removed by ghc's optimizer? Or am I totally wrong here ... Actually, looking at the Prelude (now), there is '$!' as well - is that supposed to answer my question? -- -- Johannes Waldmann, Tel/Fax: (0341) 3076 6479 / 6480 -- -- http://www.imn.htwk-leipzig.de/~waldmann/ - ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] [ANNOUNCE] Hacle
Dear Haskellers and Cleaners, You may be interested in the results of my final-year student project at the University of York. It involved the development of a translator from Haskell to Clean; an idea that probably won't be too unfamiliar to most of you. The project's homepage is: http://www.cs.york.ac.uk/~mfn/hacle/ I hope that you enjoy the read, and find the results of interest. Kind regards. -- Matthew ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] threading mutable state through callbacks
On 13 October 2004 03:36, Wolfgang Thaller wrote: b) Some predetermined order, with semantics like mdo: John Meacham wrote: The basic idea is that your entire program behaves as if in a giant 'mdo' block, ordered in module dependency order. I also like the mdo idea - in fact it occurred to me yesterday, but I wasn't sure whether there would be any gotchas when the details were worked out, and it looks like John has established that things work out nicely. GHC already has an initialisation procedure for each module in the program which could be adapted to run the initialisation-time IO actions, with a little effort. I'm more worried about what other changes we have to make to the compiler: if we can avoid having to flag top-level bindings as monadic/non-monadic all the way through the compiler, then we could avoid a pervasive change to the compiler. At the moment I can't see an obvious way to do that. What is module dependency order? There's no such thing when there are circular dependencies, and when there aren't any, it might still depend on the order of import directives, which is probably not something I want program semantics to depend on. I feel that In a large program, you'll probably get more surprises from this. The good thing is that you can always use unsafeInterleaveIO to get the other semantics back, so we should probably investigate this further. GHC's init blocks are run in dependency order, picking an arbitrary depth-first traversal when there's a recursive module dependency. Seems as good a choice as any. Cheers, Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] (no subject)
b) Some predetermined order, with semantics like mdo: Hmm, I just realized that this also means we can execute moduke intialisation code that returns no result using: _ - do ... I like that, I desperately need that for my Objective-C binding... So the extension with the specified order actually allows one to do more things than the unsafePerformIO hack. I wouldn't care about specifying the order otherwise. If the default order is wrong, people can still use unsafeInterleaveIO. GHC already has an initialisation procedure for each module in the program which could be adapted to run the initialisation-time IO actions, with a little effort. Hmm, doesn't the initialisation procedure run before the Stg machine is properly set up? I guess all the GHC init code could do is to register IO actions to be executed later (but before main is run). We probably want all the GHC module init procedures to be run before we execute any IO actions. I'm more worried about what other changes we have to make to the compiler: if we can avoid having to flag top-level bindings as monadic/non-monadic all the way through the compiler, then we could avoid a pervasive change to the compiler. At the moment I can't see an obvious way to do that. We could get away with desugaring them to some very unsafe non-IO- bindings and having the module init action do something evil to make the IO happen in the right order... should be possible to make that look exactly like mdo from the outside. We'll end up using the unsafePerformIO hack inside the implementation again, so that people end up with two IORefs instead of one, but that should be cheap enough: foo - someAction ... could be transformed into ... foo_var = unsafePerformIO $ newIORef (throw NonTermination) foo_action = someAction = writeIORef foo_var foo = unsafePerformIO $ readIORef foo ... with the appropriate NOINLINEs. The module init action would then make sure that foo_action gets invoked. So we'd only need to annotate modules with a list of init actions and extend the RTS appropriately for that... Cheers, Wolfgang -- GMX ProMail mit bestem Virenschutz http://www.gmx.net/de/go/mail +++ Empfehlung der Redaktion +++ Internet Professionell 10/04 +++ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] threading mutable state through callbacks
Wolfgang Thaller wrote: 2) Evaluation order. That's what everyone has been fighting about. [...] The basic idea is that your entire program behaves as if in a giant 'mdo' block, ordered in module dependency order. What is module dependency order? There's no such thing when there are circular dependencies, and when there aren't any, it might still depend on the order of import directives, which is probably not something I want program semantics to depend on. I feel that In a large program, you'll probably get more surprises from this. The Modula-3 language specification gives one reasonable definition: ===Begin excerpt. From http://research.compaq.com/SRC/m3defn/html/complete.html#idx.148 : 2.5.6 Initialization The order of execution of the modules in a program is constrained by the following rule: If module M depends on module N and N does not depend on M, then N's body will be executed before M's body, where: A module M depends on a module N if M uses an interface that N exports or if M depends on a module that depends on N. A module M uses an interface I if M imports or exports I or if M uses an interface that (directly or indirectly) imports I. Except for this constraint, the order of execution is implementation-dependent. ===End excerpt. According to the above constraint, the initialization order is implementation-defined in the case of circular dependencies. Note, too, that the order of import directives in a module does not affect the partial order imposed by the above constraint. (The above was delayed by the haskell mailing list anti-spam measures. Anyway, looks like the above rule is entirely consistent with Simon Marlow's description of what ghc already implements for initialization order.) -Antony ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] is $ a no-op?
At 15:55 13/10/04 +0200, Johannes Waldmann wrote: In a *lot* of places in my programs, I am using notation f $ g $ h x in favour of f (g (h x)) (that's the '$' as defined in the Prelude: right-associating infix application operator) as it avoids parentheses, and makes the code more manageable (you can write (upward) pipes with one $ f per line, etc) I liked to think of it as just a syntactical convention (for years ...) but is it really at no cost? It does introduce extra function calls, that is, extra closures etc.? Can these be removed by ghc's optimizer? I don't think it's *just* a syntactic convention, but in your case above I think they both yield the same function graph for evaluation so I see no cost there. Here's a little $-based idiom I rather like, which shows $ as more than just a no-op: [[ -- |Apply list of functions to some value, returning list of results. -- It's kind of like an converse map. -- -- This is similar to the 'ap' function in the Monad library. -- flist :: [a-b] - a - [b] flist fs a = map ($ a) fs ]] I suppose you could say that $ is a kind of syntactic convention, because without it juxtaposition for function application lacks the lexical visibility for expression in different syntactic contexts. Or am I totally wrong here ... Actually, looking at the Prelude (now), there is '$!' as well - is that supposed to answer my question? Well, that's a different function, I think. #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Global Variables and IO initializers: A proposal and semantics
Nothing to add, other than to point people at a different solution, using implicit parameters and rank-2 types: http://www.cs.chalmers.se/~rjmh/Globals.ps Admittedly, John's approach interacts in a prickly manner with the monomorphism restriction, but it does allow for the safe updating of global variables (which the unsafePerformIO technique does not). Cheers, Andy -- Andy Moran Ph. (503) 626 6616, x113 Galois Connections Inc. Fax. (503) 350 0833 12725 SW Millikan Way, Suite #290 http://www.galois.com Beaverton, OR 97005[EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] is $ a no-op?
-- |Apply list of functions to some value, returning list of results. -- It's kind of like an converse map. flist :: [a-b] - a - [b] flist fs a = map ($ a) fs I have attempted, unsuccessfully, to write flist above in a point-free manner. Is it possible? Jacques ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] is $ a no-op?
Jacques Carette [EMAIL PROTECTED] writes: -- |Apply list of functions to some value, returning list of results. -- It's kind of like an converse map. flist :: [a-b] - a - [b] flist fs a = map ($ a) fs I have attempted, unsuccessfully, to write flist above in a point-free manner. Is it possible? flist = flip (map . (flip ($))) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] is $ a no-op?
On Wed, Oct 13, 2004 at 01:00:05PM -0400, Jacques Carette wrote: -- |Apply list of functions to some value, returning list of results. -- It's kind of like an converse map. flist :: [a-b] - a - [b] flist fs a = map ($ a) fs I have attempted, unsuccessfully, to write flist above in a point-free manner. Is it possible? Jacques Of course it is, but why? flist = flip (map . flip ($)) Groeten, Remi -- Nobody can be exactly like me. Even I have trouble doing it. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] is $ a no-op?
-- It's kind of like an converse map. I have attempted, unsuccessfully, to write flist above in a point-free manner. Is it possible? Of course it is, but why? flist = flip (map . flip ($)) Some functions are simpler point-free, others are simpler with points. I was curious about this one (I like the pointwise version better). Also, the statement It's kind of like a converse map becomes quite clear from the point-free way to write it, while still not so obvious in the pointwise version. Jacques ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] is $ a no-op?
On Wednesday, October 13, 2004 11:25 AM, Jacques Carette [SMTP:[EMAIL PROTECTED] wrote: -- It's kind of like an converse map. I have attempted, unsuccessfully, to write flist above in a point-free manner. Is it possible? Of course it is, but why? flist = flip (map . flip ($)) Some functions are simpler point-free, others are simpler with points. I was curious about this one (I like the pointwise version better). Also, the statement It's kind of like a converse map becomes quite clear from the point-free way to write it, while still not so obvious in the pointwise version. I haven't proven it, but I think that this is the same function on lists: flist = (. return) . ap -- Kevin ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] threading mutable state through callbacks
Jules Bean [EMAIL PROTECTED] writes: Unless its possible to arrange haskell FFI bindings to have types in MonadIO rather than IO... MonadIO is a class, not a type. Anyway, it's conceptually impossible to wrap a computation of an arbitrary monad in the MonadIO class into IO. It's not a technical difficulty, it just does not make sense. It's similar to asking for a non-trivial function of type Monad m = m a - a. Unless you mean something else. -- __( Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] is $ a no-op?
Johannes Waldmann [EMAIL PROTECTED] writes: I liked to think of it as just a syntactical convention (for years ...) but is it really at no cost? It does introduce extra function calls, that is, extra closures etc.? Can these be removed by ghc's optimizer? It is inlined by GHC when optimization is turned on. In general it doesn't have to be optimized out - it's just a function - but it's easy to inline and eliminate, if the compiler performs any inlining at all. -- __( Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] is $ a no-op?
On Wed, 13 Oct 2004 18:06:01 +0100, Malcolm Wallace [EMAIL PROTECTED] wrote: Jacques Carette [EMAIL PROTECTED] writes: -- |Apply list of functions to some value, returning list of results. -- It's kind of like an converse map. flist :: [a-b] - a - [b] flist fs a = map ($ a) fs I have attempted, unsuccessfully, to write flist above in a point-free manner. Is it possible? flist = flip (map . (flip ($))) Note that if you define swing :: (((a - b) - b) - c - d) - c - a - d swing f = flip (f . flip ($)) then you can get this sort of effect uniformly in a number of situations: swing map :: forall a b. [a - b] - a - [b] swing any :: forall a. [a - Bool] - a - Bool swing foldr :: forall a b. b - a - [a - b - b] - b ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] RE: [Haskell] lazy constructors
[I think this thread would be more appropriate on haskell-café, so I'm redirecting it] | addToSPair :: Char - (String, String) - (String, String) | addToSPairc (xs, ys) = (c:xs, ys) | | --- | | g1 is similar to f1, g2 similar to f2. | | f1 and f2 are evaluated immediately to 'a'; | | g1 evaluates to 'a' after a long computation; | g2 evaluates to Fail: loop | | As g2 is similar to f2, should it have a value 'a' ? | In |head $ fst $ addToSPair 'a' bottomSPair Try using lazy pattern matching, thus addToSPair :: Char - (String, String) - (String, String) addToSPairc ~(xs, ys) = (c:xs, ys) The only change is the ~ in the defn of addToSPair. Now g2 will have value 'a'. Simon ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RE: [Haskell] lazy constructors
addToSPairc ~(xs, ys) =3D (c:xs, ys) I thought pattern bindings had an implicit ~? Keean. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OO idioms redux
Haskell type classes don't really behave as one might expect coming from an OO perspective; cf. http://www.ninebynine.org/Software/Learning-Haskell-Notes.html#type-class-misuse That commentary doesn't say anything about interface inheritance. I don't offhand have a good answer for that question. In my own code, I guess I kind-of work around that issue. As for inheritamnce of implementation, I guess that can be done by hand, by building a new type that contains the base type. #g -- At 18:32 12/10/04 +, John Goerzen wrote: OK, recently I posed a question about rethinking some OO idioms, and that spawned some useful discussion. I now have a followup question. One of the best features of OO programming is that of inheritance. It can be used to slightly alter the behavior of objects without requiring modification to existing code or breaking compatibility with existing APIs. As an example, say I have a ConfigParser class. This class can read in configuration files, provides various get/set methods to access them, and can write them back out. Now say I would like to make this a little more powerful. Maybe I want to support the use of environment variables in my config file, so if there's a reference to $FOO in the file, it will be replaced by the contents of $FOO in the environment. In OO, I would make a new EnvConfigParser class. I'd override the read() method. My new read() would probably start by calling the parent's read() method, to get parsing for free. Then it could iterate over the data, doing its environment variable substitution. Now, in Haskell, we obviously have no objects like this. We do have something that provides some of the same benefits -- typeclasses. However, from what I can determine, they don't support algorithm inheritance like objects do in an OOP. Specifically, it seems impossible to have two instances of a single typeclass that work on the same type, while having one share most of the code with the other. I'm wondering if there is a Haskell design pattern that I'm missing that would provid ethe kind of benefits that one gets from inheritance in the OO world. -- John -- John Goerzen Author, Foundations of Python Network Programming http://www.amazon.com/exec/obidos/tg/detail/-/1590593715 ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] lazy constructors
On Wed, Oct 13, 2004 at 09:23:43AM +0100, MR K P SCHUPKE wrote: You can only return a list of pair's lazily, not a pair of lists. If the two strings are independant, then generate each in a separate function, and pair off the results lazily. No, I have several labeled fields in a record, which are very dependent. As people teach, the costruct of ~(..,..) helps for the Pair. Maybe, the labeled record can also be handled ... - Serge Mechveliani [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] lazy constructors
addToSPair :: Char - (String, String) - (String, String) What about: addToSPair :: Char - String - String - (String,String) so that the pattern match is: addToSPair c xs ys = (c:xs,ys) This is irrefutable? Keean. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OO idioms redux
In message [EMAIL PROTECTED] John Goerzen
[EMAIL PROTECTED] writes:
OK, recently I posed a question about rethinking some OO idioms, and
that spawned some useful discussion.
I now have a followup question.
One of the best features of OO programming is that of inheritance. It
can be used to slightly alter the behavior of objects without requiring
modification to existing code or breaking compatibility with existing
APIs.
Closures can do this:
// in C++/Java
class ConfigParser {
void read (String);
int getFoo (String);
}
-- in Haskell
data ConfigParser = ConfigParser {
read :: String - IO ConfigParser
getFoo :: String - Int
}
This is a structure of functions. The difference from C++/Java style objects is
that this gives us object based polymorphism rather than class based
polymorphism. Because they are Haskell closures rather than C-style functions
they can hold private state by using partial application.
configParser :: ConfigParser
configParser = ConfigParser {
read input = ...
getFoo = ...
}
envConfigParser :: ConfigParser
envConfigParser = configParser {
read input = do env - getEnvVars
read configParser (substEnvVars input)
}
Duncan
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] lazy constructors
Serge D. Mechveliani wrote: As the types are resolved before the computation, as the above program shows, how can addToSPair expect anything besides a string pair? Why tilda is not a default? Haskell pairs are lifted, meaning that they also include an extra value (bottom) which doesn't match (x,y). Not everyone is convinced that this is a good idea, but it's the way things are at present. The only doubt may be the matching of (xs, ys) against bottom :: (String, String) Is not this natural to have a result as (bottom :: String, bottom :: String) -- = xs = ys and compute further? Possibly in this case, yes. But not in general, since there might be other data constructors also. What will occur if all the Haskell programmers set `~' before each data constructor in each pattern in their existing programs? Things won't work as you'd expect. For example, if you defined null :: [a] - Bool null list = case list of ~(x:xs) - False ~[] - True you would find that (null []) is False, not True, because the first pattern matches irrefutably. Pattern matching needs to be strict so that case statements like this work sensibly. As the types are recognized before the computation, the programs will remain safe and will become considerably faster. For example, the above program of g1 becomes a billion times faster. I wonder. Actually using irrefutable patterns tends to make a program slower, not faster, because it makes the program less strict. Good questions! -- Ben ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OO idioms redux
The only problem with this is name.
It is too easy to have naming clash in haskell. Field selectors are also
top-level functions and they shared the same namespace with other
functions.
for any reasonable scale program, we'll end up with ModuleA.read x,
ModuleB.read b. (Yes, we can alias the modules as A and B, but then we'll
have to face the module alias naming clash again)
In java/c++, we can name a method in the most meaningful and natural way we
like, rest-assured it won't have a problem just because some other
class/interface happens to use the same name for a different thing.
Plus, module, in my opinion is a logical functionality group, a quite
coarse-grained facility. not an appropriate tool to disambiguate names in a
fine-grained way.
I like the Lightweight Extensible Records for Haskell paper by Mark
Jones and Simon P. Jones. Very clean IMHO.
Not sure why it did not get implemented.
Duncan Coutts
[EMAIL PROTECTED]To: John Goerzen [EMAIL
PROTECTED]
ford.ac.ukcc: [EMAIL PROTECTED]
Sent by: Subject: Re: [Haskell-cafe]
OO idioms redux
[EMAIL PROTECTED]
l.org
10/13/2004 08:15 AM
In message [EMAIL PROTECTED] John Goerzen
[EMAIL PROTECTED] writes:
OK, recently I posed a question about rethinking some OO idioms, and
that spawned some useful discussion.
I now have a followup question.
One of the best features of OO programming is that of inheritance. It
can be used to slightly alter the behavior of objects without requiring
modification to existing code or breaking compatibility with existing
APIs.
Closures can do this:
// in C++/Java
class ConfigParser {
void read (String);
int getFoo (String);
}
-- in Haskell
data ConfigParser = ConfigParser {
read :: String - IO ConfigParser
getFoo :: String - Int
}
This is a structure of functions. The difference from C++/Java style
objects is
that this gives us object based polymorphism rather than class based
polymorphism. Because they are Haskell closures rather than C-style
functions
they can hold private state by using partial application.
configParser :: ConfigParser
configParser = ConfigParser {
read input = ...
getFoo = ...
}
envConfigParser :: ConfigParser
envConfigParser = configParser {
read input = do env - getEnvVars
read configParser (substEnvVars input)
}
Duncan
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
This message is intended only for the addressee and may contain information
that is confidential or privileged. Unauthorized use is strictly prohibited
and may be unlawful. If you are not the intended recipient, or the person
responsible for delivering to the intended recipient, you should not read,
copy, disclose or otherwise use this message, except for the purpose of
delivery to the addressee. If you have received this email in error, please
delete and advise the IT Security department at [EMAIL PROTECTED]
immediately
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] RE: [Haskell] is $ a no-op?
[Switched to haskell-cafe] At 13:24 13/10/04 -0400, Jacques Carette wrote: -- It's kind of like an converse map. I have attempted, unsuccessfully, to write flist above in a point-free manner. Is it possible? Of course it is, but why? flist = flip (map . flip ($)) Some functions are simpler point-free, others are simpler with points. I was curious about this one (I like the pointwise version better). Also, the statement It's kind of like a converse map becomes quite clear from the point-free way to write it, while still not so obvious in the pointwise version. The point-free form can be deduced thus, I think: flist fs a = map ($ a) fs (flip flist) a fs = map ($ a) fs-- swap flist args (flip flist) a = map ($ a) -- redundant arg (flip flist) a = map ((flip ($)) a) -- expand section (flip flist) a = (map . (flip ($))) a -- definition of . (flip flist) = map . (flip ($)) -- redundant arg flist = flip (map . (flip ($))) -- move flip to RHS #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] Re: OCaml list sees abysmal Language Shootoutresults
--- Robert Dockins [EMAIL PROTECTED] wrote: Then perhaps it is worth considering having multiple implementations and choosing between them with pragmas and/or command line switches (with a sensible default naturally). Maybe doubly linked lists are not a great idea, but if we had a good implementation with, eg. O(1) access to both ends of the list but poor sharing, we can choose to use it only in cases where queue semantics are important and sharing is not. It would be nice to be able to monkey about with that kind of under the hood functionality w/o having to make any code changes. You could also do fun things like have chained-buffer list implementations for [Word8], [Char] etc. Lists are an integral part of the Haskell language, and in fact most languages have some version of list at a fundamental level. Here's an interesting (not necessarily useful!) shift of viewpoint: What if List were a type class? Shawn ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootoutresults
On Wed, 13 Oct 2004, Shawn Garbett wrote: Lists are an integral part of the Haskell language, and in fact most languages have some version of list at a fundamental level. Here's an interesting (not necessarily useful!) shift of viewpoint: What if List were a type class? Then we'd need defaulting ala arithmetic - but yeah, otherwise I would go with that. -- [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell's overlooked object system: was OO idioms redux
John Goerzen wrote:
One of the best features of OO programming is that of inheritance.
...
Oleg, Keean and me have lying around a draft that adds to this
discussion. We reconstruct OCaml's tutorial in Haskell
The short paper version is online and under consideration for FOOL:
http://homepages.cwi.nl/~ralf/OOHaskell/
This work takes advantage of the HList library.
I'll attach some code related to inheritance.
So Haskell is an OOPL.
Ralf
{-# OPTIONS -fglasgow-exts #-}
{-# OPTIONS -fallow-undecidable-instances #-}
-- In the following, we refer to the tutorial Objects in Caml
-- http://caml.inria.fr/ocaml/htmlman/manual005.html
-- 3.2 Reference to self
module SelfObj where
import CommonMain hiding (HDeleteMany, hDeleteMany, TypeCast,typeCast)
import GhcSyntax
import GhcExperiments
import TypeEqBoolGeneric
import TypeEqGeneric1
import TypeCastGeneric2
import Label2
import Data.STRef
import Data.IORef
import Control.Monad.ST
import Control.Monad.Fix
infixr 9 #
m # field = (m .!. field)
-- A name space for record labels
data MyNS = MyNS
l_get_x = firstLabel MyNS get-x
l_move= nextLabel l_get_x move
l_field_x = nextLabel l_move field x
l_print = nextLabel l_field_x print
{-
Ocaml Tutorial:
3.2 Reference to self
A method or an initializer can send messages to self (that is, the
current object). For that, self must be explicitly bound, here to the
variable s (s could be any identifier, even though we will often
choose the name self.
class printable_point x_init =
object (s)
val mutable x = x_init
method get_x = x
method move d = x - x + d
method print = print_int s#get_x
end;;
let p = new printable_point 7;;
val p : printable_point = obj
p#print;;
7- : unit = ()
-}
class_printable_point x_init self
= do
x - newIORef x_init
return $
l_field_x .=. x
.*. l_get_x .=. readIORef x
.*. l_move.=. (\d - do{v-readIORef x; writeIORef x (d + v)})
.*. l_print .=. ( (self # l_get_x ) = print )
.*. emptyRecord
testp1 = do
print testp1
-- Note that 'mfix' plays the role of 'new' in the OCaml code...
p - mfix (class_printable_point 7)
p # l_get_x = print
p # l_move $ 2
p # l_get_x = print
p # l_print -- Note, the latter prints the state of the mutated obj!
print OK
{-
Ocaml Tutorial:
3.7 Inheritance
We illustrate inheritance by defining a class of colored points that
inherits from the class of points. This class has all instance
variables and all methods of class point, plus a new instance variable
c and a new method color.
class colored_point x (c : string) =
object
inherit point x
val c = c
method color = c
end;;
let p' = new colored_point 5 red;;
val p' : colored_point = obj
p'#get_x, p'#color;;
- : int * string = (5, red)
-}
-- Inheritance is simple: just adding methods...
l_color = nextLabel l_print color
class_colored_point x_init color self
= do
p - class_printable_point x_init self
return $ l_color .=. (return color) .*. p
testp2 = do
print testp2
-- Note that 'mfix' plays the role of 'new' in the OCaml code...
p - mfix (class_printable_point 7)
p' - mfix (class_colored_point 5 red)
do{ x - p' # l_get_x; c - p' # l_color; print (x,c) }
print OK
{-
Ocaml Tutorial:
3.4 Virtual methods
It is possible to declare a method without actually defining it, using
the keyword virtual. ...
class virtual abstract_point x_init =
object (self)
val mutable x = x_init
method virtual get_x : int
method get_offset = self#get_x - x_init
method virtual move : int - unit
end;;
class point x_init =
object
inherit abstract_point x_init
method get_x = x
method move d = x - x + d
end;;
-}
l_offset = nextLabel l_color offset
-- Note, compared with printable_point, the we just removed the field l_get_x
-- That made the class uninstantiatable!
-- No need for any a language extension for virtual, abstract.
class_abstract_printable_point x_init self
= do
x - newIORef x_init
return $
l_field_x .=. x
.*. l_offset .=. ((self # l_get_x ) = (\v - return$ v - x_init))
.*. l_print .=. ( (self # l_get_x ) = print )
.*. emptyRecord
class_concrete_printable_point x_init self
= do
p - class_abstract_printable_point x_init self -- inherit...
return $
-- add the missing (pure virtual) methods
l_get_x .=. (readIORef (self # l_field_x))
.*. l_move.=. (\d - do{v-readIORef (self # l_field_x);
writeIORef (self # l_field_x) (d + v)})
.*. p
testp3 = do
print testp3
-- Note, if the latter is uncommented; we get the
-- desired instantiation error.
p - mfix (class_concrete_printable_point 7)
p # l_get_x = print
p #
Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootoutresults
Shawn Garbett [EMAIL PROTECTED] writes: viewpoint: What if List were a type class? Or, what if String were one? Could we have painless read/show with arrays of Char, as well as lists, for instance? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell's overlooked object system: was OO idioms redux
Some people say that ocaml's object system is kinda useless. The best support I hear so far was:it does not hurt implementation inheritance, the strange # syntax, virtual method, why do I need them? In Java, people are doing programming-against-interface, implementation injection etc. All these show that we don't need implementation inheritance to be OO, and implementation inheritance is in many cases bad practice anyway. As somebody pointed out, we could do interface in Haskell with record. The only problem is names. If we could, as we can in OO languages, provide a separate namespace for the fields of each record. We are pretty much done. The rest is some kind of record coersion+row polymorphism mechanism. If haskell can do what Simon P. Jones and Mark Jones described in the paper Lightweight Extensible Records for Haskell, I'd say it is a already a nice functional OO language. Compared to Ocaml, 'OO' support is seamlessly integrated with the functional part. It leaves no redundancy, no overlapping in the language. In short, what if we don't create an object piece that competes with the functional part, but fix and enhance the record system that we currently have? Ben. This message is intended only for the addressee and may contain information that is confidential or privileged. Unauthorized use is strictly prohibited and may be unlawful. If you are not the intended recipient, or the person responsible for delivering to the intended recipient, you should not read, copy, disclose or otherwise use this message, except for the purpose of delivery to the addressee. If you have received this email in error, please delete and advise the IT Security department at [EMAIL PROTECTED] immediately ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell's overlooked object system: was OO idioms redux
[EMAIL PROTECTED] wrote:
Some people say that ocaml's object system is kinda useless. The best
support I hear so far was:it does not hurt
Why do you (or do these people) think having all the OO idioms of OCaml
(see OCamls OO tutorial) is useless? Or do you mean too baroque? If not,
what's
missing?
implementation inheritance, the strange # syntax, virtual method, why do
I need them?
Fine with me.
OOHaskell doesn't need them, indeed.
In Java, people are doing programming-against-interface, implementation
injection etc. All these show that we don't need implementation inheritance
to be OO, and implementation inheritance is in many cases bad practice
anyway.
Well having no implementation inheritance in Java would be a pretty
brave limitation.
Anyhow, OOHaskell (and OCaml) has programming-against-interface as well.
Some related snippet from the OCaml tutorial.
{-
A point and a colored point have incompatible types, since a point has no
method color. However, the function get_x below is a generic function
applying
method get_x to any object p that has this method (and possibly some others,
which are represented by an ellipsis in the type). Thus, it applies to both
points and colored points.
let get_succ_x p = p#get_x + 1;;
val get_succ_x : get_x : int; .. - int = fun
get_succ_x p + get_succ_x p';;
- : int = 8
-}
The corresponding OOHaskell snippet
testp2 = do
print testp2
-- Note that 'mfix' plays the role of 'new' in the OCaml code...
p - mfix (class_printable_point 7)
p' - mfix (class_colored_point 5 red)
do{ x - p' # l_get_x; c - p' # l_color; print (x,c) }
let get_succ_x obj = obj # l_get_x = (return . (+ 1))
get_succ_x p = print
get_succ_x p' = print
print OK
As somebody pointed out, we could do interface in Haskell with record. The
only problem is names. If we could, as we can in OO languages, provide a
separate namespace for the fields of each record. We are pretty much done.
Have you seen HList?
There are 4 different solutions for first-class labels in the distribution.
The rest is some kind of record coersion+row polymorphism mechanism.
Yes, good point.
That's what we meant: the object system in Haskell has been overlooked.
If haskell can do what Simon P. Jones and Mark Jones described in the paper
Lightweight Extensible Records for Haskell, I'd say it is a already a
nice functional OO language.
It can readily do more than that:
http://www.cwi.nl/~ralf/HList
Compared to Ocaml, 'OO' support is seamlessly integrated with the
functional part. It leaves no redundancy, no overlapping in the language.
What are you referring to?
I mean: where is OO support seamlessly integrated with the functional part?
Do you refer to OOHaskell?
In short, what if we don't create an object piece that competes with the
functional part, but fix and enhance the record system that we currently
have?
... or just exploit heterogeneous collections.
Ralf
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootoutresults
--- Ketil Malde wrote: Or, what if String were one? Could we have painless read/show with arrays of Char, as well as lists, for instance? --- end of quote --- I think with a decent set of type classes for collections, better handling of strings would come for free. If any list function could be made implementation independent, then strings could still be treated as lists of chars, but the underlying implementation could be completely different (arrays, PackedStrings, etc.) /gXm ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell's overlooked object system: was OO idioms redux
Why do you (or do these people) think having all the OO idioms of OCaml (see OCamls OO tutorial) is useless? Or do you mean too baroque? If not, what's missing? Because it does not give us much that we cannot do nicely with the current functional part. separate name space of course. But it does not seem obvious that the rest of the object piece is necessary. Anything missing? Can't think of one. Simplicity I guess. implementation inheritance, the strange # syntax, virtual method, why do I need them? Fine with me. OOHaskell doesn't need them, indeed. Nice. Well having no implementation inheritance in Java would be a pretty brave limitation. Anyhow, OOHaskell (and OCaml) has programming-against-interface as well. It may be. But is it a brave limitation that Haskell does not have implementation inheritance? I don't see the absolute need for impl-inheritance in an already rich and integral language such as Haskell. If impl-inheritance is already an arguable feature in OO langauges, I guess more thought should be given before it is pushed into a functional language at the cost of language complexity. (All I'm saying is general concern, it does not refer to HList or OOHaskell because I have no knowledge about them) Have you seen HList? There are 4 different solutions for first-class labels in the distribution. No. I'm just throwing in some ideas. If it is irrelavant or something already done, my apology. :) But, hey, don't get me wrong. I have no problem to see the language supporting impl-inheritance and other OO features. What I'm against is to invent a whole new standalone object system like what Ocaml has. In other words, it should not double the size of the language. The rest is some kind of record coersion+row polymorphism mechanism. Yes, good point. That's what we meant: the object system in Haskell has been overlooked. Haskell 98 does not have row-polymorphism, does it? Or am I overlooking something? If haskell can do what Simon P. Jones and Mark Jones described in the paper Lightweight Extensible Records for Haskell, I'd say it is a already a nice functional OO language. It can readily do more than that: http://www.cwi.nl/~ralf/HList Thanks. I'll certainly find some time to digest it. Compared to Ocaml, 'OO' support is seamlessly integrated with the functional part. It leaves no redundancy, no overlapping in the language. What are you referring to? I mean: where is OO support seamlessly integrated with the functional part? Do you refer to OOHaskell? No. I did not look at OOHaskell yet. What I mean by seamless is the 'extensible record' proposal. It is not created for OO, but it can be used to do OO. Whatever I do, it is just an orthogonal piece of facility. While Ocaml objects and functional part don't look quite orthogonal. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe This message is intended only for the addressee and may contain information that is confidential or privileged. Unauthorized use is strictly prohibited and may be unlawful. If you are not the intended recipient, or the person responsible for delivering to the intended recipient, you should not read, copy, disclose or otherwise use this message, except for the purpose of delivery to the addressee. If you have received this email in error, please delete and advise the IT Security department at [EMAIL PROTECTED] immediately ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] lazy constructors
I thank Jeremy Gibbons, Ben Rudiak-Gould, and other people, for their helpful explanations. On Wed, Oct 13, 2004 at 02:34:55PM +0100, Ben Rudiak-Gould wrote: Serge D. Mechveliani wrote: As the types are resolved before the computation, as the above program shows, how can addToSPair expect anything besides a string pair? Why tilda is not a default? Haskell pairs are lifted, meaning that they also include an extra value (bottom) which doesn't match (x,y). Not everyone is convinced that this is a good idea, but it's the way things are at present. The only doubt may be the matching of (xs, ys) against bottom :: (String, String) Is not this natural to have a result as (bottom :: String, bottom :: String) -- = xs = ys and compute further? Possibly in this case, yes. But not in general, since there might be other data constructors also. What will occur if all the Haskell programmers set `~' before each data constructor in each pattern in their existing programs? Things won't work as you'd expect. For example, if you defined null :: [a] - Bool null list = case list of ~(x:xs) - False ~[] - True I am sorry. Of course, I meant the functions in which it was set initially only a single pattern. People often write such. As the types are recognized before the computation, the programs will remain safe and will become considerably faster. For example, the above program of g1 becomes a billion times faster. I wonder. Actually using irrefutable patterns tends to make a program slower, not faster, because it makes the program less strict. Probably, unneeded strictness bites more seriousely than unneeded laziness. What I fear of is the following hidden slow down. Suppose that such a function (as the above addToPair) updates a value of type ([a], [b]) in a loop. And consider a client function let p = form_list_pair_via_addToPair ... ... h = g p p ... in if (take 3 $ fst p) == abc then ... else ... The value of p is used in several places, the whole program looks natural. The programmer relies on that (take 3 $ fst p) computes `lazily'. In fact, I like to rely on the `laziness' and think that it makes the programs more clear. Otherwise, one could program, say, in ML. Now, if one does not guess to set tilda in addToPair, the whole program becomes slower somewhat in (length xs)/3 times! Here xs is a list accumulated in the first component of the form_list_pair_via_addToPair result. If length xs = 900, then the slow down in 300 times. Is there any systematic approach allowing to avoid a performance adventure like this? May the compiler help, may it issue a warning? And maybe, there are other sources of the slow downs due to unneeded strictness. Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
