Re: ANNOUNCE: GHC 7.4.1 Release Candidate 2
Hi Rene, On Mon, Jan 30, 2012 at 08:15:05PM +0100, Rene de Visser wrote: What are the plans for http://hackage.haskell.org/trac/ghc/ticket/5623 which seems to be still open? We don't plan to fix it for 7.4.1. Assuming we do a 7.4.2, if we have a fix for it then it could go in 7.4.2. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Impredicative types error
Hi, I am running into an issue where some code that compiled and worked under 6.12 is failing under 7.0, the offending code is class DeNameable a where deName :: Module - a - a getDeName :: Tc (DeNameable n = n - n) getDeName = do mn - asks (tcInfoModName . tcInfo) return (\n - deName mn n) Tc is a plain typechecking monad and this returns a generic denaming function that can be used to turn haskell names back into human readable form before printing errors in jhc. I have the ImpredicativeTypes LANGUAGE feature turned on. the error I get under 7.0 is src/FrontEnd/Tc/Monad.hs:131:29: Couldn't match expected type `n - n' with actual type `DeNameable n' In the second argument of `deName', namely `n' In the expression: deName mn n In the first argument of `return', namely `(\ n - deName mn n)' John ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell - namespacing for fields
On 1/02/2012 12:26 AM, AntC wrote:
Simon Peyton-Jonessimonpjat microsoft.com writes:
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. [snip] the added expressive power
should make namespacing issues
much more tractable. [snip] 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.
I’m agnostic about nested modules. In principle they would be a good
thing. However, for the application to records in particular, ...
No! no! no! For records _don't_ put records in nested/sub-modules, and _don't_
require them in separate modules (as currently). Here's how ...
namespace management and record systems are intimately related, but as
you assert distinct issues.
taking your example of Customer_id, I expressly want to be able to
define in the same syntactic module (file). Two records with a field
with exactly the same name at two different types, say Customer_id ::
Int and Customer_id :: String. As I understand it, your proposal
would not enable this.
In reality these two different uses of the name Customer_id are
unrelated and distinct. Some would argue that therefore they should
rightly have distinct names, however that is moot, for the purpose of
this discussion lets take this as the objective.
There are two roads to travel: Customer_id is one semantic entity (in
the sense of an overloaded field, disambiguated by the type system) or
Customer_id represents two distinct semantic entities disambiguated
syntactically. I for one favor the second approach as it matches my
intent, can I say, more faithfully.
[There may be other reasons for nested/sub-modules, but records ain't it.]
as above, however, I believe the best approach is to explore both paths
and perhaps extend Haskell in both directions.
As in your example the particular construction of which suits, the
approach offered in your email better because it matches your intent
more faithfully. It is this ability to match construction with intent
that is critical, which alludes to the notion of the expressivity of a
language.
The reason was hinted at way back in Chris Done's attachment to the original
Records wiki http://hackage.haskell.org/trac/ghc/wiki/Records types in a non-
trivial project.
Let's say I have a database application with a field (meaning type)
customer_id. Then it appears in records for name and address, pricing, order
entry, etc. This is not a name 'clash', it's 'intended sharing'. (It really
galls me to even put it that way for explanatory purposes. Really it's the
**same** customer_id.)
In data model design you'd typically go about identifying all the fields
(types aka attributes) and putting them in a data dictionary. Then you'd
construct your records from them.
You might (possibly) put the data dictionary in a distinct module, for easy
maintenance. But you'd certainly want all the customer-related records in the
same module.
So a data decl:
data Customer_NameAddress = Cust_NA { customer_id :: Int, ... }
is _not_ declaring customer_id, it's _using_ an already-declared field.
(Actually, if you've got any sense, you'll declare:
newtype Customer_id = Customer_id Int
data ... = { customer_id :: Customer_id, ... }
and that takes us to Type-indexed records and then a short hop to anonymous
tuples and polymorphic records and tuple extension/concat/merge and ... one
day!)
The other purpose of the data dictionary is to declare what DBMS's call
the 'domain' of the field (Int in the case of customer_id). The terminology's
going to get a bit confusing here: Haskell's field name (selector functions)
apply to the record as the function's domain, and Int as the result (range).
For Haskell's field selectors we might also want to constrain the records they
can be used in. (For example they must be 'Persist'able so that we can write
them to an external database.)
So, to the proposal (I'm assuming http://www.haskell.org/pipermail/glasgow-
haskell-users/2011-December/021298.html can be made workable. SPJ has been
kind enough to give it a once-over http://www.haskell.org/pipermail/glasgow-
haskell-users/2012-January/021744.html, but of course all faults are the
author's alone.) Specifically, there's to be a class Has with methods get and
set. This is grossly simplified, see the posts):
0.class Has r fld t where-- record r has field fld at type t
get :: r - fld - t
set :: fld - t - r - r' -- update t into r
-- the r' is to cater for type-changing updates
-- it's actually a type function over r fld t
And then:
1. We need -XDisambiguateRecordFields,
so that we can talk about specific record types
Re: Records in Haskell - namespacing for fields
John Lask jvlask at hotmail.com writes:
On 1/02/2012 12:26 AM, AntC wrote:
No! no! no! For records _don't_ put records in nested/sub-modules, and
_don't_
require them in separate modules (as currently). Here's how ...
namespace management and record systems are intimately related, but as
you assert distinct issues.
taking your example of Customer_id, I expressly want to be able to
define in the same syntactic module (file). Two records with a field
with exactly the same name at two different types, say Customer_id ::
Int and Customer_id :: String. As I understand it, your proposal
would not enable this.
John, you can't do this now. You can't even define in the same module two
records with the same name with the _same_ type.
[I'd better check first why you've put Customer_id with upper case, that's a
type, not a field. Are you sure what you're talking about?]
I'd certainly dispute that there's anything sensible in doing that (why?
what's the use case?), and I guess my proposal is not making that easy, but it
is possible (and in fact no more difficult than a 'fixed' type for a field).
You'd go:
field customer_id :: r - t -- which is the same as no type spec at all
Then:
data CustInt = CustInt { customer_id :: Int, ... }
data CustString = CustString { customer_id :: String, ... }
It doesn't stop you also doing:
data CustBool = CustBool { customer_id :: Bool, ... }
(I could contrive that the domain of customer_id is constrained to only Int or
String, but why?)
In reality these two different uses of the name Customer_id are
unrelated and distinct. Some would argue that therefore they should
rightly have distinct names, however that is moot, for the purpose of
this discussion lets take this as the objective.
No, I'm not going to take that as an objective. You'd have to provide a much
better motivation for wanting to have two identical names in the same scope
that are unrelated and distinct.
I'd agree with the 'some' that you should use two different names. Or if this
is an 'accidental' clash of names from developers working separately (this is
my distant planet example), then the clash is not special for field names, and
it's what the module system is for. Use My.customer_id and Their.customer_id.
There are two roads to travel: Customer_id is one semantic entity (in
the sense of an overloaded field, disambiguated by the type system) or
Customer_id represents two distinct semantic entities disambiguated
syntactically. I for one favor the second approach as it matches my
intent, can I say, more faithfully.
I'm interested to know how you disambiguate syntactically distinct entities
with identical names in the same scope.
[There may be other reasons for nested/sub-modules, but records ain't it.]
as above, however, I believe the best approach is to explore both paths
and perhaps extend Haskell in both directions.
No, we can't afford to keep exploring multiple paths. What happens in fact is
that it's extremely hard work, there's very few people who can actually
implement it, they (frankly) are not very interested when there's so many
other exciting possible developments. (Record systems don't count as exciting
for programming language research: the ground is already well covered.)
There's barely the resourcing to extend Haskell in just one way, and only
providing the change is minimal.
Haskell 98's record system has been a wart since -- errm -- 1996.
As in your example the particular construction of which suits, the
approach offered in your email better because it matches your intent
more faithfully. It is this ability to match construction with intent
that is critical, which alludes to the notion of the expressivity of a
language.
Eh? This sounds like metaphysics.
___
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 2
So it embarrasses me to admit it, but I'm having the same problem I always have when I install a new ghc, and that's cabal and cabal install. I downloaded the latest cabal-install from http://hackage.haskell.org/package/cabal-install and that was a mistake right off. After fiddling around I figured out I apparently need the one bundled with ghc... and sure enough, the source version has a cabal-install-0.13.3. This one has newer but also has out of date dependencies: Configuring cabal-install-0.13.3... Setup.hs: At least the following dependencies are missing: Cabal =1.13.3 1.14, base =2.0 2.2, filepath =1.0 1.3, time =1.1 1.3, But shouldn't cabal-install be updated for the version of ghc it's with? I cloned branch 7.4 and did a ./sync-all pull so I should have the latest version, right? And how are other people testing this out if cabal-install has out of date dependencies? And strangest, why is the 'base' dependency so old? And while I'm wondering about cabal, why on earth is it that so many Setup.hs files are actually Setup.lhs and with no actual literate contents? Oh, and before I could have any of those problems, the binary distribution itself didn't want to install: it was evidently compiled against libgmp3 and archlinux is now installing libgmp5 with no option to downgrade (though oddly it calls it .10 in the so file). I tracked down an old libgmp and install with tar since arch doesn't seem to want more than one libgmp installed simultaneously. I don't know how many other linuxes out there do this, but I know I'm not the only archlinux using haskell user. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
