Browse thread
Re: [Caml-list] Bug in typing polymorphic variants found
-
Luc Maranget
- John Max Skaller
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2002-05-13 (16:35) |
From: | John Max Skaller <skaller@o...> |
Subject: | Re: [Caml-list] Bug in typing polymorphic variants found |
Luc Maranget wrote: > >I did the same thing, and even ran felix under ocamldebug >(another reason to use both bytecode and native compilation) > >1. I has to alter Flx_lex to compile > (suppress a self reference to the Flx_lex module) > Funny. Must be CVS change. It compiles on my system. [Yes, I see the self reference ..] > >2. By running the example (run), until it crashed > going back (back) in execution a little, and looking at the > call stack (backtrace), I found the loop : > > >#52327 Pc : 242856 Flx_pretok char 6183 >#52328 Pc : 242856 Flx_pretok char 6183 >#52329 Pc : 242856 Flx_pretok char 6183 >#52330 Pc : 242856 Flx_pretok char 6183 >#52331 Pc : 242856 Flx_pretok char 6183 >#52332 Pc : 242856 Flx_pretok char 6183 >#52333 Pc : 242856 Flx_pretok char 6183 > >etc... > > >Apparently the loop is in module Flx_pretok : > > >let pre_tokens_of_lexbuf buf state = > let lex_it() = Flx_lex.pre_flx_lex buf state in > let run = ref true in > let rec get () = > if !run > then let t = lex_it () in > match t with > | [Flx_parse.ENDMARKER] -> > run := false; > [Flx_parse.ENDMARKER] > | _ -> t @ get() <------- HERE is the recursive call > else [Flx_parse.ENDMARKER] > in get () > The above code has been working for 2 years. It hasn't been changed in 2 years. It is an infinite loop, which is terminated by finding an ENDMARKER token in the code. This token is generated by the lexer at end of file. | eof { fun state -> [ENDMARKER] } The parser creates a lot of polymorphic variants. It also takes *ages* to compile since a recent change I made: that change contains several 3 step type coercions: (a : t1 :> t2) Perhaps the parser is overflowing some table limit? -- John Max Skaller, mailto:skaller@ozemail.com.au snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia. voice:61-2-9660-0850 ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners