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
Jeffrey Palmer writes:
I think the question is more along the lines of Why doesn't Haskell
come bundled with complete, useful and _supported_ libraries?
There's an ongoing effort to rectify the situation. There is a mailing
list: [EMAIL PROTECTED], which you can join by going to
Alastair David Reid [EMAIL PROTECTED] writes:
In the case of the Draw monad (which is identical to the
IO monad except that it carries a device context around as an
implicit parameter), the different feel comes from aggressive
use of continuations (actually, they're not quite continuations
Johannes Waldmann [EMAIL PROTECTED] wrote,
Manuel:
... Functional GUIs like
Fruit are from a research perspective very interesting, but
their design is rather far from being a solved problem,
which makes them a not very likely candidate for a standard
that people seem to like to
S. Alexander Jacobson [EMAIL PROTECTED] wrote,
If the GUI is based on the IO monad, then it doesn't seem like there is
a lot of advantage to doing it in Haskell. It seems like a better
idea to use a more natural language for IO and make RPC/interproc calls
to a haskell server to get stuff
egards, Bill Halchin
From: Jeffrey Palmer <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: The future of Haskell discussion
Date: 14 Sep 2001 17:06:49 -0500
On Fri, 2001-09-14 at 15:12, Mark Carroll wrote:
On Fri, 14 Sep 2001, Bill Halchin wrote:
Probably this question has be
Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] writes:
Fri, 14 Sep 2001 02:09:21 -0700, Julian Seward (Intl Vendor)
[EMAIL PROTECTED] pisze:
The lack of any way to interface to C++ is a problem, IMO.
I would love to be able to write Haskell programs using Qt
and ultimately the KDE
On Friday, 14. September 2001 04:38, you wrote:
[...]
wxWindows is quite C++ centric and AFAIK nobody has made a
serious effort at a C++ FFI yet. One of the big advantages
of GTK+ is that it was written with bindings for other
languages in mind. Therefore, it is probably the toolkit
with
As such, I would like to see a focus on making Haskell great for web
application and web service development.
Right. On the server side, this is easy (and people have done it,
see the example HTML server, and I've used it to code up a game server,
used for a students' programming contest
I would love to see Haskell used on the client side, that is,
I want Haskell applets.
I know of one Haskell applet running on the internet.
This would probably require that the user
downloads Hugs as a netscape-plugin? Or ghc emits Java (byte-)code?
And in both cases: what GUI should we use?
| wxWindows is quite C++ centric and AFAIK nobody has made a
| serious effort at a C++ FFI yet. One of the big advantages
| of GTK+ is that it was written with bindings for other
| languages in mind. Therefore, it is probably the toolkit
| with the most language bindings.
The lack of any
Fri, 14 Sep 2001 02:09:21 -0700, Julian Seward (Intl Vendor) [EMAIL PROTECTED]
pisze:
The lack of any way to interface to C++ is a problem, IMO.
I would love to be able to write Haskell programs using Qt
and ultimately the KDE libraries, both of which are C++, but
I can't, at the mo.
I
As a general question (and forgive my ignorance): are the various ffi's
implemented using something like `dlopen' or are they done by actually
putting suitable stubs into the Haskell generated C-code which then gets
compiled by the C compiler as part of the overall haskell compilation?
On 14 Sep
S. Alexander Jacobson [EMAIL PROTECTED] wrote,
Out of curiosity, how does GTK+ compare with Fruit?
GTK+ has a C API heavily based on call backs and mutable
state. Thus, the Haskell transcription of that API heavily
relies on the use of the IO monad - as does H98 textual IO.
It seems like it
Mark Carroll [EMAIL PROTECTED] wrote,
On Fri, 14 Sep 2001, Manuel M. T. Chakravarty wrote:
(snip)
wxWindows is quite C++ centric and AFAIK nobody has made a
serious effort at a C++ FFI yet. One of the big advantages
(snip)
Of course, wxPython also exists - I assume that the emphasis
At 09:58 14-9-01 +0200, Wolfgang Jeltsch wrote:
I didn't mean that a Haskell binding to wxWindows should be made. I meant
that the strategy of wxWindows should be used also for a Haskell GUI library.
This strategy is to define a common GUI interface and provide implementations
for different
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Friday 14 September 2001 12:52 pm, Marcin 'Qrczak' Kowalczyk wrote:
I think it should be easy to add support for C++, except exceptions.
There are two approaches: call C++ functions directly (it requires
implementing name mangling by the
Fri, 14 Sep 2001 18:04:24 +0300, Eray Ozkural [EMAIL PROTECTED] pisze:
I understand that you ought to deal with name mangling at some stage,
but how would the interfaces ultimately look like?
It depends how sophisticated tools we create. The easy step is to
wrap everything in functions. They
Hello,
Probably this question has been brought before. Besides the Preludes, why doesn't
Haskell have libraries like Java, Squeak (Smalltalk). I found this:
http://www.cit.gu.edu.au/~arock/hlibs/
Please take a look at .pdf files. Also I remember there was a Russian (actually
Georgian) guy who
On Fri, 2001-09-14 at 15:12, Mark Carroll wrote:
On Fri, 14 Sep 2001, Bill Halchin wrote:
Probably this question has been brought before. Besides the Preludes,
why doesn't
Haskell have libraries like Java, Squeak (Smalltalk). I found this:
(snip)
I'm puzzled - it does! - see
If the GUI is based on the IO monad, then it doesn't seem like there is
a lot of advantage to doing it in Haskell. It seems like a better
idea to use a more natural language for IO and make RPC/interproc calls
to a haskell server to get stuff done.
In other words, what is the value of the GTK+
If the GUI is based on the IO monad, then it doesn't seem like there is
a lot of advantage to doing it in Haskell. It seems like a better
idea to use a more natural language for IO and make RPC/interproc calls
to a haskell server to get stuff done.
In other words, if you use the IO monad,
On 14 Sep 2001, Jeffrey Palmer wrote:
(snip) [ good stuff ]
Thoughts?
A shortage of volunteers? I get the impression that there's a reasonable
consensus on what needs to be done; it's just that too few of us have the
time and expertise to execute it.
-- Mark
Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] asks:
12 Sep 2001 12:37:25 -, [EMAIL PROTECTED]
[EMAIL PROTECTED] pisze:
* Currently HOPS implements only one evaluation strategy,
namely leftmost outermost graph rewriting with sharing preservation
(without automatic sharing
Olaf Chitil [EMAIL PROTECTED] wrote,
Here a short summary by Malcolm and me of the final discussion at the
Haskell workshop:
I also took a couple of notes which I like to add.
John Launchbury and many further people made a plea that the single
biggest hindrance to the further spread of
Rather than talking about general features of the language that might
improve adoption in general, it is more useful to talk about specific
features of the language that make it killer in a particular application
domain.
In his classic book, Crossing the Chasm : Marketing and Selling High-Tech
On Thu, 13 Sep 2001, S. Alexander Jacobson wrote:
(snip)
As such, I would like to see a focus on making Haskell great for web
application and web service development. Some of the the pieces required
are application level, some are libraries, and some are language features.
Here is my quick
There was the feeling that there is not frequent enough
feedback from the Task Forces (eg, FFI Task Force, Library
Task Force) to the Haskell community as a whole. Clause
Reinke kindly volunteered to collect status reports of Task
Forces on a 6-monthly basis and post them to the Haskell
Just a quick remark:
S. Alexander Jacobson wrote (on 13-09-01 12:40 -0400):
As a general matter, the addendum process strikes me as confusing and
dangerous. I don't want to have a conversation like: I am using
Haskell'98 with Addendum A, C, and E. I'd rather say, I am using Haskell
2001
On Thursday, 13. September 2001 17:50, Manuel M. T. Chakravarty wrote:
[...]
Let me reiterate: Gtk+HS as it is today is sufficient for
applications requiring a GUI of medium complexity. As far
as I see, despite not covering all of GTK+ yet, Gtk+HS
already has a wider variety of widgets and
In my opinion GTK+ is not that nice to develop Win32 applications because
it
provides its own look-and-feel which conflicts with the one of Windows. On
UNIX-like systems where each desktop environment has its own look-and-feel
it
does not conflict under GNOME because GNOME is based on
Wolfgang Jeltsch [EMAIL PROTECTED] wrote,
That's why I
think GTK+ should be used mainly to develop applications which are intended
to run under GNOME and preferably not to do cross-plattform GUI programming.
I think the best solution for the latter thing is to use a library which has
On Fri, 14 Sep 2001, Manuel M. T. Chakravarty wrote:
(snip)
wxWindows is quite C++ centric and AFAIK nobody has made a
serious effort at a C++ FFI yet. One of the big advantages
(snip)
Of course, wxPython also exists - I assume that the emphasis on object
orientation is the problem?
-- Mark
Out of curiosity, how does GTK+ compare with Fruit?
It seems like it would make sense for the standard Haskell GUI also to be
functional.
-Alex-
PS I don't do GUI stuff so I don't really know much. I did read the Fruit
paper and it looked interesting.
On Fri, 14 Sep 2001, Manuel M. T.
Here a short summary by Malcolm and me of the final discussion at the
Haskell workshop:
First Simon Peyton Jones stated that the Haskell'98 Report continues to
be revised in small ways for correctness and readability. He will
continue this
until a whole month passes with no further changes,
Olaf Chitil [EMAIL PROTECTED] summarised the 10 minute talks
of this years Haskell workshop, including my presentation:
Wolfram Kahl: Animating Haskell by Term Graph Rewriting
HOPS is a system for term graph rewriting that can also show the
rewriting steps in a graphical animation. [...]
It seems like a common thread is a shortage of willing programming effort
so that things may be maintained and improved. Would it be worth thinking
about how to promote Haskell in communities where people might be willing
and able to contribute to the work?
(Much thanks to the people who are
Wed, 12 Sep 2001 11:00:38 +0100, Olaf Chitil [EMAIL PROTECTED] pisze:
Mark Shields: Lightweight Modules for Haskell
Shortly stated that he is working on a new module system and would like
every interested person to join.
I'm interested. How to join?
--
__( Marcin Kowalczyk * [EMAIL
12 Sep 2001 12:37:25 -, [EMAIL PROTECTED]
[EMAIL PROTECTED] pisze:
* Currently HOPS implements only one evaluation strategy,
namely leftmost outermost graph rewriting with sharing preservation
(without automatic sharing maximisation).
With the standard rules in place, this
73 matches
Mail list logo
