I was hoping to wrap up all the pending breaking changes this month - namely the symbol stuff and also tackle the appHome directory stuff. But I haven't quite internalized the symbol design yet, so I went ahead and posted a build with the DSL feature.

DSLs

The biggest new feature in this build is DSLs which allow you to embed other languages into Fan code using the special syntax AnchorType <| ... |>.

This build includes a DSL for Regex which allows you create a regex literals without worrying about escape characters:

Regex <|foo/(\d*)|>   =>   Regex("foo/(\\d*)")  

You can read more about DSLs and how to write new ones in docLang.

String Literals

Part of the DSL changes was to remove support for r"..."' literals. Instead we have triple quoted strings and Str DSLs:

echo("""Do you know "What lies beneath the shadow of the statue"?""")

echo(Str <|no \ or $ escapes need, and
           multi-line works too|>)

Triple quotes work just like normal string literals except you don't need to escape the quote character, back slash and interpolation still work. Str DSLs are raw strings, no character including backslash or dollar sign is treated specially (except the |> sequence). Both new string literals can be multi-line following the same rules for leading whitespace as normal string literals.

Uri Interpolation

You can finally use interpolation in Uri literals now:

`outDir/${name}.fan`  => "outDir/${name}.fan".toUri

Uri interpolation is just sugar for doing string interpolation and then calling toUri. But comes in quite handy since Uris are used so heavily through out Fan.

Definite Assignment for Non-Nullable Fields

The compiler now requires that a non-nullable field is assigned a value in each constructor. This is a breaking change compared to the old behavior, but is easy to fix by just running the compiler against your code.

From docLang:

Non-nullable fields must be assigned in all code pathes. Each constructor which doesn't chain to this must set each non-nullable field which doesn't meet one of the following criteria:

• value type fields don't need to be set (Bool, Int, Float)
• fields with an initializer don't need to be set
• abstract or override fields don't need to be set
• native fields don't need to be set
• calcualted fields don't need to be set

Matching rules apply to static fields which must be set by all code paths in the static initializer.

JavaScript

Andy has been extremely busy beefing up Fan's JavaScript support. You can now decode a serialized Fan object in a browser, and he has begun a port of FWT to JavaScript. Our design goal is to define UIs as a serialized tree of FWT widgets which gets transferred to a browser where it is decoded and rendered as HTML/CSS/JS. This stuff will be pretty wicked cool once we get it all working.

Change Log

Build 1.0.43 (28 May 09)

• FWT port to JavaScript
• Change default for value type local variables
• Remove support for "..." range literals (replaced with "..<")
• Add register parameter to sys::Log.make
• ObixClient
• #429: Triple Quoted Strings and DSL Str/Regex
• #438: DSL Proposal
• #532: Improved detection immutable closures
• #578: Uri Interpolation
• #595: Definite assignment of non-nullable fields

value type fields don't need to be set (Bool, Int, Float)

Might it be possible to have a special slot to define a default value for other types, too?

I wouldn't mind empty strings or immutable empty lists, for instance. Or if not for those, then I still might like to provide default values for classes of my own.

he has begun a port of FWT to JavaScript

I've been meaning to ask a question on this topic. Is this being based on Dijit, Qooxdoo, or something else? Or is it being done from scratch?

Might it be possible to have a special slot to define a default value for other types, too?

In general most of the built-in, immutable reference types have a static field called defVal. But I think that assignment needs to be explicit.

Or is it being done from scratch?

From scratch based on compiling gfx/fwt to JS

In general most of the built-in, immutable reference types have a static field called defVal. But I think that assignment needs to be explicit.

Okay. I just try to avoid special cases. That was all.

From scratch based on compiling gfx/fwt to JS

Except that fwt is based on SWT. That's the part I'm asking about.

Except that fwt is based on SWT. That's the part I'm asking about.

It is our own code, no external dependencies

It is our own code, no external dependencies

Written in Fan, then, I presume? Side note, if you make a clear system for calling from JS to Fan, and if you make sure to avoid polluting the global namespace, you could provide a nice ecosystem where people develop their JS libraries in Fan.

For instance, folks could use fwt from JS (or other languages) without using Fan as their own language. In my opinion, this would actually increase interest for development in Fan, because people could switch to it without locking in their own users/clients.

I do expect to use the Fan JS compiler at some point, by the way. I just haven't gotten to it yet.

Written in Fan, then, I presume?

The Fan code is compiled directly to JS, while the native peers are written manually in JS (just like it works today with Java).

For instance, folks could use fwt from JS (or other languages) without using Fan as their own language

Technically yes this will work since we compile to source code, but I doubt you'd really want to do that. If you're not going to use Fan, you'd be better off using a "native" library.

For instance, folks could use fwt from JS (or other languages) without using Fan as their own language

Interesting, but I see it more from the other end of the telescope: Fan being used as a proxy language for JS, in the same way Java does this in GWT.