Records (was Re: [Haskell] Improvements to GHC)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Records (was Re: [Haskell] Improvements to GHC)

Dimitry Golubovsky
Sebastian Sylvan wrote:

>Personally I think that the dot is way to good of a symbol to be
>"wasted" on function composition. I mean, how often do you really use
>function composition in a way which doesn't obfuscate your code? I use
>($) way more often than (.). Some people do use it more often than I

I found it useful to use (mainly for debugging purposes)

mapM (putStrLn . show) <some list>

if I want to print its elements each on a new line.

--
Dimitry Golubovsky

Anywhere on the Web

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Records (was Re: [Haskell] Improvements to GHC)

Cale Gibbard
Sebastian Sylvan wrote:

>Personally I think that the dot is way to good of a symbol to be
>"wasted" on function composition. I mean, how often do you really use
>function composition in a way which doesn't obfuscate your code? I use
>($) way more often than (.). Some people do use it more often than I

Function composition is a very important and fundamental operation on
functions, and I use it all the time. Haskell is supposed to be a
functional language. I'd vote against any motion to make it less
convenient. Of course, it really shouldn't be (.) but a small circle
centred on the line, which isn't on ordinary keyboards. (°) looks
closer, but is much less convenient to type. (I need to type
"<Compose> 0 ^" in order to get that character.) Spelling it as (.)
really is the best easy-to-type approximation.

 - Cale
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Records (was Re: [Haskell] Improvements to GHC)

Jon Fairbairn
On 2005-11-17 at 13:21EST Cale Gibbard wrote:

> Sebastian Sylvan wrote:
>
> >Personally I think that the dot is way to good of a symbol to be
> >"wasted" on function composition. I mean, how often do you really use
> >function composition in a way which doesn't obfuscate your code? I use
> >($) way more often than (.). Some people do use it more often than I
>
> Function composition is a very important and fundamental operation on
> functions, and I use it all the time. Haskell is supposed to be a
> functional language. I'd vote against any motion to make it less
> convenient.

Hear hear.

> Of course, it really shouldn't be (.) but a small circle
> centred on the line, which isn't on ordinary keyboards. (°) looks
> closer, but is much less convenient to type. (I need to type
> "<Compose> 0 ^" in order to get that character.) Spelling it as (.)
> really is the best easy-to-type approximation.

Ought to be ∘, unicode 0x2218, but without defining some
keyboard macros, that's even harder to type. On the other
hand, I could define ctrl-. as (ucs-insert "2218"), and then
it would be no harder to type than >.



--
Jón Fairbairn                              Jon.Fairbairn at cl.cam.ac.uk


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Records (was Re: [Haskell] Improvements to GHC)

Ben Franksen-2
In reply to this post by Cale Gibbard
On Thursday 17 November 2005 19:21, Cale Gibbard wrote:

> Sebastian Sylvan wrote:
> >Personally I think that the dot is way to good of a symbol to be
> >"wasted" on function composition. I mean, how often do you really
> > use function composition in a way which doesn't obfuscate your
> > code? I use ($) way more often than (.). Some people do use it more
> > often than I
>
> Function composition is a very important and fundamental operation on
> functions, and I use it all the time. Haskell is supposed to be a
> functional language. I'd vote against any motion to make it less
> convenient. Of course, it really shouldn't be (.) but a small circle
> centred on the line, which isn't on ordinary keyboards. (°) looks
> closer, but is much less convenient to type. (I need to type
> "<Compose> 0 ^" in order to get that character.) Spelling it as (.)
> really is the best easy-to-type approximation.

Yes, yes, yes. I'd rather use a different operator for record selection.
For instance the colon (:). Yes, I know it is the 'cons' operator for a
certain concrete data type that implements stacks (so called 'lists').
However I am generally opposed to wasting good operator and function
names as well as syntactic sugar of any kind on a /concrete/ data type,
and especially not for stacks aka lists.

For a hypothetical Haskell2 I'd propose to get rid of all special 'list'
constructs and re-use the good symbols and names for /abstract/
interfaces to sequences and collections resp. (in case of the colon)
for record selection.

Just my 2 cent.

Ben
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Records (was Re: [Haskell] Improvements to GHC)

Cale Gibbard
On 17/11/05, Benjamin Franksen <[hidden email]> wrote:

> On Thursday 17 November 2005 19:21, Cale Gibbard wrote:
> > Sebastian Sylvan wrote:
> > >Personally I think that the dot is way to good of a symbol to be
> > >"wasted" on function composition. I mean, how often do you really
> > > use function composition in a way which doesn't obfuscate your
> > > code? I use ($) way more often than (.). Some people do use it more
> > > often than I
> >
> > Function composition is a very important and fundamental operation on
> > functions, and I use it all the time. Haskell is supposed to be a
> > functional language. I'd vote against any motion to make it less
> > convenient. Of course, it really shouldn't be (.) but a small circle
> > centred on the line, which isn't on ordinary keyboards. (°) looks
> > closer, but is much less convenient to type. (I need to type
> > "<Compose> 0 ^" in order to get that character.) Spelling it as (.)
> > really is the best easy-to-type approximation.
>
> Yes, yes, yes. I'd rather use a different operator for record selection.
> For instance the colon (:). Yes, I know it is the 'cons' operator for a
> certain concrete data type that implements stacks (so called 'lists').
> However I am generally opposed to wasting good operator and function
> names as well as syntactic sugar of any kind on a /concrete/ data type,
> and especially not for stacks aka lists.

However, the way things are currently, all symbols starting with ':'
are constructors of concrete data types, as that's how infix data
constructors are distinguished. Also, I must point out that lists are
a pretty important structure in lazy functional programming, taking
the place of loops in an imperative language, and their importance
shouldn't be taken so lightly. Given how much they are used, giving
them a little syntax sugar and good looking data constructors doesn't
seem all that far off. On the other hand, I would like to see list
comprehensions generalised to monad comprehensions again.

> For a hypothetical Haskell2 I'd propose to get rid of all special 'list'
> constructs and re-use the good symbols and names for /abstract/
> interfaces to sequences and collections resp. (in case of the colon)
> for record selection.

However, you can't abstract data constructors. If cons was abstracted,
then you couldn't use it in pattern matching, which is problematic.

>
> Just my 2 cent.
>
> Ben
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Records (was Re: [Haskell] Improvements to GHC)

Jan-Willem Maessen
In reply to this post by Ben Franksen-2

On Nov 17, 2005, at 1:52 PM, Benjamin Franksen wrote:

> ...
> Yes, yes, yes. I'd rather use a different operator for record  
> selection.
> For instance the colon (:). Yes, I know it is the 'cons' operator  
> for a
> certain concrete data type that implements stacks (so called 'lists').
> However I am generally opposed to wasting good operator and function
> names as well as syntactic sugar of any kind on a /concrete/ data  
> type,
> and especially not for stacks aka lists.

Would you be happier if it were the "yield" operator for iterators?

Yours lazily,

Jan-Willem Maessen

>
> Just my 2 cent.
>
> Ben
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Records (was Re: [Haskell] Improvements to GHC)

David Menendez
In reply to this post by Dimitry Golubovsky
Chris Kuklewicz writes:

> Would the record system describe at
> http://lambda-the-ultimate.org/node/view/1119
> also be convertable "into System Fw, GHC's existing, strongly-typeed
> intermediate language." ?

Probably. Daan's current implementation uses MLF, which I believe is
system F implemented for ML.

(We're talking about the system in Daan Leijen's paper, "Extensible
Records With Scoped Labels". Good stuff.)
--
David Menendez <[hidden email]> | "In this house, we obey the laws
<http://www.eyrie.org/~zednenem>      |        of thermodynamics!"
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Records (was Re: [Haskell] Improvements to GHC)

Ben Franksen-2
In reply to this post by Jan-Willem Maessen
On Friday 18 November 2005 02:59, you wrote:

> On Nov 17, 2005, at 1:52 PM, Benjamin Franksen wrote:
> > ...
> > Yes, yes, yes. I'd rather use a different operator for record
> > selection.
> > For instance the colon (:). Yes, I know it is the 'cons' operator
> > for a
> > certain concrete data type that implements stacks (so called
> > 'lists'). However I am generally opposed to wasting good operator
> > and function names as well as syntactic sugar of any kind on a
> > /concrete/ data type,
> > and especially not for stacks aka lists.
>
> Would you be happier if it were the "yield" operator for iterators?
>
> Yours lazily,

Ok, ok, I tend to forget that Haskell lists are lazy streams, not just
simple stacks... which makes them indeed a /lot/ more useful than the
corresponding data type in strict languages.

I still think all those nice short and meaningful names in the Prelude
(map, filter, ...) should be type class members in some suitable
standard collection library.

Ben
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Records (was Re: [Haskell] Improvements to GHC)

Keean Schupke
In reply to this post by David Menendez
You can change the project and update operators in the HList library to
behave
in exactly this way. At the moment they are constrained to not allow
multiple
identical labels in records. If this kind of access is considered
useful, I can
add it to the HList distribution.

    Keean.

David Menendez wrote:

>Chris Kuklewicz writes:
>
>  
>
>>Would the record system describe at
>>http://lambda-the-ultimate.org/node/view/1119
>>also be convertable "into System Fw, GHC's existing, strongly-typeed
>>intermediate language." ?
>>    
>>
>
>Probably. Daan's current implementation uses MLF, which I believe is
>system F implemented for ML.
>
>(We're talking about the system in Daan Leijen's paper, "Extensible
>Records With Scoped Labels". Good stuff.)
>  
>

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Records vs HList

David Menendez
Keean Schupke writes:

> David Menendez wrote:
>
> >Chris Kuklewicz writes:
> >
> >>Would the record system describe at
> >>http://lambda-the-ultimate.org/node/view/1119
> >>also be convertable "into System Fw, GHC's existing, strongly-typeed
> >>intermediate language." ?
> >
> >Probably. Daan's current implementation uses MLF, which I believe is
> >system F implemented for ML.
> >
> >(We're talking about the system in Daan Leijen's paper, "Extensible
> >Records With Scoped Labels". Good stuff.)
>
> You can change the project and update operators in the HList library
> to behave in exactly this way. At the moment they are constrained to
> not allow multiple identical labels in records. If this kind of
> access is considered useful, I can add it to the HList distribution.

This is true. I've implemented a small subset of HList that's able to
emulate Daan's three record operators using only fundeps and undecidable
instances.

    *Main> let r = foo .=. "Bar" .*. emptyRecord
    *Main> r
    Record{foo="Bar"}
    *Main> let r2 = foo .=. () .*. r          
    *Main> r2
    Record{foo=(),foo="Bar"}
    *Main> r2 .!. foo
    ()
    *Main> (r2 .-. foo) .!. foo
    "Bar"

(This is actually *more* powerful than the system described in Daan's
paper, because labels are first class.)

While this is a testament to the power of Haskell's extended type-class
system, I'm not sure that it can replace a dedicated record system. In
his paper, Daan describes how to implement the records such that field
lookups take O(log n) or even O(1) time. HList can't do better than
O(n).

Of course, in the absence of a powerful record system, HList is the way
to go. Rather than decide on a new record system sight unseen, let's
implement them using HList and see how they feel.
--
David Menendez <[hidden email]> | "In this house, we obey the laws
<http://www.eyrie.org/~zednenem>      |        of thermodynamics!"
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Records vs HList

Keean Schupke
David Menendez wrote:

>Keean Schupke writes:
>
>  
>
>>David Menendez wrote:
>>
>>    
>>
>>>Chris Kuklewicz writes:
>>>
>>>      
>>>
>>>>Would the record system describe at
>>>>http://lambda-the-ultimate.org/node/view/1119
>>>>also be convertable "into System Fw, GHC's existing, strongly-typeed
>>>>intermediate language." ?
>>>>        
>>>>
>>>Probably. Daan's current implementation uses MLF, which I believe is
>>>system F implemented for ML.
>>>
>>>(We're talking about the system in Daan Leijen's paper, "Extensible
>>>Records With Scoped Labels". Good stuff.)
>>>      
>>>
>>You can change the project and update operators in the HList library
>>to behave in exactly this way. At the moment they are constrained to
>>not allow multiple identical labels in records. If this kind of
>>access is considered useful, I can add it to the HList distribution.
>>    
>>
>
>This is true. I've implemented a small subset of HList that's able to
>emulate Daan's three record operators using only fundeps and undecidable
>instances.
>
>    *Main> let r = foo .=. "Bar" .*. emptyRecord
>    *Main> r
>    Record{foo="Bar"}
>    *Main> let r2 = foo .=. () .*. r          
>    *Main> r2
>    Record{foo=(),foo="Bar"}
>    *Main> r2 .!. foo
>    ()
>    *Main> (r2 .-. foo) .!. foo
>    "Bar"
>
>(This is actually *more* powerful than the system described in Daan's
>paper, because labels are first class.)
>
>While this is a testament to the power of Haskell's extended type-class
>system, I'm not sure that it can replace a dedicated record system. In
>his paper, Daan describes how to implement the records such that field
>lookups take O(log n) or even O(1) time. HList can't do better than
>O(n).
>
>Of course, in the absence of a powerful record system, HList is the way
>to go. Rather than decide on a new record system sight unseen, let's
>implement them using HList and see how they feel.E
>  
>
Exactly! I like the idea of being able to construct and modify the
semantics of a record system
(and with the stuff in the OOHaskell paper you can play with Object
systems in the same way).

The important point with HLists is not that record syntax should not be
added to Haskell, but
that we can translate it to the existing type system with no conflicts.
(ie the type system does not
need to be extended there just needs to be some syntax, with an
optimised implementation)

HList can do O(log n) by the way, if the labels have order, you can
implement a binary search
tree of labels (Of course all the accessor functions would need to be
rewritten).

I wonder if some syntactic support for label creation would make things
nicer.

Actually one really useful change I would like would be to define type
class functions over all tuples,
that way you could write O(1) accessor functions on tuples using peano
number indexes.

class TupleIdx u i t | u i -> t where
    idx :: u -> i -> t
instance (a,b) HNil a where
    (a,_) _ = a
instance (a,b) (HSucc HNil) b where
    (_,b) _ = b
instance (a,b,c) HNil a where
    (a,_,_) = a
instance (a,b,c) (HSucc HNil) b where
    (_,b,_) = b
instance (a,b,c) (HSucc (HSucc HNil)) c where
    (_,_,c) = c

etc...

However I haven't thought very hard about how to represent the complete
(infinite) set
of instances, but using this you can write products of tuples, and
create records with O(1)
access times from a pair of tuples.

    Keean

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Records vs HList

David Menendez
Keean Schupke writes:

> HList can do O(log n) by the way, if the labels have order, you can
> implement a binary search tree of labels (Of course all the accessor
> functions would need to be rewritten).

The idea of writing a type-level balanced binary search tree fills me
with an uncertain mixture of excitement and dread. Particularly if you
want to be able to compare records for equality.
--
David Menendez <[hidden email]> | "In this house, we obey the laws
<http://www.eyrie.org/~zednenem>      |        of thermodynamics!"
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Records vs HList

Keean Schupke
David Menendez wrote:

>Keean Schupke writes:
>
>  
>
>>HList can do O(log n) by the way, if the labels have order, you can
>>implement a binary search tree of labels (Of course all the accessor
>>functions would need to be rewritten).
>>    
>>
>
>The idea of writing a type-level balanced binary search tree fills me
>with an uncertain mixture of excitement and dread. Particularly if you
>want to be able to compare records for equality.
>  
>
Hmm... You have to write and define what you mean by equality
for normal HList records anyway. As you need to ignore the order
of elements the equality test is effectively:

a == b  if  (a `subset` b) and (b `subset` a)

The test for "a subset b" tests if each element in a exists in b.

With an ordered tree, the labels must be in the same order, so
the equality just has to compare elements is a consistant (say pre-order)
way.

In the end HList records were written as they are for clarity in the paper,
and not really as a number-crunching implementation. I find them fast
enough for database work, where the records represent the query (in terms
of projections) and the result table in a type safe way... Infact my
simple DB
library goes quite a way beyond what HaskellDB can do, mainy due to the
complex type-mechanics being hidden inside the HList/record library.

    Keean.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe