While starting to learn more about webfunctions I have noticed that hasktags doesn't recognize rwUserName and rwPasswd in the following code: data LogInController = LogInController {rLoggedIn::R Bool, rwUserName::RWE String, rwPasswd::RWE String} When using spaces it does LogInController {rLoggedIn :: R Bool, rwUserName :: RWE String, rwPasswd :: RWE String} This small patch introduces a now mywords function which recognizes a::b as words a,::,b which is what we need here (?) It does work in the above example. Here is the diff. Is it worth applying? 154c154 < let wordlines = map words aslines ---
let wordlines = map mywords aslines
161a162,174
-- my words is mainly copied from Data.List. -- difference abc::def is split into three words instead of one. mywords :: String -> [String] mywords (':':':':xs) = "::" : mywords xs mywords s = case dropWhile {-partain:Char.-}isSpace s of "" -> [] s' -> w : mywords s'' where (w, s'') = myBreak s' myBreak [] = ([],[]) myBreak (':':':':xs) = ([], "::"++xs) myBreak (' ':xs) = ([],xs); myBreak (x:xs) = let (a,b) = myBreak xs in (x:a,b)
Marc Weber
Hi Marc, On Sat, Feb 17, 2007 at 05:12:13AM +0100, Marc Weber wrote:
154c154 < let wordlines = map words aslines ---
let wordlines = map mywords aslines
161a162,174
-- my words is mainly copied from Data.List. -- difference abc::def is split into three words instead of one. mywords :: String -> [String] mywords (':':':':xs) = "::" : mywords xs
I'm not familiar with the code, but this looks like it is just a quick fix for this particular case, while a proper fix would involve something like breaking lines into blocks of characters in the same class (i.e. a weak form of lexing by the Haskell Report rules). Is that right, or does it turn out that the :: case is the only thing we need to worry about? Better still, of course, if anyone was interested in spending some time on this, would be to either (portably) use Language.Haskell to do the lexing or (GHC-only) use the GHC API to do the lexing. I think someone might actually have been looking at doing the latter already? Thanks Ian
154c154 < let wordlines = map words aslines ---
let wordlines = map mywords aslines
161a162,174
-- my words is mainly copied from Data.List. -- difference abc::def is split into three words instead of one. mywords :: String -> [String] mywords (':':':':xs) = "::" : mywords xs
I'm not familiar with the code, but this looks like it is just a quick fix for this particular case, Yes. It is only a quick fix for this particular case because I did need it ;-)
I don't wont to spend more time on this right now but perhaps I will after making my current project work.. Marc W.
On Wed, Feb 21, 2007 at 02:14:10AM +0100, Marc Weber wrote:
154c154 < let wordlines = map words aslines ---
let wordlines = map mywords aslines
161a162,174
-- my words is mainly copied from Data.List. -- difference abc::def is split into three words instead of one. mywords :: String -> [String] mywords (':':':':xs) = "::" : mywords xs
I'm not familiar with the code, but this looks like it is just a quick fix for this particular case, Yes. It is only a quick fix for this particular case because I did need it ;-)
I don't wont to spend more time on this right now but perhaps I will after making my current project work..
I've applied this fix. I've also tried to extract the essential information from this thread and put it on http://www.haskell.org/haskellwiki/Tags It could do with some filling out, though. Particularly useful would be explanations of how to use tags with common editors (vim and emacs being the obvious two) and what benefits they give you. Thanks Ian
Indeed, Chris Ryder and Simon Thompson claim to have done so in this
paper (complete with source code)
http://www.cs.kent.ac.uk/pubs/2005/2266/content.pdf
Could this replace the "old-style" hasktags?
Cheers,
JP.
On 2/20/07, Ian Lynagh
Better still, of course, if anyone was interested in spending some time on this, would be to either (portably) use Language.Haskell to do the lexing or (GHC-only) use the GHC API to do the lexing. I think someone might actually have been looking at doing the latter already?
Ian Lynagh wrote:
Hi Marc,
On Sat, Feb 17, 2007 at 05:12:13AM +0100, Marc Weber wrote:
154c154 < let wordlines = map words aslines ---
let wordlines = map mywords aslines
161a162,174
-- my words is mainly copied from Data.List. -- difference abc::def is split into three words instead of one. mywords :: String -> [String] mywords (':':':':xs) = "::" : mywords xs
I'm not familiar with the code, but this looks like it is just a quick fix for this particular case, while a proper fix would involve something like breaking lines into blocks of characters in the same class (i.e. a weak form of lexing by the Haskell Report rules). Is that right, or does it turn out that the :: case is the only thing we need to worry about?
Better still, of course, if anyone was interested in spending some time on this, would be to either (portably) use Language.Haskell to do the lexing or (GHC-only) use the GHC API to do the lexing. I think someone might actually have been looking at doing the latter already?
Yes, there's Norman Ramsey and Kathleen Fisher's partial hasktags implementation on top of the GHC API: http://hackage.haskell.org/trac/ghc/ticket/946 I think incorporating small fixes to the existing hasktags in the meantime is fine, though. We're still using it, and it may be a while before the GHC API version is working well enough. Cheers, Simon
Yes, there's Norman Ramsey and Kathleen Fisher's partial hasktags implementation on top of the GHC API:
http://hackage.haskell.org/trac/ghc/ticket/946
I think incorporating small fixes to the existing hasktags in the meantime is fine, though. We're still using it, and it may be a while before the GHC API version is working well enough.
if we're talking interim solutions, also try something like: echo ":ctags" | ghci -v0 Main.hs (or etags, if you prefer; see :? in ghci). from what i remember, that should give more useful results than hasktags. there is probably a good reason why some people still use hasktags, though, and i'd be interested to hear it (perhaps add it to the ticket?). thanks, claus
On 21-feb-2007, at 16:15, Claus Reinke wrote:
Yes, there's Norman Ramsey and Kathleen Fisher's partial hasktags implementation on top of the GHC API: http://hackage.haskell.org/trac/ghc/ticket/946 I think incorporating small fixes to the existing hasktags in the meantime is fine, though. We're still using it, and it may be a while before the GHC API version is working well enough.
if we're talking interim solutions, also try something like:
echo ":ctags" | ghci -v0 Main.hs
(or etags, if you prefer; see :? in ghci). from what i remember, that should give more useful results than hasktags. there is probably a good reason why some people still use hasktags, though, and i'd be interested to hear it (perhaps add it to the ticket?).
And some more programming actually gave me that good reason once again: the given ghci command only gives tags for exported definitions. This just plain sucks for any reasonably sized module. :) Doei, Arthur. -- /\ / | arthurvl@cs.uu.nl | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt / \/__ | you can dare to be yourself | Dance like there's nobody watching
if we're talking interim solutions, also try something like: echo ":ctags" | ghci -v0 Main.hs And some more programming actually gave me that good reason once again: the given ghci command only gives tags for exported definitions. This just plain sucks for any reasonably sized module. :)
true. if you look at the code for the :browse command just following the tag-related code, you'll see options for export-only or all top-level bindings (compare listTags with browseModule). i didn't adapt that for :ctags, but someone else could. having lots of useful example code nearby was another reason for extending ghci, rather than starting from scratch;-) but you also have to keep in mind that haskell isn't c. as an extreme example, there are people out there naming all their major types T, using qualified names to disambiguate Heap.T from Tree.T. as a less extreme example, many haskellers feel free to reuse non-exported names all over their projects. for the first example, the typical "offer-a-menu-of-all-matching-tags" is not all that helpful - i'd prefer to see the qualified tags. for the second example, the menu of tags that aren't even in scope is just plain annoying - i'd just want to see/jump to the local tag (which means that tags for all local defs would have to be generated, but only used when in scope). these are just two examples of where pattern-based tags files are not helpful; as another one, think of type class methods: if i'm hovering over a list monad's return, i'd want to jump to the monad instance for lists. so, for haskell, i'd like to see type- and module-aware tags. etc, etc. i guess what i'm trying to say is: current ghc-api-based tagsfile generators need lots more work. but working on pattern-based generators is moving in the wrong direction, if you are interested in that kind of semantics-aware ide. the current code, whether for :ctags or for the standalone variant, is just a starting point. it can be extended quite a bit without having to start from scratch, i think, but if someone has better starting points, that's fine with me. i just want to be able to use the tools!-) claus
participants (6)
-
Arthur van Leeuwen -
Claus Reinke -
Ian Lynagh -
Jean-Philippe Bernardy -
Marc Weber -
Simon Marlow