Hi all,
I had a quick idea about record field syntax as specified in the GSoC
project plan:
http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/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 t
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?
* Carter Schonwald [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
Judah Jacobson wrote:
> I had a quick idea about record field syntax as specified in the GSoC
> project plan:
>
http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Plan
> .
>
> Instead of "f.x" (to access field x of record f), maybe we could write
> "f{x}" as the record select
> Carter Schonwald 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 type-level error
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 escribió:
>> Carter Schonwald gmail.com> writes:
>>
>> indeed, this relates / a
(#) 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
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, Edwar
> Edward Kmett 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 t
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" wrote:
>> Edward Kmett writes:
>
>> If you really want to hunt for unused syntax and we wind up needing
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 writes:
>
> > If you really want to hunt for unused syntax and we wind up needing a (.)
> > analogue then (->) is
11 matches
Mail list logo
