File: 231_recFunOrder.sml

package info (click to toggle)
smlsharp 4.1.0-1
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid, trixie
  • size: 123,732 kB
  • sloc: ansic: 16,725; sh: 4,347; makefile: 2,191; java: 742; haskell: 493; ruby: 305; cpp: 284; pascal: 256; ml: 255; lisp: 141; asm: 97; sql: 74
file content (30 lines) | stat: -rw-r--r-- 1,447 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
fn x => let val rec f = fn () => x 1 and g = fn () => x = x in 1 end;
fn x => let fun f () = x 1 and g () = x = x in 1 end;
fn x => let fun f () = (x 1; g()) and g () = (x = x; f x) in 1 end;
fn x => let val rec f = fn () => (x 1; g()) and g = fn () => (x = x; f x) in 1 end;
fn x => let val rec f = fn () => x = x and g = fn () => x 1 in 1 end;
fn x => let fun f () = x = x and g () = x 1 in 1 end;
fn x => let fun f () = (x = x; g()) and g () = (x x; f x) in 1 end;
fn x => let val rec f = fn () => (x = x; g()) and g = fn () => (x 1; f x) in 1 end;

(* 2012-8-4 ohori compiler/util/main/SCCFun.sml:
  SCC returns 
   * the non-connected forests in reversed order
   * elements in a connected componets in reversed order
  The strightforwardly coding the original SCC algorithm 
  results in this; i.e. the original scc algorithm visits 
  the G^T in the decreasing order of the finished time in G.
  So when we use scc in fundecls, we do the followng.
  * We make the reference ege (instead of presedence edge)
      f -> g iff fun f x = ... g  
    so that  f-componet comes earlier than g-componet in the result of
    ssc.
    This is consistent of the original order of occurrences.
  * We then take the reversal of the reversal of ssc.
    The inner reversal is necessary since the scc make a list 
    of elements in each scc-componet in reverse order ot their
    "discovery time".
*)
(* 2012-8-4 ohori
   Fixed by 4369:a93a16990a4b
 *)