`StablePtr` in `ST`

[Matthew Farkas-Dyck]

I have been doing some work where i want `StablePtr`, but also to not
be confined to `IO`. I saw the following comment in
"compiler/prelude/PrimOp.hs":

Question: Why @RealWorld@ - won't any instance of @_ST@ do the job? [ADR]

It has been there for 20 years. What is the answer? If it is safe i'll
send the patch generalizing these operations.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Exposing target language in Haskell with GHC API

[Matthew Farkas-Dyck via Glasgow-haskell-users]

Hi, thanks for the response.

On 26/08/2016, Christiaan Baaij  wrote:
> You mentioned that GHC does name mangling, but I must say I've never
> seen GHC do this.

I guess this was unclear: our compiler is mangling the names from GHC
core, lest any clash with a BlueSpec keyword. We need to find a way to
annotate the Haskell source to tell our compiler to not mangle a name.

> What GHC does do is inlining and specialisation, which might optimise
> away your carefully constructed "primitive".
>
> What I do in this case, is simply mark my "primitive" function, your
> "exposed" BlueSpec functions, as NOINLINE.

Ah, yes, it seems we will need to do this too.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Exposing target language in Haskell with GHC API

[Matthew Farkas-Dyck via Glasgow-haskell-users]

A colleague and i are writing, as an unofficial side project, a
Haskell→Bluespec compiler, using GHC as our Haskell front-end. The
source language of the part we are writing is GHC Core. We need to
somehow expose some Bluespec terms and types to the Haskell source
program. We had a few ideas:
1. Some "NO_MANGLE" pragma which would tell GHC to not mangle the
emitted name, e.g. `x = {-# NO_MANGLE #-} x` to expose `x`
2. `foreign import prim`, not quite sure how yet
3. "CORE" pragmas, e.g. `x = {-# CORE "foo" #-} x` to expose `x`
4. "ANN" pragmas, e.g. `{-# ANN x "no_mangle" #-} x = x` to expose `x`

1 and 2 would mean modifying GHC which we'd rather not do. For 3,
we're not sure how to find the "CORE"-pragmatic annotations in a
`Core` AST. 4 seems it would work but be a little cumbersome, as the
annotation is not on the `Core` AST.

Anyone know a good way to do this?
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Records in Haskell: Explicit Classy Records

[Matthew Farkas-Dyck]

Hello GHC users.

I made another proposal for records in Haskell, meant to solve just
the namespace problem, and no more.
http://hackage.haskell.org/trac/ghc/wiki/Records/ExplicitClassyRecords

In this system, record selectors are overloaded in
explicitly-user-declared type classes. Thus one can control the scope
as of any other type class.

Cheers,
strake

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Records in Haskell: Type-Indexed Records (another proposal)

[Matthew Farkas-Dyck]

On 06/03/2012, AntC  wrote:
> Matthew Farkas-Dyck  gmail.com> writes:
>> > Oh, and how do you deal with multiple record constructors as in H98:
>> >data T a = T1 { x :: a, y :: Bool }
>> > | T2 { x :: a }
>> >
>> Not sure what you mean. With an argument of such a multiconstructed
>> type, I would do as ever in Haskell: pattern-match.
>
> So please show what record declarations look like. And how they get turned
> into Has instances. Your example decl on the wiki for R a b c is not valid
> Haskell.

Yet. That's what this all is about.

> What's more the wiki hss it as a `type`. Did you mean a `data`? I'm
> confused.

Nope. The record type in this case is
{ X ::. a, Y ::. b, Z ::. c, ... }

A value of this type is a record.

>>
>> > You don't give full details for your Has instances, but presumably you'd
>> > do
>> > the same equality constraint style as SORF and DORF.
>>
>> I assume you mean
>> instance (v~a) => Has k v (R a) where ...
>>
>> I'm not sure why we need this, but I assume that we do, since it was
>> written by SPJ, so yes.
>>
>
> Matthew, you really, really need to understand why SPJ put it that way, if you
> want your proposal to be taken seriously. He wasn't just making it up.

Sorry. I am no Haskell wizard, and it wasn't very clear on the wiki.
"Improves" the type of the result...?

>> > You don't show how you'd do record update.
>>
>> Yep. It's on the wiki.
>> "qfmap X f r is r mutated by f at X"
>>
>
> So do you mean this is what developers put in the code?
>
>> > what is the type for:
>> > r{ X = True }
>> > That is: update record r, set its X field to True.
>>
>> This is written as
>> qfmap X (const True) (r :: r) :: Quasifunctor X a Bool r s => s;
>>
>
> You mean this is what to put in the code?

Well, one could, but as I said, we might (rather, ought to) define
some sugar, since it's ugly (>_<)

> DORF is getting beaten up for the amount of boilerplate the programmer is
> expected to add (for fieldLabels, etc.) I can't compare apples with apples
> for
> your proposal, because I can't see what the code looks like that would
> appear
> in the program.
>
> So far (apart from Quasifunctor) all I can see is that you're varying the
> sugar, without adding anything to the semantics -- except you've not given
> the
> surface syntax, so I'm only guessing.

I have given the surface syntax, actually, just with no sugar.

I meant not to add to the semantics. Rather, I meant to simplify them.

Anyhow, since I read DORF a few more times, my proposal seems more
alike than I thought, when I wrote it.

Nevertheless, the magic types bother me, for the aforesaid reasons.

>
> AntC
>

Cheers,
strake

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Records in Haskell: Type-Indexed Records (another proposal)

[Matthew Farkas-Dyck]

On 03/03/2012, AntC  wrote:
> Apart from the Quasifunctor bit, I think you'll find your proposal is a rather
> cut-down version of DORF, just using different syntactic sugar.

> (Oh, and with the arguments to Has in a different order, just to be 
> confusing.)

Not so. I chose this order to make it easier to curry.

> You do have the equivalent of fieldLabel decls. Those are all your type
> indexes: data X = X, etc.

True, but data is not a new keyword.

> And you suggest defining
> x = X

We can define x = X, if we wish, but we need not; we could rather
define x as a selector. It's just that lower-case labels are customary
in Haskell.

> Which is equivalent to DORF mapping from field name `x` to phantom type
> Proxy_x, (but DORF keeps `x` as a field selector function, similar to H98).

Ah, not quite. In DORF, the phantom type is an implicit, magical type,
but in TIR it's an explicit, declared type.

In DORF, either the magical type is in scope, or not; in the former
case, it might clash with a user-defined type, and in the latter, if I
wish to call set, how shall I type its argument?

In TIR, the key type is user-defined, so if there be a clash, then the
user is at fault.

> To make `x` a selector function instead, you'd go:
> x = (.) X   -- or probably x = get X, see below
> Which is exactly the same as DORF (after adjusting for the different order
> of
> arguments).

True.

> And presumably instead of X you'd want a LongandMeaningfulLabel?

No! Real Programmers never choose such names!

I jest. Yes, plainly, I would. X is just an example.

> And if your
> data Customer_id = Customer_id
> was always an Int field, wouldn't it help the reader and the compiler to say
> that? (That's the main extra part in fieldLabels.)

It might help the reader, but so would a simple comment. Nevertheless,
this is fair.

It might help the compiler, but that's an argument by premature
optimization, I think (^_~)

> I think you don't want all those type vars in your record decls -- but only
> vars for the mutatable types, like this:
>
>   type R c = { X ::. Int, Y::. String, Z ::. c, ... }
>
> Then you don't need a Quasifunctor instance for every field, only the
> mutatable ones.

Yes, I know. That is just a very general example.

> Oh, and how do you deal with multiple record constructors as in H98:
>data T a = T1 { x :: a, y :: Bool }
> | T2 { x :: a }
>
> It wouldn't work to have a different record type for each constructor, 'cos
> you'd turn functions that use them from mono to polymorphic (overloaded --
> needing a class and instances).

Not sure what you mean. With an argument of such a multiconstructed
type, I would do as ever in Haskell: pattern-match.

> You don't give full details for your Has instances, but presumably you'd do
> the same equality constraint style as SORF and DORF.

I assume you mean
instance (v~a) => Has k v (R a) where ...

I'm not sure why we need this, but I assume that we do, since it was
written by SPJ, so yes.

> I think you still need method get and sugar to turn the dot notation into a
> call to get. Having method (.) will usurp altogether dot as function
> composition -- you'll make a lot of enemies! And we need tight binding for
> dot
> notation, so we might as well treat it as special syntax.

Not need. (.) is quite a valid name. Nevertheless, this is fair. I
meant dot as an example (though one that might ultimately be chosen).
I like bang, myself; others seem to favour get. The trouble is, in the
latter case, that we'd need to change certain widely-used libraries...

> You don't show how you'd do record update.

Yep. It's on the wiki.
"qfmap X f r is r mutated by f at X"

> The litmus test is what is the
> type
> for:
> r{ X = True }
> That is: update record r, set its X field to True.

This is written as
qfmap X (const True) (r :: r) :: Quasifunctor X a Bool r s => s;

> AntC

Cheers,
strake

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Records in Haskell: Type-Indexed Records (another proposal)

[Matthew Farkas-Dyck]

Hello all.

I wrote a new proposal for the Haskell record system. It can be found
at http://hackage.haskell.org/trac/ghc/wiki/Records/TypeIndexedRecords

Records are indexed by arbitrary Haskell types. Scope is controlled as
scope of key types. No fieldLabel declarations needed (as in DORF).

Cheers,
strake

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Holes in GHC

[Matthew Farkas-Dyck]

On 26/01/2012, Thijs Alkemade  wrote:
> Let me try to describe the goal better. The intended users are people
> new to Haskell or people working with existing code they are not
> familiar with. When starting with Haskell, at least in my experience,
> it happens lot that you have an idea about what you need to write, but
> there are some parts in the expression you're working on you don't
> know yet.
>
> This is where you would want to use a hole. Just like undefined, it
> has type `a`, so it can be used anywhere (and when compiling, we
> intend to turn it into an exception too), but the difference with
> undefined is that after the typechecking has succeeded, you get a list
> of your holes, with the type that was inferred for them, as a sort of
> todo-list.
>

Megawin. Many times, lost in a tangle of code, this was just what I
needed, and, alas, just what I lacked.

>
> Regards,
> Thijs Alkemade

Also, I think it would be nice to have a mode in which GHC would just
print the type of each hole in a module. Otherwise, one might have to
load each needed module in GHCi, which could be awkward, especially if
the holed term is in definition of others.

Cheers,
MFD

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Type operators in GHC

[Matthew Farkas-Dyck]

On 19/01/2012, Ian Lynagh  wrote:
> Do you mean that in
>
> f :: (x, X, (+), (:+))
>
> only x would be a type variable and X, (+), (:+) would be type
> constructors, but that in
>
> g :: forall y, Y, (*), (:*) .
>  (x, X, (+), (:+), y, Y, (*), (:*))
>
> y, Y, (*), (:*) would be type variables and x, X, (+), (:+) would be
> whatever is in scope (constructors, unless there is an enclosing forall
> that binds them)?

Just so.

> Perhaps we should be heading towards a case-insensitive syntax for type
> names.

I've often had that thought myself, for types and terms both. It would
make it much nicer to do general numeric computations in Haskell (e.g.
fluid mechanics) since one could use upper-case term names, which are
often customary. I actually designed a compiled-to-Haskell language
for just this reason (for fluid mechanics lab), but it's very crude.

That said, for word-names, the case-sensitive system we have is nice and brief.

>
> Thanks
> Ian
>

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Type operators in GHC

[Matthew Farkas-Dyck]

On 19/01/2012, Joachim Breitner  wrote:
> (I have no good idea, but here is at least one: A dot '.' as the first
> character indicates a type variable; compared to a ':' this is a
> non-capitalized character).

So that all symbols that start in dot are variables, and all others
are types/constructors?

> Also, is there maybe another way of distinguishing constructors and
> variables, besides capitalization, that works equally well for operators
> and non-operators? That could also help if a user would like to use
> unicode characters in the name of a constructor that are letters but
> don’t have a upper or titlecase variant. But then, this has probably
> been given thought a long time ago, without a better solution than
> capitalization resp. leading ':'.

Sometimes I thought to use "∀" to quantify over type variables, as
over term variables, at least as an option.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Posting etiquette, was Re: Records in Haskell

[Matthew Farkas-Dyck]

On 19/01/2012, Malcolm Wallace  wrote:
> I find it completely unreasonable for a reply to a very long post to quote
> the entire text, only to add a single line at the bottom (or worse, embedded
> in the middle somewhere).  In this case, there are 7 pages of quotation
> before your one-sentence contribution.  (That is on my laptop.  I dread to
> think how many pages it represents on a smartphone screen...)  Usually, if I
> need to scroll even to the second page-worth of quotation and have still not
> found any new text, I now just delete the post without reading it.
>
> Regards,
> Malcolm
>

Sorry.

The reason that I have done so is that my primary mail client (GMail
web) automatically folds quoted text (marked by ">" at start of line).
(I'm not sure whether my secondary client (mutt) can do so.)

When I first saw this message, I thought I would be slammed for
top-posts (I have been guilty a few times).

Anyhow, I shall keep this in mind.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Records in Haskell

[Matthew Farkas-Dyck]

On 18/01/2012, Simon Peyton-Jones  wrote:
> | > Has *is* a type class. It can be used and abused like any other.
> | > Record members with the same key ought to have the same semantics; the
> | > programmer must ensure this, not just call them all "x" or the like.
> | >
> | > Weak types these are not. The selector type is well-defined. The value
> | > type is well-defined. The record type is well-defined, but of course
> | > we define a type-class to let it be polymorphic.
>
> I want to mention that the issue Greg raises here is tackled under
> "Representation hiding".
>
> The way we currently prevent random clients of a data type from selecting
> its "foo" field is by hiding the record selector "foo". Similarly for its
> data constructors. This is Haskell's way of doing data abstraction; it may
> not be the best way, but it's Haskell's way.
>
> The trouble with instance declarations is that they are *always* exported.
> No hiding.

Yes. This is a fault.

I found a document, "Controlling the scope of instances in Haskell",
by Gontijo and Camarão, whose goal is to solve this very problem.

http://www.dcc.ufmg.br/~camarao/controlling-the-scope-of-instances-in-Haskell-sblp2011.pdf

The link seems broken, but if so, and anyone should want a copy, feel
free to tell me and I shall send it. The size is 244 KB.

> Under "Representation hiding" I suggest that
>
> * If the record selector "foo" is in scope (by any name),
>   then the corresponding Has instance is in scope too
>   and vice versa.
>
> That would match up with Haskell's hiding mechanisms precisely, albeit at
> the cost of having an ad-hoc rule for "Has" instances.
>
> Simon
>
>

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Records in Haskell

[Matthew Farkas-Dyck]

On 18/01/2012, Gábor Lehel  wrote:
> (I *am*, however, uncomfortable with using straight-up type level
> strings, without consideration for any particular alternative. If
> nothing else they should at least be opaque symbols which can be
> passed around and used in the supported contexts but not manipulated
> as strings. String-based hackery should be left to Template Haskell,
> and out of the type system. I can't really express at the moment why
> in particular I think it would be bad, but it feels like it would be
> bad.)
>

I strongly agree; plus, it's awkward (and ugly) that a selector be
desugarred to a type-level string of its key identifier, as if it were
some perverse quasiliteral.

The trouble is, if they were opaque, then how could a function be
polymorphic over all records with a certain member, with defined
semantics? How could one tell the compiler that the semantics of all
such members are the same? One must define a name, and then the
problem of namespace non-interoperability that is now a great bother
would be a greater bother yet.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Records in Haskell

[Matthew Farkas-Dyck]

On 18/01/2012, Greg Weber  wrote:
> On Fri, Jan 13, 2012 at 8:52 PM, Simon Peyton-Jones
> wrote:
>
>>
>> But, the Has constraints MUST exist, in full glory, in the constraint
>> solver.  The only question is whether you can *abstract* over them.
>> Imagine having a Num class that you could not abstract over. So you
>> could write
>>
>>   k1 x = x + x :: Float
>>   k2 x = x + x :: Integer
>>   k3 x = x + x :: Int
>>
>> using the same '+' every time, which generates a Num constraint. The
>> type signature fixes the type to Float, Integer, Int respectively, and
>> tells you which '+' to use.  And that is exactly what ML does!
>>
>> But Haskell doesn't.  The Coolest Thing about Haskell is that you get
>> to *abstract* over those Num constraints, so you can write
>>
>>  k :: Num a => a -> a
>>  k x = x + x
>>
>> and now it works over *any* Num type.
>>
>> On reflection, it would be absurd not to do ths same thing for Has
>> constraints.  If we are forced to have Has constraints internally, it
>> woudl be criminal not to abstract over them.  And that is precisely
>> what SORF is.
>>
>
> So I understand that internally a Has constraint is great for resolving the
> type.
> What is the use case for having the Has abstraction externally exposed?
>
> I think there is a great temptation for this because we would have a
> functionality we can point to that has some kind of extensible record
> capability.
>
> But I believe the Has abstraction to be a form of weak-typing more so than
> a form of extensibility. Just because 2 records have a field with the same
> name, even with the same type in no way signifies they are related. Instead
> we need a formal contract for such a relation. We already have that in type
> classes, and they can already be used for this very capability in a more
> type-safe way.
>
> My point is that Has abstractions are weak types and that likely we should
> be searching for something stronger or using type classes. If I am wrong
> then we should have convincing use cases outlined before we make this a
> goal of a records implementation, and still I don't see why it needs to be
> a blocking requirement if we are just trying to solve the basic records
> issue.
>
>
> Greg Weber
>

Has *is* a type class. It can be used and abused like any other.
Record members with the same key ought to have the same semantics; the
programmer must ensure this, not just call them all "x" or the like.

Weak types these are not. The selector type is well-defined. The value
type is well-defined. The record type is well-defined, but of course
we define a type-class to let it be polymorphic.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Records in Haskell

[Matthew Farkas-Dyck]

On 13/01/2012, Simon Peyton-Jones  wrote:
> Thanks to Greg for leading the records debate.  I apologise that I
> don't have enough bandwidth to make more than an occasional
> contribution.  Greg's new wiki page, and the discussion so far has
> clarified my thinking, and this message tries to express that new
> clarity.  I put a conclusion at the end.
>
> Simon
>
> Overview
> 
> It has become clear that there are two elements to pretty much all the
> proposals we have on the table.  Suppose we have two types, 'S' and 'T',
> both with a field 'f', and you want to select field 'f' from a record 'r'.
> Somehow you have to disambiguate which 'f' you mean.
>
> (Plan A) Disambiguate using qualified names.  To select field f, say
> (S.f r) or (T.f r) respectively.
>
> (Plan B) Disambiguate using types. This approach usually implies
> dot-notation.
>  If  (r::S), then (r.f) uses the 'f' from 'S', and similarly if
> (r::T).
>
> Note that
>
> * The Frege-derived records proposal (FDR), uses both (A) and (B)
>   http://hackage.haskell.org/trac/ghc/wiki/Records/NameSpacing
>
> * The Simple Overloaded Record Fields (SORF) proposal uses only (B)
>   http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields
>
> * The Type Directed Name Resolution proposal (TDNR) uses only (B)
>
> http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolution
>
> I know of no proposal that advocates only (A).  It seems that we are agreed
> that we must make use of types to disambigute common cases.
>
> Complexities of (Plan B)
> 
> Proposal (Plan B) sounds innocent enough.  But I promise you, it isn't.
> There has ben some mention of the "left-to-right" bias of Frege type
> inference engine; indeed the wohle explanation of which programs are
> accepted and which are rejected, inherently involves an understanding
> of the type inference algorithm.  This is a Very Bad Thing when the
> type inference algorithm gets complicated, and GHC's is certainly
> complicated.
>
> Here's an example:
>
>type family F a b
>data instance F Int [a] = Mk { f :: Int }
>
>g :: F Int b  -> ()
>h :: F a [Bool] -> ()
>
>k x = (g x, x.f, h x)
>
> Consider type inference on k.  Initially we know nothing about the
> type of x.
>  * From the application (g x) we learn that x's type has
>shape (F Int ).
>  * From the application (h x) we learn that x's type has
>shape (F  [Bool])
>  * Hence x's type must be (F Int [Bool])
>  * And hence, using the data family we can see which field
>f is intended.
>
> Notice that
>  a) Neither left to right nor right to left would suffice
>  b) There is significant interaction with type/data families
> (and I can give you more examples with classes and GADTs)
>  c) In passing we note that it is totally unclear how (Plan A)
> would deal with data families
>
> This looks like a swamp.  In a simple Hindley-Milner typed language
> you might get away with some informal heuristics, but Haskell is far
> too complicated.
>
> Fortunately we know exactly what to do; it is described in some detail
> in our paper "Modular type inference with local assumptions"
> http://www.haskell.org/haskellwiki/Simonpj/Talk:OutsideIn
>
> The trick is to *defer* all these decisions by generating *type constraints*
> and solving them later.  We express it like this:
>
>G, r:t1  |-  r.f : t2,  (Has t1 "f" t2)
>
> This says that if r is in scope with type t1, then (r.f) has type t2,
> plus the constraint (Has t1 "f" t2), which we read as saying
>
>Type t1 must have a field "f" of type t2
>
> We gather up all the constraints and solve them.  In solving them
> we may figure out t1 from some *other* constraint (to the left or
> right, it's immaterial. That allow us to solve *this* constraint.
>
> So it's all quite simple, uniform, and beautiful.  It'll fit right
> into GHC's type-constraint solver.
>
> But note what has happened: we have simply re-invented SORF.  So the
> conclusion is this:
>
>the only sensible way to implement FDR is using SORF.
>
> What about overloading?
> ~~~
> A feature of SORF is that you can write functions like this
>
>k :: Has r "f" Int => r -> Int
>k r = r.f + 1
>
> Function 'k' works on any record that has a field 'f'.  This may be
> cool, but it wasn't part of our original goal.  And indeed neither FDR
> nor TDNR offer it.
>
> But, the Has constraints MUST exist, in full glory, in the constraint
> solver.  The only question is whether you can *abstract* over them.
> Imagine having a Num class that you could not abstract over. So you
> could write
>
>k1 x = x + x :: Float
>k2 x = x + x :: Integer
>k3 x = x + x :: Int
>
> using the same '+' every time, which generates a Num constraint. The
> type signature fixes the type to Float, Integer, Int respectively, and
> tells you which '+' to use.  And that is exactly what ML does!
>
> But Haskell doesn't.  The Coolest Thing about H

Re: Records in Haskell

[Matthew Farkas-Dyck]

On 15/01/2012, Ian Lynagh  wrote:
> On Sun, Jan 15, 2012 at 01:38:20PM +0100, Greg Weber wrote:
>> >
>> > The blocking issues are described on
>> >  http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields
>> >
>> >  a) "Representation hiding" (look for that heading)
>
> How about
>
> http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields#ScopecontrolbygeneralisingtheStringtypeinHas
>
> for resolving this?
>

(I also posted a like comment to the wiki.)

In my opinion, this is ugly, since the selector can be either a type
name or a label and the semantics are nonsame.

>From section "Representation hiding":
"it would require a new implementation mechanism [sic] to record
exactly which instances were exported from a module"
Win.

>
> Thanks
> Ian
>
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>

Cheers,
MFD

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Composition operator [was: Re: Records in Haskell]

[Matthew Farkas-Dyck]

Actually, we don't need symbols at all, nor all these damned letters.
The set of valid characters in an identifier can be of size 2: one
each upper- and lower-case, e.g. [Pp].

For example, to define const function:

p :: P (p (P pp p));
p pp _ = pp;

where P is function type.

If we drop all the symbols, and all numerals but [01], we could have a
6-bit character set!

On 12/01/2012, Donn Cave  wrote:
>> Quoth Brandon Allbery ,
> ...
>> Seems obvious to me:  on the one hand, there should be a plain-ASCII
>> version of any Unicode symbol; on the other, the ASCII version has
>> shortcomings the Unicode one doesn't (namely the existing conflict between
>> use as composition and use as module and now record qualifier).  So, the
>> Unicode one requires support but avoids weird parse issues.
>
> OK.  To me, the first hand is all you need - if there should be a
> plain-ASCII version of any Unicode symbol anyway, then you can avoid
> some trouble by just recognizing that you don't need Unicode symbols
> (let alone with different parsing rules.)
>
>   Donn
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Composition operator [was: Re: Records in Haskell]

[Matthew Farkas-Dyck]

On 13/01/2012, Herbert Valerio Riedel  wrote:
> On Fri, 2012-01-13 at 15:16 +1100, Morten Brodersen wrote:
>> Unfortunately most unix/windows/tools/source controls/editors out
>> there are Ascii only.
>
> So after about 20 years the unicode standard has been around, the
> quantification "most" still applies? Maybe I'm using a
> non-representative platform, but every tool for manipulating source-code
> I use nowadays has support for the unicode charset w/ with at least the
> utf8 encoding...

This is my experience also.

> -- hvr
>
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Composition operator [was: Re: Records in Haskell]

[Matthew Farkas-Dyck]

On 12/01/2012, Morten Brodersen  wrote:
> Even if Unicode is not required, there is still a fallout. Let's look at
> a simple scenario:
>
> Somebody uploads a nice useful Haskell module that include a number of
> Unicode symbols.
>
> Unfortunately most unix/windows/tools/source controls/editors out there
> are Ascii only.

If so, most unix/windows/tools/source controls/editors out there are broken.

> So people who wants to use the module now potentially need to convert
> the code to Ascii (and potentially back again) in order to use it with
> non-Unicode tools.

No, people need to get Unicode (or, better yet, when possible,
code-agnostic) tools.

> Yes it is *of course* doable but all of that just because of a
> *relatively" simple problem to do with how you access record fields? Really?
>
> That is IMHO a clear example of shooting birds with nuclear rockets.
>
> Let me suggest that a simple non-nuclear alternative would be for people
> interested in Unicode symbols to use an editor that auto converts from
> Haskell Ascii to Haskell Unicode when loading and (of course) back again
> when saving. You can do that today. You can even pick your own Ascii
> from/to Unicode mapping. No need to argue about whether a symbol is
> prettier than another. All of this without forcing the rest of the
> (couldn't care less about record access syntax) Haskell community to
> have to deal with Unicode :-)

That is (in my opinion) a clear example of shooting foes in heavy
armour with bird-shot. From a muzzle-loader.

> Morten
>
> On 13/01/12 14:43, Brandon Allbery wrote:
>> On Thu, Jan 12, 2012 at 22:32, Morten Brodersen
>> > > wrote:
>>
>> Requiring unicode characters for the Haskell syntax to solve a
>> *relatively* simple problem is a bad bad idea.
>>
>>
>> Nobody said anything about requiring it.
>>
>> --
>> brandon s allbery allber...@gmail.com 
>> wandering unix systems administrator (available) (412) 475-9364 vm/sms
>>
>
>

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Records in Haskell

[Matthew Farkas-Dyck]

On 13/01/2012, Simon Peyton-Jones  wrote:
> Thanks to Greg for leading the records debate.  I apologise that I
> don't have enough bandwidth to make more than an occasional
> contribution.  Greg's new wiki page, and the discussion so far has
> clarified my thinking, and this message tries to express that new
> clarity.  I put a conclusion at the end.
>
> Simon
>
> Overview
> 
> It has become clear that there are two elements to pretty much all the
> proposals we have on the table.  Suppose we have two types, 'S' and 'T',
> both with a field 'f', and you want to select field 'f' from a record 'r'.
> Somehow you have to disambiguate which 'f' you mean.
>
> (Plan A) Disambiguate using qualified names.  To select field f, say
> (S.f r) or (T.f r) respectively.
>
> (Plan B) Disambiguate using types. This approach usually implies
> dot-notation.
>  If  (r::S), then (r.f) uses the 'f' from 'S', and similarly if
> (r::T).
>
> Note that
>
> * The Frege-derived records proposal (FDR), uses both (A) and (B)
>   http://hackage.haskell.org/trac/ghc/wiki/Records/NameSpacing
>
> * The Simple Overloaded Record Fields (SORF) proposal uses only (B)
>   http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields
>
> * The Type Directed Name Resolution proposal (TDNR) uses only (B)
>
> http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolution
>
> I know of no proposal that advocates only (A).  It seems that we are agreed
> that we must make use of types to disambigute common cases.
>
> Complexities of (Plan B)
> 
> Proposal (Plan B) sounds innocent enough.  But I promise you, it isn't.
> There has ben some mention of the "left-to-right" bias of Frege type
> inference engine; indeed the wohle explanation of which programs are
> accepted and which are rejected, inherently involves an understanding
> of the type inference algorithm.  This is a Very Bad Thing when the
> type inference algorithm gets complicated, and GHC's is certainly
> complicated.
>
> Here's an example:
>
>type family F a b
>data instance F Int [a] = Mk { f :: Int }
>
>g :: F Int b  -> ()
>h :: F a [Bool] -> ()
>
>k x = (g x, x.f, h x)
>
> Consider type inference on k.  Initially we know nothing about the
> type of x.
>  * From the application (g x) we learn that x's type has
>shape (F Int ).
>  * From the application (h x) we learn that x's type has
>shape (F  [Bool])
>  * Hence x's type must be (F Int [Bool])
>  * And hence, using the data family we can see which field
>f is intended.
>
> Notice that
>  a) Neither left to right nor right to left would suffice
>  b) There is significant interaction with type/data families
> (and I can give you more examples with classes and GADTs)
>  c) In passing we note that it is totally unclear how (Plan A)
> would deal with data families
>
> This looks like a swamp.  In a simple Hindley-Milner typed language
> you might get away with some informal heuristics, but Haskell is far
> too complicated.
>
> Fortunately we know exactly what to do; it is described in some detail
> in our paper "Modular type inference with local assumptions"
> http://www.haskell.org/haskellwiki/Simonpj/Talk:OutsideIn
>
> The trick is to *defer* all these decisions by generating *type constraints*
> and solving them later.  We express it like this:
>
>G, r:t1  |-  r.f : t2,  (Has t1 "f" t2)
>
> This says that if r is in scope with type t1, then (r.f) has type t2,
> plus the constraint (Has t1 "f" t2), which we read as saying
>
>Type t1 must have a field "f" of type t2
>
> We gather up all the constraints and solve them.  In solving them
> we may figure out t1 from some *other* constraint (to the left or
> right, it's immaterial. That allow us to solve *this* constraint.
>
> So it's all quite simple, uniform, and beautiful.  It'll fit right
> into GHC's type-constraint solver.
>
> But note what has happened: we have simply re-invented SORF.  So the
> conclusion is this:
>
>the only sensible way to implement FDR is using SORF.
>
> What about overloading?
> ~~~
> A feature of SORF is that you can write functions like this
>
>k :: Has r "f" Int => r -> Int
>k r = r.f + 1
>
> Function 'k' works on any record that has a field 'f'.  This may be
> cool, but it wasn't part of our original goal.  And indeed neither FDR
> nor TDNR offer it.
>
> But, the Has constraints MUST exist, in full glory, in the constraint
> solver.  The only question is whether you can *abstract* over them.
> Imagine having a Num class that you could not abstract over. So you
> could write
>
>k1 x = x + x :: Float
>k2 x = x + x :: Integer
>k3 x = x + x :: Int
>
> using the same '+' every time, which generates a Num constraint. The
> type signature fixes the type to Float, Integer, Int respectively, and
> tells you which '+' to use.  And that is exactly what ML does!
>
> But Haskell doesn't.  The Coolest Thing about H

Re: Records in Haskell

[Matthew Farkas-Dyck]

On 12/01/2012, Greg Weber  wrote:
> I added this and your Control.Category.<<< to the wiki.

Thanks.

> I am not sure about the tuple proposal - tuples normally imply an ordering,
> which would imply that all record fields must be accounted for at least
> with an empty comma or an underscore, particularly if updating the last
> field in a record. For records we want a syntax where we can pick out one
> or many fields to update and ignore the rest.

Sorry, my proposal was unclear. This is not what I meant; rather, I
meant that one could write
let r.(x, y) = (x', y')
whatever other fields might be in r. I clarify further on the wiki.

That said, I notice now that this syntax is quite verbose, far more so
than the .{} syntax, which is a loss. I think the brevity worth the
added complexity.

> My feeling on <<< is that <~ is slightly more intuitive than <<< because it
> looks like an arrow which I equate with functions, and <<< is more
> difficult to parse because I have to recognize three in a row of the same
> character . However, if everyone likes using the unicode dot, then it
> doesn't matter what the non-unicode symbol is, and re-using existing
> symbols is certainly advantageous.
>
>
>
> On Thu, Jan 12, 2012 at 10:02 AM, Matthew Farkas-Dyck
> wrote:
>
>> On 09/01/2012, Isaac Dupree  wrote:
>> > You mean this wiki page, right?:
>> > http://hackage.haskell.org/trac/ghc/wiki/Records/NameSpacing
>> >
>> >> That is, there are no fundamental
>> >> objections to the implementation of this records implementation.
>> >
>> > I think that might be overly optimistic... I think there's a risk that
>> > SPJ finds an irritating complication to type inference & the rest of us
>> > aren't type-system-savvy enough to continue trying to guess at that :)
>> > But I think you're referring to whether we object to ad-hoc overloading
>> > of record field names (neither parametric nor class-based polymorphism),
>> > if no difficulties crop up.  Some of the concerns on
>> > http://www.haskell.org/haskellwiki/TypeDirectedNameResolution apply --
>> > I'm not sure to what extent, but address those concerns rather than
>> > require those people to repeat themselves again! :)
>> >
>> > (If we dodge all those obstacles, well, a better record system is
>> better!)
>> >
>> >
>> > Regardless, I think the proposal needs more precision, so I tried for
>> > syntax.  And got this thousand word email just about syntax, in several
>> > sections of reasoning, sorry!
>> >
>> > --so here are my conclusions/suggestions up front in case you prefer,
>> > most complicated first - look later for details in a different order,
>> > referenced by [number].
>> >
>> >
>> > Given that type inference for expr.field decides between several
>> > different possible meanings of "field", which "field"s in scope count as
>> > possibilities?  I concluded "All identifiers 'field' in top-level scope
>> > (i.e. declared in this module or imported unqualified from another
>> > module), but no local let/lambda bindings." [1]
>> >
>> > I have an unrelated record/module system tweak suggestion to prevent
>> > leaks of the field-ness of exports meant only as functions. [2]
>> >
>> > ".field", for any identifier "field", is a postfix operator that binds
>> > more tightly than function application. [1]
>> >
>> > I don't care whether the expression and ".field" are permitted to be
>> > separated by whitespace or not. [4]
>> >
>> > "(.field)" as a section: should it always require parentheses? (assuming
>> > there is a way to type-inference the unapplied dot operator usefully at
>> > all). [3]
>> >
>> > The Type.{...} / expr.{...} variations look probably fine ("Syntax for
>> > updates" in the wiki). [5]
>> >
>> > Allow "TyCon.field" for selecting a specific version of "field", but
>> > only if there isn't a module in scope as "TyCon" in which case it's
>> > interpreted as "Module.field". [7]
>> >
>> > Allow "expr.TyCon.field" / "expr.Module.field" wherever "expr.field" is
>> > allowed. [8]
>> >
>> > I bikesheddily suggest "field@expr" rather than "expr.field" (I'd be
>> > alright with either/both). [6]
>>

Re: Records in Haskell

[Matthew Farkas-Dyck]

On 09/01/2012, Isaac Dupree  wrote:
> You mean this wiki page, right?:
> http://hackage.haskell.org/trac/ghc/wiki/Records/NameSpacing
>
>> That is, there are no fundamental
>> objections to the implementation of this records implementation.
>
> I think that might be overly optimistic... I think there's a risk that
> SPJ finds an irritating complication to type inference & the rest of us
> aren't type-system-savvy enough to continue trying to guess at that :)
> But I think you're referring to whether we object to ad-hoc overloading
> of record field names (neither parametric nor class-based polymorphism),
> if no difficulties crop up.  Some of the concerns on
> http://www.haskell.org/haskellwiki/TypeDirectedNameResolution apply --
> I'm not sure to what extent, but address those concerns rather than
> require those people to repeat themselves again! :)
>
> (If we dodge all those obstacles, well, a better record system is better!)
>
>
> Regardless, I think the proposal needs more precision, so I tried for
> syntax.  And got this thousand word email just about syntax, in several
> sections of reasoning, sorry!
>
> --so here are my conclusions/suggestions up front in case you prefer,
> most complicated first - look later for details in a different order,
> referenced by [number].
>
>
> Given that type inference for expr.field decides between several
> different possible meanings of "field", which "field"s in scope count as
> possibilities?  I concluded "All identifiers 'field' in top-level scope
> (i.e. declared in this module or imported unqualified from another
> module), but no local let/lambda bindings." [1]
>
> I have an unrelated record/module system tweak suggestion to prevent
> leaks of the field-ness of exports meant only as functions. [2]
>
> ".field", for any identifier "field", is a postfix operator that binds
> more tightly than function application. [1]
>
> I don't care whether the expression and ".field" are permitted to be
> separated by whitespace or not. [4]
>
> "(.field)" as a section: should it always require parentheses? (assuming
> there is a way to type-inference the unapplied dot operator usefully at
> all). [3]
>
> The Type.{...} / expr.{...} variations look probably fine ("Syntax for
> updates" in the wiki). [5]
>
> Allow "TyCon.field" for selecting a specific version of "field", but
> only if there isn't a module in scope as "TyCon" in which case it's
> interpreted as "Module.field". [7]
>
> Allow "expr.TyCon.field" / "expr.Module.field" wherever "expr.field" is
> allowed. [8]
>
> I bikesheddily suggest "field@expr" rather than "expr.field" (I'd be
> alright with either/both). [6]
>
>
>
>
> = Defining the basic dot syntax for record field selection =
>
> [1]
> .x, for any identifier x, is a postfix operator that binds more tightly
> than function application.  This operator does not constrain the type of
> its operand or its result.  After regular type inference, the type
> system collects in-scope "x"s and does something to try to choose one.
>
> (As a non-type-system-expert, I'm not addressing what "does something"
> means in this email, besides capitalizing TYPE INFERENCE where I suspect
> there might (or might not) be extra problems.  Anyway, I wish the
> algorithm do the right thing for "expr.x.y.z".)
>
>
> But which in-scope "x"es does it collect?  Regular Haskell scope would
> completely break "let x = var.x" if we wished to allow "let x = var.x".
>
> How about: all record fields 'x' declared in this module or imported
> (qualified[??] or unqualified) from another module.
>
> [[[
> Should qualified ones be allowed?
> Pro: if you import Data.Map qualified, as is common (let's just pretend
> that Maps have members), then someMap.field works.
>
> Pro: it's like allowing qualified imports for instance declaration
> class-member-definitions.
>
> Con: it's not really like that. It makes qualified imports a weaker
> protection, as the class/instance exception can lead to no ambiguity,
> but this can lead to ambiguity.  The PVP would make a sad face.
>
> Con: using unqualified import with (..) would easily bring the field
> names into scope.  Fictitiously, "import qualified Data.Map as Map;
> import Data.Map(Map(..))".
>
> Observation: allowing qualified imports, but not following the
> class/instance system's style of including everything in the transitive
> closure of imported modules, still prevents you (Pro) from breaking
> intentional abstraction barriers, but (Con?) requires you to import the
> operators for types you receive but don't import.
>
> Opinion: only unqualified imports should be part of the selection process.
> ]]]
>
> [[[
> Problem: Restricting the selection to only record fields further
> compromises an existing imperfect property of Haskell:
> module Library (Type, constructor, deconstructor) where
> data Type = Constructor { deconstructor :: Int }
> -- let's pretend it's a bounds-limited int or such.
> constructor int | int >= 3 && int < 17 = Constructor 

Re: Records in Haskell

[Matthew Farkas-Dyck]

On 09/01/2012, Greg Weber  wrote:
> Thank you for all your feedback! I updated the wiki page accordingly.
>
> Let us stop and take note of what this feedback is about: the most
> convenient syntax for manipulating records, and much of this feedback
> applies to any records proposal. That is, there are no fundamental
> objections to the implementation of this records implementation. If you
> give this kind of general feedback then I assume you are fine with the
> name-spacing records implementation.
>
> At this point I feel we are largely waiting on feedback from implementers
> to give the implementation critiques or a green light.
>
> But that does not need to stop us from continuing our discussion of the
> best syntax for using records.
> For the left-right, right-left issue, I added a discussion and potential
> solution through partial application:
>
> Partial application provides a potential solution:
>
>(b . .a) r
>
> So if we have a function f r = b r.a then one can write it points-free:
>
>b . .a
>
> Our longer example from above:
>
>e . d . .c . .b . .a
>
> At first glance it may look odd, but it is starting to grow on me. Let us
> consider more realistic usage with longer names:
>
>echo . delta . .charlie . .beta . .alpha
>
> Is there are more convenient syntax for this? b <.a
> Note that a move to a different operator for function composition
> (discussed in dot operator section) would make things easier to parse:
>
>b <~ .a
>
> where the unicode dot might be even nicer.

I told you so (^_^)

Unicode dot (∘) would be optimal, since that's what it's for. If to
type '∘' is awkward, then one can use (Control.Category.<<<). We need
not (and, in my opinion, should not) define another operator.

> On Mon, Jan 9, 2012 at 3:15 AM, wren ng thornton  wrote:
>
>> quux (y . (foo>.<  bar).baz (f . g)) moo
>> It's not that easy to distinguish from
>> quux (y . (foo>.<  bar) . baz (f . g)) moo
>>
>

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Records in Haskell

[Matthew Farkas-Dyck]

On 08/01/2012, Gábor Lehel  wrote:
> 2012/1/8 Greg Weber :
>>
>>
>> 2012/1/8 Gábor Lehel 
>>>
>>> Thank you. I have a few questions/comments.
>>>
>>>
>>>
>>> "The module/record ambiguity is dealt with in Frege by preferring
>>> modules and requiring a module prefix for the record if there is
>>> ambiguity."
>>>
>>> I think I see why they do it this way (otherwise you can't refer to a
>>> module if a record by the same name is in scope), but on the other
>>> hand it would seem intuitive to me to choose the more specific thing,
>>> and a record feels more specific than a module. Maybe you could go
>>> that way and just not give your qualified imports the same name as a
>>> record? (Unqualified imports are in practice going to be hierarchical,
>>> and no one's in the habit of typing those out to disambiguate things,
>>> so I don't think it really matters if qualified records shadow them.)
>>
>>
>> In the case where a Record has the same name as its containing module it
>> would be more specific than a module, and preferring it makes sense. I
>> think
>> doing this inside the module makes sense, as one shouldn't need to refer
>> to
>> the containing module's name. We should think more about the case where
>> module & records are imported.
>>
>>>
>>>
>>> "Expressions of the form x.n: first infer the type of x. If this is
>>> just an unbound type variable (i.e. the type is unknown yet), then
>>> check if n is an overloaded name (i.e. a class operation). [...] Under
>>> no circumstances, however, will the notation x.n contribute in any way
>>> in inferring the type of x, except for the case when n is a class
>>> operation, where an appropriate class constraint is generated."
>>>
>>> Is this just a simple translation from x.n to n x? What's the
>>> rationale for allowing the x.n syntax for, in addition to record
>>> fields, class methods specifically, but no other functions?
>>
>>
>> It is a simple translation from x.n to T.n x
>> The key point being the function is only accessible through the record's
>> namespace.
>> The dot is only being used to tap into a namespace, and is not available
>> for
>> general function application.
>
> I think my question and your answer are walking past each other here.
> Let me rephrase. The wiki page implies that in addition to using the
> dot to tap into a namespace, you can also use it for general function
> application in the specific case where the function is a class method
> ("appropriate class constraint is generated" etc etc). I don't
> understand why. Or am I misunderstanding?
>
>
>>
>>>
>>>
>>>
>>> Later on you write that the names of record fields are only accessible
>>> from the record's namespace and via record syntax, but not from the
>>> global scope. For Haskell I think it would make sense to reverse this
>>> decision. On the one hand, it would keep backwards compatibility; on
>>> the other hand, Haskell code is already written to avoid name clashes
>>> between record fields, so it wouldn't introduce new problems. Large
>>> gain, little pain. You could use the global-namespace function as you
>>> do now, at the risk of ambiguity, or you could use the new record
>>> syntax and avoid it. (If you were to also allow x.n syntax for
>>> arbitrary functions, this could lead to ambiguity again... you could
>>> solve it by preferring a record field belonging to the inferred type
>>> over a function if both are available, but (at least in my current
>>> state of ignorance) I would prefer to just not allow x.n for anything
>>> other than record fields.)
>>
>>
>> Perhaps you can give some example code for what you have in mind - we do
>> need to figure out the preferred technique for interacting with old-style
>> records. Keep in mind that for new records the entire point is that they
>> must be name-spaced. A module could certainly export top-level functions
>> equivalent to how records work now (we could have a helper that generates
>> those functions).
>
> Let's say you have a record.
>
> data Record = Record { field :: String }
>
> In existing Haskell, you refer to the accessor function as 'field' and
> to the contents of the field as 'field r', where 'r' is a value of
> type Record. With your proposal, you refer to the accessor function as
> 'Record.field' and to the contents of the field as either
> 'Record.field r' or 'r.field'. The point is that I see no conflict or
> drawback in allowing all of these at the same time. Writing 'field' or
> 'field r' would work exactly as it already does, and be ambiguous if
> there is more than one record field with the same name in scope. In
> practice, existing code is already written to avoid this ambiguity so
> it would continue to work. Or you could write 'Record.field r' or
> 'r.field', which would work as the proposal describes and remove the
> ambiguity, and work even in the presence of multiple record fields
> with the same name in scope.
>
> The point is that I see what you gain by allowing record fields to be
> referred to 

Re: Records in Haskell

[Matthew Farkas-Dyck]

On 02/01/2012, Simon Peyton-Jones  wrote:
> It seems to me that there's only one essential missing language feature,
> which is appropriately-kinded type-level strings (and, ideally, the ability
> to reflect these strings back down to the value level). Given that, template
> haskell, and the HList bag of tricks, I'm confident that  a fair number of
> elegant records packages can be crafted. Based on that experience, we can
> then decide what syntactic sugar would be useful to elide the TH layer
> altogether.
>
> I think we can do this part without much trouble, once the dust has settled
> on -XPolyKinds.  It certainly fits with all the work we've been doing
> recently on the kind system. I agree that it's a fairly basic requirement;
> for example, it's also assumed by
> http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields
>
> Specifically
>
> *Allow String as a new kind
>
>
> *Now you can define classes or types with kinds like
>
> MyCls :: String -> a -> Constraint
>
> T :: String -> *
>
>
> *Provide type-level string literals, so that "foo" :: String
>
> Open questions:
>
> *Is String (at the kind level) a synonym for [Char]?  I'm inclined
> *not* to do this initially, because it would require us to have promoted
> character literals too -- and the implementation of record labels as strings
> of type-level cons-cells is not going to be efficient.
>
> *If String is not a kind level synonym for [Char], maybe it should
> have a different name.  For example,   "foo" :: Label?  Or Atom?   After
> all, if it doesn't behave like a Haskell string it probably should not have
> the same name.

I agree. In this case, though, I think we ought to allow
kind-polymorphic quoted type-level literals, thus:
"foobar" :: Label
or
"foobar" :: String
at least.

> *Are there any operations over Labels?
>
> *I don't know exactly what you have in mean by "the ability to
> reflect the type-level string at the value level".
>
> Simon
>
> From: Gershom Bazerman [mailto:gersh...@gmail.com]
> Sent: 31 December 2011 19:12
> To: Simon Peyton-Jones
> Cc: Greg Weber; glasgow-haskell-users@haskell.org
> Subject: Re: Records in Haskell
>
> On Dec 31, 2011, at 1:28 PM, Simon Peyton-Jones wrote:
> The trouble is that I just don't have the bandwidth (or, if I'm honest, the
> motivation) to drive this through to a conclusion. And if no one else does
> either, perhaps it isn't *that* important to anyone.  That said, it clearly
> is *somewhat* important to a lot of people, so doing nothing isn't very
> satisfactory either.
>
> Usually I feel I know how to move forward, but here I don't.
>
> Simon
> It seems to me that there's only one essential missing language feature,
> which is appropriately-kinded type-level strings (and, ideally, the ability
> to reflect these strings back down to the value level). Given that, template
> haskell, and the HList bag of tricks, I'm confident that  a fair number of
> elegant records packages can be crafted. Based on that experience, we can
> then decide what syntactic sugar would be useful to elide the TH layer
> altogether.
>
> Beyond that, it would really help namespacing in general to appropriately
> extend the module system to allow multiple modules to be declared within a
> single file -- or, better yet, "submodules". I know that this introduces a
> few corner cases that need to be thought through -- what happens with
> overlapping declarations, for example. But I tend to think the path here is
> relatively straightforward and obvious, and the added expressive power
> should make namespacing issues much more tractable. Like the type-level
> strings proposal, this isn't about implementing records as such -- rather,
> it's about generally extending the expressive power of the language so that
> record systems--among other things--are easier to write.
>
> Cheers,
> Gershom
>

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Records in Haskell

[Matthew Farkas-Dyck]

> It seems to me that there's only one essential missing language feature,
> which is appropriately-kinded type-level strings

Isn't this possible now with type → kind promotion?

> Cheers,
> Gershom

Cheers, (and Happy New Year),
MFD

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Records in Haskell

[Matthew Farkas-Dyck]

On 30/12/2011, Andriy Polischuk  wrote:
> You're right, i should have written "ambiguities" instead.
> That was not joke, just i somehow didn't notice Chris Smith answer.

Hm. I though at first that if backslash were the selection operator,
then there must be programs of unclear semantics, but actually I can't
find any.

I'm sorry if my earlier message seemed unkind, by the way; it wasn't
meant to be.

> However, I think, there are some drawbacks in using dot for that in
> comparison with qualified imports access. The latter is easier to
> distinguish from composition by eye, because module-identifier is always one
> word, starting from uppercase letter (which, moreover, in many editors is
> highlighted differently). But in field access left operand is not always
> atomic - it can be expression.
>
> Consider this example:
> quux (y . (foo >.< bar).baz (f . g)) moo
> It's not that easy to distinguish from
> quux (y . (foo >.< bar) . baz (f . g)) moo

Yeah, that's why I dislike dot as compose operator (^_~)

>
> Matthew Farkas-Dyck wrote
>>
>> Certainly not no conflicts: lambda expressions.
>>
>
>
> --
> View this message in context:
> http://haskell.1045720.n5.nabble.com/Records-in-Haskell-tp4806095p5111428.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://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>

Backslash is a possibility then, it seems, but in my opinion breaks
the principle of least surprise, i.e. "I can't believe it's not
lambda!"

Cheers,
Matthew Farkas-Dyck

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Records in Haskell

[Matthew Farkas-Dyck]

Certainly not no conflicts: lambda expressions.


On 30/12/2011, Colin Adams  wrote:
> On 30 December 2011 15:55, Matthew Farkas-Dyck  wrote:
>
>> On 30/12/2011, Andriy Polischuk  wrote:
>> > Yet another idea:
>> > Consider using '\' as record access operator. No conflicts with anything
>> at
>> > all, and,
>> > moreover, it really looks like hierarchical access. Reminds of
>> filesystems
>> > though.
>>
>> I hope this is a joke.
>>
>
> Why?
>

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Records in Haskell

[Matthew Farkas-Dyck]

On 30/12/2011, Andriy Polischuk  wrote:
> Yet another idea:
> Consider using '\' as record access operator. No conflicts with anything at
> all, and,
> moreover, it really looks like hierarchical access. Reminds of filesystems
> though.

I hope this is a joke.

>
> Matthew Farkas-Dyck wrote
>>
>> Another thought:
>> Perhaps bang as record selection operator. It would avoid further
>> corner cases of dot, and it's not unprecedented in Haskell (e.g.
>> Data.Map.!).
>>
>
>
> --
> View this message in context:
> http://haskell.1045720.n5.nabble.com/Records-in-Haskell-tp4806095p5109437.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://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: "GeneralizedNewtypeDeriving"

[Matthew Farkas-Dyck]

*query*

Ah. So it does.

Thanks. I'll learn this language yet (^_~)

On 27/12/2011, Chris Dornan  wrote:
> That’s as maybe but last time I looked (I don’t have it to hand) the OED
> generally accepts –ize or –ise spellings for British English (maybe even
> favouring the former).
>
> Chris
>
> From: glasgow-haskell-users-boun...@haskell.org
> [mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of David Fox
> Sent: 27 December 2011 14:50
> To: Matthew Farkas-Dyck
> Cc: GHC users
> Subject: Re: "GeneralizedNewtypeDeriving"
>
> My guess is that Americans were involved.
> On Mon, Dec 26, 2011 at 7:24 AM, Matthew Farkas-Dyck 
> wrote:
> Just of curiosity, why is it spelt with a z? Is it spelt thus in
> Scottish English? I thought that "generalised" is written throughout
> Great Britain.
>
> Cheers,
> MFD
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

"GeneralizedNewtypeDeriving"

[Matthew Farkas-Dyck]

Just of curiosity, why is it spelt with a z? Is it spelt thus in
Scottish English? I thought that "generalised" is written throughout
Great Britain.

Cheers,
MFD

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Records in Haskell

[Matthew Farkas-Dyck]

Fair enough.


On 20/12/2011, Chris Smith  wrote:
> On Tue, Dec 20, 2011 at 5:57 PM, Matthew Farkas-Dyck
>  wrote:
>> Another thought:
>> Perhaps bang as record selection operator. It would avoid further
>> corner cases of dot, and it's not unprecedented in Haskell (e.g.
>> Data.Map.!).
>
> We already have weird syntax rules for dot, and the proposed change
> (i.e., dot is an identifier when surrounded with spaces, else it's
> reserved syntax) actually makes the rules *simpler* in some ways
> rather than more complex... so why wouldn't we do it that way?
>
> The more difficult bit isn't about quirks of syntax, but rather about
> some significant semantic issues and differing design goals should
> we have a built-in notion of lenses... if so, which formulation...
> what kinds of punning do we want to preserve, and how deeply should
> punning go in the semantics, versus be a shallow kind of sugar... how
> does that interact with the type system... and so on.  These are the
> significant problems.
>

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Records in Haskell

[Matthew Farkas-Dyck]

Another thought:
Perhaps bang as record selection operator. It would avoid further
corner cases of dot, and it's not unprecedented in Haskell (e.g.
Data.Map.!).
If one wished to use dot, one could do this:

import Prelude hiding ((.));
import Control.Category.Unicode((∘));

(.) = (!);

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Records in Haskell

[Matthew Farkas-Dyck]

On 04/11/2011, Simon Peyton-Jones  wrote:
> | I really like Simon PJ's "proposal for records in Haskell". Some
> | reasons for this are:
>
> Which one?  You'll need to give your readers an explicit link
>
> S
>

Sorry.

http://research.microsoft.com/en-us/um/people/simonpj/Haskell/records.html

-- 
Matthew Farkas-Dyck

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Records in Haskell

[Matthew Farkas-Dyck]

I really like Simon PJ's "proposal for records in Haskell". Some
reasons for this are:
- Anonymous record types. For example, an anonymous record type can
easily hold ad-hoc keyword arguments. (Oh, just noticed that said in
the document.)
- To quote the document, "We can express polymorphic update (a
standard awkward case) quite nicely". (If I'm not mistaken (please
tell me if so), OverloadedRecordFields proposal fails here.)
- Nice syntax (in my opinion).

Possible record member set syntax:
let x.k = value in x
Pros:
- No new syntax
- Least Surprise
Cons:
- Verbosity (especially such: (\ x -> let x.k = value in x))

On 20/10/2011, Simon Peyton-Jones  wrote:
> | Subject: Re: Records in Haskell
> |
> | I have added my proposal to the wiki.The only downsides to it that I can
> see are:
>
> Thanks to Barney for articulating a proposal for records in Haskell.  Over
> various plane rides and ICFP chats I've worked out some more details.  It's
> not as simple as I'd hoped.
>
> I'm underwater with stuff at the moment but I did find the time to capture a
> summary here
>   http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields
>
> Please do correct errors, suggest solutions, or explore variants.
>
> Simon
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>


-- 
Matthew Farkas-Dyck

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Profile: zero total time

[Matthew Farkas-Dyck]

Yes -- I just tried it threaded, and the profile is true.

Thanks for your help.

Might this warrant another ticket?

On 8 July 2011 16:27, David Peixotto  wrote:
> Does it make a difference if you use the threaded vs. non-threaded runtime? 
> I'm seeing the odd behavior on Mac, but only for the single-threaed runtime.
>
> http://hackage.haskell.org/trac/ghc/ticket/5282#comment:8
>
> On Jul 7, 2011, at 2:45 PM, Matthew Farkas-Dyck wrote:
>
>> Sorry, I ought to have mentioned:
>>
>> $ uname -sr
>> Linux 2.6.38
>>
>> On 7 July 2011 14:03, Daniel Fischer  
>> wrote:
>>> On Thursday 07 July 2011, 20:44:57, Matthew Farkas-Dyck wrote:
>>>> I am trying to take a profile of a program, but when I run it, the
>>>> total time (as given in the profiling report file) is zero!
>>>
>>> If you're on a Mac, it could be
>>>
>>> http://hackage.haskell.org/trac/ghc/ticket/5282
>>>
>>
>>
>>
>> --
>> Matthew Farkas-Dyck
>>
>> ___________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
>



-- 
Matthew Farkas-Dyck

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Profile: zero total time

[Matthew Farkas-Dyck]

Sorry, I ought to have mentioned:

$ uname -sr
Linux 2.6.38

On 7 July 2011 14:03, Daniel Fischer  wrote:
> On Thursday 07 July 2011, 20:44:57, Matthew Farkas-Dyck wrote:
>> I am trying to take a profile of a program, but when I run it, the
>> total time (as given in the profiling report file) is zero!
>
> If you're on a Mac, it could be
>
> http://hackage.haskell.org/trac/ghc/ticket/5282
>



-- 
Matthew Farkas-Dyck

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Profile: zero total time

[Matthew Farkas-Dyck]

I am trying to take a profile of a program, but when I run it, the
total time (as given in the profiling report file) is zero!

total time  =0.00 secs   (0 ticks @ 20 ms)

However, the -s option yields the following data:

   3,429,300,984 bytes allocated in the heap
 210,760,024 bytes copied during GC
  23,647,224 bytes maximum residency (13 sample(s))
   3,536,968 bytes maximum slop
  58 MB total memory in use (0 MB lost due to fragmentation)

  Generation 0:  6339 collections, 0 parallel,  1.14s,  1.42s elapsed
  Generation 1:13 collections, 0 parallel,  0.28s,  0.34s elapsed

  INIT  time0.00s  (  0.00s elapsed)
  MUT   time   96.60s  (124.50s elapsed)
  GCtime1.42s  (  1.75s elapsed)
  RPtime0.00s  (  0.00s elapsed)
  PROF  time0.00s  (  0.00s elapsed)
  EXIT  time0.00s  (  0.00s elapsed)
  Total time   98.02s  (126.25s elapsed)

  %GC time   1.4%  (1.4% elapsed)

  Alloc rate35,498,347 bytes per MUT second

  Productivity  98.5% of total user, 76.5% of total elapsed

The time taken by each cost centre is also zero. The program is
compiled with options "-prof -auto-all -caf-all" by GHC 7.0.3 and run
with RTS options "-p -s".

The true time taken is certainly NOT zero. How is this possible?

Thanks.

Cheers,
Matthew Farkas-Dyck

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users