Re: [Haskell] Libraries mailing list
Hi Krasmir, It is possible that you may be running up against one of GMail's ideosynchrosies. I have found that GMail tries to avoid showing multiple copies of the same mail. In particular, if one sends a mail to a list that one is subscribed to, one will not see a second copy of the mail when it is eventually posted. This behaviour is usually exactly what one wants, but it can be a little confusing sometimes. Hope this helps. -Rob On 12/8/05, Krasimir Angelov <[EMAIL PROTECTED]> wrote: > Hi Guys, > > Yesterday I sent a message to [EMAIL PROTECTED] mailing list but > it seems like the message isn't dispatched yet. Is there any problem > with the list or I have to send the message again? > > Cheers, > Krasimir > ___ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > > ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Records (was Re: [Haskell] Improvements to GHC)
On 11/28/05, Wolfgang Jeltsch <[EMAIL PROTECTED]> wrote:
>
> As I already said, this approach may lead to mixing different concepts.
> Example:
>
> data Person = Person { name :: String }
> data File = File { name :: String }
>
> A field identifier has to be seen in context of the datatype it belongs to.
> When used in conjunction with Person, name means a person's name while it
> means a filename (a notably different thing) when used in conjunction with
> File. With the typeclass approach, we would have a single function called
> "name" which deals with different things. Important details would just be
> camouflaged. This is not good. In fact, it is really bad in my opinion.
Hi Wolfgang,
I think you are right in that two similarly named fields should not be
automatically considered to be equivilent. Indeed that is why the
typeclass approach I proposed requires that one explicitly declare any
typeclasses, and explicitly declare when two similarly named fields
are part of the same typeclass -- one thus cannot have two fields been
considered equivalent without the programmer making a conscious
descision that this is correct behaviour.
> Maybe it would really be better to have functions like Person.name and
> File.name?
In the case you give, I think you are right. In this case, using
namespaces to distinguish fields is preferable to treating the same.
However I think there are also other cases in which it *is* desirable
to allow several datatypes to have the same field -- with the
programmer making a contious descision to do things this way.
[snip]
-Rob
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: Records (was Re: [Haskell] Improvements to GHC)
On 11/23/05, David Roundy <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 22, 2005 at 02:32:47PM +0000, Rob Ennals wrote:
[snip]
> > 1. Field namespaces: solved by using type classes
>
> But these classes are required to be manually specified, right? This avoids
> the problem of proliferation of typeclasses if one had one class per field,
> but does mean that coordination is necesary in order to avoid namespace
> clashes.
>
> As far as I can tell, this means that we'd have issues with
>
> data StupidDouble = StupidDouble { value :: Double }
> data StupidInt = StupidInt { value :: Int }
>
> unless we use multiparameter typeclasses or something.
You are indeed right.
My thinking was that fields should be thought of in much the same way
as functions. If two same-named fields are supposed to be used the
same way, then one should declare a type class, and if they are
supposed to be distinct, then one should use module namespaces.
As regards multiparameter typeclasses - I think that they should work
quite well with this proposal.
e.g.
class HasVal a b where
value :: a -> b
instance HasVal StupidDouble Double
instance HasVal StupidDouble Int
[snip]
> > 3. "Safe" getters for multi-constructor data types: ditto
>
> I think either you misunderstood my meaning by "safe", or I misunderstood
> your paper. I meant that if I write
>
> data FooBar = Foo { foo :: String } | Bar { bar :: String }
>
> there shouldn't be accessors of type
>
> foo :: FooBar -> String
> bar :: FooBar -> String
I did indeed misunderstand what you meant by "safe". Bottom is indeed
a nasty thing.
Perhaps such definitions should generate a warning? (banning them
outright would cause compatability issues)
> > 7. Unordered records: yep (if I understand the problem correctly)
>
> I don't think you understood correctly.
I was thinking along the same lines as Wolfgang : don't export the
internal representation of the type, but do expose the field
manipulator functions.
This needn't prevent the use of pattern matching, provided the
desugaring of patterns is consistent with the rest of the system.
E.g. I was assuming that
case e of { x = 3, y = 4} -> ...
would desugar to
case e of _ | x z = 3 && y z = 4 -> ...
Note that this pattern matching syntax will continue to work, even if
'x' and 'y' are reimplemented as normal functions, rather than fields.
Hope this all makes sense.
-Rob
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: Records (was Re: [Haskell] Improvements to GHC)
Hi guys, Since discussion has returned to records, it might be useful for me to post a link to a proposal that I knocked up a while back when this topic came up a few years ago: http://www.cambridge.intel-research.net/~rennals/records.pdf The basic idea is to keep records largely as they are, but add two extensions: - field getter functions are placed in type classes - fields desugar to setter functions as well as getters Useful features of this approach are: - backward compatibility with existing code - the existing type-class mechanism is used for shared field names - setters can be redefined if a type is changed, just as getters can now To go through Dave's issues: 1. Field namespaces: solved by using type classes 2. Multi-constructor getters: solved by desugaring to functions 3. "Safe" getters for multi-constructor data types: ditto 4. Getters for multiple data types with a common field: solved by type-classes (no special "constains" feature required) 5. Setters as functions: yep 6. Anonymous records: not supported 7. Unordered records: yep (if I understand the problem correctly) And Georg's points: 8. Subtyping: yep -using type classes 9. higher order versions for selecting, updateing ... : not sure what is meant here Of course, my proposal might very well not do what you want, but I thought it was worth posting it again. Hope people find this useful. -Rob On 11/22/05, Johannes Waldmann <[EMAIL PROTECTED]> wrote: > On records in Haskell - can we start by formulating requirements > (design goals). What do we want from a record system, > and what are non-goals. > > Some of the proposals here sound like records should be more like > objects (with some kind of inheritance). Do we really want this? > We already have inheritance (for interfaces). Isn't that enough? > > My main objection is that concrete data types (e. g. records) > should not be exposed by a module anyway, > and should definitely not be a base for derivations > (Compare the OO design pattern literature). > > Still if they are exposed (or while we're inside a module), > what makes the current records quite impractical > is the namespace issue (for component names). > > Sure, one thing would be to invent some ad-hoc solution > (automatic qualification by type name or something) > but another possibility is to allow ad-hoc polymorphisms > generally in the language. > > Just my 2 cent (and none of them new, I'm afraid) > -- > -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- > http://www.imn.htwk-leipzig.de/~waldmann/ --- > > ___ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > > ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
