[Haskell] ANNOUNCE: Haskell Communities & Activities Report (9th ed., November 2005)
On behalf of the many, many contributors, I am pleased to announce that the Haskell Communities and Activities Report (9th edition, November 2005) http://www.haskell.org/communities/ is now available from the Haskell Communities home page in several formats: PDF, for screenreading as well as printing, HTML, for those of you who prefer not to deal with plugins or external viewers, and PostScript, for those of you who have nice quick printers that do not grok PDF. Many thanks go to all the people that contributed to this report, both directly, by sending in descriptions, and indirectly, by doing all the interesting things that are reported. I hope you will find it as interesting a read as we did. If you haven't encountered the Haskell Communities and Activities Reports before, you may like to know that the first of these reports was published in November 2001. Their goal is to improve the communication between the increasingly diverse groups, projects and individuals working on, with, or inspired by Haskell. The idea behind these reports is simple: Every six months, a call goes out to all of you enjoying Haskell to contribute brief summaries of your own area of work. Many of you respond (eagerly, unprompted, and well in time for the actual deadline ;) ) to the call. The editor collects all the contributions into a single report and feeds that back to the community. When we try for the next update, six months from now, you might want to report on your own work, project, research area or group as well. So, please put the following into your diaries now: End of April 2006: target deadline for contributions to the May 2006 edition of the HC&A Report Unfortunately, many Haskellers working on interesting projects are so busy with their work that they seem to have lost the time to follow the Haskell related mailing lists and newsgroups, and have trouble even finding time to report on their work. If you are a member, user or friend of a project so burdened, please find someone willing to make time to report and ask them to `register' with the editor for a simple e-mail reminder in the middle of April (you could point me to them as well, and we can then politely ask if they want to contribute, but it might work better if you do the initial asking). Of course, they will still have to find the ten to fifteen minutes to draw up their report, but maybe we can increase our coverage of all that is going on in the community. Feel free to circulate this announcement further in order to reach people who might otherwise not see it. Enjoy! Andres Loeh -- Haskell Communities and Activities Report (http://haskell.org/communities) ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Records (was Re: [Haskell] Improvements to GHC)
On Sun, Nov 20, 2005 at 02:09:04PM -0500, David Roundy wrote:
> > [x,y,z]
> [...]
> > R { field1 = x, field2 = y, field3 = z }
> >
> > I think this is very consistent.
>
> I see, you're right that it's consistent, but I still don't like the use of
> '=' in this scenario.
I understand you. I had the same feelings some time ago, I even have
them today to some degree. At least consistency helps to get used to it.
Best regards
Tomasz
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: Records (was Re: [Haskell] Improvements to GHC)
On Sun, Nov 20, 2005 at 03:43:08PM +0100, Tomasz Zielonka wrote:
> On Sun, Nov 20, 2005 at 08:54:35AM -0500, David Roundy wrote:
> > As an aside, what's responsible for the insanity of pattern matching
> > record fields being backwards? I'd bar = b to bind b to bar, not the
> > other way around... why should record pattern matching use '=' in a
> > manner opposite from the rest of Haskell?
>
> It just mimics the way (record) values are constructed, as in all
> pattern matching in Haskell. You can put a pattern variable everywhere
> you could put a value in a corresponding constructing expression. For
> example, all these "terms" can be used both as an expression and a
> pattern. In the first case x, y, z are expressions, in the second they
> are patterns.
>
> [x,y,z]
[...]
> R { field1 = x, field2 = y, field3 = z }
>
> I think this is very consistent.
I see, you're right that it's consistent, but I still don't like the use of
'=' in this scenario. I don't really have a better idea, but something
like
R { field1 -:- x, field2 -:- y, field3 -:- z }
(where I don't like the -:- but can't think of anything better off the top
of my head) might be more intuitive, since '=' means bind the value on the
right to the name on the left everywhere else in haskell, but in record
syntax it's part of a constructor. It'd be nice to reuse an existing
haskell syntax ("->" ?), but I can't think of one that would fit. One
could perhaps use :=, which at least looks like a constructor rather than a
binding...
--
David Roundy
http://www.darcs.net
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: Records (was Re: [Haskell] Improvements to GHC)
Am Sonntag, 20. November 2005 13:40 schrieb Georg Martius: > [...] > 4. Getters for multiple data types with a common field. Do we need this? Couldn't this have ugly consequences? Say, I have a datatype with a field of a certain name and another datatype with a field of the same name. Having a single getter for both fields might be bad if the fields mean different things. For example, a "name" and a "name" can be quite different things. > [...] Best wishes, Wolfgang ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Records (was Re: [Haskell] Improvements to GHC)
On Sun, Nov 20, 2005 at 08:54:35AM -0500, David Roundy wrote:
> As an aside, what's responsible for the insanity of pattern matching record
> fields being backwards? I'd bar = b to bind b to bar, not the other way
> around... why should record pattern matching use '=' in a manner opposite
> from the rest of Haskell?
It just mimics the way (record) values are constructed, as in all
pattern matching in Haskell. You can put a pattern variable everywhere
you could put a value in a corresponding constructing expression. For
example, all these "terms" can be used both as an expression and a
pattern. In the first case x, y, z are expressions, in the second they
are patterns.
[x,y,z]
(x:y:z)
(x,(y,z))
(C x y, D z)
R { field1 = x, field2 = y, field3 = z }
I think this is very consistent.
Best regards
Tomasz
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: Records (was Re: [Haskell] Improvements to GHC)
On Sun, Nov 20, 2005 at 01:40:01PM +0100, Georg Martius wrote:
> 7. Unordered records.
> I don' t understand it.
It's just that I'd like to be able to write:
data FooBar = FooBar { foo, bar :: String }
such that you can't write
let f = FooBar "a" "b"
but instead are forced to write
let f = FooBar { foo = "a", bar = "b" }
More importantly when you pattern match, you couldn't write
case f of FooBar _ b -> b
but instead would have to write
case f of FooBar { bar = b } -> b
The reason being that I'd like to be able to export constructors from a
module in such a way that I can later reorder or add or remove field from
that record without breaking any pattern-matching code, and if I'm only
reordering the fields, I shouldn't break any constructor code either.
As an aside, what's responsible for the insanity of pattern matching record
fields being backwards? I'd bar = b to bind b to bar, not the other way
around... why should record pattern matching use '=' in a manner opposite
from the rest of Haskell?
--
David Roundy
http://www.darcs.net
signature.asc
Description: Digital signature
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Records (was Re: [Haskell] Improvements to GHC)
Hi folks,
rather than discussing about which operator symbol to use for record access,
which is really a question of personal taste we should try to seriously
discuss the proposals and get to a solutions!
We all seem to agree that records are broken in Haskell. In order to fix that
we need a new and most probably incompatible solution. However, I think the
new solution should go in a new version of the Haskell standard (among other
things :-) ).
I would strongly disadvice to try to stick with the old system and improve it.
Just because there are lots of different opinions we should still try to find
a reasonable solution soon.
Desite the minor problem of '.' that dominated the discussion so far, what are
the REAL offences against Simons proposal [1] (denoted as SR in the
following)?
To me it sounds like a very reasonable starting point.
Which other proposals exist?
I quote David Roundy's list of problems [2] with a short annotation whether SR
solves them:
1. The field namespace issue.
solved by not sharing the same namespace with functions
2. Multi-constructor getters, ideally as a function.
not solved. only possible by hand
- As stated by Wolfgang Jeltsch [3] another datatype design might be
better
- I can image a solution is within SR example:
>data Decl = DeclType { name :: String, ... }
> | DeclData { name :: String, ... }
> | ...
> d :: Decl
in addition to
> d.DeclType.name
> d.DeclData.name
we provide (only if save, see 3.)
> d.name
3. "Safe" getters for multi-constructor data types.
not supported as it is
- with the above suggestion it could be possible (don't know if
desireable)
4. Getters for multiple data types with a common field.
- solved with contrains
> getx :: (r <: { x :: a }) => r -> a
5. Setters as functions.
doesn't seem to be supported, or I don't see it right now.
6. Anonymous records.
Supported
7. Unordered records.
I don' t understand it.
points added from me:
8. Subtyping
Supported, quite nicely
9. higher order versions for selecting, updateing ... [4]
not supported
seems important to me, any solutions?
Regards
Georg
[1] http://research.microsoft.com/~simonpj/Haskell/records.html
[2] http://www.haskell.org//pipermail/haskell-cafe/2005-November/012226.html
[3] http://www.haskell.org//pipermail/haskell-cafe/2005-November/012227.html
[4] http://www.haskell.org//pipermail/haskell-cafe/2005-November/012162.html
Am Donnerstag, 17. November 2005 19:08 schrieb Dimitry Golubovsky:
> Sebastian Sylvan wrote:
> >Personally I think that the dot is way to good of a symbol to be
> >"wasted" on function composition. I mean, how often do you really use
> >function composition in a way which doesn't obfuscate your code? I use
> >($) way more often than (.). Some people do use it more often than I
>
> I found it useful to use (mainly for debugging purposes)
>
> mapM (putStrLn . show)
>
> if I want to print its elements each on a new line.
>
> --
> Dimitry Golubovsky
>
> Anywhere on the Web
--
Georg Martius, Tel: (+49 34297) 89434
--- http://www.flexman.homeip.net -
pgpuroWJrVcBG.pgp
Description: PGP signature
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
