Problem with 'nested' pattern matching
Hello. I'm having some trouble trying to understand exactly what's behind the rule for pattern-matching with data constructors. The code I'm having trouble with is similar to this: f (C p1 p2 (C2 p3 p4)) = ... f _ = False What happens is if f is called with (C p1 p2 (NOT_C2 ...)), I get a program error, and not False. I dug up the semantics of pattern-matching on the Report, which says, concerning data constructors: "4. Matching a non- bot value can occur against three kinds of refutable patterns: (a) Matching a non- bot value against a pattern whose outermost component is a constructor defined by data fails if the value being matched was created by a different constructor. If the constructors are the same, the result of the match is the result of matching the sub-patterns left-to-right against the components of the data value: if all matches succeed, the overall match succeeds; the first to fail or diverge causes the overall match to fail or diverge, respectively." The "overall" match refers to the whole function or the equation being considered? More specifically, in my example: if matching against C succeeds, and matching against C2 fails, should the implementation try the next equation or give a program error? I used to think that if C succeeded and C2 failed, the next equation would be tried, but it seems that is not what is happening (at least with Hugs). One workaround seems to be to change (C2 p3 p4) into a var pattern, and match the C2 constructor inside a separate case statement, but this would clutter up the code considerably (maybe not in the example case, but I intended to pattern-match against some reasonably complex structures) Is there any solution? Thank you in advance, and thanks for helping, Carlos Eduardo Scheidegger ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: n+k patterns
On 30 Jan 2002, at 12:01, [EMAIL PROTECTED] wrote: Yet for floats there may not be such an x (y = positive zero), or there may be more than one (y=2^n with n chosen so that 2^n+1 is not exactly representable but 2^n-1 is, then x could be 2^n or 2^n-1). Well, I am just a newbie in Haskell, but this reason, together with the fact that n+k patterns were designed to be used in inductive definitions do make me strongly favor the restriction of n+k patterns to the class Integral (Malcolm Wallace pointed out that there may be a use for Rational n+k patterns, but I think it would only be advisable in the case that Rational numbers were implemented explicitly with numerators and denominators). Besides that, what about deprecating n+k patterns in future Haskell reports? :) just my $0.02, Carlos Eduardo Scheidegger ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
GHC doesn't compile Happy example
Hello all.
I'm trying to use GHC to compile the example parser in Happy,
but with no success. I'm using GHC 5.02 for W2K, and I'm not
quite sure what to do to make it work. I successfully compiled
some small test cases, to see if I had installation problems, and
they compiled just fine.
First, the Happy example uses some functions that exist in
Hugs but not in GHC, like isAlpha, isDigit and isSpace (I think so,
at least, because i type ':t isAlpha' in GHCi and get 'variable not in
scope'), so I created a module called CharClasses with these
functions. So, I ran happy and generated calc.hs without any
problems.
When I try to compile calc.hs, by doing
ghc -o calc.exe calc.hs CharClasses.hs
I get:
c:/ghc/ghc-
5.02/libHSstd.a(PrelMain__1.o)(.text+0x16)://c/tmp/ghc1756.hc:
undefined reference to `__stginit_Main'
c:/ghc/ghc-
5.02/libHSstd.a(PrelMain__2.o)(.text+0x4)://c/tmp/ghc1756.hc:
undefined reference to `Main_main_closure'
c:/ghc/ghc-
5.02/libHSstd.a(PrelMain__2.o)(.text+0x33)://c/tmp/ghc1756.hc:
undefined reference to `Main_main_closure'
I tried to compile each .o file separately, but I got the exact
same errors. I don't know much about the structure of ghc and the
interactions with gcc, but this does look like a linker error, and I'm
guessing it's trying to tell me that I don't have a main function. But I
do have one, as I checked the calc.hs and the
main = getContents print . calc . lexer
is there. GHCi seems to load the module just fine, and the
parser and lexer seem to be working correctly. One strange thing
that happens is that if I run an example from the interactive mode,
it works, but if I call the main function, I get
*** Exception: calc.hs:285: Non-exhaustive patterns in function
lexer
Another strange behavior is that I can only call the main function
once. Any other call I get:
Happy main
*** Exception: illegal operation
Action: hGetContents
Handle: {loc=stdin,type=semi-closed,binary=False,buffering=line}
Reason: handle is closed
File: stdin
If I reload all modules with ':s' I can run it again, but also only
once.
I really don't know what I'm doing wrong. Can anyone help me?
Thank you in advance,
Carlos
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
WinHugs crashes reversing infinite lists
Hello all. I think I found a bug on Hugs for Windows 32 (both on the GUI version and the console). If you try to reverse an infinite list, for example: reverse (repeat 0) reverse [1..] This will make Hugs segfault. Of course, reversing an infinite list is not something you should do, but so isn't segfaulting :) GHC for W2K just freezes (as would be expected). Hope I helped, Carlos ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
