I've been having a go at hacking the compiler to add a language feature (more later). The coding actually turned out to be pretty easy (having understood javac, Fan's compiler is easy).

The biggest problems were not having any kind of Eclipse editor, and not being able to tell the difference between a variable and a method (because the convention is to leave off the () on a method). An editor might help the latter, otherwise I might be tempted to say that the convention should change.

Anyway, back to the point... Where would I add code to de-sugar? I could see the various steps, but none of them seemed a perfect match. Basically I want to take an extra piece of information I've stored in the AST and desugar to cause an alternate piece of AST to be added instead. Would you recommend using Normalize, or adding a new step?

and not being able to tell the difference between a variable and a method (because the convention is to leave off the () on a method)

I have problems exactly with that ;). Is there a reason to drop mandatory () on a method call or is it just for convenience? I personally hate that on, for example, Groovy syntax..

I mistly remember there was also a corner case making empty parens mandatory somewhere (I've seen it in discussions here - some sort of newline problem? ... dunno exactly).

I also miss syntax highlighting a bit. Do you have some conventions / vim syntax definitions files or whatever? I tried to run "flux" program which I thought was an editor but it had eaten all JVM memory and had panicked ;).

coding actually turned out to be pretty easy

Hacking the compiler - very cool. I'm glad you are finding it hackable.

Where would I add code to de-sugar?

It depends on whether your AST manipulation is at the slot level or is an expression. Currently only two steps walk the AST all the way down to exprs - ResolveExpr and CheckErrors. If it is a pretty small change, then I typically add to Normalize if at the slot level, and CheckErrors at the expr level. Sticking stuff into CheckErrors is starting to get a little ugly, so I really need to pull that out into a new step like NormalizeExpr. If a manipulation is more than a couple dozen lines of code, then I typically pull out into a new step.

Is there a reason to drop mandatory () on a method call or is it just for convenience

It is just for convenience - you don't have to leave off the () if you don't want. Although it does make your code source compatible when switching b/w a field and method. Andy and I leave them off always by convention - not because it is necessarily a great rule, but because it is the simplest convention rule to remember.

I also miss syntax highlighting a bit.

Andy and I both use TextPad - if you like TextPad I would be happy to share my syntax file with you. If anyone has other editor syntax definitions then I would be happy to add them into the distro. You might also check out Una which as Fan syntax built-in.

I tried to run "flux" program which I thought was an editor

Flux will be an editor, but it isn't included in the distro yet (it still has a little ways to go before it does the basics). Flux does syntax coloring code based on rules (declared in a fog file of course). Not sure why trying it should eat up all your memory - it should just error out with UnknownPodErr. There was a bug reported a couple weeks about something similar.

I see if I can add it to Normalize for now, and then take it from there.

+1 for optional ()

Brian I'd like your syntax file and will look at porting it to jEdit.

I will bundle it in the next build under "/adm/tools/textpad" (and stick other editor files under adm/ too). Chris if you want it sooner, why don't you email me.

Although quick summary for the syntax rules are:

• find keywords here
• // and ** are end of line comments
• /* */ is block comment (they can be nested)
• "", r"", , and string like literals

Thanks Brian.

For anyone using Jedit, here's my first stab at a Fan edit mode for it.

Thanks Brian and cgrinds ;)

According to your rules I adapted the java syntax highlighting for vim to Fan syntax. Here you can download the stab. It is far from perfect but usable.

To get it working copy this file to /usr/share/vim/vim71/syntax (or whatever dir it is in your installation) and add this

" Fan
au BufNewFile,BufRead *.fan                     setf fan

to /usr/share/vim/vim71/filetype.vim. This should be sufficient.

Thanks Chris and Katox, I will include the jedit and vim files into the next build under /adm/tools. Let me know if you make updates.