Version française
Home     About     Download     Resources     Contact us    
Browse thread
Re: [Caml-list] Bug in typing polymorphic variants found
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
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