Firstly, thank you to SPJ for putting some detailed design into 'Overloaded
record fields' [SPJ 1].
What I'm showing here draws heavily on the techniques he demonstrates.
I wasn't happy with several parts of the design proposal;
especially not with the amount of not-yet-available type machinery
doesn't know why asking for the type of a term would help, or
can't figure out which sub-term they need to worry about, or doesn't
understand the type they get back, I don't see that any fancy extension to
GHCi is going to help much.
AntC
___
Glasgow
Ryan Newton rrnewton at gmail.com writes:
I admit I'm a big fan of polymorphic extension. But I don't love it enough
for it to impede progress!
Regarding extension: In trying to read through all this material I don't
see a lot of love for lacks constraints a la TRex.
Cheers,
Ryan Newton rrnewton at gmail.com writes:
I admit I'm a big fan of polymorphic extension. But I don't love it enough
for it to impede progress!
Regarding extension: In trying to read through all this material I don't
see a lot of love for lacks constraints a la TRex.
Cheers,
-Ryan
Ryan Newton rrnewton at gmail.com writes:
I admit I'm a big fan of polymorphic extension. But I don't love it enough
for it to impede progress!
Regarding extension: In trying to read through all this material I don't
see a lot of love for lacks constraints a la TRex.
Cheers,
-Ryan
John Lask jvlask at hotmail.com writes:
On 1/02/2012 12:26 AM, AntC wrote:
No! no! no! For records _don't_ put records in nested/sub-modules, and
_don't_
require them in separate modules (as currently). Here's how ...
namespace management and record systems are intimately related
!
(By the way, none of the 'Records in Haskell' proposals describe themselves
as extremely simple.
http://hackage.haskell.org/trac/ghc/wiki/Records
AntC
--
View this message in context:
http://haskell.1045720.n5.nabble.com/simple-extension-to-ghc-s-record-disambiguation-rules-tp5494549p5497846.html
with that; and that DORF fits in with it.
Greg, please give some specific examples! I'm trying to understand, but I'm
only guessing from the fragments of info you're giving.
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http
.
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
that.)
Is it good enough to be able to create records with h-r fields (using the data
constructor)? (Both SORF and DORF can do that.)
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo
on this forum
One thing I can be pretty sure of: proposals not written up won't get
implemented.
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
SORF is driven by String Kind, which cannot be scope
controlled.
- DORF uses (Proxy) types for (roughly) the same purpose as the String Kinds.
But because they're types, you can control the scope, and keep the
abstraction.
AntC
___
Glasgow-haskell
want the `name` field to be polymorphic for some given record
declaration.
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
like
the 'experimental' Kinds in SORF, and you couldn't control their namespace.)
So what you call My approach is almost identical to DORF -- except that
you're confusing it with SORF syntax. What you're criticising is SORF, not
DORF.
AntC
with the ugly.
Hmm. Maybe this is Haskelly as well as convenient enough. Did I get
everything right? What do you think about my concern about F?
Well done! Nearly everything. I hope I've allayed your concerns re F.
AntC
[1]
http://hackage.haskell.org/trac/ghc/wiki/Records
done is hand-desugarred. (Look at it for yourself, it's attached to the
implementor's page.)
SORF, on the other hand, needs user-defined Kinds, which are only just being
introduced in v7.4, and don't yet include String Kind.
AntC
___
Glasgow
later posts to clarify this.
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
the use case?
AntC
data ARecordType a =
C1 {
...,
fieldX :: a,
...,
fieldY :: a - a,
...
}
or existentially quantified as in:
data AnotherRecordType
. (DORF and SORF
differ slightly in how that's implemented.)
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
is hiding the implementation, not the existence of the `Has`
class -- as is good practice.
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
tightening up??)
- the higher-ranked variety
neither proposal has a way of updating
(well, DORF did but it's an unscalable hack [SPJ],
I put it on the wiki anyway, in case somebody can improve it)
AntC
___
Glasgow-haskell-users
changes' requirement, I'm trying to avoid syntax
changes to record decls.)
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
the track of designing DORF, as an
improvement over SORF, and to avoid the suggestions of sub-modules.
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
, despite the client guessing the fieldnames, they can't use them at
all if you don't export them -- because they're in a sealed-off namespace,
just like regular Haskell.
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http
.
This is beginning to exasperate me. Read the wikis: can you see type-level
string? Certainly not on the DORF pages, I'm pretty sure not on the SORF
pages. If you find it somewhere else, tell me and I'll get it changed.
AntC
___
Glasgow-haskell-users mailing
J. Garrett Morris jgmorris at cs.pdx.edu writes:
On Wed, Feb 29, 2012 at 11:05 PM, AntC anthony_clayden at clear.net.nz
wrote:
I repeat: nobody is using a type-level string. You (or someone) is
making it up.
It isn't clear where that idea came from.
On Mon, Jan 2, 2012 at 4:38 AM
J. Garrett Morris jgmorris at cs.pdx.edu writes:
On Wed, Feb 29, 2012 at 11:58 PM, AntC anthony_clayden at clear.net.nz
wrote:
SORF's whadyoumaycalls are at the Kind level. (I'm not opposed to them
because they're new-fangled, I'm opposed because I can't control the
namespace.)
Nah
Ian Lynagh igloo at earth.li writes:
On Thu, Mar 01, 2012 at 07:58:42AM +, AntC wrote:
SORF's whadyoumaycalls are at the Kind level. (I'm not opposed to them
because
they're new-fangled, I'm opposed because I can't control the namespace.)
I haven't followed everything, so
Ian Lynagh igloo at earth.li writes:
On Thu, Mar 01, 2012 at 08:52:29PM +, AntC wrote:
And you get In my opinion, this is ugly, ...
That comment was from strake888, not SPJ?
Thanks Ian, you're right. Specifically, it's 'igloo's tweak to the proposal
and 'strake888's comment. (I
AntC anthony_clayden at clear.net.nz writes:
Ian Lynagh igloo at earth.li writes:
But I think you are agreeing that (leaving aside the issue of whether
the design is reasonable) the above variant would indeed allow the user
to choose the behaviour of either SORF or DORF
Ian Lynagh igloo at earth.li writes:
On Thu, Mar 01, 2012 at 11:32:27PM +, AntC wrote:
AntC anthony_clayden at clear.net.nz writes:
Ian Lynagh igloo at earth.li writes:
But I think you are agreeing that (leaving aside the issue of whether
the design
, imports and hiding: how do I do that for these non-String-type-Kinds?
And is this allowed?:
data NotaField = Constr Int Bool
data AmIaRec = AmI{ Constr :: String }
...
... r.Constr ...
It's all getting very tangled trying to squeeze constructors into other roles.)
AntC
Isaac Dupree ml at isaac.cedarswampstudios.org writes:
AntC (in an unrelated reply to Ian) :
I prefer DORF's sticking to conventional/well-understood H98 namespacing
controls.
...
I'm not sure yet that DORF's namespacing is well-understood by
anyone but you.
No of course I'm not saying
this do expect to remain patient, civil and polite.
Do not expect to have a social life or get much sleep. Do expect your wife to
ask who you're writing to, and why.
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http
factor: perversely, the record type and field labels might
have been exported, but not the selector function.
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
, but
not update them. Other fields I don't want the client to even know about.
(You've achieved the last part with your Client1, for all of the fields.)
(FYI: that's how wiki pages turn out so long; specifying exactly all the ins
and outs at that sort of subtle detail.)
AntC
AntC anthony_clayden at clear.net.nz writes:
Gábor Lehel illissius at gmail.com writes:
...
... My main complaint against DORF is
that having to write fieldLabel declarations for every field you want
to use is onerous. If that could be solved, I don't think there are
any others
don't show how you'd do record update. The litmus test is what is the type
for:
r{ X = True }
That is: update record r, set its X field to True.
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org
approach handles those. It's not a case
of whether it's possible, but rather how awkward.
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
syntax you're going to desugar differently
* ideally build a prototype to prove it
* demonstrate in the prototype how the namespace control works
Then we can hold the beauty pageant.
(Oh yes: and explain what you'd have instead of dot notation, so that we can
fire up another syntax debate ;-)
AntC
to the semantics -- except you've not given the
surface syntax, so I'm only guessing.
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
On Fri, Mar 02, 2012 at 01:04:13AM +, AntC wrote:
Let me explain better what I mean by two private namespaces, then we'll
try to understand how your proposal goes ...
Folks, it has been very difficult keeping up with all the twists and turns of
this thread.
So here's a summary
' might get addressed.
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Ian Lynagh igloo at earth.li writes:
On Mon, Mar 26, 2012 at 10:47:14PM +, AntC wrote:
Ticket #3356 claims that {-# LANGUAGE NoTraditionalRecordSyntax #-} was
implemented in 7.2.1.
But GHCi v7.2.1 complains Unsupported extension:
NoTraditionalRecordSyntax.
What
.
Yes, the pruning is _too_ radical, the tree withered away.
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
-- not parametric
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
this to be treated:
e{ x = True }
{* `e` is some arbitrary expression, possibly denoting a record type;
`x` one of those names for which you've solved the namespace problem*}
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
/Kind application for this to work?
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
wagnerdm at seas.upenn.edu writes:
Quoting AntC anthony_clayden at clear.net.nz:
{-# OPTIONS_GHC -XDataKinds -XPolyKinds -XKindSignatures#-}
data MyNat = Z | S MyNat
class NatToIntN (n :: MyNat)
where natToIntN :: (n :: MyNat) - Int
instance NatToIntN Z
José Pedro Magalhães jpm at cs.uu.nl writes:
On Thu, Jun 7, 2012 at 2:46 AM, AntC anthony_clayden at clear.net.nz
wrote:
What does the `ArgKind' message mean?
`ArgKind` and `OpenKind` is what previously was called `?` and `??` (or the
otherway around; I can't remember).
http
we have :k (-) :: OpenKind - * - * -- why not?
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Edward Kmett ekmett at gmail.com writes:
On Mon, Jun 11, 2012 at 9:58 PM, AntC anthony_clayden at clear.net.nz
wrote:
[snip ...]
Could we have :k (-) :: OpenKind - * - * -- why not?
I don't quite understand why you would want arbitrary kinded arguments, but
only in negative position
Richard Eisenberg eir at cis.upenn.edu writes:
Hi Richard, I was hoping one of the type/class/family luminaries would
pick this up, but I'll make a crack at moving it along.
It’s come to my attention that there is a tiny lurking potential hole in
GHC’s type safety around type families in
, it's just too hard to guard against
infinite types appearing from chains of instances, possibly in 'distant'
imports or recursive module references.
So I understand it's not worth sacrificing type safety.
AntC
___
Glasgow-haskell-users mailing list
that for a 'decidable' family there could be instances
declared in other modules that get compiled with a different flag setting.
But with 'closed type families', that can't happen, right?)
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users
operator is not really an operator, neither
is it part of the name as in module prefixes(?)
(I'll add some more thoughts to SPJ's comment.)
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman
Simon Peyton-Jones simonpj at microsoft.com writes:
| record projections. I would prefer to have dot notation for a
| general, very tightly-binding reverse application, ...
| Such a general reverse application dot would
| allow things like string.toUpper and for me personally, it would
person.lastName.toUpper-- == toUpper (lastName person)
Oops! that should be one of:
person.lastName.head.toUpper
person.lastName.(map toUpper)
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
:
template-haskell functions for lens try to tackle the SORF/DORF-like
aspects. These are what Greg Weber was referring to in that earlier email.
errm I didn't see an email from Greg(?)
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users
Adam Gundry adam.gundry at strath.ac.uk writes:
I've started to document the plan on the GHC wiki:
http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Pla
n
Thank you Adam, (Simon)
I like the approach for Representation hiding. (That was something I was
particularly
. (If GSoC hasn't expired yet!)
Implement ‑XDotPostfixFuncApply as an orthogonal extension ;-).
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
might have to define a local
type
data Unused = U { foo :: Int }
simply so that there *is* at least on foo field in scope.
No, I don't see that funny decls are needed.
AntC
| -Original Message-
| From: glasgow-haskell-users On Behalf Of AntC
| Sent: 27 June 2013 13:37
Malcolm Wallace malcolm.wallace at me.com writes:
With the orthogonal proposal, f is equivalent to
f r b = foo r b
I believe Simon's point is that, if dot is special, we can infer
the Has type above, even if the compiler is
not currently aware of any actual record types that
, bar, baz } - xs, baz = 27 ]
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Carter Schonwald carter.schonwald at gmail.com writes:
indeed, this relates / augments record puns syntax already in
GHC http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-
extns.html#record-puns.
Uh-oh. That documentation gives an example, and it exactly explains the
weird
the challenge yet? ;-)
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Simon Peyton-Jones simonpj at microsoft.com writes:
...; it’s a tradeoff between polymorphism and overloading.
Hah! my post crossed with Simon's. This time I'll be succinct.
There's **three** alternatives. ...
data R a = MkR { foo :: a - a }
data S = MkS { bar
Adam Gundry adam.gundry at strath.ac.uk writes:
On 04/07/13 12:27, AntC wrote:
H-R fields are a limitation because we can't update them either. So I
think it's a fair question whether supporting h-r polymorphism is
worth the limitations?
Yes, higher rank polymorphism is bound to cause
Simon Peyton-Jones simonpj at microsoft.com writes:
I've realised that GHC's -XIncoherentInstances flag is,
I think, over-conservative.
Hi Simon, by coincidence I've just come across a very similar issue with
overlapping instances and FunDeps (following-up some discussion with Oleg,
AntC anthony_clayden at clear.net.nz writes:
Uh-oh, quoted the wrong example. I mean:
Starting with:
class C a b | a - b where foo :: a - b
instance C [a] [a] where foo = id
t11 = \x - foo [x] -- t11 :: t - [t]
I then added:
instance C [Char] [Char] where foo = id
',
then you don't need IncoherentInstances, IMO.
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
, but no partial overlaps.)
So I would like the pragmas to be able to say:
OK for this instance to subsumes or be subsumed by some other instance
but it must not partially overlap any instance.
(I guess this is beyond the question Simon's OP asked.)
AntC
if I have the result type
as an extra param to the class,
with a FunDep in the classic style:
class C a b | a - b where
f :: a - b
(I can supply those more complex examples if need be,
but this post is already too long.)
AntC
family ... where ...
- t'other where we want everything to do with a type constructor together
that fits better with the separate instances
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin
/library module
you don't want to touch.
Is this separate instance group idea still a gleam in someone's eye?
If not, is there some deep theoretical reason against?
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http
From: AntC
Date: 2015-06-04 22:39:25 GMT
Take the standard example for partial overlaps.
Suppose I have a class: ...
I'm also getting (in more complex examples)
GHC complaining it can't infer the types
for the result of f.
So now I'm having to put type equality
constraints
to appear with the class instances
-- even as Associated types.
(And we'd need type disequality guards
on the class instances.)
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo
. Automatically generate the type eq constraint.
(Or at least suggest that as a Possible fix
in the error message.)
2. Don't bother with a type family in such cases.
Instead use Overlaps with FunDeps.
(And needs UndecidableInstances.)
On Jun 6, 2015, at 2:04 AM, AntC wrote:
needs the eq
f the time ...
DuplicateRecordFields is aiming for the simple examples.
If some case isn't simple enough,
you can always add signatures until it is.
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
i page.
>
It's linked as Solution 2 on that records page, called "TDNR".
Surely there can't be any records approaches that haven't been aired by now?
And GHC's direction is set.
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@h
i/Records/OverloadedRecordFields/SORF
That had to be abandoned,
until explicit type application was available IIRC.
We now have type application in GHC 8.0.
Is there some hope for higher-rank type fields?
AntC
___
Glasgow-haskell-users mailing list
Glasgow-hask
ass's logic
get built into the first?)
Yes DuplicateRecordFIelds is a bit of a hack.
The proper solution (MagicTypeClasses) is still awaited.
Can you explain why GHC should depart from that plan?
AntC
___
Glasgow-haskell-users mailing list
G
ot;) (Record3 True False "ok"
:: Record3 "foo" Bool "foo" Bool "bar" String)
Again if it is a requirement,
it's easy enough to build a smart constructor wrapper
that validates for duplicate labels, á la HList.
Did that answer (any of) your question?
indexing by Type Constructor
> Except starting lower case,
> otherwise the #name prefix will throw a wobbly.
??Is that actually true?
H98 field labels must be lower case,
so all the examples are.
But Symbol can be upper??
AntC
___
Glasgow-
> > On 26/04/16 09:20, AntC wrote:
> > There's an intriguing comment here wrt anonymous records: ...
>
> I'm afraid the sentence on the wiki page is slightly misleading, ...
> with the change to functional dependencies,
> the overlapping instances solu
> Jeremy hotmail.com> writes:
> > AntC wrote
> > I think you'll find rather a lot of those in existing code.
> > So this is a code-breaking change.
>
> Could you give an example of existing code that would break?
> This certainly wasn't what I had in mind.
T
mbiguation applies only to them,
not in general to bare function names.
> (I'm not endorsing the proposal, ...
Quite.
> ... just trying to clarify what it is.)
>
Quite.
And since 8.0 is officially released as of this weekend,
I rather think "syntaxless TDNR", whatever it is/was, i
wiki/Records/OverloadedRecordFields
I suspect Part 1: Duplicate Record Fields
will go a long way towards disambinguating label names,
with only an occasional need for explicit type signatures.
How does that compare with TDNR minus syntax?
AntC
___
Glas
se to my q on this thread.
But v.v. if you have some piece using type families,
and then want to delegate to FunDeps because of nasty overlaps;
that tends to get awkward.
It's better than it was with the first releases of type families.
AntC
___
R *is* to apply to that sort of function application(?)
So to ($) or not? to (.) or not? to sections or not?
to bare name functions supplied as arguments (to say map) or not?
I think this is the point SPJ would ask you to write up a proposal on a wiki,
to the same level of detail as all those other records pr
90 matches
Mail list logo
