On Mon, Feb 20, 2012 at 4:41 AM, AntC anthony_clay...@clear.net.nz wrote:
Folks, I've put my 'Record in Haskell' proposal on the wiki
http://hackage.haskell.org/trac/ghc/wiki/Records as suggestion 5 Declared
Overloaded Record Fields.
Thanks to the voiciferousness on this thread, dot notation
Gábor Lehel illissius at gmail.com writes:
On Mon, Feb 20, 2012 at 4:41 AM, AntC anthony_clayden at clear.net.nz
wrote:
Folks, I've put my 'Record in Haskell' proposal on the wiki
http://hackage.haskell.org/trac/ghc/wiki/Records as suggestion 5 Declared
Overloaded Record Fields.
I'm proposing my record fields so that selectors are just functions. Then
it's
independent of dot notation. (It's the semantics I'm far more concerned
with.)
Folks, I've put my 'Record in Haskell' proposal on the wiki
http://hackage.haskell.org/trac/ghc/wiki/Records as suggestion 5 Declared
OK, we could implement lenses, make `tempo' a lens instead of a selector,
desugar the update syntax to call the update 'method' out of the lens, ...
And of course somehow arrange the sugar that when `tempo' appears in other
contexts we take the select 'method'.
implement lenses - Done, of
On 2/8/12 10:10 PM, Anthony Clayden wrote:
I chose the most available non-ASCII character I could
find. Set the criterion to be present in most ISO 8-bit
character sets and there are really only two candidates,
section sign and degrees sign. ...
Brilliant! We'll use degrees sign for function
On Fri, Feb 10, 2012 at 5:31 AM, Evan Laforge qdun...@gmail.com wrote:
You can also enforce invariants, etc. It would be a shame to have a
nice record update syntax only to be discouraged from using it because
it would tie you too tightly to the current shape of the data
structure. There
On Thu, Feb 9, 2012 at 10:03 PM, Donn Cave d...@avvanta.com wrote:
Quoth Evan Laforge qdun...@gmail.com,
On Thu, Feb 9, 2012 at 12:49 PM, Donn Cave d...@avvanta.com wrote:
...
For example, in a better world you could write stuff like
modifyConfig :: (Config - a) - (a - a) - Config - Config
On 10/02/2012 03:22, Donn Cave wrote:
modifyRecord :: RecordType r = (a - a) - (r - a) - r - r
data Config { tempo :: Int, ...}
f = modifyRecord tempo (+20)
I'm hoping I missed something, and that you don't intend the (r - a)
part of this in particular to be taken literally.
Although it's a bit off topic, I must say I agree with Malcolm on that.
Record-fields-selection-as-functions might be sometime unconvenient, but
it is simple and easy to reason about and deal with, with usual Haskell
strategies (prefixed names, modules, qualified imports ... business as
usual).
Quoth Evan Laforge qdun...@gmail.com,
...
The non-composing non-abstract updates are what bug me, and
make me scatter about tons of 'modifyThis' functions, both for
composability and to protect from field renames.
So ... at the risk of stating the obvious, is it fair to say the root
of this
modifyConfig :: (Config - a) - (a - a) - Config - Config
modifyConfig fr fv a = a { fr = fv (fr a)
I like this Idea. The only problem I see is this: if I'm trying to write
code that is very generic and abstract, how does the compiler know if the
update
a { fr = 5 }
is targeting a field
Donn Cave donn at avvanta.com writes:
Quoth Evan Laforge qdunkan at gmail.com,
...
The non-composing non-abstract updates are what bug me, and
make me scatter about tons of 'modifyThis' functions, both for
composability and to protect from field renames.
So ... at the risk of stating
Quoth AntC anthony_clay...@clear.net.nz,
...
No, Donn, it's not the lack of syntax, it's the lack of semantics for first-
class (polymorphic) record update. And there's very little that's obvious.
Ah, you're right, I certainly shouldn't have used the word syntax there.
But just to be clear on
On Thu, Feb 9, 2012 at 12:49 PM, Donn Cave d...@avvanta.com wrote:
Quoth Evan Laforge qdun...@gmail.com,
...
The non-composing non-abstract updates are what bug me, and
make me scatter about tons of 'modifyThis' functions, both for
composability and to protect from field renames.
So ... at
Donn Cave donn at avvanta.com writes:
-- modifyRecord :: RecordType r = (a - a) - (r - a) - r - r
modifyRecord :: RecordType r = (r - a) - (a - a) - r - r
... while this does obviously represent a polymorphic function,
Exactly!
if I write
-- data Config { tempo :: Int, ...}
Quoth Evan Laforge qdun...@gmail.com,
On Thu, Feb 9, 2012 at 12:49 PM, Donn Cave d...@avvanta.com wrote:
...
For example, in a better world you could write stuff like
modifyConfig :: (Config - a) - (a - a) - Config - Config
modifyConfig fr fv a = a { fr = fv (fr a) }
upTempo config =
Quoth AntC anthony_clay...@clear.net.nz,
Donn Cave donn at avvanta.com writes:
...
The narrow issue we're trying to address is namespacing, and specifically name
clashes: two different records with the same named field.
...
Now in return for me answering that, please answer the questions in my
On 07/02/2012 22:56, Richard O'Keefe wrote:
On 8/02/2012, at 2:11 AM, Steve Horne wrote:
To be fair, field OF record isn't bad in that sense. However, it would defeat
the purpose of TDNR - the record isn't first, and therefore cannot be used (given a
left-to-right typing direction) as a
On 8/02/2012, at 14:16, Steve Horne sh006d3...@blueyonder.co.uk wrote:
I haven't given a lot of thought to updates.
I very much fail to see the point of replacing prefix function application with
postfix dots, merely for field selection. There are already some imperfect,
but adequate,
On 9/02/2012, at 3:16 AM, Steve Horne wrote:
On 07/02/2012 22:56, Richard O'Keefe wrote:
On 8/02/2012, at 2:11 AM, Steve Horne wrote:
To be fair, field OF record isn't bad in that sense. However, it would
defeat the purpose of TDNR - the record isn't first, and therefore cannot
be
record.field (read record, oops, I only want part of it.)
I would read this record's field
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
On Wed, Feb 8, 2012 at 2:47 PM, Malcolm Wallace malcolm.wall...@me.com wrote:
On 8/02/2012, at 14:16, Steve Horne sh006d3...@blueyonder.co.uk wrote:
I haven't given a lot of thought to updates.
I very much fail to see the point of replacing prefix function application
with postfix dots,
How about § then? Surely at this late date we can allow ourselves *one*
non-ASCII character?
The very name of it (*section* sign) suggests taking a part; and if you are
totally in love
with dot, think of it as a dot with ponytails.
I suggest record的field, or record之field for the more
On 9/02/2012, at 1:26 PM, Evan Laforge wrote:
How about § then? Surely at this late date we can allow ourselves *one*
non-ASCII character?
The very name of it (*section* sign) suggests taking a part; and if you are
totally in love
with dot, think of it as a dot with ponytails.
I
I chose the most available non-ASCII character I could
find. Set the criterion to be present in most ISO 8-bit
character sets and there are really only two candidates,
section sign and degrees sign. ...
Brilliant! We'll use degrees sign for function composition
(so that it follows the
On 06/02/2012 23:58, Richard O'Keefe wrote:
On 4/02/2012, at 12:13 AM, Gábor Lehel wrote:
All of this said, record.field is still the most readable, intuitive,
and familiar syntax for selecting a field from a record that I know
of.
Having learned COBOL and Algol 68 before Haskell was dreamed
Crash blossoms, while amusing, are not a desirable feature of a programming
language. They are specifically a failure to communicate clearly.
On Feb 6, 2012 6:38 PM, AntC anthony_clay...@clear.net.nz wrote:
Donn Cave donn at avvanta.com writes:
You can find stuff like fromIntegral.ord in
On 7/02/2012, at 1:41 PM, AntC wrote:
Richard, now you're just being playful.
Half fun and full earnest.
I *do* regard 'field OF record' as far more readable, intuitive, c
than 'record.field'. With the number of meanings '.' already has in
Haskell, I *do* regard any attempt to overload it for
On 2/7/12 4:52 PM, Richard O'Keefe wrote:
Anyone who has had occasion to write Fortran in the last 20+ years
has had to discover just how quickly you can get used to using
'record%field'. I'm not really a COBOL programmer, but Prolog and
Erlang and Smalltalk taught me well that '.' in a
On 8/02/2012, at 2:11 AM, Steve Horne wrote:
On 06/02/2012 23:58, Richard O'Keefe wrote:
On 4/02/2012, at 12:13 AM, Gábor Lehel wrote:
All of this said, record.field is still the most readable, intuitive,
and familiar syntax for selecting a field from a record that I know
of.
Having
On 4/02/2012, at 12:13 AM, Gábor Lehel wrote:
All of this said, record.field is still the most readable, intuitive,
and familiar syntax for selecting a field from a record that I know
of.
Having learned COBOL and Algol 68 before Haskell was dreamed of,
I regard
field OF record
as
Donn Cave donn at avvanta.com writes:
Quoth AntC anthony_clayden at clear.net.nz,
...
We're on the slippery slope! Where will it end?
And now that I've found it, I so love:
customer.lastName.tail.head.toUpper-- Yay!
... compared to present practice, with where dot is
Richard O'Keefe ok at cs.otago.ac.nz writes:
On 4/02/2012, at 12:13 AM, Gábor Lehel wrote:
All of this said, record.field is still the most readable, intuitive,
and familiar syntax for selecting a field from a record that I know
of.
Having learned COBOL and Algol 68 before
Quoth AntC anthony_clay...@clear.net.nz,
...
It was a surprise to me that dot without spaces around is still legal
syntax for function composition.
It isn't even unusual. You can find stuff like fromIntegral.ord in
packages downloaded to build cabal-install for example. It graphically
appeals
Donn Cave donn at avvanta.com writes:
You can find stuff like fromIntegral.ord in
packages downloaded to build cabal-install for example. It graphically
appeals to the notion of a function composed of several functions, so
the programmers in question will likely not even be repentant!
Kevin Quick quick at sparq.org writes:
Currently under H98:
f.g-- (both lower case, no space around the dot)
Is taken as function composition -- same as (f . g).
f. g -- is taken as func composition (f . g)
f .g -- is taken as func composition (f . g)
On Fri, Feb 3, 2012 at 10:30 AM, AntC anthony_clay...@clear.net.nz wrote:
You seem to be not alone in wanting some special syntax for applying field
selectors (see other posts on this thread). H98 field selectors don't do this,
they're just functions.
And there's me bending over backwards to
On 03/02/2012 11:13, Gábor Lehel wrote:
The first problem is that mixing prefix and postfix function
application within the same line makes it harder to read. When you
read code to try to understand what it does, the direction you like to
go in is here's some object, first do this to it, then do
Gábor Lehel illissius at gmail.com writes:
On Fri, Feb 3, 2012 at 10:30 AM, AntC anthony_clayden at clear.net.nz
wrote:
You seem to be not alone in wanting some special syntax for applying field
selectors (see other posts on this thread). H98 field selectors don't do
this,
they're just
Steve Horne sh006d3...@blueyonder.co.uk wrote:
There's a proposal at the moment to add support for TDNR to Haskell -
to leverage the power of the dot (e.g. for intellisense).
http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolution
I'm not sure whether this should really
On Fri, Feb 3, 2012 at 2:37 PM, AntC anthony_clay...@clear.net.nz wrote:
Do people really write code with huge pile-ups of functions prefix upon
prefix? Wouldn't that be confusing even when it's unidirectional?
Not really. Pipeline-like chains where you apply each function to the
result of the
Gábor Lehel illissius at gmail.com writes:
On Fri, Feb 3, 2012 at 2:37 PM, AntC anthony_clayden at clear.net.nz
wrote:
Do people really write code with huge pile-ups of functions prefix upon
prefix? Wouldn't that be confusing even when it's unidirectional?
Not really. Pipeline-like
Quoth AntC anthony_clay...@clear.net.nz,
...
We're on the slippery slope! Where will it end?
And now that I've found it, I so love:
customer.lastName.tail.head.toUpper-- Yay!
... compared to present practice, with where dot is function
composition only -
On 2/3/12 6:13 AM, Gábor Lehel wrote:
The first problem is that mixing prefix and postfix function
application within the same line makes it harder to read. When you
read code to try to understand what it does, the direction you like to
go in is here's some object, first do this to it, then do
Kevin Quick quick at sparq.org writes:
On Tue, 31 Jan 2012 23:10:34 -0700, Anthony Clayden
anthony_clayden at clear.net.nz wrote:
I'm proposing x.f is _exactly_ f x. That is, the x.f gets
desugared at an early phase in compilation.
Anthony,
I think part of the concern people are
Fair deuce. With all due respect now included, my same concern still seems to
apply although I believe I poorly stated it originally. Allow me to retry:
By declaring partial application an invalid parse, it introduces an exception
to point-free style that is at odds with the normal intuition
I haven't read the underlying proposals, so I apologize if the following is
covered, but my understanding of the discussion is that the x.f notation is
intended to disambiguate f to be a field name of the type of x and therefore
be advantageous over f x notation where f is presently in the
quick at sparq.org writes:
Fair deuce. With all due respect now included, my same concern still seems
to
apply although I believe I poorly stated it originally. Allow me to retry:
OK, thank you.
By declaring partial application an invalid parse, it introduces an
exception
to
On 1/02/2012, at 7:10 PM, Anthony Clayden wrote:
On 1/02/2012, at 11:38 AM, AntC wrote:
As soon as you decide to make 'virtual record selectors'
just ordinary functions (so they select but not update)
, then you can see that field names are also just
ordinary functions (for selection
On Wed, 01 Feb 2012 19:42:19 -0700, AntC anthony_clay...@clear.net.nz
wrote:
A piece of background which has perhaps been implicit in the discussions
up to
now. Currently under H98:
f.g-- (both lower case, no space around the dot)
Is taken as function composition -- same as (f
Donn Cave donn at avvanta.com writes:
On 28/01/2012 13:00, Paul R wrote:
...
All this dot syntax magic frankly frightens me. Haskell, as a pure
functionnal language, requires (and allows !) a programming style that
just does not mix well with object oriented practices.
In the
Quoth AntC anthony_clay...@clear.net.nz,
...
My proposal is that field selection functions be just ordinary functions, and
dot notation be just function application(tight-binding). Then:
object.fieldfuncmethod == fieldfuncmethod object
(Subject to the tight binding for the dot.)
And
Donn Cave donn at avvanta.com writes:
Quoth AntC anthony_clayden at clear.net.nz,
...
My proposal is that field selection functions be just ordinary functions,
and
dot notation be just function application(tight-binding). Then:
object.fieldfuncmethod == fieldfuncmethod object
On 1/02/2012, at 11:38 AM, AntC wrote:
As soon as you decide to make 'virtual record selectors' just ordinary
functions (so they select but not update), then you can see that field names
are also just ordinary functions (for selection purposes). So the semantics
for field 'selection'
On 1/02/2012, at 11:38 AM, AntC wrote:
As soon as you decide to make 'virtual record selectors'
just ordinary functions (so they select but not update)
, then you can see that field names are also just
ordinary functions (for selection purposes). So the
semantics for field
On Tue, 31 Jan 2012 23:10:34 -0700, Anthony Clayden
anthony_clay...@clear.net.nz wrote:
I'm proposing x.f is _exactly_ f x. That is, the x.f gets
desugared at an early phase in compilation.
Anthony,
I think part of the concern people are expressing here is that the above
would imply the
On 30/01/2012 07:09, Donn Cave wrote:
((separate . crack . .smallEnd) egg).yolk
(f egg).yolk where f = separate . crack . .smallEnd
Scary - that .smallEnd worries me. It's like a field is being
referenced with some magical context from nowhere.
Obviously I need to read that full proposal.
Steve Every programmer has their own favorite editor, usually using the same
Steve one to work in many different languages. For the moment, you'd have
Steve a hard job separating me from Notepad++.
Main editors have very advanced customization features (though
incredibly hacky most of the time).
Quoth Steve Horne sh006d3...@blueyonder.co.uk,
On 30/01/2012 07:09, Donn Cave wrote:
((separate . crack . .smallEnd) egg).yolk
(f egg).yolk where f = separate . crack . .smallEnd
Scary - that .smallEnd worries me. It's like a field is being
referenced with some magical context from
On 28/01/2012 13:00, Paul R wrote:
AntC Steve, I think that proposal has been rather superseeded by
AntC http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields,
which
AntC draws on TDNR. But SORF is best seen as an evolving design space, with
precise
AntC details yet to be
On 30/01/2012 04:23, Steve Horne wrote:
On 28/01/2012 13:00, Paul R wrote:
AntC Steve, I think that proposal has been rather superseeded by
AntC
http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields,
which
AntC draws on TDNR. But SORF is best seen as an evolving design
On 28/01/2012 13:00, Paul R wrote:
...
All this dot syntax magic frankly frightens me. Haskell, as a pure
functionnal language, requires (and allows !) a programming style that
just does not mix well with object oriented practices. Stretching the
syntax to have the dot feel
AntC Steve, I think that proposal has been rather superseeded by
AntC http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields,
which
AntC draws on TDNR. But SORF is best seen as an evolving design space, with
precise
AntC details yet to be clarified/agreed. I've put my own
Steve Horne sh006d3592 at blueyonder.co.uk writes:
There's a proposal at the moment to add support for TDNR to Haskell
- to leverage the power of the dot (e.g. for
intellisense).http://hackage.haskell.org/trac/haskell-
prime/wiki/TypeDirectedNameResolution
I approve of the goal,
There's a proposal at the moment to add support for TDNR to Haskell - to
leverage the power of the dot (e.g. for intellisense).
http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolution
I approve of the goal, but I'd like to suggest a different approach.
My basic idea is
65 matches
Mail list logo
