RE: Unit unboxed tuples
| Just of out curiosity, what would be a compelling use case for singleton | and unit unboxed tuples? | | For singleton unboxed tuples, any situation where you want to return a | single value but not force its evaluation. This occurs for example | with some low level functions in the implementation of ordinary lazy | arrays. True; but you don't need the singleton constructor as a function to do that; just write f x = (# x+1 #) for example. Singleton unboxed tuples are a perfectly valid data type; it's just that we don't (now) have a name for their constructor. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1
Am Donnerstag, den 22.12.2011, 00:02 +0100 schrieb Bas van Dijk:
On 21 December 2011 19:29, Ian Lynagh ig...@earth.li wrote:
* There is a new feature constraint kinds (-XConstraintKinds):
http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/constraint-kind.html
I'm trying to run the ConstraintKinds example from the documentation:
{-# LANGUAGE ConstraintKinds, TypeFamilies #-}
type family Typ a b :: Constraint
type instance Typ Int b = Show b
type instance Typ Bool b = Num b
But GHC complains:
Not in scope: type constructor or class `Constraint'
By the way, is there a reason behind the fact that “Constraint” uses the
ordinary case, while “BOX” has all three letters capitalized? Wouldn’t
it be more sensible if it were “Box” instead of “BOX”?
Things like capitalization might not seem very important first, but
unfortunately, decisions about them seem to persist.
Best wishes,
Wolfgang
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ANNOUNCE: GHC 7.4.1 Release Candidate 1
| By the way, is there a reason behind the fact that “Constraint” uses the | ordinary case, while “BOX” has all three letters capitalized? Wouldn’t | it be more sensible if it were “Box” instead of “BOX”? Only that BOX is a sort (currently the one and only sort), whereas Constraint is a kind. I'm not sure that BOX should ever be displayed to users. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
The semantics of Frege's records are layed out in its manual [1] in the
following sections:
4.2.1 Algebraic Data type Declaration - Constructors with labeled fields
3.2 Primary Expression
The Frege record system explanation is the first one that I could read and
immediately understand (oh, it just creates a namespace!). Perhaps this is
just in part because it was better explained. But I think it is also
because desugaring records to a library is a very complicated proposition,
whereas taking the same library concept but baking it into the compiler and
making simple language modifications is actually much more straightforward
to understand.
Many of the built-in record proposals seem more ambitious (create a new
record from an existing one, generalize in some other direction). More
power or generalization could be very useful, but it can wait for later -
Haskell's records are glaringly bad because they lack name-spacing.
I think one of the problems being faced with improving records is a false
choice between a quick but hacky library desugaring or a major Extensible
records built into the compiler. What I am proposing is that (unless
someone proposes a great desugaring solution) we make it the immediate goal
to have records built into the compiler, but done in the simplest (perhaps
least Extensible) way that just accomplishes name-spacing.
[1] http://code.google.com/p/frege/downloads/detail?name=Language-202.pdf
On Tue, Dec 27, 2011 at 8:32 AM, Greg Weber g...@gregweber.info wrote:
The original goal was to come up with a simple solution. Perhaps that goal
is unattainable, or at least attaining it has much higher cost than we had
hoped. If that is the case we must take a step back and look at changing
how things are done currently. Perhaps the approach that a record label
becomes a global module function is just not feasible.
In the Frege http://code.google.com/p/frege (a Haskell with some
differences implementation on the JVM) language every data type is at the
same time a namespace.
* the function that accesses field x of data type T is T.x
* If a::T then a.x = T.x a
* the function that updates field x of data type T is T.{x=}
* the function that sets field x in a T to 42 is T.{x=42}
* If a::T then a.{x=} and a.{x=42} are valid
* the function that changes field x of a T by applying some function to it
is T.{x -}
* T.{x?} is a function that returns true iff the argument was constructed
with a data constructor that has field x.
In the Opa language a Module is in fact a Record specially marked as a
module.
What do you think of the Frege system?
On Fri, Dec 23, 2011 at 2:40 PM, Greg Weber g...@gregweber.info wrote:
I am willing to help on this as much as I can. Unfortunately I don't
think you want me to lead the discussion or make decisions on this - many
of these discussions seem over my head. I will continue to study them
though and see if the sink in more.
I do think almost all of these proposals want a dot selector, so it is a
good idea for Haskell to require the normal function (composition) dot to
have spaces around it - should this be brought to the Haskell
Prime committee?
Greg Weber
On Fri, Dec 23, 2011 at 1:52 PM, Simon Peyton-Jones
simo...@microsoft.com wrote:
Are Records stalled out again? I am perfectly willing to leave the
fate of records up to a willing and capable implementer. That seems much
better than waiting another 5 years for perfection :)
** **
Yes, they are stalled again. The “simple solution” turned out to be not
simple. I wrote it up at length in
http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields*
***
There are various unsatisfactory aspects of the proposal, particularly
concerning record update. I am not sure how to resolve them.
** **
There was essentially no reaction. As it’s quite a lot of work to
implement, and no one seemed to care very much, I put it back on the back
burner. So that’s where it stands.
** **
Meanwhile, AntC has put forth another proposal that I have not had time
to look at in detail.
http://www.haskell.org/pipermail/glasgow-haskell-users/2011-December/021298.html
** **
*What this needs is someone (not me) to lead the discussion and try to
make sure it makes progress*. For example, does AntC’s proposal work?
Is it better than the one I articulated? Are any other variants worth
considering? Is the gain from overloading record fields worth the pain or
design and implementation?Volunteers, stand forth!
** **
Simon
** **
** **
*From:* Greg Weber [mailto:g...@gregweber.info]
*Sent:* 09 December 2011 19:38
*To:* Simon Peyton-Jones
*Cc:* Wolfgang Jeltsch; glasgow-haskell-users@haskell.org
*Subject:* Re: Records in Haskell
** **
Are Records stalled out again? I am perfectly willing to leave the fate
of records up to a willing and capable implementer. That seems much better
than waiting
Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1
Hi Wolfgang, On Wed, Dec 28, 2011 at 13:51, Wolfgang Jeltsch g9ks1...@acme.softbase.orgwrote: Am Mittwoch, den 28.12.2011, 12:48 + schrieb Simon Peyton-Jones: | By the way, is there a reason behind the fact that “Constraint” uses the | ordinary case, while “BOX” has all three letters capitalized? Wouldn’t | it be more sensible if it were “Box” instead of “BOX”? Only that BOX is a sort (currently the one and only sort), whereas Constraint is a kind. I'm not sure that BOX should ever be displayed to users. Okay, this makes sense then. However, note that the GHC User’s manual mixes the terminology (“kind” vs. “sort”) at one point: Note that List, for instance, does not get kind BOX - BOX, because we do not further classify kinds; all kinds have sort BOX. http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/kind-polymorphism-and-promotion.html I think, it should say “sort BOX - BOX”. Yes, it should indeed say sort, not kind. If you know of any other places in the documentation with this type/kind/sort of inconsistency, please let me know :-) Cheers, Pedro Best wishes, Wolfgang ___ 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: ANNOUNCE: GHC 7.4.1 Release Candidate 1
I've pushed a patch to the docs. Thanks S From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of José Pedro Magalhães Sent: 28 December 2011 15:08 To: Wolfgang Jeltsch Cc: glasgow-haskell-users@haskell.org Subject: Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1 Hi Wolfgang, On Wed, Dec 28, 2011 at 13:51, Wolfgang Jeltsch g9ks1...@acme.softbase.orgmailto:g9ks1...@acme.softbase.org wrote: Am Mittwoch, den 28.12.2011, 12:48 + schrieb Simon Peyton-Jones: | By the way, is there a reason behind the fact that Constraint uses the | ordinary case, while BOX has all three letters capitalized? Wouldn't | it be more sensible if it were Box instead of BOX? Only that BOX is a sort (currently the one and only sort), whereas Constraint is a kind. I'm not sure that BOX should ever be displayed to users. Okay, this makes sense then. However, note that the GHC User's manual mixes the terminology (kind vs. sort) at one point: Note that List, for instance, does not get kind BOX - BOX, because we do not further classify kinds; all kinds have sort BOX. http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/kind-polymorphism-and-promotion.html I think, it should say sort BOX - BOX. Yes, it should indeed say sort, not kind. If you know of any other places in the documentation with this type/kind/sort of inconsistency, please let me know :-) Cheers, Pedro Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.orgmailto: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: Records in Haskell
Quoth Greg Weber g...@gregweber.info, ... Many of the built-in record proposals seem more ambitious (create a new record from an existing one, generalize in some other direction). More power or generalization could be very useful, but it can wait for later - Haskell's records are glaringly bad because they lack name-spacing. I think one of the problems being faced with improving records is a false choice between a quick but hacky library desugaring or a major Extensible records built into the compiler. What I am proposing is that (unless someone proposes a great desugaring solution) we make it the immediate goal to have records built into the compiler, but done in the simplest (perhaps least Extensible) way that just accomplishes name-spacing. It's sure easy to imagine something like that happening, in principle, but ... are you saying that extensibility specifically has been a major issue? Could be, I haven't been paying so much attention. Wouldn't extensibility more or less come along with row polymorphism? I mean, my understanding of the term is that an expression that instantiates a particular record field, can incorporate a record lacking that field, which seems to me to be implicit in row polymorphism anyway. I would think row polymorphism is a must-have. If you're interested in looking at old, Haskell-related record systems, also see O'Haskell. Donn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
On Wed, Dec 28, 2011 at 2:12 PM, Donn Cave d...@avvanta.com wrote: Quoth Greg Weber g...@gregweber.info, ... Many of the built-in record proposals seem more ambitious (create a new record from an existing one, generalize in some other direction). More power or generalization could be very useful, but it can wait for later - Haskell's records are glaringly bad because they lack name-spacing. I think one of the problems being faced with improving records is a false choice between a quick but hacky library desugaring or a major Extensible records built into the compiler. What I am proposing is that (unless someone proposes a great desugaring solution) we make it the immediate goal to have records built into the compiler, but done in the simplest (perhaps least Extensible) way that just accomplishes name-spacing. It's sure easy to imagine something like that happening, in principle, but ... are you saying that extensibility specifically has been a major issue? Could be, I haven't been paying so much attention. Yes, I believe it is common knowledge and stated in many places that the community cannot decide on the best *extensible* record system. http://www.haskell.org/haskellwiki/GHC:FAQ#Extensible_Records Wouldn't extensibility more or less come along with row polymorphism? I mean, my understanding of the term is that an expression that instantiates a particular record field, can incorporate a record lacking that field, which seems to me to be implicit in row polymorphism anyway. I would think row polymorphism is a must-have. Perhaps if you want *extensible* records. If you would like to make some progress with records in the near future rather than keeping records in limbo, I think we really need to give up for the moment on any higher form of abstraction than straight-forward name-spacing. If you're interested in looking at old, Haskell-related record systems, also see O'Haskell. I am interested in any potential solution. You could link to it on the ExtensibleRecords wiki page and explain it a bit for future reference. O'Haskell seems to be very much concerned with being as extensible as possible - to the point of trying to do OO in Haskell. Greg Weber 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: Records in Haskell
Quoth Greg Weber g...@gregweber.info, On Wed, Dec 28, 2011 at 2:12 PM, Donn Cave d...@avvanta.com wrote: ... I would think row polymorphism is a must-have. Perhaps if you want *extensible* records. If you would like to make some progress with records in the near future rather than keeping records in limbo, I think we really need to give up for the moment on any higher form of abstraction than straight-forward name-spacing. No, to be clear on that, I haven't given much thought to extensibility per se, I was thinking row polymorphism is a valuable feature on its own, and extensibility just seemed to me to be an implicit side benefit. In principle, a less is more approach to language features appeals to me a lot, but not to the point where we just preemptively give up on any higher form of abstraction. Given the potential for backwards incompatibility, you'd want to have something pretty good to show for it. Donn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
On Wed, Dec 28, 2011 at 3:34 PM, Donn Cave d...@avvanta.com wrote: Quoth Greg Weber g...@gregweber.info, On Wed, Dec 28, 2011 at 2:12 PM, Donn Cave d...@avvanta.com wrote: ... I would think row polymorphism is a must-have. Perhaps if you want *extensible* records. If you would like to make some progress with records in the near future rather than keeping records in limbo, I think we really need to give up for the moment on any higher form of abstraction than straight-forward name-spacing. No, to be clear on that, I haven't given much thought to extensibility per se, I was thinking row polymorphism is a valuable feature on its own, and extensibility just seemed to me to be an implicit side benefit. In principle, a less is more approach to language features appeals to me a lot, but not to the point where we just preemptively give up on any higher form of abstraction. Given the potential for backwards incompatibility, you'd want to have something pretty good to show for it. This is a valid concern. The goal I think we should have is to just to get a release with simple name-spacing resulting in module-like dot notation member selection plus a similar easy syntax for updates. Every extensible records solution I have seen wants this plus some other features. Admittedly I don't understand any of the extensible solutions, so if you can come up with a specific example of backwards incompatibility that would be very useful. 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: Unit unboxed tuples
Quoting Simon Peyton-Jones simo...@microsoft.com: for example. Singleton unboxed tuples are a perfectly valid data type; it's just that we don't (now) have a name for their constructor. Well, Haskell *does* have a mechanism for giving two different implementations to a particular name... class UnboxedUnit a where (# #) :: a instance UnboxedUnit (##) instance UnboxedUnit (a - (# a #)) That only leaves solving the equivalent problem for the type-level name (# #). ~d ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ANNOUNCE: GHC 7.4.1 Release Candidate 1
Quoting Wolfgang Jeltsch g9ks1...@acme.softbase.org: Am Mittwoch, den 28.12.2011, 12:48 + schrieb Simon Peyton-Jones: Only that BOX is a sort (currently the one and only sort), whereas Constraint is a kind. I'm not sure that BOX should ever be displayed to users. Okay, this makes sense then. However, note that the GHC User’s manual mixes the terminology (“kind” vs. “sort”) at one point: Note that List, for instance, does not get kind BOX - BOX, because we do not further classify kinds; all kinds have sort BOX. I think, it should say “sort BOX - BOX”. I don't think that would be quite correct. Sorts are typically constants, and there are usually a finite amount of them, each presenting a level of the type system. For instance, * and BOX are both sorts, even though we also have * :: BOX. In a system where BOX - BOX would be well-formed, it should probably be called something else, maybe kind-classifying term (whose sort would be something new, maybe TRIANGLE). But it seems a bit funny to spend a lot of time thinking about what to call things that don't exist in GHC. Maybe it'd be easiest to just drop that awkward hypothetical BOX - BOX altogether from the manual. Lauri ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
