30 Jun 2013 08:59

## A possible alternative to dot notation for record access

Hi all,

Instead of "f.x" (to access field x of record f), maybe we could write "f{x}" as the record selection.  That is, we'd reuse the brace notation which is already in place for record updates.  Unlike dot notation, this is unambiguous and doesn't conflict with any existing syntax (AFAIK).  It would also generalize to "f{x}{y}{z}" instead of "f.x.y.z".

This proposal would add two new forms of expressions:

f{x} to access field x of data f
({x}) = \f -> f{x} as a field access section

Additionally, it seems like record mutation expressions could also have sections:

({x=2}) = \f -> f{x=2}

That actually seems useful by itself, regardless of whether we use dot notation for field access.

Best,
-Judah
```_______________________________________________
```
30 Jun 2013 09:26

### Re: A possible alternative to dot notation for record access

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.

Otoh, would there be any ambiguity wrt applying functions to blocks?

eg
f = (+ 1)
h= f {let x = 7 in 3*x},
would that trip up the syntax?

On Sun, Jun 30, 2013 at 2:59 AM, Judah Jacobson wrote:
Hi all,

Instead of "f.x" (to access field x of record f), maybe we could write "f{x}" as the record selection.  That is, we'd reuse the brace notation which is already in place for record updates.  Unlike dot notation, this is unambiguous and doesn't conflict with any existing syntax (AFAIK).  It would also generalize to "f{x}{y}{z}" instead of "f.x.y.z".

This proposal would add two new forms of expressions:

f{x} to access field x of data f
({x}) = \f -> f{x} as a field access section

Additionally, it seems like record mutation expressions could also have sections:

({x=2}) = \f -> f{x=2}

That actually seems useful by itself, regardless of whether we use dot notation for field access.

Best,
-Judah

_______________________________________________

```_______________________________________________
```
30 Jun 2013 11:09

### Re: A possible alternative to dot notation for record access

```* Carter Schonwald <carter.schonwald <at> gmail.com> [2013-06-30 03:26:22-0400]
> Otoh, would there be any ambiguity wrt applying functions to blocks?
>
> eg
> f = (+ 1)
> h= f {let x = 7 in 3*x},
> would that trip up the syntax?

This is not valid Haskell anyway (there's no such thing as "applying
functions to blocks"). You can write

h = f (let {x = 7} in 3*x)

or

h = f \$ let {x = 7} in 3*x

Roman

> On Sun, Jun 30, 2013 at 2:59 AM, Judah Jacobson <judah.jacobson <at> gmail.com>wrote:
>
> > Hi all,
> >
> > I had a quick idea about record field syntax as specified in the GSoC
> > project plan:
> > .
> >
> > Instead of "f.x" (to access field x of record f), maybe we could write
> > "f{x}" as the record selection.  That is, we'd reuse the brace notation
> > which is already in place for record updates.  Unlike dot notation, this is
> > unambiguous and doesn't conflict with any existing syntax (AFAIK).  It
> > would also generalize to "f{x}{y}{z}" instead of "f.x.y.z".
> >
> > This proposal would add two new forms of expressions:
> >
> > f{x} to access field x of data f
> > ({x}) = \f -> f{x} as a field access section
> >
> > Additionally, it seems like record mutation expressions could also have
> > sections:
> >
> > ({x=2}) = \f -> f{x=2}
> >
> > That actually seems useful by itself, regardless of whether we use dot
> > notation for field access.
> >
> > Best,
> > -Judah
> >
> > _______________________________________________
> >
> >

> _______________________________________________
```
1 Jul 2013 04:59

### Re: A possible alternative to dot notation for record access

```> Carter Schonwald <carter.schonwald <at> gmail.com> writes:
>
> indeed, this relates / augments record puns syntax already in
extns.html#record-puns.
>

Uh-oh. That documentation gives an example, and it exactly explains the
weird type-level error I got when I tried to use the proposed syntax
myself:

Note that:

*   Record punning can also be used in an expression, writing, for
example,

let a = 1 in C {a}            -- !!!

let a = 1 in C {a = a}

The expansion is purely syntactic, so the expanded right-hand side
expression refers to the nearest enclosing variable that is spelled the
same as the field name.

IOW the proposal _does_ conflict with existing syntax. (And I guess I can
see a use for the example. Note that outside of that let binding, `a`
would be a field selector function generated from the data decl in which
field `a` appears -- that's the weirdity I got.)

I suppose the existing syntax has a data constructor in front of the
braces, whereas the proposal wants a term. But of course a data
constructor is a term.

So the proposal would be a breaking change. Rats! Is anybody using that
feature?

>
> On Sun, Jun 30, 2013 at 2:59 AM, Judah Jacobson <judah.jacobson <at>
gmail.com> wrote:
>
> Unlike dot notation, this is unambiguous and doesn't conflict with any
existing syntax (AFAIK). ...

_______________________________________________
```
1 Jul 2013 05:38

### Re: A possible alternative to dot notation for record access

```As long as we're bikeshedding...

Possibly '#' is unused syntax -- Erlang uses it for its records too, so we wouldn't be pulling it out of thin
air. E.g. "person#firstName"

Tom

El Jun 30, 2013, a las 22:59, AntC <anthony_clayden <at> clear.net.nz> escribió:

>> Carter Schonwald <carter.schonwald <at> gmail.com> writes:
>>
>> indeed, this relates / augments record puns syntax already in
> extns.html#record-puns.
>
> Uh-oh. That documentation gives an example, and it exactly explains the
> weird type-level error I got when I tried to use the proposed syntax
> myself:
>
>    Note that:
>
>    *   Record punning can also be used in an expression, writing, for
> example,
>
>        let a = 1 in C {a}            -- !!!
>
>
>        let a = 1 in C {a = a}
>
>        The expansion is purely syntactic, so the expanded right-hand side
> expression refers to the nearest enclosing variable that is spelled the
> same as the field name.
>
> IOW the proposal _does_ conflict with existing syntax. (And I guess I can
> see a use for the example. Note that outside of that let binding, `a`
> would be a field selector function generated from the data decl in which
> field `a` appears -- that's the weirdity I got.)
>
> I suppose the existing syntax has a data constructor in front of the
> braces, whereas the proposal wants a term. But of course a data
> constructor is a term.
>
> So the proposal would be a breaking change. Rats! Is anybody using that
> feature?
>
>>
>> On Sun, Jun 30, 2013 at 2:59 AM, Judah Jacobson <judah.jacobson <at>
> gmail.com> wrote:
>>
>> Unlike dot notation, this is unambiguous and doesn't conflict with any
> existing syntax (AFAIK). ...
>
>
> _______________________________________________

_______________________________________________
```
1 Jul 2013 07:10

### Re: A possible alternative to dot notation for record access

(#) is a legal operator today and is used in a number of libraries.

On Sun, Jun 30, 2013 at 11:38 PM, wrote:
As long as we're bikeshedding...

Possibly '#' is unused syntax -- Erlang uses it for its records too, so we wouldn't be pulling it out of thin air. E.g. "person#firstName"

Tom

El Jun 30, 2013, a las 22:59, AntC <anthony_clayden <at> clear.net.nz> escribió:

>> Carter Schonwald <carter.schonwald <at> gmail.com> writes:
>>
>> indeed, this relates / augments record puns syntax already in
> extns.html#record-puns.
>
> Uh-oh. That documentation gives an example, and it exactly explains the
> weird type-level error I got when I tried to use the proposed syntax
> myself:
>
>    Note that:
>
>    *   Record punning can also be used in an expression, writing, for
> example,
>
>        let a = 1 in C {a}            -- !!!
>
>
>        let a = 1 in C {a = a}
>
>        The expansion is purely syntactic, so the expanded right-hand side
> expression refers to the nearest enclosing variable that is spelled the
> same as the field name.
>
> IOW the proposal _does_ conflict with existing syntax. (And I guess I can
> see a use for the example. Note that outside of that let binding, `a`
> would be a field selector function generated from the data decl in which
> field `a` appears -- that's the weirdity I got.)
>
> I suppose the existing syntax has a data constructor in front of the
> braces, whereas the proposal wants a term. But of course a data
> constructor is a term.
>
> So the proposal would be a breaking change. Rats! Is anybody using that
> feature?
>
>>
>> On Sun, Jun 30, 2013 at 2:59 AM, Judah Jacobson <judah.jacobson <at>
> gmail.com> wrote:
>>
>> Unlike dot notation, this is unambiguous and doesn't conflict with any
> existing syntax (AFAIK). ...
>
>
> _______________________________________________

_______________________________________________

```_______________________________________________
```
1 Jul 2013 07:12

### Re: A possible alternative to dot notation for record access

If you really want to hunt for unused syntax and we wind up needing a (.) analogue then (->) is currently a reserved operator, so opening it up for use at the term level could be made to work, and there is a precedent with c/c++ pointer dereferencing.

-Edward

On Mon, Jul 1, 2013 at 1:10 AM, Edward Kmett wrote:
(#) is a legal operator today and is used in a number of libraries.

On Sun, Jun 30, 2013 at 11:38 PM, wrote:
As long as we're bikeshedding...

Possibly '#' is unused syntax -- Erlang uses it for its records too, so we wouldn't be pulling it out of thin air. E.g. "person#firstName"

Tom

El Jun 30, 2013, a las 22:59, AntC <anthony_clayden <at> clear.net.nz> escribió:

>> Carter Schonwald <carter.schonwald <at> gmail.com> writes:
>>
>> indeed, this relates / augments record puns syntax already in
> extns.html#record-puns.
>
> Uh-oh. That documentation gives an example, and it exactly explains the
> weird type-level error I got when I tried to use the proposed syntax
> myself:
>
>    Note that:
>
>    *   Record punning can also be used in an expression, writing, for
> example,
>
>        let a = 1 in C {a}            -- !!!
>
>
>        let a = 1 in C {a = a}
>
>        The expansion is purely syntactic, so the expanded right-hand side
> expression refers to the nearest enclosing variable that is spelled the
> same as the field name.
>
> IOW the proposal _does_ conflict with existing syntax. (And I guess I can
> see a use for the example. Note that outside of that let binding, `a`
> would be a field selector function generated from the data decl in which
> field `a` appears -- that's the weirdity I got.)
>
> I suppose the existing syntax has a data constructor in front of the
> braces, whereas the proposal wants a term. But of course a data
> constructor is a term.
>
> So the proposal would be a breaking change. Rats! Is anybody using that
> feature?
>
>>
>> On Sun, Jun 30, 2013 at 2:59 AM, Judah Jacobson <judah.jacobson <at>
> gmail.com> wrote:
>>
>> Unlike dot notation, this is unambiguous and doesn't conflict with any
> existing syntax (AFAIK). ...
>
>
> _______________________________________________

_______________________________________________

```_______________________________________________
```
1 Jul 2013 08:27

### Re: A possible alternative to dot notation for record access

```>>>>> Edward Kmett <ekmett <at> gmail.com> writes:

> If you really want to hunt for unused syntax and we wind up needing a (.)
> analogue then (->) is currently a reserved operator, so opening it up for
> use at the term level could be made to work, and there is a precedent with
> c/c++ pointer dereferencing.

Imagine this possible code:

foo :: Maybe Foo -> Bar
foo (fromMaybe def -> x) = \x -> case x of
Foo x -> x->y->z

I think it might get a bit ugly to give it a 5th meaning.

--

--
John Wiegley
FP Complete                         Haskell tools, training and consulting
```
1 Jul 2013 15:24

### Re: A possible alternative to dot notation for record access

```Sure. I'd rather have nothing, but at least unlike the (.) proposals it doesn't break existing code.

That said I don't think we need either.

On Jul 1, 2013, at 2:27 AM, "John Wiegley" <johnw <at> fpcomplete.com> wrote:

>>>>>> Edward Kmett <ekmett <at> gmail.com> writes:
>
>> If you really want to hunt for unused syntax and we wind up needing a (.)
>> analogue then (->) is currently a reserved operator, so opening it up for
>> use at the term level could be made to work, and there is a precedent with
>> c/c++ pointer dereferencing.
>
> Imagine this possible code:
>
>    foo :: Maybe Foo -> Bar
>    foo (fromMaybe def -> x) = \x -> case x of
>        Foo x -> x->y->z
>
> I think it might get a bit ugly to give it a 5th meaning.
>
> --
> John Wiegley
> FP Complete                         Haskell tools, training and consulting
>
> _______________________________________________
```
12 Jul 2013 08:01

### Re: A possible alternative to dot notation for record access

6 even:

foo :: (Maybe :: * -> *) Foo -> Bar
foo (fromMaybe def -> x) = \x -> case x of
Foo x -> x->y->z

On Mon, Jul 1, 2013 at 4:27 PM, John Wiegley wrote:
>>>>> Edward Kmett <ekmett <at> gmail.com> writes:

> If you really want to hunt for unused syntax and we wind up needing a (.)
> analogue then (->) is currently a reserved operator, so opening it up for
> use at the term level could be made to work, and there is a precedent with
> c/c++ pointer dereferencing.

Imagine this possible code:

foo :: Maybe Foo -> Bar
foo (fromMaybe def -> x) = \x -> case x of
Foo x -> x->y->z

I think it might get a bit ugly to give it a 5th meaning.

--
John Wiegley
FP Complete                         Haskell tools, training and consulting

_______________________________________________

```_______________________________________________
```
1 Jul 2013 03:22

### Re: A possible alternative to dot notation for record access

```Judah Jacobson wrote:
> I had a quick idea about record field syntax as specified in the GSoC
> project plan:
>
> .
>
> Instead of "f.x" (to access field x of record f), maybe we could write
> "f{x}" as the record selection.  That is, we'd reuse the brace notation
> which is already in place for record updates.  Unlike dot notation, this
is
> unambiguous and doesn't conflict with any existing syntax (AFAIK).  It
> would also generalize to "f{x}{y}{z}" instead of "f.x.y.z".
>
> This proposal would add two new forms of expressions:
>
> f{x} to access field x of data f
> ({x}) = \f -> f{x} as a field access section
>
> Additionally, it seems like record mutation expressions could also have
> sections:
>
> ({x=2}) = \f -> f{x=2}
>
> That actually seems useful by itself, regardless of whether we use dot
> notation for field access.

I think this is a pretty nice idea. (Disclaimer: I haven't spent any time on
of-dot faction). In any case it is light-weight enough to be actually
useful, it is readable and suggestive, and (at least conceptually) fits well
in the existing record syntax.

This deserves a fully fleshed-out proposal for Haskell' IMO.

Cheers
--

--
Ben Franksen
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachm€nts

_______________________________________________