Another suggestion is to use pattern matching at the function level:

doLex' lexer loc [] = [makeToken EOF]
doLex' lexer loc (x:xs) = case x of
    ' '     -> more (locInc loc 1) xs
    '\n'    -> more (locNL loc) xs
    ...
    _      ->

That saves you from having to deconstruct repeatedly in your case statements.

You might also want to check out the excellent HLint (available on hackage), which will give you even more suggestions.

On Tue, May 22, 2012 at 8:36 AM, Taylor Hedberg <t@tmh.cc> wrote:
John Simon, Tue 2012-05-22 @ 10:13:07-0500:
> - My `consume` function seems basic enough that it should be library
> code, but my searches turned up empty. Did I miss anything?

   consume = span . flip elem


> - Is creating data structures with simple field names like `kind`,
> `offset`, etc a good practice? Since the names are global functions, I
> worry about namespace pollution, or stomping on functions defined
> elsewhere.

If you don't intend your module to be imported and used as a library,
then there's no reason to worry about this. If you do intend it to be
used that way, then it's probably still not worth worrying about, as
name clashes can be resolved at the import level via qualified imports
or `hiding` lists. If it ends up really being a problem, you can always
add a namespace prefix to those names, though honestly I find that kind
of ugly.

The compiler will always catch cases of ambiguity caused by multiple
definitions of the same name being in scope, so you don't have to worry
about this causing inadvertent runtime bugs.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe