I'm sorry if this example has already been posted, but I couldn't
find it by searching the archives. If it's new (and works properly),
it provides more evidence that ATs are a good thing.
You can use associated type synonyms to implement polymorphic
extensible records.
Of course, under Usage, I should have written:
The record {N1 = x1, ... Nn = xn} should be constructed as (extend N1
x1 $ ... $ extend Nn xn $ Empty).
Sorry about any confusion!
Barney.
___
Haskell mailing list
Haskell@haskell.org
http://www.haske
The implementation of records using types data N a r = N a r might
well be inefficient, and I don't know enough about the workings of
the compiler to see whether it could be improved by unboxing and
strictness. But the real point of my post was the classes Contains,
Lacks and Disjoint which
Manuel M T Chakravarty:
This is problematic as the instance heads are distinguished only by
the
context; ie, both instances are for `Lacks m (N a r)'. Haskell's
instance selection mechanism (with or without associated types)
selects
instances purely by looking at the arguments of the class;
Sorry if people are really bored with this thread, but I thought of
another advantage of this approach.
Trex (and similar systems) have a limitation that stops you using
them to define functions with default values. In systems like R (the
stats package) most functions have a huge number of
I think you should add the form:
(function -> pattern) @ pattern
as well. The reason you don't need general 'pattern @ pattern' with
normal patterns is that, if anything is going to match, the two
patterns must have the same outermost constructor, so you can push
the @ inside. This doesn't
Now that I have a version of ghc with type classes, I have had a go
at implementing records based on the ideas I mentioned on this list a
few months ago. The code of my first attempt is available at http://
homepage.ntlworld.com/b.hilken/files/Records.hs
I am releasing this to get feedback.
From: Isaac Dupree
I haven't been able to see how it makes sense to subscribe to
haskell@ but not haskell-cafe -- because if a discussion interested
you, and went in-depth, you might want to be able to read the whole
thread! (It is possible to read the archives, but that doesn't
help i
Everyone wants to add extensible records to Haskell. The problem is
that, in a formally defined language like Haskell, we need to agree
how they should behave, and there are too many conflicting ideas.
I was involved recently in an attempt to try to sort out some of the
alternatives (record
The scoped labels paper has an interesting feature in this regard:
labels with different names can be swapped at will, but labels having
the same name (which is allowed) maintain their order.
- Cale
Yes, I know. The problem is that there are TOO MANY proposals, and
they are all fundamental
new record (x = 3,y = 4)
subtraction \r -> ( x = 3 | r - x)
replacement \r -> (x := 3 | r) (equivalent to the above)
type (x::Int,y::Char)
degenerate cases:
empty record (|)
subtracting a label (| r - x)
a record can always be determined by the presence of a '|' within
parenthesis.
One of the
2. List the possible features that “records” might mean. For example:
· Anonymous records as a type. So {x::Int, y::Bool} is a
type. (In Haskell as it stands, records are always associated with
a named data type.
· Polymorphic field access. r.x accesses a field in any
What about just implementing the cheapest solution that still gets
us most
of the way?
(3) If it is as cheap (to implement) as advertised then there is no
great
risk involved. If it turns out the missing features are a great
show-stopper for some people (which I don't believe) then let them
Begin forwarded message:
From: Ben Franksen <[EMAIL PROTECTED]>
Date: 18 February 2008 21:32:29 GMT
To: haskell@haskell.org
Could you be more specific? Which proposals exactly do you mean and
where
can I read more about them?
Hlist is one of the ones | was thinking of. Two more are "poor ma
My rationale for these criteria goes like this: efficient access is
necessary if we want to compete with the much simpler record systems
in
mainstream languages. If records are not as light-weight
(syntactically as
well as wrt run-time performance) as 'normal' Haskell data types, then
people
While I agree with your general argument, I wonder if you realize
that functional dependencies have a strong, general, and elegant
mathematical foundation that long predates their use in Haskell?
If you want even a brief glimpse, there's s short article at
http://en.wikipedia.org/wiki/Functional_
(sorry, I meant to send this to the list, but only sent it to Wolfgang)
Here is my understanding of the current state of the argument:
Instead of Labels, there will be a new kind String, which is not a subkind of
*, so its elements are not types. The elements of String are strings at the
type l
Is there any deep reason why I can't write a polymorphic type in a context? I
think the record update problem can be (sort of) solved if you could write:
class Has r Rev (forall a. [a] -> [a]) => HRClass r where
setHRClass :: (forall a.[a] -> [a]) -> r -> r
but polymorphic types are not
'
'Qualified Types'.
Barney Hilken and Giuliano Procida
This is a proposal for an expressive record language. Records are
first class values and can be manipulated by the extraction, addition
and deletion of named fields. Polymorphism is allowed over the types
of fiel
19 matches
Mail list logo
