laser 0.7.0.pre1

data/status_reports/2010/12/2010-12-23.md

@@ -0,0 +1,298 @@
+# Type Annotation Grumblings
+
+I'm trying to hammer out how I want type annotations for Ruby methods
+and/or classes to work. I usually only think about methods because, well,
+they're damn-near everything in Ruby.
+
+First off, this is just for types. All other annotations will just be
+using YARD's parser, straight up. I'm just gonna fork it.
+
+I know I want to support annotations that "say" something about the type,
+because my idea is that Rubyists use Ruby for its expressivity. They expect
+every line to mean something, damn it. So I just don't accept that [DRuby](http://www.cs.umd.edu/projects/PL/druby/)
+has this right – mainly because I can't convince *myself* to use it.
+
+The type system has gotta have a simple – and I mean literally, closest to
+the fewest characters possible – way to describe each case.
+
+Given an expression `E`, I want the user to be able to simply tell Laser:
+
+* `E` has class `T`.
+* `E` is a subtype of `E`.
+* `E` is a subclass of `E`. (Not the same as subtype. We know this by now!)
+* `E` is a supertype of `E`.
+* `E` is a superclass of `E`.
+* `E`'s class, or one of `E`'s superclasses, includes module `M`. (Could easily piggyback off of the subclass mechanism)
+* `E`'s class, or one of `E`'s superclasses, extends module `M`.
+* `E`'s class is of class (using `C\+\+`/everyone else notation) `S<T>`: a type
+  `S` parameterized on type `T` (or any tuple of types).
+
+Those are the easy ones. Now for something better/weirder:
+
+## Better Syntax for Parameterized types.
+
+First off: which would you prefer?
+
+    # opts: CustomOptionsClass<Symbol, String>
+    def compute(opts=DEFAULT_OPTIONS)
+    end
+    
+or:
+
+    # opts: CustomOptionsClass<Symbol => String>
+    def compute(opts=DEFAULT_OPTIONS)
+    end
+
+I prefer the latter. Oh, and as a synonym for `Hash<Symbol => String>`:
+  
+    # opts: Symbol => String
+    def compute(opts=DEFAULT_OPTIONS)
+    end
+
+Now, a function type is just a mapping from a tuple of types to a return type. So I'd like to allow both Go syntax:
+
+    # compute_proc: (String, MyLib::TreeNode) Integer
+
+and a normal arrow syntax:
+
+    # compute_proc: (String, MyLib::TreeNode) -> Fixnum= | Bignum=
+
+It's natural for people to group arguments together with parens and separate them with commas. They will with Laser's syntax.
+
+## Union Types
+
+Crucial. Vertical bar. String | Symbol.
+
+## Imports? Kinda!
+
+`E`'s class is defined in module M or one of M's submodules (or sub-submodules... the whole set of modules in M's module tree). This could be *extremely* useful to a gem author to ensure that his library's boundaries are well-defined: if I make it easy enough, a Ruby user could say "Everything in module Laser uses only top-level classes and classes defined in Laser." With a smart enough annotation system, I could make it so a user writes something like this (throwaway syntax), where "in Amp" means "was defined in ::Amp or a submodule" and "in ::!" means "defined in the top-level, and NOT a submodule." "in ::!" would likely be added by default, actually – who could write Ruby without the top level? So yeah – I'm guessing have the default argument type of course be "completely unknown," but as soon as you activate a "defined in M" annotation somewhere, it implicitly includes "in the top-level and only top-level" as an other possibility (hence the Union in the throwaway syntax).
+
+    # Laser: defaults.argument_type = in Amp | in ::!
+
+## Strict Unknowns
+
+A lot of times you might not know a type (by itself or as a type parameter) but want to have it checked to be add the requirement that that type be *consistent with some other constraint across global usage*. The obvious constraint would be type compatibility or class compatibility, though the 'defined in module M' is another common one you might consider. Simple use case: marking that you return object `X` which was returned to you by a library. Who knows what class it is? You don't care, but as long as you don't accidentally return a `String` there instead of a `SomeLibrary::UselessModule::Ruby19Hack::XMLNode` you never knew existed. This has *got* to be simple to express for a Ruby type system. I'm considering `?` but worry it will be confused with the Java covariance/contravariance `? super Y`/`? extends Z` notations. Maybe '?!', with '?' meaning 'no idea,' and '?!' meaning 'no idea, but keep it strict.' I like the idea of using '!' as a way to easily add strictness to certain rules, since I hope for the defaults for most annotations to be "the most common" scenarios. Contravariance, for example, is typical in generic type parameters for argument parameters. I intend to ask the developer to add extra characters to their annotation to request invariance or covariance in that position. The same holds true for covariance in return values, invariance in container type parameters (which I expect to be more common but still not as common as covariance).
+
+## Duh: Duck Typing
+
+Responds-to. Has to be dead simple and *natural*. I like the idea of using hashes:
+
+    # @return-type #read
+    def get_stream
+      MagicIOFairy.visit
+    end
+    
+    # @return-type #write(#to_s)
+    def get\_universal\_writer
+      stream = MagicIOFairy.visit
+      def stream.write(y)
+        super(y.to_s)
+      end
+      stream
+    end
+
+but I'm not sure yet.
+
+## Motherfuckin' Tuples.
+
+The *most common API is Ruby* is Rack's #call syntax, and it must return a tuple!
+
+DRuby has it so I better have it. I like their syntax:
+
+    # @return-type (Fixnum, String => String, String)
+    def call
+      [200, {'content-type' => 'text/plain'}, 'Hello, World!']
+    end
+    
+For some reason, for them Tuples are subtypes of "Top". That's.... foolish.
+`Tuple<T1, T2, ..., Tn>` is clearly a subtype of `Array<BasicObject>` if not
+`Array<SomeMoreSpecificCommonSuperclass>`. It's actually a dependent type, which DRuby
+doesn't do in a general way. I intend to address dependent types in at least a limited
+fashion. I will definitely allow for dynamic semantic checking of dependent types, but
+the really interesting part is of course the static analysis. I'm not writing a proof
+checker like Coq's, thank you very much.
+
+Not much else to say. I think it may introduce ambiguity with my ideas for function
+type annotations, though. I was going to have a function that had no interesting return
+type be able to be left out. However that means that an n-argument function type with no
+interesting return type is *the same type* as a function from that 1 argument to... nothing,
+since it's now of type `(ArgType) -> NothingInteresting`. If you drop the NothingInteresting,
+your syntax is `(ArgType) -> ` or `(ArgType)`. To me, the first is clearly a function to void,
+but it means the programmer has to type out something for something that doesn't matter. The
+latter is ambiguous with the 1-argument tuple type `(ArgType)`. Can't have ambiguity. Not for
+a mini annotation language i want people to use foreals. However,
+there is one very good thing: no object in Ruby itself is "callable" - you can't do:
+
+    x = FooBar.new
+    x(5)
+    
+and expect that to call a function. That's because it will look to call a method. So we actually
+don't have any objects with names that are of function type. So whenever you annotate something callable,
+you're using the #call idiom, and so 'function types' get swept away to structural typing! I think
+I may provide a special syntax as a shortcut for #call, as it's a common thing to structurally type
+(even `Rack` picked it – it's a great name for a `Runnable` (from Java) or Functor method).
+
+    # list: Array<String>
+    # proc: (String)
+    def each_proc(list, proc)
+      list.each {|x| proc.call(x)}
+    end
+
+The one time you might want to annotate a "function type" is when you're describing a method in
+what I call *compact* form: it's just a type declaration all at once, no separate lines for
+each argument or return type. I refuse to require you to type the name of a method in the docs
+just above the method, so it's just a function type:
+
+    # (Fixnum, Fixnum) -> Fixnum= | Bignum=
+    def add(a, b)
+      a + b
+    end
+
+A method with 1 argument and an uninteresting return type is thus annotated as such:
+
+    # (#to_s) ->
+    def write(x)
+      @stream.write(x)
+    end
+
+or
+
+    # (#to_s)
+    def write(x)
+      @stream.write(x)
+    end
+
+Which is the same as a 1-argument tuple. However: I *know* in this case that the syntax is being used
+to describe a function, never a 1-argument tuple. So there is no ambiguity here. All other objects of
+function type would need to use the name of a method, so I'm in the clear for ambiguity. However, I
+will remind users that this is there but probably won't bite them.
+
+## Customizable annotation syntax?
+
+Switch between Haskell-like and C-like? Specify a function as `Fixnum doubler(Fixnum)` instead of go-like syntax?
+
+## Method Generation
+
+Most importantly added to method_missing as an annotation, but could possibly be moved to other places: listing generated methods. Now, you might want to just list a bunch of methods that will get created at load time:
+
+    # generates: doubler(#to_i) Fixnum
+    # generates: tripler(#to_i) Fixnum
+    # generates: quadrupler(#to_i) Float
+    [[2, 'doubler'],[3, 'tripler'],[4.0,'quadupler']].each do |num, name|
+      define_method name do |y|
+        y.to_i * num
+      end
+    end
+
+Which would generate type notes for 3 methods it then assumes exist with those annotations. Of course you can specify multiple overloads for these just by adding more lines:
+
+    # generates: doubler(Fixnum) Fixnum
+    # overflow lawlz
+    # generates: doubler(Fixnum) Bignum
+
+## Varargs
+
+DRuby screwed the pooch on this one. First of all, you can tell just by looking at the damn method declaration that the argument is a vararg list. It already has a damn star on it. Also, they talk in their manual about how it makes "parameter list types as first-class types". I'm not entirely clear about that, because a parameter list in Ruby is just an `Array`. Anyway, I think it's important for people to be able to have
+a way to note in the type declaration that something is a vararg. Or they could do that with `Array<Type>`. Or they might want me to infer it from the big effing star in their argument list.
+  
+I think I'm going to allow `*` to denote a vararg, and require its use if you want to enter a type annotation for something. No just writing "String" and letting me figure out that of course it's `Array<String>`. (Unless, of course, you use a certain flag, since I'll be happy to let you shoot yourself in the foot for it. Oh, and it won't work if it's an Array of Arrays, because there'd be ambiguity in the grammar there.)
+
+## Arbitrary annotations
+
+Things like "could_raise?" (for functions) or "pure" (for functions) are going to be accessible from the type system. Since those are just going to be instances of a more general labeling system the user can extend themselves, that means the user can define their own tags. For example, a user wants to eventually deprecate an API. They want to do it quick and dirty, so they implement the "[v1]" tag. Take your V1API module, slap the entire module with [v1]. Bam. Every class in that module is now deprecated. Then later, when you think you're done with the migration, require [v1=false] on your arguments to a method. If it fails type-checking, then that means I can prove a non-deprecated object will make its way to to that method, and you must not have fully removed all uses of the deprecated code. A smarter way would be of course to deprecate 1 method at a time, by adding the @deprecated or [v1] tag around. I could integrate this with YARD's existing tag system, though I don't want to get mucked up in Documentation-related code.
+
+## Overloads
+
+Overloads have to be done right, because they're pretty common. Especially in the standard library, and I'm going to have to type these damn annotations.
+
+For one, you could just write each new possibility as separate lines, as DRuby does.
+
+    # (Fixnum) -> Fixnum | nil
+    # (Fixnum, Fixnum) -> String | nil
+    def slice(*args)
+    end
+
+Of course slice has all kinds of other overloads, but this is simple enough. Notice that | binds tighter than the method arrow. That means it also works just fine for the "elided arrow" style that Go uses:
+
+    # (Fixnum, Fixnum) String | nil
+    # |---------------||-----|-|---|
+    # |---------------||-----------|
+    # |----------------------------|
+
+Yay for a bootleg ascii concrete parse tree.
+
+It's fine with me, to be honest.
+
+## Blocks?
+
+How to annotate blocks? Not sure yet. Explicit blocks as arguments need to be annotated as well, though
+they're another case of simple structural typing on #call. Oh, and I want to be able to annotate
+how many *times* the block gets called. Possibly as a function of the arguments, so this could be
+profiled at runtime. See contracts later.
+
+But yeah, specifying that either the current function yields and what it yields is important. What
+the block itself returns is also important. I saw DRuby trying to specify the type for Proc#initialize
+and it made my brain hurt, even though Proc#initialize is just a no-arg function, that takes a block
+with args and a return value, and returns #call(ArgTuple -> RetType). But the declaration was horrid:
+
+    ##% initialize: () {(^args) -> ret} -> Proc<^args, ret>  
+    def initialize(); end
+
+You couldn't pay me to type that out. Do I know better? Not sure yet, but for one, I'd prefer this:
+
+    # {*args -> ret} -> #call(*args) -> ret
+    def initialize; end
+
+But even that feels like pushing it to me.
+
+    # {*args ret} #call(*args) ret
+
+Is what that example would be with the unnecessary arrows. I like that the braces so "this stuff is
+block stuff!" The more symbols I use, the more arcane it becomes, unfortunately. I bet people would
+prefer more english words, but I should look into that first. DRuby uses `or` for Union types, after all.
+
+## Contracts
+
+Used as a preprocessor, Laser could inject contracts into specified locations in methods. These could
+be used for both assertions (invariants) and to profile code. So the user should be able to have simple
+syntax for common contracts, but also have the fully power of arbitrary Ruby to put in there. That way,
+you run in dev mode with the contracts on, and when run in production *all those assertions disappear*.
+But the nice thing is, they're still there *as documentation*!
+
+I haven't fleshed this out enough and it's going to be the last part of my work. Loren Segal is working
+in this area as well.
+
+## Dependent Types
+
+How much dependent typing can I support? Literals lend themselves to a few (array length forming a tuple),
+but beyond those? How about: the keys of this hash come from this set. That's a good one. Rails probably
+wastes tons of time manually checking those. Of course, they'd never *remove* them to protect users... but they'd know during
+development that their own code isn't using them wrong without running the code to find out!
+Oh, and whether a string is frozen or not, though this could be done with a generic type over TrueClass and
+FalseClass. Technically, no need to invoke dependent types. 
+
+## Detecting Data Dependencies?
+
+Here's an interesting note about this: I may not be able to do dependent type checking without a hugely
+complicated proof checker, but by allowing the annotation of dependent types, I can find *data dependencies*
+whenever code converts a non-dependent version of the type (ie: Hash<Symbol => Object>) to the dependent one,
+(i.e. Hash<SymbolInSomeSet => Object>), without an annotation, we are observing the moment when the code makes
+the assumption that the the object is of the correct dependent type.
+
+For example, if you read in a configuration YAML file and assign keys to values in a Hash in a method #read_file, you could have this
+dependent type annotation saying that #read_file returns an `Hash<SymbolInSomeSet => Object>` object, then
+when the code executes `hash[key.to_sym] = value`, that `key.to_sym` is of type `Symbol`, not `SymbolInSomeSet`.
+Since `Hash<SomeSymbolInSomeSet => Object>`'s `[]=` method is of type `(SomeSymbolInSomeSet) -> Object`, we
+must coerce SomeSymbolInSomeSet into a Symbol. This is the data dependency, and our general-purpose static
+analysis tool can detect them and require a disclaimer saying "hey, i know this is a data dependency here."
+
+## Mutability
+
+When annotating a type, you should mark if it will be mutated. That way you don't have to type when something
+is `const` or immutable. As it should be.
+
+I like the idea of using `!` to indicate mutation, so perhaps just adding a ! at the end of a type adds [mutable = true] as a custom annotation (described above).
+
+## Refinements
+
+It'd be huge to support these out the gate. It should be inferable extremely easily.

data/status_reports/2010/12/2010-12-24.md

@@ -0,0 +1,6 @@
+Just noticed that the "Strict Unknowns" I described yesterday is already in-place
+with only 1 specific constraint (super/sub-typing from a given class). I kind of
+like my addition of "no idea but ensure consistency across calls" idea, and allowing
+generic constraints is awesome.
+
+Also, Scala uses `_`to mean "unknown", so I'm stealing it.

data/test/third_party_tests/rgl_tests/TestComponents.rb

@@ -0,0 +1,65 @@
+require 'test/unit'
+
+require 'laser/third_party/rgl/traversal'
+require 'laser/third_party/rgl/connected_components'
+require 'laser/third_party/rgl/adjacency'
+require_relative 'test_helper'
+
+include RGL
+
+def graph_from_string(s)
+  g = DirectedAdjacencyGraph.new(Array)
+  s.split(/\n/).collect{|x| x.split(/->/)}.each do |a|
+	from = a[0].strip
+	a[1].split.each do |to|
+	  g.add_edge from,to
+	end
+  end
+  g
+end
+
+class TestComponents < Test::Unit::TestCase
+
+  def setup
+    @dg = DirectedAdjacencyGraph.new(Array)
+	edges = [[1,2],[2,3],[2,4],[4,5],[1,6],[6,4]]
+    edges.each do |(src,target)| 
+      @dg.add_edge(src, target)
+    end
+	@bfs = @dg.bfs_iterator(1)
+	@dfs = @dg.dfs_iterator(1)
+
+	@ug = AdjacencyGraph.new(Array)
+	@ug.add_edges(*edges)
+
+	@dg2 = graph_from_string(
+"a -> b f h 
+b -> c a 
+c -> d b 
+d -> e 
+e -> d 
+f -> g 
+g -> f d 
+h -> i 
+i -> h j e c")
+  end
+
+  def test_connected_components
+	ccs = []
+	@ug.each_connected_component { |c| ccs << c }
+	assert_equal(1,ccs.size)
+
+	ccs = []
+	@ug.add_edge 10,11
+	@ug.add_edge 33,44
+	@ug.each_connected_component { |c| ccs << c.sort }
+	assert_equal([[10, 11], [1, 2, 3, 4, 5, 6], [33,44]].sort,ccs.sort)
+  end
+
+  def test_strong_components
+	vis = @dg2.strongly_connected_components
+	
+	assert_equal(4,vis.num_comp)
+	assert_equal([["a", 3], ["b", 3], ["c", 3], ["d", 0], ["e", 0], ["f", 1], ["g", 1], ["h", 3], ["i", 3], ["j", 2]],vis.comp_map.to_a)
+  end
+end

data/test/third_party_tests/rgl_tests/TestCycles.rb

@@ -0,0 +1,61 @@
+$LOAD_PATH << "../lib"
+require 'test/unit'
+require 'laser/third_party/rgl/adjacency'
+require_relative 'test_helper'
+
+include RGL
+
+class TestCycles < Test::Unit::TestCase
+
+  def setup
+    @dg = DirectedAdjacencyGraph.new(Array)
+    edges = [[1,2],[2,2],[2,3],[3,4],[4,5],[5,1],[6,4],[6,6],[1,4],[7,7],[7,7]]
+    edges.each do |(src,target)| 
+      @dg.add_edge(src, target)
+    end
+
+    @ug = AdjacencyGraph.new(Array)
+    @ug.add_edges(*edges)
+  end
+
+  # Helper for testing for different permutations of a cycle
+  def contains_cycle?(cycles,cycle)
+    cycle.size.times do |i|
+      return true if cycles.include?(cycle)
+      cycle = cycle[1..-1] + [cycle[0]]
+    end
+  end
+
+  def test_cycles
+    d_cycles = @dg.cycles
+    assert_equal 6, d_cycles.size
+    assert d_cycles.include?([6])
+    assert d_cycles.include?([7])
+    assert d_cycles.include?([2])
+    assert contains_cycle?(d_cycles, [1,4,5])
+    assert contains_cycle?(d_cycles, [1,2,3,4,5])
+  
+    assert_equal 5, DirectedAdjacencyGraph.new(Set, @dg).cycles.size
+
+    u_cycles = AdjacencyGraph.new(Set, @dg).cycles.sort
+
+    assert u_cycles.include?([2])
+    assert u_cycles.include?([6])
+    assert u_cycles.include?([7])
+    assert contains_cycle?(u_cycles, [1,2,3,4,5])
+    assert contains_cycle?(u_cycles, [1,5,4,3,2])
+    assert contains_cycle?(u_cycles, [1,4,3,2])
+    assert contains_cycle?(u_cycles, [1,4,5])
+    assert contains_cycle?(u_cycles, [1,5,4])
+    assert contains_cycle?(u_cycles, [1,5])
+    assert contains_cycle?(u_cycles, [1,2])
+    assert contains_cycle?(u_cycles, [1,2,3,4])
+    assert contains_cycle?(u_cycles, [2,3])
+    assert contains_cycle?(u_cycles, [1,4])
+    assert contains_cycle?(u_cycles, [3,4])
+    assert contains_cycle?(u_cycles, [4,5])
+    assert contains_cycle?(u_cycles, [4,6])
+    assert_equal 16, u_cycles.size
+  end
+
+end

data/test/third_party_tests/rgl_tests/TestDirectedGraph.rb

@@ -0,0 +1,125 @@
+require 'test/unit'
+require 'laser/third_party/rgl/adjacency'
+
+include RGL
+include RGL::Edge
+
+class TestDirectedGraph < Test::Unit::TestCase
+  def setup
+    @dg = DirectedAdjacencyGraph.new
+    [[1,2],[2,3],[3,2],[2,4]].each do |(src,target)| 
+      @dg.add_edge(src, target)
+    end
+  end
+  
+  def test_empty_graph
+    dg = DirectedAdjacencyGraph.new
+    assert dg.empty?
+    assert dg.directed?
+    assert(!dg.has_edge?(2,1))
+    assert(!dg.has_vertex?(3))
+    # Non existend vertex result in a Name Error because each_key is
+    # called for nil
+    assert_raises(NoVertexError) {dg.out_degree(3)}
+    assert_equal([],dg.vertices)
+    assert_equal(0,dg.size)
+    assert_equal(0,dg.num_vertices)
+    assert_equal(0,dg.num_edges)
+    assert_equal(DirectedEdge,dg.edge_class)
+    assert([].eql?(dg.edges))
+  end
+  
+  def test_add
+    dg = DirectedAdjacencyGraph.new
+    dg.add_edge(1,2)
+    assert(!dg.empty?)
+    assert(dg.has_edge?(1,2))
+    assert(!dg.has_edge?(2,1))
+    assert(dg.has_vertex?(1) && dg.has_vertex?(2))
+    assert(!dg.has_vertex?(3))
+    
+    assert_equal([1,2],dg.vertices.sort)
+    assert([DirectedEdge.new(1,2)].eql?(dg.edges))
+    assert_equal("(1-2)",dg.edges.join)
+    
+    assert_equal([2],dg.adjacent_vertices(1))
+    assert_equal([],dg.adjacent_vertices(2))
+    
+    assert_equal(1,dg.out_degree(1))
+    assert_equal(0,dg.out_degree(2))
+  end
+  
+  def test_edges
+    assert_equal(4, @dg.edges.count)
+    assert_equal([1,2,2,3], @dg.edges.map {|l| l.source}.sort)
+    assert_equal([2,2,3,4], @dg.edges.map {|l| l.target}.sort)
+    assert_equal("(1-2)(2-3)(2-4)(3-2)", @dg.edges.map {|l| l.to_s}.sort.join)
+    #    assert_equal([0,1,2,3], @dg.edges.map {|l| l.info}.sort)
+  end
+  
+  def test_vertices
+    assert_equal([1,2,3,4], @dg.vertices.sort)
+  end
+  
+  def test_edges_from_to?
+    assert @dg.has_edge?(1,2)
+    assert @dg.has_edge?(2,3)
+    assert @dg.has_edge?(3,2)
+    assert @dg.has_edge?(2,4)
+    assert !@dg.has_edge?(2,1)
+    assert !@dg.has_edge?(3,1)
+    assert !@dg.has_edge?(4,1)
+    assert !@dg.has_edge?(4,2)
+  end
+  
+  def test_remove_edges
+    @dg.remove_edge 1,2
+    assert !@dg.has_edge?(1,2)
+    @dg.remove_edge 1,2
+    assert !@dg.has_edge?(1,2)
+    @dg.remove_vertex 3
+    assert !@dg.has_vertex?(3)
+    assert !@dg.has_edge?(2,3)
+    assert_equal('(2-4)',@dg.edges.join)
+  end
+  
+  def test_add_vertices
+    dg = DirectedAdjacencyGraph.new
+    dg.add_vertices 1,3,2,4
+    assert_equal dg.vertices.sort, [1,2,3,4]
+    
+    dg.remove_vertices 1,3
+    assert_equal dg.vertices.sort, [2,4]
+  end
+  
+  def test_creating_from_array
+    dg = DirectedAdjacencyGraph[1, 2, 3, 4]
+    assert_equal([1,2,3,4], dg.vertices.sort)
+    assert_equal('(1-2)(3-4)', dg.edges.join)
+  end
+  
+  def test_reverse
+    reverted = @dg.reverse
+    @dg.each_edge do |u,v|
+      assert(reverted.has_edge?(v,u))
+    end
+  end
+  
+  def test_reverse
+    # Add isolated vertex
+    @dg.add_vertex(42)
+    reverted = @dg.reverse
+    
+    @dg.each_edge do |u,v|
+      assert(reverted.has_edge?(v,u))
+    end
+    
+    assert(reverted.has_vertex?(42),
+           'Reverted graph should contain isolated Vertex 42')
+  end
+  
+  def test_to_undirected
+    undirected = @dg.to_undirected
+    assert_equal '(1=2)(2=3)(2=4)', undirected.edges.sort.join
+  end
+end