HaskellDirect bugs
Hello, Where should I send HaskellDirect bug reports: 1. Bug tracker at sourceforge.net/projects/ghc, 2. This mailing list, 3. Something else? Best wishes, Kostya Lukin ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: HaskellDirect bugs
I suggest you send them to Sigbjorn. His email address is above | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On | Behalf Of ? ?? ?? | Sent: 11 September 2003 09:11 | To: [EMAIL PROTECTED] | Subject: HaskellDirect bugs | | Hello, | | Where should I send HaskellDirect bug reports: | | 1. Bug tracker at sourceforge.net/projects/ghc, | | 2. This mailing list, | | 3. Something else? | | Best wishes, | | Kostya Lukin | | | | | ___ | Glasgow-haskell-bugs mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Windows and HToolkit's MySQL bindings
Lunar Sigbjorn writes: Yes, delayed threads were put to sleep with incorrect thread status in ghc-6.x, which I reckon is the problem here. Fixed a month or two ago in HEAD. My guess is that the other Win32 bug reports you've forwarded run across the same bug. So I'm going to assume that the same thing fixes your bug, unless you say otherwise. The fix will be in 6.2 which we'll put out shortly, but you can test it by building from source (a snap, these days) simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On | Behalf Of Lunar | Sent: 20 August 2003 21:13 | To: [EMAIL PROTECTED] | Subject: Windows and HToolkit's MySQL bindings | | -BEGIN PGP SIGNED MESSAGE- | Hash: SHA1 | | Hello, | | I'm trying to get HToolkit's MySQL bindings working on Windows, but this | message keep coming : | internal error: resumeThread: thread not found | Please report this as a bug to [EMAIL PROTECTED], | or http://www.sourceforge.net/projects/ghc/ | | There's no problems on GNU/Linux. | | See the attached archive for files involved. I'm using MinGW environnement to | build. | | $ ghc --version | The Glorious Glasgow Haskell Compilation System, version 6.0.1 | $ pexport --version | PExports 0.43 Copyright 1998, Anders Norlander | $ dlltool --version | GNU dlltool 2.13.90 20030111 | $ gcc -v | gcc version 3.2.3 (mingw special 20030504-1) | $ ld -v | GNU ld version 2.13.90 20030111 | $ mysql --version | d:\mysql\bin\mysql.exe Ver 12.21 Distrib 4.0.14, for Win95/Win98 (i32) | | I'll be glad to be any other help. | | Lunar. | -BEGIN PGP SIGNATURE- | Version: GnuPG v1.0.6 (GNU/Linux) | Comment: For info see http://www.gnupg.org | | iD8DBQE/Q9ZYd1rcjNWgdWQRAhgYAKCaYOhHQz7gl04c3Vm8KxGUisftdwCePvq5 | 1QsjEc+L1w3ExQN+mMH7sDo= | =qy75 | -END PGP SIGNATURE- ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc 6.0.1 and Mac OS X 10.2.6 build
Gregory Wright wrote: Hello, I've fixed it in the darwinports version. I patched the linker to try to find symbols with and without a leading underscore. I thought I had sent a note to the list but perhaps I overlooked doing so. The underlying issue is that there are versions of dlcompat using both conventions. Darwinports uses the port-fink convention (dlcompat adds a leading underscore), Wolfgang's package uses the fink convention (dlcompat does not add a leading underscore). Ah yes, that explains everything. Thanks for finding that out. I changed Linker.c to look up symbols with the GHC prefixed leading underscore removed. If the lookup fails, it trys the unmodified symbol. For reference, rebuilding dlcompat with debugging caught the error immediately, showing the stray underscore. The patch is a simple and should allow Linker.c to work on systems that use either convention. I've attached it in case it's useful to add it to the repository. If not, I'm content to patch the downloaded source. Sorry for my silence in the past week. While your patch should work, I remember seeing C code that uses function names like foo and _foo in the same way that a Haskell programmer might use foo and foo', so I had a bad feeling about automatically trying both. I've just commited a patch (rev 1.129 on the head and 1.128.2.1 on the 6.2 branch) that just bypasses dlcompat for lookupSymbol only. It uses NSLookupAndBindSymbol directly, so we don't need to worry about differences between dlcompat versions any more. Cheers, Wolfgang ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc 6.0.1 and Mac OS X 10.2.6 build
On Thursday, September 11, 2003, at 11:27 AM, Wolfgang Thaller wrote: Sorry for my silence in the past week. While your patch should work, I remember seeing C code that uses function names like foo and _foo in the same way that a Haskell programmer might use foo and foo', so I had a bad feeling about automatically trying both. I've just commited a patch (rev 1.129 on the head and 1.128.2.1 on the 6.2 branch) that just bypasses dlcompat for lookupSymbol only. It uses NSLookupAndBindSymbol directly, so we don't need to worry about differences between dlcompat versions any more. Cheers, Wolfgang Hi Wolfgang, Excellent. I'll update the darwinports version as soon as 6.2 becomes available and back out my patch. The fink/non-fink dlcompat issue comes up a lot. You approach to avoid it is best. Thanks, Greg ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc 6.0.1 and Mac OS X 10.2.6 build
While your patch should work, I remember seeing C code that uses function names like foo and _foo in the same way that a Haskell programmer might use foo and foo', so I had a bad feeling about automatically trying both. Could I recommend that you use or adapt the autoconf test HUGS_TRY_DYNLINK (hugs98/src/unic/aclocal.m4 in the same cvs repository that has ghc). This test generates a C object file to be loaded then tries to load the object file using one of dlopen, LoadLibrary, NSCreateObjectFileImageFromFile and shl_load then tries looking up both the symbol '_test' and 'test' in the file. It sets the linker flags to use to build dynamically loadable object files and whether or not to use an underscore when doing the lookup and it works on HPUX, Mac, Win32 and most mainstream unix variants. (Bug reports and improvements are, of course, welcome.) -- Alastair Reid ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc 6.0.1 and Mac OS X 10.2.6 build
Alastair Reid wrote: Could I recommend that you use or adapt the autoconf test HUGS_TRY_DYNLINK (hugs98/src/unic/aclocal.m4 in the same cvs repository that has ghc). I would recommend against this. :-) This test generates a C object file to be loaded then tries to load the object file using one of dlopen, LoadLibrary, NSCreateObjectFileImageFromFile and shl_load then tries looking up both the symbol '_test' and 'test' in the file. It sets the linker flags to use to build dynamically loadable object files and whether or not to use an underscore when doing the lookup and it works on HPUX, Mac, Win32 and most mainstream unix variants. (Bug reports and improvements are, of course, welcome.) Tests needing a *target* machine are bad when it comes to cross-compilation, so we should try to avoid this for GHC. OK, GHC is not really capable of cross-compilation yet, but we shouldn't make things worse. Regarding the underscore story: I think I've seen similar tests in other programs (some version of Guile?), but I can't remember. Could somebody explain in a few sentences what exactly the underscore problem is in GHC(i) and/or the libraries? Things look a bit muddled in the source code... :-] Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Who supports HaskellDirect now?
Hello! Who supports HaskellDirect now? Best wishes. Kostya Lukin ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Who supports HaskellDirect now?
Sigbjorn Finne, still. | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] | On Behalf Of ? ?? ?? | Sent: 11 September 2003 08:17 | To: [EMAIL PROTECTED] | Subject: Who supports HaskellDirect now? | | Hello! | | Who supports HaskellDirect now? | | Best wishes. | | Kostya Lukin | | | | ___ | Glasgow-haskell-users mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: stg_ap_v_ret porting crash: solved?
Things aren't so easy with alpha as gcc rejects the -mieee flag when GHC calls gcc for -cpp'ing. I fear a nasty hacky wrapper may be in order. Is this when running gcc on the Alpha, or on the bootstrapping host? Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: stg_ap_v_ret porting crash: solved?
simonmar: Things aren't so easy with alpha as gcc rejects the -mieee flag when GHC calls gcc for -cpp'ing. I fear a nasty hacky wrapper may be in order. Is this when running gcc on the Alpha, or on the bootstrapping host? alpha-dec-osf3 bootstrapped quite cleanly today. Using the right config.h makes a big difference ;) It isn't working yet though. I had to comment out/hack various decls in the rts on the alpha, which let the compile go through. The GHC that got built seems to loop when invoked. Probably an MBlock thing, I haven't looked into it yet. Anyway, I assume Ian was talking about the bootstrapped GHC on the target rejecting -mieee when being used to compile a full GHC. I didn't get that far, but I had no problems with -mieee on the host, or with .hc file-booting gcc. -- Don ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: stg_ap_v_ret porting crash: solved?
On Thu, Sep 11, 2003 at 02:21:29PM +1000, Matt Chapman wrote: On Thu, Sep 11, 2003 at 02:06:57AM +0100, Ian Lynagh wrote: Bootstrapping IA64 from x86 (with numerous patches from CVS) looks like it is working fine, although I am getting ghc-6.0.1(9371): unaligned access to 0x41e6177a, ip=0x40dd46c1 when compiling even hello world with optimisation. The result seems to work fine though. Is this expected? Or maybe I missed a patch? Hmm, no, I don't get any unaligned accesses. My tree is a few months old though, I will update and check. I'm not using CVS, I'm using 6.0.1 with the patch at http://merulo.debian.org/~igloo/patch I'm not really too worried about it as it seems to work regardless, and will presumably become fixed when 6.2 is released. Thanks Ian ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: stg_ap_v_ret porting crash: solved?
On Thu, Sep 11, 2003 at 09:52:07AM +0100, Simon Marlow wrote: Things aren't so easy with alpha as gcc rejects the -mieee flag when GHC calls gcc for -cpp'ing. I fear a nasty hacky wrapper may be in order. Is this when running gcc on the Alpha, or on the bootstrapping host? The bootstrapping host. Oh, and while I think about it, on the building docs: Minor niggle - missing cd T on the first line $ ./configure --enable-hc-boot --enable-hc-boot-unregisterised When you say change TARGETPLATFORM appropriately. I've been assuming you mean the name of the foo_TARGET_ARCH etc variables too. Presumably this is the same as passing configure --target=what-remote-one-says ? Thanks Ian ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: stg_ap_v_ret porting crash: solved?
The bootstrapping host. That is expected, then. I've mentioned before that trying to build the HC files on the bootstrapping host might not work, because these files are meant to be built on the target. The same goes for the invocation of gcc itself: it is using flags designed for use on the target machine. Oh, and while I think about it, on the building docs: Minor niggle - missing cd T on the first line $ ./configure --enable-hc-boot --enable-hc-boot-unregisterised added, thanks. When you say change TARGETPLATFORM appropriately. I've been assuming you mean the name of the foo_TARGET_ARCH etc variables too. Yes, I'll update the docs to say that too. Presumably this is the same as passing configure --target=what-remote-one-says ? configure doesn't cope with different --host/--target at the moment. There's no reason in principle why it shouldn't. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Syntax extensions (was: RE: The Future of Haskell discussion at the Haskell Workshop)
| 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 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 parameters
| - template haskell
| - FFI
| - rank-N polymorphism (forall keyword)
| - recursive 'do' (mdo keyword)
Haskell gets pulled in many different directions to meet the needs
and whims of developers, researchers, and educators, among others.
For quite a long time, it seemed that the choice between Standard
Haskell 98 and Kitchen Sink Haskell with all the extras was
adequately dealt with using a single command line option. Those
looking for the stability of Haskell 98 got what they wanted by
default, while the adventurers looking to play with all the new
toys just added an extra -fglasgow-exts or -98 or ... etc.
As the number of extensions grows (and the potential for unexpected
interactions), it is clear that we can't get by with that simple
scheme any more. It's important that implementations continue to
provide the stable foundation, but people also need a more flexible
way to select extensions when they need them.
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 any more; there's a whole lattice of options, which, by
the proposal above might be controlled through a slew of tool-specific
and either cryptic or verbose command line switches. Will you
remember which switches you need to give to compile your code for
the first time in two months? How easy will it be to translate
those settings if you want to run your code through a different
compiler? How much help will the compiler give you in tracking
down a problem if you forget to include all the necessary switches?
And how will you figure out what options you need to use when you
try to combine code from library X with code from library Y, each
of which uses its own interesting slice through the feature set?
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 command line complexities
by integrating the selection of language extensions more tightly
with the rest of the language.
The main idea is to use the module system to capture information
about which language features are needed in a particular program.
For example, if you have a module that needs implicit parameters
Template Haskell, and TREX, then you'll indicate this by including
something like the following imports at the top of your code:
import Extensions.Types.ImplicitParams
import Extensions.Language.TemplateHaskell
import Extensions.Records.TREX
Code that needs recursive do, O'Haskell style structs, rank-n
polymorphism, and multiple parameter classes might specify:
import Extensions.Language.Mdo
import Extensions.Records.Structs
import Extensions.Types.RankN
import Extensions.Types.Multiparam
Imports are always at the top of a module, so they're easy to
find, and so provide clear, accessible documentation. (Don't
worry about the names I've picked here; they're intended to
suggest possibilities, but they're not part of the proposal.)
What, exactly is in those modules? Perhaps they just provide
tool-specific pragmas that enable/disable the corresponding
features. Or perhaps the compiler detects attempts to import
particular module names and instead toggles internal flags.
But that's just an implementation detail: it matters only to the
people who write the compiler, and not the people who use it.
It's the old computer science trick: an extra level of indirection,
in this case through the module system, that helps to decouple
details that matter to Haskell programmers from details that
matter to Haskell implementers.
Of course, code that does:
import Extensions.Types.Multiparam
is not standard Haskell 98 because there's no such library in the
standard. This is a good thing; our code is clearly annotated as
relying on a particular extension, without relying on the command
line syntax for a particular tool. Moreover, if the implementers
of different tools can agree on the names they use, then code that
imports Extensions.Types.Multiparam will work on any compiler that
supports multiple parameter classes, even if the underlying
mechanisms for enabling/disabling those features are different.
When somebody
command-line options become extensional imports
Regarding M. P. Jones proposal to move command-line options to the module space, I would like to reiterate something from an earlier email: What if you want to express that overlapping instances are fine for a certain class C but not for the rest? Recasted to the module speak of MPJ, would that require some parameterisation? I am sure this question makes sense for several extensions. (A humble solution: One could dedicate a module to the class C, and then rely on scope rules for modules regarding the propagation of the import Extension.OverlappingInstances.) Another issue is of course that this modulish approach, which I like very much, requires sometimes that an imported extension X is *reexported* from hacker module H so that some other module A will also be compiled with the corresponding extensions enabled. Such invasive, implicit reexport is quite non-standard. In general, this raises the issue of scopes for such extensions. For some extensions, they might be *invasive* that they really require special code for all modules. For some other extension, there might be a *choice* for applying the extension to the given module or also all clients transitively or non-transitively. Aligning these options with the module system, or more precisely with the existing scope/import/export rules of the module system seems to be non-convincing to me at this stage. In fact, finding the ultimate solution would go beyond the scope of Haskell, it would be an achievement for programming languages but also software configuration in general. Regards, Ralf ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
A gentle reminder: Coordination2004 Deadline is approaching
[[ -- Apologies for multiple copies of this message -- ]] COORDINATION 2004 Second Call for Papers Sixth International Conference on Coordination Models and Languages 24-27 February 2004 -- Pisa, Italy === IMPORTANT DATES: Submission of abstract: September 22, 2003 Submission of Papers: September 29, 2003 ** FIRM ** Notification of Acceptance: November 14, 2003 Camera-Ready Copy: December 4, 2003 TOPICS OF INTEREST (include, but are not limited to): * Theoretical models and foundations for coordination * Coordination middlewares * Specification, refinement, and analysis of software architectures * Architectural, and interface definition languages * Agent-oriented languages and models * Dynamic software architectures * Component Programming * Web Services * Coordination in Peer to Peer and Grid Computing * Tools and environments for the development of coordinated applications * Industrial relevance of coordination and software architectures * Domain-specific software coordination models and case studies. PROCEEDINGS The conference proceedings will be published by Springer, in the Lecture Notes in Computer Science series. For submissions and further information see: http://www.di.unipi.it/Coordination2004 ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Where are higher-rank and existential types used?
Hello, Norman Ramsey and I are looking for examples of where higher-rank polymorphism and existential types are useful. Can anyone think of uses besides the following? Higher-rank types are used in: - Deforestation Andrew Gill, John Launchbury, and Simon L. Peyton Jones. 1993. A short cut to deforestation. In _Functional programming languages and computer architecture: 6th conference_, 223-232. New York: ACM Press. - Lazy functional state threads John Launchbury and Simon L. Peyton Jones. 1994. Lazy functional state threads. In _PLDI '94: Proceedings of the ACM conference on programming language design and implementation_, vol. 29(6) of _ACM SIGPLAN Notices_, 24-35. New York: ACM Press. - Generic (polytypic) programming Ralf Hinze. 2000. A new approach to generic functional programming. In _POPL '00: Conference record of the annual ACM symposium on principles of programming languages_, 119-132. New York: ACM Press. Ralf Lämmel and Simon L. Peyton Jones. 2003. Scrap your boilerplate: A practical design pattern for generic programming. In _Proceedings of the 2003 ACM SIGPLAN international workshop on types in languages design and implementation_, 26-37. New York: ACM Press. - Data type invariants Chris Okasaki. 1999. From fast exponentiation to square matrices: An adventure in types. In _ICFP '99: Proceedings of the ACM international conference on functional programming_, vol. 34(9) of _ACM SIGPLAN Notices_, 28-35. New York: ACM Press. Ralf Hinze. 2001. Manufacturing datatypes. _Journal of Functional Programming_ 11(5): 493-524. Richard Bird and Ross Paterson. 1999. de Bruijn notation as a nested datatype. _Journal of Functional Programming_ 9(1): 77-91. Existential types are used in: - Object-oriented programming Benjamin C. Pierce and David N. Turner. 1994. Simple type-theoretic foundations for object-oriented programming. _Journal of Functional Programming_ 4(2): 207-247. Konstantin Läufer. 1996. Type classes with existential types. _Journal of Functional Programming_ 6(3): 485-517. - Abstract data types John C. Mitchell and Gordon D. Plotkin. 1988. Abstract types have existential type. _ACM Transactions on Programming Languages and Systems_ 10(3): 470-502. Any pointers or technique descriptions would be highly appreciated! If there are many contributions, I will post an updated version of this list. Ken -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig United Nations Day is 24 October. http://www.un.org/events/unday/ The Lost Voice of Radio Beijing http://www.milinfoserv.net/lvrb.html Write letters! We got half of New Testament that way. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The Future of Haskell discussion at the Haskell Workshop
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
set :: r - Field r a - a - r
get :: r - Field r a - a
The example would then look like:
class Wibble r where
wibble :: Field r Int
wobble :: Field r String
data Foo =
MkFoo{ wibble :: Int
, wobble :: String
}
deriving Wibble
What do you think of this?
The type Field can be implemented as:
data Field r a = MkField (r - a - r) (r - a)
set rec (MkField f _) x = f rec x
get rec (MkField _ g) = g rec
Regards,
/Koen
(*) I prefer the following operators but I realize that
there are other people who are less fond of binary operator
symbols :-)
type Field r a
type Setting r
(=:) :: Field r a - a - Setting r
(!) :: r - Setting r - r
(?) :: r - Field r a - a
Such that selecting the field wibble from a record rec would
look like:
rec ? wibble
And setting the field wibble from the record rec to the
value val would look like:
rec ! wibble =: val
The last should parse as:
rec ! (wibble =: val)
/K
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: The Future of Haskell discussion at the Haskell Workshop
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] All very cute :-)) The downside is of course that it would no longer be a compatible extension to the existing Haskell language. Current Haskell programs consider the field name to be a function from types to field values. If we are to retain compatibility then we need to preserve this. Still very cute though :-) [snip] -Rob ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: GHC code generation
There is no C-- backend for GHC (search the mailing list and you'll see Simon asking someone to try to do this :P). GHC either generates code by itself, or generates normal C code (with -fvia-c or -O2, iirc) and then uses GCC to compile this. Ah... for some value of normal! It's very GCC-specific, and there is a nasty hack that it does to the output assembly code to rearrange function entry points so that the info table lives directly before the entry point. It's certainly not ANSI or C99 code. But it's not C-- either. --KW 8-) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Syntax extensions (was: RE: The Future of Haskell discussion at the Haskell Workshop)
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 any more; there's a whole lattice of options, which, by
the proposal above might be controlled through a slew of tool-specific
and either cryptic or verbose command line switches. Will you
remember which switches you need to give to compile your code for
the first time in two months? How easy will it be to translate
those settings if you want to run your code through a different
compiler? How much help will the compiler give you in tracking
down a problem if you forget to include all the necessary switches?
And how will you figure out what options you need to use when you
try to combine code from library X with code from library Y, each
of which uses its own interesting slice through the feature set?
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 command line complexities
by integrating the selection of language extensions more tightly
with the rest of the language.
Initially I liked the idea, but now I'm not so sure (more about that
later). But first I'll point out that the situation isn't nearly as bad
as you make out. In GHC, the approved way to add these flags is by
using a pragma to the source code, for example:
{-# OPTIONS -fth -fffi #-}
module Foo where
...
this in itself addresses most of your complaints. Using a
compiler-independent syntax would address another one. We're left with:
How much help will the compiler give you in tracking
down a problem if you forget to include all the necessary
switches?
We don't make any attempt to address this, but there are various ways we
could be more helpful: eg. finding a stray 'forall' in a type when
rank-N is not turned on is a clear indication. Nevertheless, this seems
orthogonal to the issue of how to specify the language flavour in the
first place.
And how will you figure out what options you need to use when you
try to combine code from library X with code from library Y, each
of which uses its own interesting slice through the feature set?
Interesting point. Our take on this is that the extension-flags specify
the language variant in which the source code *in this module* is
written. For example, if I define a multi-parameter type class C in
module A, then it is completely legal to import A into any other module
regardless of the settings of the flags, but I will only be able to
write an instance of C if multi-parameter type classes are enabled.
This is a consistent position which has the benefit of being easy to
understand.
The main idea is to use the module system to capture information
about which language features are needed in a particular program.
For example, if you have a module that needs implicit parameters
Template Haskell, and TREX, then you'll indicate this by including
something like the following imports at the top of your code:
import Extensions.Types.ImplicitParams
import Extensions.Language.TemplateHaskell
import Extensions.Records.TREX
How do I enable hierarchical modules using this scheme? ;-)
Can any of these extensions affect the syntax of the export list? If
so, how do I parse the module? (perhaps I have to use a most-general
syntax for the export list, parse up to and including the imports, then
re-parse the export list).
[snip]
Of course, code that does:
import Extensions.Types.Multiparam
is not standard Haskell 98 because there's no such library in the
standard. This is a good thing; our code is clearly annotated as
relying on a particular extension, without relying on the command
line syntax for a particular tool. Moreover, if the implementers
of different tools can agree on the names they use, then code that
imports Extensions.Types.Multiparam will work on any compiler that
supports multiple parameter classes, even if the underlying
mechanisms for enabling/disabling those features are different.
When somebody tries to compile that same piece of code using a
tool that doesn't support the feature, they'll get an error
message about a missing import with a (hopefully) suggestive
name/description, instead of a cryptic Syntax error in constraint
or similar.
This complaint is also addressed by using a compiler-independent pragma,
except the error message would be unsupported extension.
Also, when you come back to compile your code after some
time away, you won't need to remember which command line options you
need because it's all there, built in to the source in a readable and
perhaps even portable notation. You just invoke the compiler (without
RE: Circular Instance Declarations
OK, I yield!
The HEAD now runs this program. It turned out to be a case of
interchanging two lines of code, which is the kind of fix I like.
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Ashley Yakeley
| Sent: 07 September 2003 06:57
| To: [EMAIL PROTECTED]
| Subject: Circular Instance Declarations
|
| When -fallow-undecidable-instances is switched on, is there any reason
| why circular instances are forbidden? For instance:
|
| module CircularInsts where
| {
| data D r = ZeroD | SuccD (r (D r));
|
| instance (Eq (r (D r))) = Eq (D r) where
| {
| ZeroD == ZeroD = True;
| (SuccD a) == (SuccD b) = a == b;
| _ == _ = False;
| };
|
| newtype C a = MkC a deriving Eq;
|
| equalDC :: D C - D C - Bool;
| equalDC = (==);
| }
|
| When I compile this, I get this:
|
| $ ghc -fglasgow-exts -fallow-undecidable-instances -c
CircularInsts.hs
| CircularInsts.hs:2:
| Context reduction stack overflow; size = 21
| Use -fcontext-stack20 to increase stack size to (e.g.) 20
| `Eq (C (D C))' arising from use of `==' at CircularInsts.hs:16
| `Eq (D C)' arising from use of `==' at CircularInsts.hs:16
| `Eq (C (D C))' arising from use of `==' at CircularInsts.hs:16
| `Eq (D C)' arising from use of `==' at CircularInsts.hs:16
|
| Would it be reasonable for the compiler to check back through the
stack
| and allow the circularity? It will just create an ordinary recursive
| function.
|
| --
| Ashley Yakeley, Seattle WA
|
| ___
| Haskell mailing list
| [EMAIL PROTECTED]
| http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: Syntax extensions
I don't mind pointing out that either solution, compiler independent pragmas or extension import lists, would be great for the Library Infrastructure Project, since it will save us from having to include per-file command-line flags in a package configuration database (see my message to [EMAIL PROTECTED] from yesterday). Also I've mentioned several times that I think it would be great if we had another flag which turned on the features that are shared between the major Haskell implementations. So for each implementation, there would be three modes, haskell98, kitchen-sink, and shared-options, the last of which turns on extentions like multi-param type classes and hierarchical modules that are implemented in a standard way. This way, the user can tell that they're writing mostly portable code (though with no guarantees as to future compatibility). It also could possibly be used as a staging ground for the next version of Haskell once there's a feature freeze. peace, isaac ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Syntax extensions (was: RE: The Future of Haskell discussion at the Haskell Workshop)
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 define a new module that imports all the features you need, and then allows you to access them by a single name. For example, you could capture the second feature set above in the following: module HackersDelight where import Extensions.Language.Mdo import Extensions.Records.Structs import Extensions.Types.RankN import Extensions.Types.Multiparam Now the only thing you have to write at the top of a module that needs some or all of these features is: import HackersDelight ... Neat! But maybe it is not always desirable to impose an extension on the client of a module, just because the module itself needs it. If extensions were a kind of entity that can be mentioned in export and import lists, we could write module HackersDelight(mdo,structs,rankN,multiparam) where import Extensions.Language(mdo) ... Now, familiar mechanisms can be used from the module system. In particular, we can encode Hal's example (all extensions except Template Haskell): import HackersDelight hiding (th) /M ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Syntax extensions (was: RE: The Future of Haskell discussion at the Haskell Workshop)
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 learn yet another construct. reduce the cognitive overhead so to speak (i've wanted to use this phrase since i learned it in HCI class :-) Magnus Carlsson wrote: 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 define a new module that imports all the features you need, and then allows you to access them by a single name. For example, you could capture the second feature set above in the following: module HackersDelight where import Extensions.Language.Mdo import Extensions.Records.Structs import Extensions.Types.RankN import Extensions.Types.Multiparam actually the way the module system works at the moment this sould probably be written as: module HackersDelight (module A) where import Extensions.Language.Mdo as A import Extensions.Records.Structs as A import Extensions.Types.RankN as A import Extensions.Types.Multiparam as A otherwise i would assume that the extensions only apply to the current module. Neat! But maybe it is not always desirable to impose an extension on the client of a module, just because the module itself needs it. i think with the above interpretation no extensions would be forced on a client, unless a module actually re-exports the extensions it used. If extensions were a kind of entity that can be mentioned in export and import lists, we could write module HackersDelight(mdo,structs,rankN,multiparam) where import Extensions.Language(mdo) ... Now, familiar mechanisms can be used from the module system. In particular, we can encode Hal's example (all extensions except Template Haskell): import HackersDelight hiding (th) yes, this is nice. and i don't think it can be done if extnesions are modules (as mark suggested) rather than entities (as magnus suggested). one thing to consider though is that if extensions are entities they can presumably be mentioned in expressions, etc. one way to handle that is to introduce a new kind, e.g. something like: mdo :: Extension :: ExtensionKind an alternative (perhaps simpler) approach would be to have extensions live in another name space, so that they can't syntactically be placed in expressions, e.g. something like: import HackersDelight hidning (#th) bye iavor -- == | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | == ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
