Readline on Windows?
Hi, Compiling the following program (Bug.hs): module Main where import System.Console.Readline main = do ms - readline Hi print ms Using GHC 6.2.2 on Windows XP, using the command line: ghc --make Bug -o bug Produces the following message: Chasing modules from: Bug Compiling Main ( Bug.hs, Bug.o ) Linking ... c:/ghc/ghc-6.2.2/libHSreadline.a(Readline__96.o)(.text+0xaa):ghc11748.hc: undefined reference to `readline' Tried linking by hand (not using --make), specifying -package readline, specifying -lreadline; nothing worked. /Koen ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Derivable type classes bug?
Hi,
Take a look at the following program, making use of
derivable type classes.
module Bug where
import Data.Generics
class Foo a where
foo :: a - Int
foo{| Unit |}_ = 1
foo{| a :*: b |} _ = 2
foo{| a :+: b |} _ = 3
instance Foo [a]
GHC 6.2.2 produces the following error message:
Bug.hs:12:
Could not deduce (Foo a) from the context (Foo [a])
arising from use of `foo' at Bug.hs:12
Why is the context needed? 'foo' is not a recursive
function?
I guess it is because the default declaration is split up
into several instances:
instance Foo Unit where
foo _ = 1
instance (Foo a, Foo b) = Foo (a :*: b) where
foo _ = 2
instance (Foo a, Foo b) = Foo (a :+: b) where
foo _ = 3
Why not generating:
instance Foo Unit where
foo _ = 1
instance Foo (a :*: b) where
foo _ = 2
instance Foo (a :+: b) where
foo _ = 3
when the context is not needed?
(My motivation is: I have a class like this:
class Arbitrary a = Shrink a where
shrinkSub :: a - [a]
shrinkSub{| ... |} = ... shrink ...
The definition of shrinkSub is not recursive, it calls a
function 'shrink' from the Arbitrary class instead.)
Regards,
/Koen
PS. Has the implementation of Generics changed from some
earlier compiler version (GHC 5.xx)? I have code lying
around that I am almost certain of used to compile with an
earlier version of GHC (that I do not have access to
anymore).
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1069656 ] ghc-ghci inconsisteny
Bugs item #1069656, was opened at 2004-11-19 19:57 Message generated for change (Settings changed) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1069656group_id=8032 Category: None Group: None Status: Closed Resolution: None Priority: 5 Submitted By: Nightmare (goronsf) Assigned to: Nobody/Anonymous (nobody) Summary: ghc-ghci inconsisteny Initial Comment: The following program has different semantics in ghc and ghci. main = do putStrLn something putStr something else It's the linebuffering. NoLineBuffering should be used on expressions without side-effects. So 5*5 should print immediately, and do putStrLn something should behave the same in both applications. How doesn't matter that much to me, but they should be the same. -- Comment By: Simon Marlow (simonmar) Date: 2004-11-22 13:30 Message: Logged In: YES user_id=48280 Buffering of the standard handles does indeed differ in GHCi compared to GHC. The behaviour is a compromise: you don't want NoBuffering by default for stdout in a compiled program, because it would be too slow. You probably *do* want NoBuffering in an interactive environment, however, because you want interactivity. So, unless we hear from lots of people who want this to change, it'll stay as is. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1069656group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Derivable type classes bug?
Yes, you guessed right. Your generic class declaration gives rise to
instance declarations like
| instance (Foo a, Foo b) = Foo (a :*: b) where
| foo _ = 2
You suggest that it could be cleverer about guessing the context for the
instance decl, and that would make sense. But this'd then be the *only*
time that the context of an instance decl was inferred, rather than
provided. So (a) that's unusual (needs explanation etc), and (b) it'd
require some jiggling in the compiler, which is currently set up for
checking instance decls only.
An alternative, I guess, would be to ask the programmer to supply the
context for the instance decls. But it's hard to see good syntax. Were
would the context go in the class decl?
Another alternative could be for the programmer to give the
separated-out instance declarations himself, rather than having them
grouped in the class decl. But we'd still need some way to signal that
the method should be generated generically. Something like
class Foo a where
foo :: a - Int
generic foo -- New keyword
instance Foo Unit where ...
instance Foo (a :+: b) where ...
etc
Signalling generic-ness like this could even allow generic-ness on a
method-by-method basis. Kind of like specifying the default method. I
don't want to eat another keyword, though. And somehow it'd be better
if the same signal happened for the current case. But
class Foo a where
foo :: a - Int
generic foo
foo {| Unit |} = ...
seems rather heavy.
So the possibilities are:
(A). Infer the instance context.
(B). Somehow specify the instance contexts in the class decl
(C). Optionally, give separate instances for Unit, :+: etc, plus a
signal
in the class decl the default method is generic. Syntax?
I think my preferences would go (C), (A), (B); if we could agree a
syntax for (C).
Does anyone else have a (somewhat informed) opinion?
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-bugs-
| [EMAIL PROTECTED] On Behalf Of Koen Claessen
| Sent: 16 November 2004 17:17
| To: [EMAIL PROTECTED]
| Subject: Derivable type classes bug?
|
| Hi,
|
| Take a look at the following program, making use of
| derivable type classes.
|
|
| module Bug where
|
| import Data.Generics
|
| class Foo a where
| foo :: a - Int
| foo{| Unit |}_ = 1
| foo{| a :*: b |} _ = 2
| foo{| a :+: b |} _ = 3
|
| instance Foo [a]
|
|
| GHC 6.2.2 produces the following error message:
|
|
| Bug.hs:12:
| Could not deduce (Foo a) from the context (Foo [a])
| arising from use of `foo' at Bug.hs:12
|
|
| Why is the context needed? 'foo' is not a recursive
| function?
|
| I guess it is because the default declaration is split up
| into several instances:
|
|
| instance Foo Unit where
| foo _ = 1
|
| instance (Foo a, Foo b) = Foo (a :*: b) where
| foo _ = 2
|
| instance (Foo a, Foo b) = Foo (a :+: b) where
| foo _ = 3
|
|
| Why not generating:
|
|
| instance Foo Unit where
| foo _ = 1
|
| instance Foo (a :*: b) where
| foo _ = 2
|
| instance Foo (a :+: b) where
| foo _ = 3
|
|
| when the context is not needed?
|
| (My motivation is: I have a class like this:
|
| class Arbitrary a = Shrink a where
| shrinkSub :: a - [a]
| shrinkSub{| ... |} = ... shrink ...
|
| The definition of shrinkSub is not recursive, it calls a
| function 'shrink' from the Arbitrary class instead.)
|
| Regards,
| /Koen
|
| PS. Has the implementation of Generics changed from some
| earlier compiler version (GHC 5.xx)? I have code lying
| around that I am almost certain of used to compile with an
| earlier version of GHC (that I do not have access to
| anymore).
|
|
| ___
| 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
[ ghc-Bugs-1071030 ] internal error: update_fwd: unknown/strange object 12238336
Bugs item #1071030, was opened at 2004-11-22 15:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1071030group_id=8032 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gour (ggd) Assigned to: Nobody/Anonymous (nobody) Summary: internal error: update_fwd: unknown/strange object 12238336 Initial Comment: Hi! In my attempt to emerge i.e. compile gtk2hs on amd64 arch, I've encountered the following problem: [..] ../c2hs/c2hs -C-D__signed=signed -C-D__GLASGOW_HASKELL__=602 +RTS -H180m -M350m-RTS -C-I/usr/include/glib-2.0 -C-I//usr/lib/glib-2.0/include -C-I/usr/include/gtk-2.0 -C-I//usr/lib/gtk-2.0/include -C-I/usr/X11R6/include -C-I/usr/include/pango-1.0 -C-I/usr/include/freetype2 -C-I/usr/include/atk-1.0 -iabstract:buttons:display:entry:general:layout:menuComboToolbar:misc:multiline:ornaments:scrolling:selectors:treeList:windows:gdk:glib:pango:../compat:embedding -o : gtk/gtk.h general/Hierarchy.chs general/Signal.chs glib/GValue.chs glib/GList.chs glib/GObject.chs pango/PangoTypes.chs treeList/TreeModel.chs treeList/TreeViewColumn.chs multiline/TextIter.chs gdk/Region.chs abstract/Bin.chs abstract/Box.chs abstract/ButtonBox.chs abstract/Container.chs abstract/FileChooser.chs abstract/Misc.chs abstract/Object.chs abstract/Paned.chs abstract/Range.chs abstract/Scale.chs abstract/Widget.chs buttons/Button.chs buttons/CheckButton.chs buttons/RadioButton.chs buttons/ToggleButton.chs display/AccelLabel.chs display/Image.chs display/Label.chs display/ProgressBar.chs display/Statusbar.chs entry/Editable.chs entry/Entry.chs entry/EntryCompletion.chs entry/HScale.chs entry/SpinButton.chs entry/VScale.chs general/Enums.chs general/General.chs general/IconFactory.chs general/Style.chs layout/Alignment.chs layout/AspectFrame.chs layout/Expander.chs layout/Fixed.chs layout/HBox.chs layout/HButtonBox.chs layout/HPaned.chs layout/Layout.chs layout/Notebook.chs layout/Table.chs layout/VBox.chs layout/VButtonBox.chs layout/VPaned.chs menuComboToolbar/CheckMenuItem.chs menuComboToolbar/ComboBox.chs menuComboToolbar/ComboBoxEntry.chs menuComboToolbar/Combo.chs menuComboToolbar/ImageMenuItem.chs menuComboToolbar/MenuBar.chs menuComboToolbar/Menu.chs menuComboToolbar/MenuItem.chs menuComboToolbar/MenuShell.chs menuComboToolbar/OptionMenu.chs menuComboToolbar/RadioMenuItem.chs menuComboToolbar/TearoffMenuItem.chs menuComboToolbar/Toolbar.chs menuComboToolbar/ToolItem.chs misc/Adjustment.chs misc/Calendar.chs misc/DrawingArea.chs misc/EventBox.chs misc/FileChooserWidget.chs misc/GArrow.chs misc/HandleBox.chs misc/SizeGroup.chs misc/Tooltips.chs misc/Viewport.chs multiline/TextBuffer.chs multiline/TextMark.chs multiline/TextTag.chs multiline/TextTagTable.chs multiline/TextView.chs ornaments/Frame.chs ornaments/HSeparator.chs ornaments/VSeparator.chs scrolling/HScrollbar.chs scrolling/ScrolledWindow.chs scrolling/VScrollbar.chs selectors/ColorSelection.chs selectors/ColorSelectionDialog.chs selectors/FontSelection.chs selectors/FontSelectionDialog.chs treeList/CellRendererPixbuf.chs treeList/CellRendererText.chs treeList/CellRendererToggle.chs treeList/ListStore.chs treeList/TreeModelSort.chs treeList/TreeSelection.chs treeList/TreeStore.chs treeList/TreeView.chs windows/Dialog.chs windows/FileChooserDialog.chs windows/FileSel.chs windows/Window.chs gdk/Drawable.chs gdk/GC.chs gdk/Gdk.chs gdk/GdkEnums.chs gdk/Keys.chs gdk/Pixbuf.chs glib/GError.chs glib/GType.chs glib/GValueTypes.chs pango/PangoLayout.chs pango/Rendering.chs embedding/Plug.chs embedding/Socket.chs c2hs: internal error: update_fwd: unknown/strange object 12238336 Please report this as a bug to [EMAIL PROTECTED], or http://www.sourceforge.net/projects/ghc/ /bin/sh: /bin/sed s/\(.*\)\.chs/\1.hs/: No such file or directory removing make[1]: *** [compile] Error 1 make[1]: Leaving directory `/var/tmp/portage/gtk2hs-0.9.6-r1/work/gtk2hs-0.9.6/gtk' make: *** [make-all] Error 1 I'm on Gentoo amd64 with dev-lang/ghc-6.2.2-r1. gaura-nitai gtk2hs # uname -a Linux gaura-nitai 2.6.9-gentoo-r1 #23 SMP Mon Nov 15 21:51:39 CET 2004 x86_64 AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux Sincerely, Gour -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1071030group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Readline on Windows?
On 16 November 2004 17:16, Koen Claessen wrote: Compiling the following program (Bug.hs): module Main where import System.Console.Readline main = do ms - readline Hi print ms Using GHC 6.2.2 on Windows XP, using the command line: ghc --make Bug -o bug Produces the following message: Chasing modules from: Bug Compiling Main ( Bug.hs, Bug.o ) Linking ... c:/ghc/ghc-6.2.2/libHSreadline.a(Readline__96.o)(.text+0xaa):ghc11748.hc : undefined reference to `readline' Sigbjorn describes how to fix this bug here: http://www.haskell.org/pipermail/glasgow-haskell-users/2004-November/007 370.html I'll add the information to the FAQ. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
filterSet
Dear GHC team, As there exists, say,Data.mapSet, is this natural to provide also filterSet ? - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Bug in touchForeignPtr?
On 20 November 2004 23:02, Benjamin Franksen wrote: I am using Foreign.Concurrent.newForeignPtr and touchForeignPtr inside the finalizers to express liveness dependencies as hinted to by the documentation. This doesn't seem to work, though, or at least I can't see what I've done wrong. I attached a test module; compiled with ghc -fglasgow-exts --make TestForeignTouchBug.hs, ghc version 6.2.2, this gives .../foreigntouchbug ./a.out hit enter here before finalizing A after finalizing A before finalizing B after finalizing B hit enter here I expected the order of the finalizer calls be be the other way around, since the finalizer for the Bs explicitly touches the A value. The problem is that the runtime is running all outstanding finalizers at the end of execution, without regard for GC dependencies like the ones introduced by touchForeignPtr. I've been planning to remove this automatic running of finalizers for other reasons. However, then you will get absolutely no guarantee that your finalizer will ever run at all (indeed, the property isn't always true right now, but it is usually true). Let me share with you something that I've come to appreciate over the last few years: Finalizers are almost always not the right thing. Finalizers look terribly attractive, but often lead to a huge can of worms - best avoided if at all possible. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bug in touchForeignPtr?
Some thoughts on this, Whilst I agree that finalizers are best avoided, it must be possible to order the finalizers for running on exit... Perhaps a simple multi-pass algorith would do? (ie: run all finalizers that do not refer to other objects with finalizers - repeat until no objects with finalizers remain. What can be done about loops I am not sure (where A refers to B which refers to A and both have finalizers)... The alternative would seem to be writing your finilizers such that they first call the finalizers on any refered objects which haven't been finalized yet (In the case of loops if we specify running the finalizers on any objects refered to on which the finalizer has not been entered yet - it should work too) Whatever happens I think it must make sure all system resources allocated by a program are freed on exit - otherwise the machine will have a resource leak and will need rebooting eventually. Keean. Simon Marlow wrote: The problem is that the runtime is running all outstanding finalizers at the end of execution, without regard for GC dependencies like the ones introduced by touchForeignPtr. I've been planning to remove this automatic running of finalizers for other reasons. However, then you will get absolutely no guarantee that your finalizer will ever run at all (indeed, the property isn't always true right now, but it is usually true). Let me share with you something that I've come to appreciate over the last few years: Finalizers are almost always not the right thing. Finalizers look terribly attractive, but often lead to a huge can of worms - best avoided if at all possible. Cheers, Simon ___ 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: unlit/ghci does not work on DOS file
On 18 November 2004 20:31, Christian Maeder wrote: calling unlit on a DOS file fails, whereas hugs is able to process the same file (under unix). Christian Prelude readFile Test.lhs = putStrLn . show \r\n module Test where\r\n\r\n Prelude :l Test.lhs Test.lhs line 2: unlit: Program line next to comment phase `Literate pre-processor' failed (exitcode = 1) Thanks, fixed. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
User-defined operators and compound expressions using Happy
Hi there folks, once again, I've got a question related to Happy (I've got version 1.13 at the moment). Maybe, it's even more a question on formal languages, but well... How can I write a grammar that can cope with user-defined operators (of different precedences/associativities) and compound expression like function calls, if-then-else- and case-statements and the like. I tried to write it down straight forwardly, but failed terribly (alas, I didn't keep it, so I can't show you - if someone of you is versed in this issue, I can try to explain the language's constructs). Thank you so much, Frank-Andre Riess ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: proposal for ghc-pkg to use a directory of .conf files
On 21 November 2004 00:56, Isaac Jones wrote: The systems that would want to do this kind of thing, such as Debian, have other mechanisms for deciding whether packages conflict, etc. IIRC, this is the argument I just used against adding support for multiple libraries in Cabal, so I guess I agree :-D Over-all I'm kinda neutral about whether HC-pkg needs to be an opaque interface to the packaging system. What are the advantages to this? Well, for one thing it allows us flexibility in how we store the package database. In GHC, I'm using the show/read form of [InstalledPackageInfo] to store the database, but it'd be nice if I could use binary serialisation in the future. To support a directory of config files, we don't have to expose the complete format, though. As long as hc-pkg can process the InstalledPackageInfo to produce the native format into a file, then we just ship that file with the distribution. So I'm fine with this, as long as we're not specifying the contents of the *.conf file. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bug in touchForeignPtr?
Keean Schupke wrote: [...] Whatever happens I think it must make sure all system resources allocated by a program are freed on exit - otherwise the machine will have a resource leak and will need rebooting eventually. That's an OS task IMHO, not really the task of an RTS. Looks like you're working on WinDoze... (sorry, couldn't resist :-) Cheers, S. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bug in touchForeignPtr?
Nope there are some unix resources that c exit routines do not free like semaphores. Sven Panne wrote: Keean Schupke wrote: [...] Whatever happens I think it must make sure all system resources allocated by a program are freed on exit - otherwise the machine will have a resource leak and will need rebooting eventually. That's an OS task IMHO, not really the task of an RTS. Looks like you're working on WinDoze... (sorry, couldn't resist :-) Cheers, S. ___ 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: Bug in touchForeignPtr?
On Monday 22 November 2004 14:45, Simon Marlow wrote: On 20 November 2004 23:02, Benjamin Franksen wrote: I am using Foreign.Concurrent.newForeignPtr and touchForeignPtr inside the finalizers to express liveness dependencies as hinted to by the documentation. This doesn't seem to work, though, or at least I can't see what I've done wrong. I attached a test module; compiled with ghc -fglasgow-exts --make TestForeignTouchBug.hs, ghc version 6.2.2, this gives .../foreigntouchbug ./a.out hit enter here before finalizing A after finalizing A before finalizing B after finalizing B hit enter here I expected the order of the finalizer calls be be the other way around, since the finalizer for the Bs explicitly touches the A value. The problem is that the runtime is running all outstanding finalizers at the end of execution, without regard for GC dependencies like the ones introduced by touchForeignPtr. I understand that there are situations where finalizers cannot be guaranteed to run: First because of an unconditional termination signal (SIGKILL), second because of circular dependencies resulting in a deadlock. I don't understand why it is necessary to performGC explicitly, in order to run finalizers at *normal* program termination and without a deadlock. BTW, the sensible thing to do in this case would be to throw an exception whenever a deadlock condition is detected. (That is, if it can be detected.) However, what I don't understand is why touchForeignPtr is not honored in my example program: Note that the output text lines from the finalizers appear *before* the last action in the program (which is a second getChar). The finalizers *are* called by the GC, and still the order is wrong. I've been planning to remove this automatic running of finalizers for other reasons. However, then you will get absolutely no guarantee that your finalizer will ever run at all (indeed, the property isn't always true right now, but it is usually true). It is unclear to me what usually means, here. Wouldn't it be better to state the conditions under which they are called resp. aren't? Documenting the current state of affairs would be to say - Finalizers are *not* guaranteed to run (instead they usually are, whatever that means). - Calling touchForeignPtr does *not* guarantee that the targeted foreignPtr is not finalized before this call. This would make it obvious that finalizers are not a reliable tool (which they aren't, at the moment). Let me share with you something that I've come to appreciate over the last few years: Finalizers are almost always not the right thing. Finalizers look terribly attractive, but often lead to a huge can of worms - best avoided if at all possible. I am ready to believe this, but I am nevertheless somewhat disturbed. I use finalizers to automatically reclaim resources from a foreign library. If I don't use them, these resources must be reclaimed explicitly. This is bad for two reasons: (1) The programmer has to remember to reclaim resources. (2) Handles for such resources become invalid after reclamation. If finalizers are not the right thing, what else is? Ben -- Top level things with identity are evil.-- Lennart Augustsson ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bug in touchForeignPtr?
If finalizers are not the right thing, what else is? I've found that when writing an interface to a C library that requires resource management, it's much better to use the withX (see Control.Exception.bracket) style of function than to use finalizers - programs are much easier to reason about and debug. Abe ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bug in touchForeignPtr?
Abraham Egnor wrote: I've found that when writing an interface to a C library that requires resource management, it's much better to use the withX (see Control.Exception.bracket) style of function than to use finalizers - programs are much easier to reason about and debug. ... and have a much more deterministic behaviour regarding resource consumption. This is a very important point which is often forgotten. Cheers, S. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bug in touchForeignPtr?
Keean Schupke wrote: Nope there are some unix resources that c exit routines do not free like semaphores. Which library/OS calls do you mean exactly? I always thought that files are the only resources surviving process termination. Cheers, S. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: User-defined operators and compound expressions using Happy
On Mon, 2004-11-22 at 17:48 +0100, Frank-Andre Riess wrote: Hi there folks, once again, I've got a question related to Happy (I've got version 1.13 at the moment). Maybe, it's even more a question on formal languages, but well... How can I write a grammar that can cope with user-defined operators (of different precedences/associativities One standard solution is to parse user defined operators as if they were all one precedence/associativity and then re-associate them later once you know what the precedence and associativity of each operator is. That way the parser grammar does not need to be adjusted on the fly. So you wold parse 1+2*3 as [LiteralInt 1, Op '+', LiteralInt 2, Op '*', LiteralInt 3] and then later turn that into BinOp '+' (LiteralInt 1) (BinOp '*' (LiteralInt 2) (LiteralInt 3)) using your mapping of operators to precedence/associativity. Duncan ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bug in touchForeignPtr?
Semaphores (SYSV style) are not freed automatically. Currenly I am using C's at_exit funtion (which is even called on a signal)... Perhaps this is the way to deal with foreign resources... bracket notation and at_exit to clean up on signals? Keean. Sven Panne wrote: Keean Schupke wrote: Nope there are some unix resources that c exit routines do not free like semaphores. Which library/OS calls do you mean exactly? I always thought that files are the only resources surviving process termination. Cheers, S. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: User-defined operators and compound expressions using Happy
On 2004 nov 22, at 17:48, Frank-Andre Riess wrote: Hi there folks, once again, I've got a question related to Happy (I've got version 1.13 at the moment). Maybe, it's even more a question on formal languages, but well... How can I write a grammar that can cope with user-defined operators (of different precedences/associativities) and compound expression like function calls, if-then-else- and case-statements and the like. I tried to write it down straight forwardly, but failed terribly (alas, I didn't keep it, so I can't show you - if someone of you is versed in this issue, I can try to explain the language's constructs). One way of doing this using combinator based parsing (where you can generate parsers dynamically) is to read the fixity declarations, and to use the result of this to build the precedence parser. This idea has been sketched in: S. D. Swierstra and P. R. Azero Alcocer. Fast, Error Correcting Parser Combinators: a Short Tutorial. In J. Pavelka, G. Tel, and M. Bartosek, editors, SOFSEM'99 Theory and Practice of Informatics, 26th Seminar on Current Trends in Theory and Practice of Informatics, volume 1725 of LNCS, pages 111--129, November 1999. If you do not have access to this I will be happy to send it to you, Doaitse Swierstra == some text (created from the pdf) from this paper As an example of what can be done we will now show how to construct parsers dynamically by writing a parser for an expression language with infix operators. An example input is: (L+R*)a+b*(c+d) and the code we want to generate is: abcd+*+ which is the reversed Polish notation of the input expressions. The text (L+R*) indicates that + is left (L) associative and has lower priority than *, which is right (R) associative. In this way an unlimited number of operators may be specified, with relative priorities depending on their position in this list. We start by defining a function that parses a single character identifier and returns as its result that identifier in the form of a string: pVar = (\c - [c]) $ pAnyOf ['a'..'z'] . The next step is to define a function that, given the name of an operator, recognizes that operator and as a result returns a function that will concatenate the two arguments of that operator and postfix it with the name of the operator, thus building the reversed Polish notation: pOp name = (\ left right - left++right++[name]) $ pSym name Note that, by using the operator $ we indicate that we are not interested in the recognized operator; we already know what this is since it was passed as a parameter. Next we de ne the function compile. For this we introduce a new combinator @, that takes as its left hand side operand a parser constructor f and as its right hand side operand a parser g. The results v of parsing a pre x of the input with g, are used in calling f; these calls, in their turn, result in new parsers which are applied to the rest of the input: (f @ g) input = [ f v rest | (v, rest) - g input ] Since our input consists of two parts, the priority declarations and the expression itself , we postulate that the function compile reads: compile = pRoot @ pPrios First we focus on the function pRoot, that should take as argument the result of recognizing the priorities. Here we will assume that this result is a function that, given how to parse an operand, parses an expression constructed out of operands and the de ned operators: pRoot prios = let pExpr = prios (pVar | pParens pExpr) in pExpr There is a difference between an operator that occurs in the declaration part of the input and one in the expression part: the former may be any operator, whereas the latter can only be an operator that has been declared before. For the priority declaration part we thus introduce a new parser that recognizes any operator, and returns a parser that compiles the just recognized operator using the function pOp defined before: pAnyOp = pOp $ pAnyOf +*/-^ just some possible operators Now suppose we have recognized a left and a right associative operator resulting in operator compilers pLeft and pRight. Out of these we can construct a function that, given the operand parser, parses infix expressions containing pLeft and pRight occurrences: pLR factor = (pChainl pLeft . pChainr pRight) factor. Generalizing this pattern to an unlimited number of operators we now deduce the definition: pPrios = pParens $ pFoldr ((.), id) (( pChainl $ pSym 'L' | pChainr $ pSym 'R' ) * pAnyOp ) Let us now compare once more this approach with the situation where we would have used a special parser generator. In the combinator approach we can freely introduce all kinds of abbreviations by defining new combinators in terms of existing ones; furthermore we may de ne higher order combinators that take arguments and return values that may be parsers. This is a property we get for free
Re: Bug in touchForeignPtr?
On Monday 22 November 2004 18:55, Sven Panne wrote: Abraham Egnor wrote: I've found that when writing an interface to a C library that requires resource management, it's much better to use the withX (see Control.Exception.bracket) style of function than to use finalizers - programs are much easier to reason about and debug. ... and have a much more deterministic behaviour regarding resource consumption. This is a very important point which is often forgotten. Ok, the 'withX' pattern solves both of the problems I mentioned and in addition is more deterministic (and, using bracket, also exception safe). Maybe I should use it instead of finalizers. However, I wonder if it is general enough to be the only method exported from a library. I doubt it, otherwise there would be no 'openFile' and 'hClose' in System.IO but only a 'withFile'. Do you recommend supplying 'newX' and 'freeX' in addition to 'withX'? Or should I rather use 'newX' plus finalizers for those (rare?) cases where 'withX' is not general enough? Ben -- Top level things with identity are evil.-- Lennart Augustsson ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bug in touchForeignPtr?
Keean Schupke wrote: C exit routines aren't responsible for freeing OS resources; the OS is. The fact that the SysV IPC objects aren't freed on exit is intentional; they are meant to be persistent. For the same reason, the OS doesn't delete upon termination any files which the process created. Right, which is why if you want to clean up temporary files, or temporary semaphores the OS doesn't do it for you, and you need to put some routine inplace to do it (using at_exit)... It seems this is the only way to guarantee something gets run when a program exits for whatever reason. There isn't any way to *guarantee* that something is run upon termination. The program may be terminated due to SIGKILL (e.g. due to a system-wide lack of virtual memory). If you run out of stack, you may not be able to call functions to perform clean-up. Also, if the program crashes, handling the resulting SIGSEGV (etc) is likely to be unreliable, as the memory containing the resource references may have been trashed. Calling remove() on a filename which might have been corrupted is inadvisable. Also, at_exit() isn't standard. atexit() is ANSI C, but that is only supposed to be called for normal termination (exit() or return from main()), not for _exit() or fatal signals. -- Glynn Clements [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bug in touchForeignPtr?
Although, this does remind me. A suitable atexit-equivalant in the haskell libraries would be much appreciated. John -- John Meacham - repetae.netjohn ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Top Level TWI's again was Re: [Haskell] Re: Parameterized Show
On Friday 19 Nov 2004 2:27 pm, Benjamin Franksen wrote: Implicit parameters are evil, agreed. Their deficiencies should be added as a warning to the docs (with many exclamation marks). Well I dunno. Maybe whatever's currently wrong with them can be fixed up. But I can't say they're something I've ever felt a need for. But it's ironic that some folk advocate the use of this (mis?)feature as a solution to the (so-called) global variables problem. I don't like this idea at all, but at least they recognise that there is a problem. But toplevel things with identity (TWI) are evil as well, *especially* if they are easy to use. Just repeating this again and again doesn't make it any more true. Neither you or any of the other nay-sayers have provided any evidence or credible justification for this assertion, nor have any of you provided any workable alternative for even the simplest example. Lennart has yet to explain how he proposes to implement his supposedly safer openDevice. You have yet to explain how you propose to deal with stdout etc.. BTW, top level TWI's are easy to create anyway, via the *unsound* unsafePerformIO hack. The evil here not their existance, it is the unsoundness of their creation mechanism. Given that in the absence of anything better folk are going to continue to use this (because it really is necessary sometimes), objecting to the provision of a sound alternative is just silly. This is the militant denial I was talking about. And of course there's one top level TWI that none of us can live without. I am refering to the unique and stateful world that is implicitly referenced by all IO operations (with the possible exception of those operations I would like to put in the SafeIO monad). So is this evil too? Perhaps it is, but if so, I'd like to know how you propose to live without it and what purpose the IO monad would serve in such a situation. Regards -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Top Level TWI's again was Re: [Haskell] Re: Parameterized Show
Adrian Hey wrote: Just repeating this again and again doesn't make it any more true. Ditto... I for one think the best solution is to use the language as intended and pass the values as function arguments. As pointed out on this list - the only possible situation where you cannot do this is when interfacing to a badly written C library. In which case do your one-shot initialisation in C, as you will be importing foreign functions anyway. Neither you or any of the other nay-sayers have provided any evidence or credible justification for this assertion, nor have any of you provided any workable alternative for even the simplest example. Lennart has yet to explain how he proposes to implement his supposedly safer openDevice. You have yet to explain how you propose to deal with stdout etc.. openDevice would use OS semaphores (like the namedSem library I posted to the cafe) - the OS is the only thing that can deal with device driver initialisations. Infact the OS driver should multiplex single access devices such that access is serialised. I guess stdin, stdout etc should be passed to main as arguments like you would any other file handle. Although if file handles are simply Ints, then there is nothing wrong with having: stdin = 0 stdout = 1 stderr = 2 In this case they are not IO actions anyway. And of course there's one top level TWI that none of us can live without. I am refering to the unique and stateful world that is implicitly referenced by all IO operations (with the possible exception of those operations I would like to put in the SafeIO monad). So is this evil too? Perhaps it is, but if so, I'd like to know how you propose to live without it and what purpose the IO monad would serve in such a situation. This is true - but only because unsafePerformIO exists. Without it World is simply a value passed via the IO Monad. I would ask an alternative question - is it possible to live without unsafePerformIO? I have never needed to use it! Keean ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Top Level TWI's again was Re: [Haskell] Re: Parameterized Show
On Mon, Nov 22, 2004 at 07:27:44PM +0100, Lennart Augustsson wrote: [snip] I admit there are proper uses of global variables, but they are very rare. You have not convinced me you have one. -- Lennart It's with some trepidation I bring a problem as a total newbie, but I've been obsessed with this and hung up on it ever since I decided a couple of weeks ago to learn Haskell by using it. Some brief background: A while back I decided I wanted a simple 'concept mapping' program that would work the way I work instead of the way someone else works. I envisioned a GUI with a canvas and an entry box (TK/tcl). I type a concept name into the entry box, and it shows up on the canvas (initially in a slightly randomized position), in a box, with a unique sequenced identifier. The identifier is also used as a canvas tag for the item. Similar input for relations between concepts. I think that's enough description for now. Initially, I started programming this with PerlTK, but that effort was interrupted for a few weeks. When I got back to it, I decided to do it in Python instead. But that effort also got interrupted for a few weeks. Before I got back to it, I ran across some material on Haskell I've had in my files for a few years, and decided that I'd use this as a vehicle to actually learn Haskell. (This all sounds a bit unfocused, and it is: I'm retired, sometimes describe myself as an ex mathematician or an ex-PhD having spent years in the aerospace industry instead of academia. Anyway, I have both the luxury and lack of focus of no deadlines, no pressure to publish. I hope to use Haskell to further my main hobby of knowledge representation.) In perl, my labels/tags were very easy: In the initialization code: my @taglist = (); my $nextag = a; and in the callback for the entry box: push(@taglist,$nextag); $nextag++; (With the starting tag of a this results in a,z,aa,ab,...) Also, ultimately, I want to be able to save my work and restart the next day (say) picking up the tags where I left off. I'm darned if I can see how to do this in a callback without a global variables (and references from other callbacks, by the way). In looking for a method, I've discovered that Haskell is a lot richer than I thought (or learned when I tinkered with it back in the late '90s ). I've found out about (but don't know how to use properly) implicit parameters, linear implicit parameters, unsafePerformIO, safe and sound implementation of polymorphic heap with references and updates (Oleg Kiselyov, (http://www.haskell.org/pipermail/haskell/2003-June/011939.html), implicit configurations, phantom types, ... I've also found warnings against many of these. I'm inclined to try the unsafePerformIO route as being the simplest, and most commonly used, even though perhaps the least haskell-ish. I like implicit configurations, but couldn't begin to say I understand them yet, and it's a bit heavy for a novice. In a nutshell: I want to use the old value of a tag to compute the new value, in a callback, I want to access the tag from other callbacks, and I want to the value to a mutable list from within the callback. I'd certainly be interested in doing without global variables, and would appreciate any advice. (By the way, I'm using Linux, and so far it looks like HTk is my choice for the GUI interface.) Best, John Velman ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Top Level TWI's again was Re: [Haskell] Re: Parameterized Show
On Mon, 2004-11-22 at 23:34, John Velman wrote:
In a nutshell:
I want to use the old value of a tag to compute the new value, in a
callback,
I want to access the tag from other callbacks, and
I want to the value to a mutable list from within the callback.
I'd certainly be interested in doing without global variables, and would
appreciate any advice.
For GUI programming you don't need global variables. You can partially
apply all those values to the callback that are necessary. In
particular, those values can be MVars or IORefs which are like pointers
to a value (i.e. you can modify them). For example to draw a bit of
graphics:
canvas - drawingAreaNew
text - canvas `widgetCreateLayout` Hello World.
canvas `onExpose` updateCanvas canvas text
where the function updateCanvas takes 3 arguments:
updateCanvas :: DrawingArea - PangoLayout - Event - IO Bool
updateCanvas canvas text (Expose { area=rect }) = do
(By the way, I'm using Linux, and so far it looks like HTk is my choice for
the GUI interface.)
I don't know if HTk is still maintained. The most popular GUI toolkit is
wxHaskell now; if you're only developing on Unix then gtk2hs might be a
choice.
Axel.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] foldlWhile
On Saturday 20 November 2004 10:47, Serge D. Mechveliani wrote: Is such a function familia to the Haskell users? foldlWhile :: (a - b - a) - (a - Bool) - a - [b] - a Maybe this link is of interest to you: http://okmij.org/ftp/Haskell/#fold-stream Ben -- Top level things with identity are evil.-- Lennart Augustsson ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Problem with overlapping class instances
Once again, the Haskell class system is proving rather subtle for me. On this occasion, I'm getting an overlapping class instance error which I think should be fully disambiguated by the supplied class context. The code below (end of message) is a .lhs file that reproduces the problem in Hugs, with external dependencies from my working codebase stripped out. It should be possible to simply load it (or this whole email) to get the same error: [[ Reading file D:\Cvs\DEV\HaskellDL\spike-overlap-conceptexpr.lhs: ERROR D:\Cvs\DEV\HaskellDL\spike-overlap-conceptexpr.lhs:30 - Overlapping inst ances for class ConceptExpr *** This instance : ConceptExpr (a b) *** Overlaps with : ConceptExpr AtomicConcept *** Common instance : ConceptExpr [Char] ]] The line referred to as this instance is: instance (ConceptWrapper cw c, ConceptExpr c) = ConceptExpr (cw c) where The reported overlapping instance is [Char], which I take to be derived from the type constructor [] applied to type Char, this yielding a form that matches (cw c). But the instance ConceptExpr (cw c) is declared to be dependent on the context ConceptWrapper cw c, which has *not* been declared for the type constructor []. GHCi with -fglasgow-exts is no more informative. What am I missing here? #g -- [Source code follows] spike-overlap-ConceptExpr.lhs - type AtomicConcepts a = [(AtomicConcept,[a])] type AtomicRoles a = [(AtomicRole ,[(a,a)])] type TInterpretation a = ([a],AtomicConcepts a,AtomicRoles a) class (Eq c, Show c) = ConceptExpr c where iConcept :: Ord a = TInterpretation a - c - [a] ... type AtomicConcept = String -- named atomic concept Declare AtomicConcept and AtomicRole as instances of ConceptExpr and RoleExpr (AtomicRole is used by AL, and including AtomicConcept here for completeness). instance ConceptExpr AtomicConcept where iConcept = undefined ... To allow a common expression to support multiple description logics, we first define a wrapper class for DLConcept and DLRole: class ConceptExpr c = ConceptWrapper cw c | cw - c where wrapConcept :: c - cw c - cw c getConcept :: cw c - c Using this, a ConceptWrapper can be defined to be an instance of ConceptExpr: This is line 30: instance (ConceptWrapper cw c, ConceptExpr c) = ConceptExpr (cw c) where iConcept = iConcept . getConcept Error message: Reading file D:\Cvs\DEV\HaskellDL\spike-overlap-conceptexpr.lhs: ERROR D:\Cvs\DEV\HaskellDL\spike-overlap-conceptexpr.lhs:30 - Overlapping inst ances for class ConceptExpr *** This instance : ConceptExpr (a b) *** Overlaps with : ConceptExpr AtomicConcept *** Common instance : ConceptExpr [Char] Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problem with overlapping class instances
Instance selection and thereby overlapping resolution is *independent* of constraints. It is defined to be purely syntactical in terms of instance heads. See the HList paper for some weird examples. Ralf Graham Klyne wrote: The reported overlapping instance is [Char], which I take to be derived from the type constructor [] applied to type Char, this yielding a form that matches (cw c). But the instance ConceptExpr (cw c) is declared to be dependent on the context ConceptWrapper cw c, which has *not* been declared for the type constructor []. GHCi with -fglasgow-exts is no more informative. What am I missing here? ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Top Level TWI's again was Re: [Haskell] Re: Parameterized Show
[Switching to Haskell-cafe] At 11:26 22/11/04 +, you wrote: I would ask an alternative question - is it possible to live without unsafePerformIO? I have never needed to use it! I have used it once, with reservations, but at the time I didn't have the time/energy to find a better solution. (The occasion of its use was accessing external entities within an XML parser; by making the assumption that the external entities do not change within any context in which results from a program are compared, I was able to satisfy the proof obligation of not causing or being sensitive to side effects.) The reason this was important to me is that I wanted to be able to use the parser from code that was not visibly in the IO monad. For me, treating Web data transformations as pure functions is one of the attractions of using Haskell. (Since doing that, I had an idea that I might be able to parameterize the entity processing code on some Monad, and use either an Identity monad or IO depending on the actual requirements. This way, I could keep pure XML processing out of the IO monad, but use IO when IO was needed.) In short: I think it's usually possible to avoid using unsafePerformIO, but I'd be reluctant to cede it altogether, if only for sometimes quick-and-dirty pragmatic reasons. #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Top Level TWI's again was Re: [Haskell] Re: Parameterized Show
Obviously without knowing the details I am speculating, but would it not be possible to do a first pass of the XML and build a list of files to read (a pure function) this returns its result to the IO monad where the files are read and concatenated together, and passed to a second (pure functional) processing function. If written well this can take advantage of lazy execution, so both functions end up running concurrently. It seems to me that as unsafePerformIO is not in the standard and only implemented on some compilers/interpreters, that you limit the portability of code by using it, and that it is best avoided. Also as any safe use of unsafePerformIO can be refactored to not use it I could certainly live without it. Keean. Graham Klyne wrote: [Switching to Haskell-cafe] I have used it once, with reservations, but at the time I didn't have the time/energy to find a better solution. (The occasion of its use was accessing external entities within an XML parser; by making the assumption that the external entities do not change within any context in which results from a program are compared, I was able to satisfy the proof obligation of not causing or being sensitive to side effects.) The reason this was important to me is that I wanted to be able to use the parser from code that was not visibly in the IO monad. For me, treating Web data transformations as pure functions is one of the attractions of using Haskell. (Since doing that, I had an idea that I might be able to parameterize the entity processing code on some Monad, and use either an Identity monad or IO depending on the actual requirements. This way, I could keep pure XML processing out of the IO monad, but use IO when IO was needed.) In short: I think it's usually possible to avoid using unsafePerformIO, but I'd be reluctant to cede it altogether, if only for sometimes quick-and-dirty pragmatic reasons. #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Top Level TWI's again was Re: [Haskell] Re: Parameterized Show
On Monday 22 November 2004 23:22, Keean Schupke wrote: It seems to me that as unsafePerformIO is not in the standard and only implemented on some compilers/interpreters, that you limit the portability of code by using it, and that it is best avoided. Also as any safe use of unsafePerformIO can be refactored to not use it I could certainly live without it. With one exception: If a foreign function (e.g. from a C library) is really pure, then I see no way to tell that to the compiler other than using unsafePerformIO. IIRC, unsafePerformIO is in the standard FFI libraries. Ben -- Top level things with identity are evil.-- Lennart Augustsson ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Top Level TWI's again
Benjamin Franksen writes: If a foreign function (e.g. from a C library) is really pure, then I see no way to tell that to the compiler other than using unsafePerformIO. What's the problem with importing it with a pure signature? Like this: foreign import ccall unsafe sin :: CDouble - CDouble Peter ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
