How would I optimize this parser?

[bearophile]

T.D.Spense:

>     public TagNode(String name){
>         this.name = name;
>         this.children = new ArrayList<Node>(1);
>     }
> 
>     public TagNode(String name, Node... children){
>         this.children = Arrays.asList(children);
>         for (Node child : children) {
>             child.parent = this;
>         }
>     }
> 
> It's allowed in Java, but I can see why this can be prohibited.


Java code, prints "12":


class Node {}
 
class Main {
  public void foo(String name) {
    System.out.print("1"); 
  }
 
  public void foo(String name, Node... nodes) {
    System.out.print("2"); 
  }
 
   public static void main(String[] args) {
    Main m = new Main();
    m.foo("hello");
    m.foo("hello", new Node());
  }
}


In D the T[]... syntax means zero or more T, so if you supply zero T, the compiler can't know what of the two methods you are calling, so it's statically forbidden.

This prints 22 in Java:


class Node {}
 
class Main {
  public void foo(String name, Node... nodes) {
    System.out.print("2"); 
  }
 
   public static void main(String[] args) {
    Main m = new Main();
    m.foo("hello");
    m.foo("hello", new Node());
  }
}

Here I prefer how D is designed, it looks tidier (often it's the opposite, the C# looks designed in a more clear way compared to D).


> You're right about unit tests. One thing that surprised me is that unit tests are
> run when the program is run. For some reason I thought they were run immediately
> after the compilation with the appropriate flag.

If you compile your code with:

dmd foo.d
And then you run the program:
foo.exe
or:
./foo

Your unit tests aren't run.

If you instead compile with this:
dmd -unittest foo.d

And then you run the program, the unittests are run and then the program is run. In D2 with a version(unittest) you may disable the running as you like.


> Interesting. I didn't think about GC, because there aren't any objects that get
> unreferenced. But, of course, garbage collector can't know about that until it
> runs.

Right, the program builds the data structure and then now and then the GC transversed it all and marks all objects as reachable. This takes a lot of time.


> (Well, unless there is a mechanism for marking objects as non-collectible manually.)

A simple way to make objects not collectable is to allocate them from the C heap (there is a kind of placement new in D).


> Tangent question. Is there a way to disable GC per application thread?

I am not expert on this, I think there is no way yet. Maybe it will be added.

Bye,
bearophile