Re: [Haskell-cafe] Why were datatype contexts removed instead of fixing them?
Dan Doel wrote: I don't really think they're worth saving in general, though. I haven't missed them, at least. Maybe you haven't :-) My code is cluttered with redundant type contexts - I can't think of a similar redundancy in any other language. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Diving into the records swamp (possible GSoC project)
Hi, I am hoping to do a GSoC project this year working on GHC, and have been pointed in the direction of the records issue (in particular, the desire to overload field names). This has been discussed on-and-off for years, and while there are lots of ideas [1], little has been implemented in GHC itself. The plan would be to implement a solution to the narrow issue of overloaded field names, along the lines of Simon PJ's SORF proposal (on the wiki). This would provide a basis for experimentation with first-class record types. While there are still design issues to resolve, the broad plan is clear and I'm confident it can be implemented in a summer and without overly restricting future record system designs. Does this sound like a reasonable strategy? I'd appreciate comments and criticism, although arguing about the details of the design should perhaps wait. (A little about me: I'm a PhD student working on type inference for Haskell and dependent types, with about four years' Haskell experience including work on big type-system related projects. I am familiar with the theory behind GHC, but I haven't worked on the code before.) Thanks, Adam Gundry [1] http://hackage.haskell.org/trac/ghc/wiki/Records ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Diving into the records swamp (possible GSoC project)
Adam Gundry adam.gundry at strath.ac.uk writes: Hi, I am hoping to do a GSoC project this year working on GHC, and have been pointed in the direction of the records issue (in particular, the desire to overload field names). Heck you're brave! Are you sure you want to step into the aggravated issue of changing the dot operator from being function composition? Are you going to use explicit type application? (The type of get is very odd.) Are you going to handle type-changing update? The plan would be to implement a solution to the narrow issue of overloaded field names, along the lines of Simon PJ's SORF proposal So has someone decided that SORF is the best of those many proposals? I guess it's because it comes with the SPJ ring of confidence? Before jumping to that decision, I suggest you/your sponsors consider the implications of the NewAxioms stuff in GHC Head [2] to support 'controlled' overlap. I think overlap is the only extra feature needed to support the DORF or TPDORF proposals. (Plus the syntactic sugar already outlined in that proposal.) This would provide a basis for experimentation with first-class record types. No: first-class record types needs much more than the SORF proposal. In particular it needs a way to extend an existing record to make a new one; project a subset of fields; and most important to merge two records with some fields in common avoiding doubling-up those fields (aka Relational Natural Join). The DORF/TPDORF proposals are aimed much better as a step towards first- class record types. [IMO **] Oleg/Ralf's HList paper covers all the ground for first-class records. It depends heavily on overlaps, which is why the NewAxioms stuff would work in really well. AntC [2] http://hackage.haskell.org/trac/ghc/wiki/NewAxioms [**] Declaration of interest: I wrote the DORF and TPDORF proposals. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Diving into the records swamp (possible GSoC project)
Slightly, off-topic, but just because I've been spending my last couple of days trying to shoehorn an inheritance-based subytping type system into Haskell (without full OO-power, so no methods or mutable state.) Oleg/Ralf's HList paper covers all the ground for first-class records. It depends heavily on overlaps, which is why the NewAxioms stuff would work in really well. I've been kicking around the idea of re-implementing HList on the basis of the new DataKinds [1] extension. I don't know if there'd be much of a need for that, though. More generally, I'm wondering what can be done on extensible records and inheritance-based type systems with FC-pro under one's belt… Here's one thing I don't like about the current way HList-based extensible record are represented (and used in OOHaskell [2]): the access time is linear in the number of records a certain type has. Somehow just the thought of reorder the records in your constructors to make your program go faster makes me cringe a little. Oleg and Ralf do hint at implementing some binary search tree based technique to alleviate the problem, but I have no idea how to go about it, except extending the compiler. ~ A. References [1] Yorgey, Brent A., et al. Giving Haskell a promotion. Proceedings of the 8th ACM SIGPLAN workshop on Types in language design and implementation. ACM, 2012. [2] Kiselyov, Oleg, and Ralf Lämmel. Haskell's overlooked object system. arXiv preprint cs/0509027 (2005). signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Diving into the records swamp (possible GSoC project)
Hi Aleksandar, This library for extensible records does use -XDataKinds: http://hackage.haskell.org/package/vinyl. It doesn't have as many definitions as HList, but that might be because more recent extensions are more powerful. Many other libraries are listed http://www.haskell.org/haskellwiki/Extensible_record#Libraries_on_hackage. I don't know of a comparison between all of them. -- Adam ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Diving into the records swamp (possible GSoC project)
Hi Adam, very nice idea. As the others, I'm curious why you chose to implement SORF in favor of the other ideas? I just read the SORF proposal, and I'm a bit concerned about what error messages would GHC issue when someone would type incorrect code involving such records. Currently Haskell's error messages already pose a barrier for newcomers (like No instance for (Num (a - a))), and if records are converted into those very complicated `Has` instances, type errors would be probably undecipherable even for moderate skilled Haskell users. Considering that records are a basic feature of Haskell and something that people with OOP background are familiar with, this could result in a feature that would without doubts deter many (if not most) newcomers. So do you think it would be possible to implement it in such a way that users get sensible type error messages? Best regards, Petr 2013/4/26 Adam Gundry adam.gun...@strath.ac.uk Hi, I am hoping to do a GSoC project this year working on GHC, and have been pointed in the direction of the records issue (in particular, the desire to overload field names). This has been discussed on-and-off for years, and while there are lots of ideas [1], little has been implemented in GHC itself. The plan would be to implement a solution to the narrow issue of overloaded field names, along the lines of Simon PJ's SORF proposal (on the wiki). This would provide a basis for experimentation with first-class record types. While there are still design issues to resolve, the broad plan is clear and I'm confident it can be implemented in a summer and without overly restricting future record system designs. Does this sound like a reasonable strategy? I'd appreciate comments and criticism, although arguing about the details of the design should perhaps wait. (A little about me: I'm a PhD student working on type inference for Haskell and dependent types, with about four years' Haskell experience including work on big type-system related projects. I am familiar with the theory behind GHC, but I haven't worked on the code before.) Thanks, Adam Gundry [1] http://hackage.haskell.org/trac/ghc/wiki/Records ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why were datatype contexts removed instead of fixing them?
That is because every other language conflates the notion of a class with a vtable smashed into every inhabitant of the class where everything has to be defined together in one monolithic definition. You also can't write sensible Monads in those languages (Where does return go?) or retroactively define new classes and make existing types instances of it without controlling the source code to every instance. On Fri, Apr 26, 2013 at 4:02 AM, Guy guytsalmave...@yahoo.com wrote: Dan Doel wrote: I don't really think they're worth saving in general, though. I haven't missed them, at least. Maybe you haven't :-) My code is cluttered with redundant type contexts - I can't think of a similar redundancy in any other language. __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Diving into the records swamp (possible GSoC project)
Hi Adam,
Since we have already had *very* long discussions on this topic, I'm
worried that I might open a can of worms be weighing in here, but the issue
is important enough to me that I will do so regardless.
Instead of endorsing one of the listed proposals directly, I will emphasize
the problem, so we don't lose sight of it. The problem people run into *in
practice* and complain about in blog posts, on Google+, or privately when
we chat about Haskell over beer, is that they would like to write a record
definition like this one:
data Employee = Employee { id :: Int, name :: String }
printId :: Employee - IO ()
printId emp = print $ id emp
but since that doesn't work well in Haskell today due to name collisions,
the best practice today is to instead write something like:
data Employee = Employee { employeeId :: Int, employeeName :: String }
printId :: Employee - IO ()
printId emp = print $ employeeId emp
The downsides of the latter have been discussed elsewhere, but briefly they
are:
* Overly verbose when there's no ambiguity.
* Ad-hoc prefix is hard to predict (i.e. sometimes abbreviations of the
data type name are used).
The important requirement, which might seem a bit obvious, is that any
solution to this problem better not be *even more* verbose than the second
code snippet above. If I understand the SORF proposal correctly, you would
write:
data Employee = Employee { id :: Int, name :: String }
printId :: Employee - IO ()
printId emp = print $ emp.id
Is that correct or do you have to replace 'Employee' with 'r { id :: Int }'
in the type signature of 'printId'?
The discussions about an overhauled record system also involve lots of talk
about record sub-typing, extensible records, and other more advanced
features. I'd like to point out that there doesn't seem to be a great
demand for these features. They might be nice-to-haves or might fall
out naturally from a solution to the namespacing problem above, but they
are in fact not needed to solve the common problem people have with the
Haskell record system.
Cheers,
Johan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] [ANN] Hac Phi 2013
Hac Phi 2013, a Haskell hackathon/get-together, will be held June 7-9 at the University of Pennsylvania in Philadelphia. The hackathon will officially kick off at 2:30 Friday afternoon, and go until 5pm on Sunday (with breaks for sleep, of course). Last year's Hac Phi was a lot of fun, drawing more than 30 Haskellers, and many people have already expressed interest in coming back this year. Everyone is welcome - you do not have to be a Haskell guru. Helping hack on someone else's project could be a great way to increase your Haskell-fu. If you plan on coming, please officially register [1]. Registration, travel, lodging and many other details can be found on the Hac Phi wiki [2]. This year, we are making a public list of attendees' names and nicks - please let us know if you'd prefer not to be listed when you register. We're also looking for a few people interested in giving short (15-20 min.) talks, probably on Saturday afternoon. Anything of interest to the Haskell community is fair game - a project you've been working on, a paper, a quick tutorial. If you'd like to give a talk, add it on the wiki [3]. Hope to see you in Philadelphia! - The Hac Phi team Brent Yorgey (byorgey) Daniel Wagner (dmwit) Chris Casinghino (ccasin) [1] http://www.haskell.org/haskellwiki/Hac_%CF%86/Register [2] http://www.haskell.org/haskellwiki/Hac_%CF%86 [3] http://www.haskell.org/haskellwiki/Hac_%CF%86/Talks ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Looking for portable Haskell or Haskell like language
Hi. I've got this work situation where I've got to do all my work on /ancient/ RHEL5 systems, with funky software configurations, and no root privileges. I wanted to install GHC in my local account, but the gnu libc version is so old (2.5!) that I can't even get the binary packages to install. I've had success installing some other simple functional languages (like CLISP) on these same systems, so I was wondering if there was perhaps another language very similar to Haskell (but presumably simpler) with a super portable compiler easily built from source, which I could try. I'll admit -- I haven't tried the HUGS compiler for Haskell. The quick description didn't make it sound much more portable than GHC, but I guess I could try it if I heard some good reasons to think it would be more portable. -- frigidcode.com signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Looking for portable Haskell or Haskell like language
Hugs98, or failing that, the original Hugs, will almost certainly be easier to compile for your RHEL5 system, but do note that it's not a compiler in the sense that it makes standalone binaries. Given your constraints, it's probably the best choice. Tommy On Apr 26, 2013, at 22:21 , Christopher Howard christopher.how...@frigidcode.com wrote: Hi. I've got this work situation where I've got to do all my work on /ancient/ RHEL5 systems, with funky software configurations, and no root privileges. I wanted to install GHC in my local account, but the gnu libc version is so old (2.5!) that I can't even get the binary packages to install. I've had success installing some other simple functional languages (like CLISP) on these same systems, so I was wondering if there was perhaps another language very similar to Haskell (but presumably simpler) with a super portable compiler easily built from source, which I could try. I'll admit -- I haven't tried the HUGS compiler for Haskell. The quick description didn't make it sound much more portable than GHC, but I guess I could try it if I heard some good reasons to think it would be more portable. -- frigidcode.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
