Trying out the Fan-to-Javascript served from Wisp, I know it's experimental but it's cool so I'm trying it out. Seem to have found a bug; an ititializer like this (in Fan):

matrix = DlxNode[][,]
nCol.times |Int c| {
  matrix.add(DlxNode[,] { size = nRow }) // filled with nulls
}

generates javascript like this:

this.m_Matrix = fan.sys.List.make(fan.sys.Type.find("sys::List"), []);
fan.sys.Int.times(nCol,fan.sys.Func.make(
  function(c)
  {
    fan.sys.List.add(
      $this.m_Matrix,
      fan.sys.Obj.$with(
        fan.sys.List.make(fan.sys.Type.find("sudoku::DlxNode"), []),
        fan.sys.Func.make(function(it)
        {  
          fan.sys.List.size(it,(nRow);
Uncaught SyntaxError: Unexpected token ;
          return;
        },
        [new fan.sys.Param("it","sys::List",false)],
        fan.sys.Type.find("sys::Void")
      )
    ));
    return;
  },
  [new fan.sys.Param("c","sys::Int",false)],
  fan.sys.Type.find("sys::Void")
));

which doesn't surprise me, just wanted to get it logged.

By the way (on the generation topic, not in relation to the bug), what I'd love to see is this (or something like it):

this.matrix(fan.sys.List.make(fan.sys.List.of(fan.sudoku.DlxNode)));
nCol.times(function(c) {
  $this.matrix().add(fan.sys.obj.$with(
    fan.sys.List.make(fan.sudoku.DlxNode),
    function(it) {it.size(nRow)}
  ));
});

Basically, allow direct type referencing, allow methods directly on the objects, just use raw functions (at least for common sys methods that you know won't abuse the function, ... or can an anonymous function reference itself in Fan?). I tweaked a couple of other things there, too.

I debate fan.sys.List vs. just sys.List, but in the end, I agree with the cleaner namespace. Some facet to generate top level for a pod could be nice, though.

Just some thoughts.

Promoted to ticket #749 and assigned to andy

@tom - I'm not sure we'll see that level of parity with JavaScript (at least right now) - its very important to have a solid type system implementation in JavaScript - since alot of code relies on it. That was a mistake I made early on. It comes at the expense of being to work with Fan-Js naturally - but its necessary for Fan to run well in a jsvm.

There is still alot of room for improvement/optimization though (can count a few that are easy in KevinKelley's code). Type lookups in particular have been at the top of my list for sometime - but since they currently work, I've left them as is. They will eventually be just a field reference like we do in Java/C#:

fan.sys.List.make(fan.sudoku.DlxNode.$type);

But there is a chicken and egg problem in the sys library I need to sort through to make sure classes, static initializers/fields, and type info get parsed in the correct order.

Renamed from compilerJs bug in multi-dim list initializer to compilerJs bug in list initializer

The root issue here is that List.size is not properly implemented in the sys library and the compiler. I plan to move Lists to a wrapper object instead of a native JavaScript array, which will solve this issue (and a host of others like it).

a solid type system implementation in JavaScript

+1 on that; it seems to me that this is going to end up being one of Fan's really big wins, if you can develop in Fan with type safety and then emit JS to run.

Side question ( Seaside question actually) -- you familiar with the Seaside webapp framework? Would be interesting to see something like it in Fan. I've only experimented a little with it, but I really like what I've seen.

Seaside webapp framework

I looked at it a few years ago. The big thing I recall was it was based on continuations, which was much easier to implement in Smalltalk than in the JVM. But ignoring performance and implementation issues, the model is undoubtedly easier and more natural to program against.

Thanks for the feedback on issues.

Ticket resolved in 1.0.49

Root syntax bug fixed, so above code should compile/execute.