On 11/28/05, Wolfgang Jeltsch <[EMAIL PROTECTED]> wrote:
>
> As I already said, this approach may lead to mixing different concepts.
> Example:
>
> data Person = Person { name :: String }
> data File = File { name :: String }
>
> A field identifier has to be seen in context of the d
Am Sonntag, 27. November 2005 22:34 schrieb John Lask:
> correct me if I am wrong but ...
>
> 1. Field namespaces: solved by using type classes
>
> This would imply that the type of the field is the same between all
> instances of this common field.
>
> Under this proposal two fields with s
> It actually sounds a lot like pattern guards, since you're suggesting this
> sugar could be applied to any sort of object? So your desugarer would
> allow a function like
>
> islong :: [a] -> Bool
> islong {length = l} = l > 10
this looks like a hack that only works for one-argument functions
On Sun, Nov 27, 2005 at 08:47:54PM +, Rob Ennals wrote:
> On 11/23/05, David Roundy <[EMAIL PROTECTED]> wrote:
> > > 3. "Safe" getters for multi-constructor data types: ditto
> >
> > I think either you misunderstood my meaning by "safe", or I misunderstood
> > your paper. I meant that if I wri
:: String }, { name :: Int }
John
- Original Message -
From: "Rob Ennals" <[EMAIL PROTECTED]>
To: "Johannes Waldmann" <[EMAIL PROTECTED]>
Cc:
Sent: Wednesday, November 23, 2005 1:32 AM
Subject: Re: Records (was Re: [Haskell] Improvements to GHC)
On 11/23/05, David Roundy <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 22, 2005 at 02:32:47PM +, Rob Ennals wrote:
[snip]
> > 1. Field namespaces: solved by using type classes
>
> But these classes are required to be manually specified, right? This avoids
> the problem of proliferation of typeclas
you can always do:
case (field1 record,field2 record, field3 record ...) of
(pat1,pat2,pat3) ->
_ ->
Which lets you pattern match on fields independantly of their
position in the record.
Keean.
David Roundy wrote:
On Wed, Nov 23, 2005 at 02:58:43PM +0100, Wolfgang Jeltsch
On Wed, Nov 23, 2005 at 02:58:43PM +0100, Wolfgang Jeltsch wrote:
> Am Mittwoch, 23. November 2005 14:22 schrieb David Roundy:
> > On Tue, Nov 22, 2005 at 02:32:47PM +, Rob Ennals wrote:
> > [...]
>
> > > 7. Unordered records: yep (if I understand the problem correctly)
...
> You can just omit
Hello David,
Wednesday, November 23, 2005, 4:22:47 PM, you wrote:
>> 7. Unordered records: yep (if I understand the problem correctly)
DR> I don't think you understood correctly. What I'd like (and this is another
DR> one of those David-specific issues--I've never heard anyone else complain
DR>
Am Mittwoch, 23. November 2005 14:22 schrieb David Roundy:
> On Tue, Nov 22, 2005 at 02:32:47PM +, Rob Ennals wrote:
> [...]
> > 7. Unordered records: yep (if I understand the problem correctly)
>
> I don't think you understood correctly. What I'd like (and this is another
> one of those Davi
David Roundy <[EMAIL PROTECTED]> writes:
> > 7. Unordered records: yep (if I understand the problem correctly)
>
> I don't think you understood correctly. What I'd like (and this is another
> one of those David-specific issues--I've never heard anyone else complain
> about this) is to be able to
On Tue, Nov 22, 2005 at 02:32:47PM +, Rob Ennals wrote:
> Since discussion has returned to records, it might be useful for me to
> post a link to a proposal that I knocked up a while back when this
> topic came up a few years ago:
>
> http://www.cambridge.intel-research.net/~rennals/records.pd
Hi guys,
Since discussion has returned to records, it might be useful for me to
post a link to a proposal that I knocked up a while back when this
topic came up a few years ago:
http://www.cambridge.intel-research.net/~rennals/records.pdf
The basic idea is to keep records largely as they are, bu
My 2 cents:
John Lask (Thu, Nov 17, 2005 at 08:57:52AM +1030):
> I would like to sound out the Haskell community on what the feeling are
> most desirable to improve the "commerciality" (i.e. its general use) of ghc
> and Haskell in general (as distinct from feature set)
>
> 3) Macro / condition
On records in Haskell - can we start by formulating requirements
(design goals). What do we want from a record system,
and what are non-goals.
Some of the proposals here sound like records should be more like
objects (with some kind of inheritance). Do we really want this?
We already have inherita
2005/11/20, Georg Martius <[EMAIL PROTECTED]>:
> 7. Unordered records.
> I don' t understand it.
>
Consider this example:
data DataT = DataT (Int,String) (String,String)
if we treat records as tuples with labels, then we could write:
data DataR = DataR {tel::Int,addr::String} {zip::Stri
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 th
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
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...
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
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 th
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
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
On Thu, Nov 17, 2005 at 08:46:50AM -0500, David Roundy wrote:
> On Thu, Nov 17, 2005 at 10:03:00AM +0100, Ketil Malde wrote:
> > >2) Improving Haskell support for records.
> >
> > Right - the problem is that nobody seems to agree exactly how to do
> > this. I like the fact that record access lo
On Thu, 2005-11-17 at 22:11 +, Claus Reinke wrote:
> > > To solve this problem I just made them all instances of a class with a
> > > gameId function. Still, not ideal.
> >
> > That gives you a getter function but you would then need an extra setter
> > function.
>
> But there is no need to
> > To solve this problem I just made them all instances of a class with a
> > gameId function. Still, not ideal.
>
> That gives you a getter function but you would then need an extra setter
> function.
But there is no need to have two names for each label when you
only want to talk about two w
On 11/17/05, Duncan Coutts <[EMAIL PROTECTED]
> wrote:
That gives you a getter function but you would then need an extra setterfunction.
Of course, but that offended me less -- I spent much more time getting things than setting them. YMMV.
Fraser.
__
Don't get me started, please :-). I tried making each field a
separate class but then needed to compose records of difference field
instances which led to HList which led to GHC eating up all my memory
and crashing, etc.
I can see where you are going but if I have 250 records with shared
On Thu, 2005-11-17 at 15:12 +0100, Fraser Wilson wrote:
>
>
> On 11/17/05, Joel Reymont <[EMAIL PROTECTED]> wrote:
> I vote for a separate namespace for record access functions.
>
> I agree, but ...
>
>
> My users now have to deal with tiGameID, blahBlahGameID, etc.
> a
On 11/17/05, Joel Reymont <[EMAIL PROTECTED]> wrote:
I vote for a separate namespace for record access functions.
I agree, but ...
My users now have to deal with tiGameID, blahBlahGameID, etc. andthey are all the same.
To solve this problem I just made them all instances of a class with a gameId f
I vote for a separate namespace for record access functions. To me a
gameID in one record is always the same gameID in another record and
having to add prefixes to each access field sucks when records number
in the hundreds :-(.
My users now have to deal with tiGameID, blahBlahGameID, etc.
On Thu, Nov 17, 2005 at 10:03:00AM +0100, Ketil Malde wrote:
> >2) Improving Haskell support for records.
>
> Right - the problem is that nobody seems to agree exactly how to do
> this. I like the fact that record access looks like (is?) a simple
> function application, and conversely, dislike
John Lask wrote:
I would like to sound out the Haskell community on what the feeling
are most desirable to improve the "commerciality" (i.e. its general
use) of ghc and Haskell in general (as distinct from feature set)
I think more standardization on an extended feature set would be nice.
I
(Sorry about replying at the top. This web interface doesn't seem to want to let me do otherwise.)
I was just reading Wadler's article "How enterprises use functional languages, and why they don't" when your message came through. A definite "must read" for anyone wanting to promote the use of Has
I would like to sound out the Haskell community on what the feeling are most
desirable to improve the "commerciality" (i.e. its general use) of ghc and
Haskell in general (as distinct from feature set)
my pick would be to
1) GHC runtime to be dynamically loaded.
Enable the ghc runtime sys
35 matches
Mail list logo
