Claus Reinke wrote:
i had been hoping for some more feedback regarding my attempt to address
parts of ticket #1617 (unrestricted variant of :browse), as well as
emails regarding capturing the output of GHCi commands
as Haskell Strings.
http://www.haskell.org/pipermail/glasgow-haskell-bugs/2007-August/009735.html
http://www.haskell.org/pipermail/glasgow-haskell-users/2007-August/013040.html
http://hackage.haskell.org/trac/ghc/ticket/1617
but that was before the branch, and i'd like to get at
least an initial version of this functionality into 6.8.
One reason I haven't responded is that I have an uneasy feeling about what
you're trying to do here. You want to use GHCi programmatically, and
you're depending on details of GHCi's user interface in your tool. We want
to be free to change GHCi's user interface whenever we like, without
worrying about breaking 3rd-party tools (of course we need to document any
changes).
I realise this already happens: the emacs GHCi mode talks to GHCi directly,
and GuiHaskell does too. But I hereby declare that this is the Wrong Way
To Do It. The right way is to use the GHC API, starting from your own copy
of the GHCi front-end if you like.
Having said that, of course it's up to you if you want to use GHCi for this
purpose, and we'll certainly apply patches within reason that help you, but
I don't want to commit to supporting features of GHCi that are only used by
layered tools, nor commit to not changing the UI.
Ok, rant over.
so i've implemented (draft patches wrt current head attached):
- :browse! a variant of :browse, that does not filter out
children, and does not display children in context of their parents
(as described; this still suffers from the issue that i have not
found a function to display the stored type of class methods
correctly; it also does not yet account for qualified names,
when their unqualified versions are available, nor does it
address the issue of not updating properly on :reload, both
issues are described in ticket #1617)
I think this is low-impact enough that it could go in. I'm not terribly
keen on the syntax - there's no precedent for a ! suffix, and it feels a
bit obscure. How about ':names'?
[btw, how did the debugger manage to steal :b from
:browse? i think this should be changed back to the
traditional (pre 6.7) behaviour, but have not done so yet]
This was partly accidental, partly because I'm used to using 'b' to set a
breakpoint in gdb, and partly because I think it'll be used more often than
:browse. But I don't feel too strongly about it.
- GHCi command output capture (again, as described)
for :help, :browse, :info, :set, :show (showModules,
showBindings,showBkptTable,showContext).
mostly this has been about refactoring hardcoded i/o
into separate i/o and rendering, so that the rendered
output can be captured in a variable ('output'). the
capturing itself is isolated in a single function ('out'),
so changing the variable name would be easy.
This part I'm not sure about at all. We're really getting into "you should
be using the GHC API" territory here. There are various holes in what
you've done: what if the variable "output" is already bound? What if
"System.IO.putStrLn" is in scope and means something else? What if stdout
has been redirected. etc. And the fact that this only applies to certain
commands, and not to output generated by ordinary expressions/statements,
means it feels too ad-hoc to me.
i would still like to know how one is supposed to display
the type of class methods,
doesn't ':t (+)' work?
and why 'it' is not bound in the same naive
way i've used to bind 'output'.
Because 'it' is bound either by a let or a monadic binding, depending on
the type of the expression.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
