On 11/09/2003, at 9:46 PM, Simon Marlow wrote:
I know that some of these problems can be addressed, at least in
part, by careful use of Makefiles, {-# custom pragmas #-}, and perhaps
by committing to a single tool solution. But I'd like to propose
a new approach that eliminates some of the
| We at GHC HQ agree, and for future extensions we'll move to
| using separate options to enable them rather than lumping
| everything into -fglasgow-exts. This is starting to happen
| already: we have -farrows, -fwith, -fffi (currently implied
| by -fglasgow-exts).
|
| Of course, if we
Karl-Filip Faxen wrote:
| Yes, things are clearer and I rather like the idea.
| The only thorny issue is that the update function for
| field 'wibble' is formed from but not equal to the
| field name itself.
This could be solved by having an abstract type Field
thusly (*):
type Field r a
Karl-Filip Faxen wrote:
| Yes, things are clearer and I rather like the idea.
| The only thorny issue is that the update function for
| field 'wibble' is formed from but not equal to the
| field name itself.
This could be solved by having an abstract type Field
thusly (*):
[snip]
Mark Jones writes:
As a solution to that problem, the many-command-line-options
scheme described seems quite poor! It's far too tool specific,
not particularly scalable, and somewhat troublesome from a software
engineering perspective. We're not talking about a choice between
two points
Mark P Jones writes an interesting suggestion:
...
Hmm, ok, but perhaps you're worrying now about having to enumerate
a verbose list of language features at the top of each module you
write. Isn't that going to detract from readability? This is where
the module system wins big! Just
hello,
it's a pity i don't know how to get my mailer to reply to a few messages
at once :-)
i also like mark's idea. i know that ghc can alredy achive some of that
with the OPTION pragmas, but i think it is nice if we can reuse what is
already in the language rather than making programmers
On Wednesday 10 September 2003 04:54, Andrew J Bromage wrote:
G'day all.
On Tue, Sep 09, 2003 at 02:52:48PM +0200, Johannes Waldmann wrote:
but this might be an issue for others, who have to maintain legacy
code.
You know a language has made it when we're talking about legacy code.
On
Iavor Diatchki [EMAIL PROTECTED] writes:
Adrian Hey wrote:
IMHO preserving the status quo wrt records should be low priority.
It really doesn't bother me much if new (useful) language features break
existing code. I think this is a better option than permanently
impoverishing the language
What about ad-hoc overloading (allowing visible entities to share names,
as long as they can be distinugished by their typing).
This is orthogonal to the proper records issue (?)
but it might improve the current situtation (?)
and it seems backward-compatible (?)
Of course this would need an
Johannes Waldmann [EMAIL PROTECTED] writes:
What about ad-hoc overloading (allowing visible entities to share names,
as long as they can be distinugished by their typing).
This is orthogonal to the proper records issue (?)
but it might improve the current situtation (?)
and it seems
I'd like to add a voice of dissent here.
I would much prefer it if Haskell didn't add specific extensible records
support - even if it could be done without breaking backwards compatibility.
This is because I believe that extensible records encourage poor style. They
encourage people to
Hi!
So in summary, here is my proposal:
No specific extensible records system.
Define record update to be a function just like record selection is.
Allow these functions to be in type classes.
I do not understand the second and third point: As I understand your
idea, record selectors
Hi!
So in summary, here is my proposal:
No specific extensible records system.
Define record update to be a function just like record selection is.
Allow these functions to be in type classes.
I do not understand the second and third point: As I understand your
idea, record
Yes, things are clearer and I rather like the idea. The only
thorny issue is that the update function for field 'wibble'
is formed from but not equal to the field name itself.
In short, the magic thing would be in the 'deriving' clause:
If the data type declares fields with names x_1, ..., x_n
Yes, things are clearer and I rather like the idea. The only
thorny issue is that the update function for field 'wibble'
is formed from but not equal to the field name itself.
In short, the magic thing would be in the 'deriving' clause:
If the data type declares fields with names x_1,
On Wed, 10 Sep 2003 10:26:04 +0100, Robert Ennals
[EMAIL PROTECTED] wrote:
class Wibble a where
wibble :: a - Int
wobble :: a - String
set_wibble :: Int - a - a
set_wobble :: String - a - a
data Foo = Foo {wibble :: Int, wobble :: String}
deriving Wibble
The Wibble
Robert Ennals [EMAIL PROTECTED] writes:
[Heavy snippage, hopefully preserving semantics]
data Foo = Foo {wibble :: Int, wobble :: String}
deriving Wibble
We could imagine the definition of Foo being automatically desugared to the
following:
data Foo = Foo Int String
instance
[EMAIL PROTECTED] (Ketil Z. Malde) writes:
Robert Ennals [EMAIL PROTECTED] writes:
BTW, isn't this more or less exactly what Simon suggested (at the very
top of this thread)?
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
On Wed, Sep 10, 2003 at 02:27:33PM +0200, Ketil Z. Malde wrote:
Shouldn't that rather be:
class HasWibble a where
wibble :: a - Int
set_wibble :: a - Int - a
class HasWobble a where ...
Or even:
class HasWibble a b | a - b where
wibble :: a - b
[EMAIL PROTECTED] (Ketil Z. Malde) writes:
Robert Ennals [EMAIL PROTECTED] writes:
BTW, isn't this more or less exactly what Simon suggested (at the very
top of this thread)?
Not really, no.
I assume you mean the system suggested by Peter Thieman, outlined in the
initial email by
On Wed, Sep 10, 2003 at 02:27:33PM +0200, Ketil Z. Malde wrote:
Shouldn't that rather be:
class HasWibble a where
wibble :: a - Int
set_wibble :: a - Int - a
class HasWobble a where ...
Or even:
class HasWibble a b | a - b where
wibble ::
Simon Marlow [EMAIL PROTECTED] writes:
Of course, if we change the language that is implied by -fglasgow-exts now,
we risk breaking old code :-) Would folk prefer existing syntax extensions
be moved into their own flags, or left in -fglasgow-exts for now? I'm
thinking of:
- implicit
I agree with Malcolm, with the possible addition of:
keep -fglasgow-exts as it is (or, even, perhaps continue making it the
add all extensions keyword). also have -fffi, -farrows, -fth, etc.
but also have, -fnoth and -fnoffi. that way, if a lot of us have code
that uses all the extensions
On Wednesday 10 September 2003 07:22 am, Hal Daume III wrote:
I agree with Malcolm, with the possible addition of:
keep -fglasgow-exts as it is (or, even, perhaps continue making it the
add all extensions keyword). also have -fffi, -farrows, -fth, etc.
but also have, -fnoth and -fnoffi.
On Wednesday 10 September 2003 10:51, Ketil Z. Malde wrote:
And now, let's just screw any backwards compatibility, and re-engineer
the records system¹.
I don't need any of this, and it makes my life harder. Are you guys
going to keep at it, until I regret ever using Haskell?
I can't speak
At 13:13 10/09/03 +0100, Simon Marlow wrote:
Of course, if we change the language that is implied by -fglasgow-exts
now, we risk breaking old code :-) Would folk prefer existing syntax
extensions be moved into their own flags, or left in -fglasgow-exts for
now? I'm thinking of:
- implicit
In article [EMAIL PROTECTED],
Graham Klyne [EMAIL PROTECTED] wrote:
- implicit parameters
- template haskell
- FFI
- rank-N polymorphism (forall keyword)
- recursive 'do' (mdo keyword)
...
Where do multi-parameter classes fit in?
I think some of the type extensions such as
On Tue, 9 Sep 2003, Adrian Hey wrote:
I rarely use named fields in my Haskell progs with Haskell as it is ...
but you sure agree records are useful for collecting heterogenous data?
for example, see data DynFlags here:
Hello,
I may be wrong but can't we keep old records and add new ones (as
proposed in the First Class Modules paper)
with a different syntax?
Ussual records and extensible records are both usefull, in different
cases.
Best regards,
Nicolas Oury
Le mardi, 9 sep 2003, Ã 14:52 Europe/Paris,
On Tuesday 09 September 2003 13:52, Johannes Waldmann wrote:
On Tue, 9 Sep 2003, Adrian Hey wrote:
I rarely use named fields in my Haskell progs with Haskell as it is ...
but you sure agree records are useful for collecting heterogenous data?
Yes, I would agree that even the current
hello,
i think records are very useful, and we don't use them much in haskell,
becuase the current record system is not very good.
Adrian Hey wrote:
IMHO preserving the status quo wrt records should be low priority.
It really doesn't bother me much if new (useful) language features break
Coming from the ML world, I can say that I find the lack of
proper records a real loss. It is extremely convenient to
write functions which take many parameters as taking a record,
for then you don't have to worry so much about the order
of arguments. SML gets this much right, but the ad hoc
Hi.
Here's another opinion for the Records! Records! chorus:
- The record and module system is one of the two big things I'd like
to see changed in Haskell. (OT: the other is subtyping.)
- It shouldn't happen before Haskell 2, because of backward
compatability. (The dot operator
G'day all.
On Tue, Sep 09, 2003 at 02:52:48PM +0200, Johannes Waldmann wrote:
but this might be an issue for others, who have to maintain legacy code.
You know a language has made it when we're talking about legacy code.
On the other hand, you have to worry about a pure declarative language
35 matches
Mail list logo
