On 15/06/16 04:29, AntC wrote:
> ...
>
> The earlier design for SORF tried to support higher-ranked fields.
> https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/SORF
>
> That had to be abandoned,
> until explicit type application was available IIRC.
>
> We now have type applicat
> Adam Gundry writes:
> ... Having spent more time thinking about record field overloading
> than perhaps I should, ...
Thanks Adam, another thing on the back burner ...
The earlier design for SORF tried to support higher-ranked fields.
https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRec
any
function, but only helps with disambiguation. There is some overlap, but it
is a different solution for different requirements.
--
View this message in context:
http://haskell.1045720.n5.nabble.com/TDNR-without-new-operators-or-syntax-changes-tp5835927p5836818.html
Sent
> Evan Laforge gmail.com> writes:
>
> That's why I was trying to emphasize "not an operator".
> TDNR is complicated because ...
>> Peter voldermort writes:
>> A slightly more refined definition for disambiguation: ...
Hi Evan, Peter, (and even James),
I'm not seeing you're proposing anything t
On Sat, May 28, 2016 at 3:13 AM, AntC wrote:
>> Evan Laforge gmail.com> writes:
>
>> ... what would happen if you tried to do records
>> just like C structs? So e.g. a•b requires 'a' to be a record with a
>> 'b' field, and is just one identifier, no functions involved, and 'b'
>> is not a separa
(although it may require two passes to disambiguate on the
inferred type of an argument), and disambiguating one name will not depend
on disambiguating any other name.
--
View this message in context:
http://haskell.1045720.n5.nabble.com/TDNR-without-new-operators-or-syntax-changes
> Evan Laforge gmail.com> writes:
> ... what would happen if you tried to do records
> just like C structs? So e.g. a•b requires 'a' to be a record with a
> 'b' field, and is just one identifier, no functions involved, and 'b'
> is not a separate value.
Hi Evan, um, that's the original TDNR isn
As long as were back on this topic again (sort of), and just to
satisfy my curiousity, what would happen if you tried to do records
just like C structs? So e.g. a•b requires 'a' to be a record with a
'b' field, and is just one identifier, no functions involved, and 'b'
is not a separate value.
I
> Dan Doel gmail.com> writes:
>
>> On Thu, May 26, 2016 at 5:14 AM, Peter hotmail.com> wrote:
>> Solving for everything but f, we get f :: T -> Int.
>
> So TDNR happens for things in function position (applied to something).
Before we get carried away, TDNR doesn't happen at all.
You're specul
On Thu, May 26, 2016 at 5:14 AM, Peter wrote:
> Solving for everything but f, we get f :: T -> Int.
So TDNR happens for things in function position (applied to something).
> Solving for everything but f, we get f :: T -> Int.
So TDNR happens for things in argument position.
> May not be solvab
:: Int
> i3 = f v
May not be solvable, would fail to disambiguate.
--
View this message in context:
http://haskell.1045720.n5.nabble.com/TDNR-without-new-operators-or-syntax-changes-tp5835927p5836657.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at
Nabble.com.
As a supplement, here's a series of definitions to think about. The
question is: what should happen in each section, and why? The more
detailed the answer, the better. Definitions from previous sections
are in scope in subsequent ones, for convenience. The examples are
arranged in a slippery slope,
Thanks for starting this discussion! Having spent more time thinking
about record field overloading than perhaps I should, here are some
things to think about...
On 22/05/16 16:01, Jeremy wrote:
> Bertram Felgenhauer-2 wrote
>>> 1. If the compiler encounters a term f a, and there is more than one
of a at a given time, then you need special treatment for
> unambiguous names or even trivial programs will fail to type-check, just
> as Anthony said.
Why special treatment for unambiguous names? They shouldn't be effected at
all by this.
--
View this message in context:
http://
Jeremy . wrote:
> Yes, that it indeed was I meant. AntC seems to be replying to a much
> more complicated/invasive proposal than what I had intended, apologies
> if I wasn't clear. (I see in retrospect that I may have misunderstood
> the original TDNR proposal, understandably leading to confusion.)
e.
--
View this message in context:
http://haskell.1045720.n5.nabble.com/TDNR-without-new-operators-or-syntax-changes-tp5835927p5836376.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at
Nabble.com.
___
Glasgow-haskell-users ma
On Sun, 22 May 2016, Jeremy . wrote:
1. If the compiler encounters a term f a, and there is more than one definition
for f in scope (after following all of
the usual rules for qualified imports);
2. And exactly one of these definitions matches the type of a (or the expected
type of f if give
Yes, that it indeed was I meant. AntC seems to be replying to a much more
complicated/invasive proposal than what I had intended, apologies if I wasn't
clear. (I see in retrospect that I may have misunderstood the original TDNR
proposal, understandably leading to confusion.)
1. If the compiler
> Bertram Felgenhauer googlemail.com> writes:
> ...
> I don't understand your conclusion.
Hi Bertram, I'm trying to tease out of Jeremy,
what he thinks his proposal amounts to.
Seeing as he's given very little clue so far.
So if I've arrived at an incorrect conclusion,
I want him to tell me wher
AntC wrote:
> >
> > With syntaxless TDNR enabled, the last line could be:
> >
> > f b c = do { reset b; reset c }
> >
>
> Heck, I didn't think you meant something that radical.
> So bare name in a function application context is to need disambiguating.
>
> I think you'll find rather a lot
> 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.
Then what do you have in mind?
"Do not
.nabble.com/TDNR-without-new-operators-or-syntax-changes-tp5835927p5836060.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at
Nabble.com.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org
>
> With syntaxless TDNR enabled, the last line could be:
>
> f b c = do { reset b; reset c }
>
Heck, I didn't think you meant something that radical.
So bare name in a function application context is to need disambiguating.
I think you'll find rather a lot of those in existing code.
So th
for reset, and in each case, pick the one which matches its
argument.
--
View this message in context:
http://haskell.1045720.n5.nabble.com/TDNR-without-new-operators-or-syntax-changes-tp5835927p5835978.html
Sent from the Haskell - Glasgow-haskell-users mailing list
> Jeremy hotmail.com> writes:
Hi Jeremy, I feel your frustration at the slow evolution of records proposals.
There are many reasons, including that there has been much debate
and little consensus.
>
> Previous attempts to propose TDNR [1] have met with opposition over the
> accompanying proposal
l.org/wiki/TypeDirectedNameResolution
--
View this message in context:
http://haskell.1045720.n5.nabble.com/TDNR-without-new-operators-or-syntax-changes-tp5835927.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at
Nabbl
26 matches
Mail list logo
