Brandon Allbery | 1 Jan 03:21 2012
Picon

Re: ghc-cabal-Random

On Sat, Dec 31, 2011 at 15:46, Serge D. Mechveliani <mechvel <at> botik.ru> wrote:
Its installation requires Cabal:
 > which cabal
 cabal: Command not found.
 >
And Cabal is difficult to install, it reports that such and such package
versions are missing.
On the other hand, Cabal is, probably, present inside ghc-7.4.0.20111219,
somewhere in the installation directory. Thus I see its  .a and .o files
in
 ~/ghc/7.4.1pre/inst0/lib/ghc-7.4.0.20111219/Cabal-1.14.0/

This is confusing.  Cabal itself is a library, which is included with ghc; the "cabal" command is not, however, part of that library.  It comes from the cabal-install package.

--
brandon s allbery                                      allbery.b <at> gmail.com
wandering unix systems administrator (available)     (412) 475-9364 vm/sms

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Matthew Farkas-Dyck | 1 Jan 07:22 2012
Picon

Re: Records in Haskell

> 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 <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Brent Yorgey | 1 Jan 07:52 2012

Re: Records in Haskell

On Sun, Jan 01, 2012 at 01:22:31AM -0500, Matthew Farkas-Dyck wrote:
> > 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?

Unfortunately, I believe promotion of built-in types other than lists
and tuples has not yet been implemented.  In particular, Char cannot
yet be promoted.  However, there are no theoretical impediments to
implementing it that I know of and it should be possible in the
future.

-Brent

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Yitzchak Gale | 1 Jan 13:11 2012

Re: ghc-cabal-Random

I wrote:
>> Today, it is very unusual to use GHC by itself.
>> To use Haskell, you install the Haskell Platform.
>> That is GHC together with Cabal and a basic
>> set of libraries. It is very easy to install.

Wolfram Kahl wrote:
> However, since you are willing and able to test bleeding-edge versions of GHC,
> you need to be able to live without the platform, which typically
> catches up to GHC versions only within a couple of months.

It's true that the platform provides a stable version of GHC,
as needed by most people, not the bleeding edge. But even if you need
GHC HEAD you would typically use cabal. Unless for some reason
you need to shuffle around manually the various pieces that get built,
follow trees
of package dependencies manually, etc. There are some people
who need to do it, and it is doable, though much more
complicated and error-prone than just using cabal.

>> Almost all Haskell software is expected to
>> be installed using Cabal nowadays.

> It is important to know that people associate two packages
> with the name ``Cabal''

They are closely interconnected though. If you use the platform,
that distinction is not very important. It just works.

> Life without cabal-install is not only possible,
> but also safer.

I disagree with that. Manual processes are error-prone.

With experience, you can learn how
to do things totally manually, just like you can learn to
build C projects manually without make, and with even
more experience, you can learn to avoid all of the
pitfalls. It's a good thing to know, but I wouldn't put
it at first priority unless there's a special reason for it.

> (See also: http://www.vex.net/~trebla/haskell/sicp.xhtml )

The Cabal system is quite mature now, but still far
from perfect. Problems can arise. Most of the problems
are inherent to the "DLL Hell" that can occur in any
separate compilation system, and some arise from the fact
that Cabal's dependency solver needs improvement (that's
a hard problem).

That link is a detailed write-up of just about everything
that can possibly go wrong. In my experience, none of that
happens until you've been using an installation for a long time,
or if you are very trigger-happy with upgrading packages to the latest
version for no reason. Or if you're using a package with a huge amount
of fast-changing dependencies, like one of the web frameworks.

Even then, it's almost always easy enough just to re-install the
platform to get a fresh install. Your next few compiles will take a
few minutes longer as some packages get rebuilt, but that's about it.

To avoid that altogether, I use cabal-dev. This allows me to
build a package I am working on in a sandbox with just the
dependencies it needs, tailored exactly for the needs
of my specific package. Cabal-dev also makes it
easy to experiment with how users will experience
building my package.

It's good to know all the intricacies of the build system,
and what is happening beneath the surface if it gets
lost. The linked article is a worthwhile read for that.

Regards,
Yitz
Ryan Newton | 1 Jan 13:51 2012
Picon

Re: ghc-cabal-Random

I haven't entirely followed this and I see that it's been split over
multiple threads.

Did "cabal install random" actually fail for you under
ghc-7.4.0.20111219?  If so I'd love to know about it as the maintainer
of the "random" package.  (It seems to work for me for
random-1.0.1.1.)

That said, I'm sure AC-random is a fine alternative, and there are
many other packages on Hackage as well, including cryptographic
strength ones (crypto-api, intel-aes, etc).

Cheers,
  -Ryan

On Sun, Jan 1, 2012 at 7:11 AM, Yitzchak Gale <gale <at> sefer.org> wrote:
> I wrote:
>>> Today, it is very unusual to use GHC by itself.
>>> To use Haskell, you install the Haskell Platform.
>>> That is GHC together with Cabal and a basic
>>> set of libraries. It is very easy to install.
>
> Wolfram Kahl wrote:
>> However, since you are willing and able to test bleeding-edge versions of GHC,
>> you need to be able to live without the platform, which typically
>> catches up to GHC versions only within a couple of months.
>
> It's true that the platform provides a stable version of GHC,
> as needed by most people, not the bleeding edge. But even if you need
> GHC HEAD you would typically use cabal. Unless for some reason
> you need to shuffle around manually the various pieces that get built,
> follow trees
> of package dependencies manually, etc. There are some people
> who need to do it, and it is doable, though much more
> complicated and error-prone than just using cabal.
>
>>> Almost all Haskell software is expected to
>>> be installed using Cabal nowadays.
>
>> It is important to know that people associate two packages
>> with the name ``Cabal''
>
> They are closely interconnected though. If you use the platform,
> that distinction is not very important. It just works.
>
>> Life without cabal-install is not only possible,
>> but also safer.
>
> I disagree with that. Manual processes are error-prone.
>
> With experience, you can learn how
> to do things totally manually, just like you can learn to
> build C projects manually without make, and with even
> more experience, you can learn to avoid all of the
> pitfalls. It's a good thing to know, but I wouldn't put
> it at first priority unless there's a special reason for it.
>
>> (See also: http://www.vex.net/~trebla/haskell/sicp.xhtml )
>
> The Cabal system is quite mature now, but still far
> from perfect. Problems can arise. Most of the problems
> are inherent to the "DLL Hell" that can occur in any
> separate compilation system, and some arise from the fact
> that Cabal's dependency solver needs improvement (that's
> a hard problem).
>
> That link is a detailed write-up of just about everything
> that can possibly go wrong. In my experience, none of that
> happens until you've been using an installation for a long time,
> or if you are very trigger-happy with upgrading packages to the latest
> version for no reason. Or if you're using a package with a huge amount
> of fast-changing dependencies, like one of the web frameworks.
>
> Even then, it's almost always easy enough just to re-install the
> platform to get a fresh install. Your next few compiles will take a
> few minutes longer as some packages get rebuilt, but that's about it.
>
> To avoid that altogether, I use cabal-dev. This allows me to
> build a package I am working on in a sandbox with just the
> dependencies it needs, tailored exactly for the needs
> of my specific package. Cabal-dev also makes it
> easy to experiment with how users will experience
> building my package.
>
> It's good to know all the intricacies of the build system,
> and what is happening beneath the surface if it gets
> lost. The linked article is a worthwhile read for that.
>
> Regards,
> Yitz
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users <at> haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Greg Weber | 1 Jan 18:39 2012

Re: Records in Haskell



On Sat, Dec 31, 2011 at 3:28 PM, Simon Peyton-Jones <simonpj <at> microsoft.com> wrote:

Frege has a detailed explanation of the semantics of its record implementation, and the language is *very* similar to Haskell. Lets just start by using Frege's document as the proposal. We can start a new wiki page as discussions are needed.

 

If it’s a serious proposal, it needs a page to specify the design.  Currently all we have is a paragraph on http://hackage.haskell.org/trac/ghc/wiki/Records, under “Better name spacing”.

 

As previously stated on this thread, the Frege user manual is available here:

see Sections 3.2 (primary expressions) and 4.2.1 (Algebraic Data type Declaration - Constructors with labeled fields)

 

To all those concerned about Records: look at the Frege implementation and poke holes in it.

 

Well the most obvious issue is this.  3.2 says

e.m = (T.m e) if the expression e has type t and the type constructor

of t is T and there exists a function T.m

But that innocent-looking statement begs the *entire* question!  How do we know if “e has type t?   This is the route ML takes for arithmetic operators: + means integer plus if the argument is of type Int, float plus if the argument is of type Float, and so on. 

 

Haskell type classes were specifically designed to address this situation. And if you apply type classes to the record situation, I think you end up with

http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields


More specifically I think of this as TDNR, which instead of the focus of the wiki page of maintaining backwards compatibility and de-surgaring to polymorphic constraints. I had hoped that there were different ideas or at least more flexibility possible for the TDNR implementation.
 

 

Well, so maybe we can give up on that.  Imagine Frege without the above abbreviation.  The basic idea is that field names are rendered unique by pre-pending the module name.  As I understand it, to record selection one would then be forced to write (T.m e), to select the ‘m’ field.  That is the, qualification with T is compulsory.   The trouble with this is that it’s *already* possible; simply define suitably named fields

  data T = MkE { t_m :: Int, t_n :: Bool }

Here I have prefixed with a (lower case version of) the type name.  So we don’t seem to be much further ahead.

 

Maybe one could make it optional if there is no ambiguity, much like Haskell’s existing qualified names.  But there is considerable ambiguity about whether T.m means

  m imported from module T

or

  the m record selector of data type T


If there is ambiguity, we expect the T to be a module. So you would need to refer to Record T's module: OtherModule.T.n or T.T.n
Alternatively these conflicts could be compilation errors.
Either way programmers are expected to structure their programs to avoid conflicting names, no different then they do now.

 

Perhaps one could make it work out.  But before we can talk about it we need to see a design. Which takes us back to the question of leadership.



I am trying to provide as much leadership on this issue as I am capable of. Your critique is very useful in that effort.

At this point the Frege proposal without TDNR seems to be a small step forward. We can now define records with clashing fields in the same module. However, without TDNR we don't have convenient access to those fields.
I am contacting the Frege author to see if we can get any more insights on implementation details.
 

Simon

 

 

We only want critiques about

* achieving name-spacing right now

* implementing it in such a way that extensible records could be implemented in its place in the future, although we will not allow that discussion to hold up a records implementation now, just possibly modify things slightly.

 

Greg Weber

 

On Thu, Dec 29, 2011 at 2:00 PM, Simon Peyton-Jones <simonpj <at> microsoft.com> wrote:

| The lack of response, I believe, is just a lack of anyone who
| can cut through all the noise and come up with some
| practical way to move forward in one of the many possible
| directions.

You're right.  But it is very telling that the vast majority of responses on
       http://www.reddit.com/r/haskell/comments/nph9l/records_stalled_again_leadership_needed/
were not about the subject (leadership) but rather on suggesting yet more, incompletely-specified solutions to the original problem.  My modest attempt to build a consensus by articulating the simplest solution I could think of, manifestly failed.

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

 


_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Serge D. Mechveliani | 2 Jan 13:35 2012
Picon

Re: ghc-cabal-Random

On Sun, Jan 01, 2012 at 07:51:39AM -0500, Ryan Newton wrote:
> I haven't entirely followed this and I see that it's been split over
> multiple threads.
> 
> Did "cabal install random" actually fail for you under
> ghc-7.4.0.20111219?  If so I'd love to know about it as the maintainer
> of the "random" package.  (It seems to work for me for
> random-1.0.1.1.)

"cabal install random" 
cannot run in my situation, because I have not  cabal  usable in the 
command line (I only have the Cabal library in the place where the   
ghc-7.4.0.20111219 libraries are installed).
My idea is that having installed GHC, I use the GHC packages and, probably, 
do not need to install Cabal (why complicate things?, why force a DoCon 
user to install extra software?). 

> That said, I'm sure AC-random is a fine alternative, and there are
> many other packages on Hackage as well, including cryptographic
> strength ones (crypto-api, intel-aes, etc).

I tried AC-Random, and see that it suggests just different classes, 
with different operations. So that all the Random instances in my 
application must be re-programmed. So is the consequence of being out of 
Standard, and out of GHC !

------
Sergei
mechvel <at> botik.ru
Simon Peyton-Jones | 2 Jan 13:38 2012
Picon

RE: Records in Haskell

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.

·        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:gershomb <at> gmail.com]
Sent: 31 December 2011 19:12
To: Simon Peyton-Jones
Cc: Greg Weber; glasgow-haskell-users <at> 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 <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Brent Yorgey | 2 Jan 14:07 2012

Re: ghc-cabal-Random

On Mon, Jan 02, 2012 at 04:35:25PM +0400, Serge D. Mechveliani wrote:
> On Sun, Jan 01, 2012 at 07:51:39AM -0500, Ryan Newton wrote:
> > I haven't entirely followed this and I see that it's been split over
> > multiple threads.
> > 
> > Did "cabal install random" actually fail for you under
> > ghc-7.4.0.20111219?  If so I'd love to know about it as the maintainer
> > of the "random" package.  (It seems to work for me for
> > random-1.0.1.1.)
> 
> "cabal install random" 
> cannot run in my situation, because I have not  cabal  usable in the 
> command line (I only have the Cabal library in the place where the   
> ghc-7.4.0.20111219 libraries are installed).
> My idea is that having installed GHC, I use the GHC packages and, probably, 
> do not need to install Cabal (why complicate things?, why force a DoCon 
> user to install extra software?). 

It is not really "forcing them to install extra software".  Pretty
much everyone these days will already have the Haskell Platform, which
comes with cabal-install anyway.

-Brent
Ryan Newton | 2 Jan 17:37 2012
Picon

Re: ghc-cabal-Random

Just FYI it is possible to use OLD "cabal" binaries with the new GHC 7.4.  No need to necessarily rebuild cabal-install with GHC 7.4.

I do this all the time.  Perhaps it's a bad practice ;-).

  -Ryan

On Mon, Jan 2, 2012 at 8:07 AM, Brent Yorgey <byorgey <at> seas.upenn.edu> wrote:
On Mon, Jan 02, 2012 at 04:35:25PM +0400, Serge D. Mechveliani wrote:
> On Sun, Jan 01, 2012 at 07:51:39AM -0500, Ryan Newton wrote:
> > I haven't entirely followed this and I see that it's been split over
> > multiple threads.
> >
> > Did "cabal install random" actually fail for you under
> > ghc-7.4.0.20111219?  If so I'd love to know about it as the maintainer
> > of the "random" package.  (It seems to work for me for
> > random-1.0.1.1.)
>
> "cabal install random"
> cannot run in my situation, because I have not  cabal  usable in the
> command line (I only have the Cabal library in the place where the
> ghc-7.4.0.20111219 libraries are installed).
> My idea is that having installed GHC, I use the GHC packages and, probably,
> do not need to install Cabal (why complicate things?, why force a DoCon
> user to install extra software?).

It is not really "forcing them to install extra software".  Pretty
much everyone these days will already have the Haskell Platform, which
comes with cabal-install anyway.

-Brent

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Gmane