Lambda the Ultimate

Fortress is similar to Scala: it's an object-orientend language with traits, functions, and generic types.

Fortress is also similar to Fortran: it's a language designed for the needs of high performance computation with special support for arrays and matrices as complex data structures, and ways of explicitly parallelizing computation in a shared address space model.

There are also new things in Fortress: the component system, the syntax, the model of generic types are all new and developed for Fortress.

Just as an example, the following two expressions are the same:

  a sin x log log x

  a * (sin (x)) * (log (log (x)))

Fortress looks very promising -- but I must admit I did a double take when I saw the syntactic ambiguity (for human readers) between multiplication and function application.

While an expression like "a sin x log log x" may be obviously unambiguous because we recognize sin and log as functions, what about "a foo x bar quux x"? In almost all other languages, it's possible to identify both function application and multiplication purely by syntactic inspection, without having to look elsewhere to figure out whether some name represents a function or not. Unless I'm missing something, I would vote strongly against allowing such ambiguity in a language.

The rest looks great, though. :)

One of the goals of the Fortress syntax has been to express mathematical notation as closely as possible. That means that some things require context-sensitive disambiguation, because that how mathematical notation works. However, I doubt people will use juxtaposition for function application for all their functions, without any parens.

However, I doubt people will use juxtaposition for function application for all their functions, without any parens.

I would prefer requiring multiplication signs where necessary -- it should make type errors much much easier to understand.

Fortress is intended to be a language real people use. That means that it needs features for what people need, not just what is publishable research.


It's also a language produced by a research lab, so it has new (and hopefully interesting) ideas.

Tossing everything else in just because "it's needed in a modern language" without first examining whether or not that feature brings anything to the table seems perverse.

We certainly didn't just add features without thought. You'll note that the language doesn't bear a particularily strong resemblance to the languages it's authors have worked on previously (Scheme, Java, Common Lisp, Fortran, Haskell, Modula-3, ML). We thought hard about what would make a language useful.


Conversely, some things are needed in a modern language, like a way to structure software. And some things are needed by the particular goals of this language, like support for scientific computation.


Finally, Fortress is indeed not a small language. But no real-world language is. OCaml is not small, neither is MzScheme or Python. GHC Haskell isn't small either, nor is Java or C#.

In fact, I would bet that real users would benefit more from a type system that inferred matrix dimensions concretely if possible and abstractly if necessary than from set comprehensions.

For instance,

A, B: matrix
C = A * B
D = C + 1

tells us quite a bit about the required sizes of A, B, C and D. Getting matrix sizes wrong by forgetting a transpose or some such is one of the most common mistakes in numerical programming. Fixing that will fix much more code than comprehensions ever will.

Will build AI for fun or profit

..on Dependent ML. Checking matrix sizes was the first thing I thought of when I read his work.

You'll note that the language doesn't bear a particularily strong resemblance to the languages it's authors have worked on previously (Scheme, Java, Common Lisp, Fortran, Haskell, Modula-3, ML).

From a first reading of the spec I would say quite the contrary - its heritage from most of these shows through. This is not intended as criticism, of course.

I also suppose the design is far from frozen and that it will still change in more or less radical ways. In many respects it already looks very nice, but I'm slightly puzzled by a few design choices.

No doubt the authors have thought about this a lot more than I have, but the language does not look very amenable to partial parsing (mostly because of the way juxtaposition is used for multiplication and function application). It feels like the C typedef mistake again: difficult to parse a piece of code without knowing what the identifiers stand for. Today partial parsing is useful not only in editors (where it has many uses) but also debuggers, static code analysis tools, interface generators etc.

I have way too much respect for the authors to believe that they have asked computation scientists what they would have liked in a language and used that as a base, but frankly it appears as if someone wanted to lift mathematical notation directly from paper into code. This is only superficially attractive since the notations of code and maths are used in very different ways and should be optimised accordingly.

I understand your concern, and I believe that there is a lot of clunkiness in the language as well. However, I think that this is on purpose, because the purpose of the language is to provide two levels of use. On one level, you'll have those researchers who don't know how to program really well (and who don't want to learn either) but who need a program to approximate some values. On the other level you'll have your researchers who do understand programming and will put together libraries in Fortress (using that nifty AST syntax) that will allow those on the other level to do more stuff intuitively.

That being said, I think that this approach betrays the initial statement that they are writing a one-purpose language. I also have a problem with the idea that there'll need to be a special editor to write code in the language, and again I think they comprimised on this because they are trying to create a language for two audiences.

Nathaniel Dean: I also have a problem with the idea that there'll need to be a special editor to write code in the language, and again I think they comprimised on this because they are trying to create a language for two audiences.

I'm not so sure about this. First of all, I've long missed the "structure editors" of some of the first Lisp environments I ever used. Later, I was exposed to VaxTPU and LSE (Language-Sensitive Editor), and I thought they were heading in the right direction: why should it be possible to make a syntax error? The editor should prevent it! What we hand to the compiler should already be an abstract syntax tree instead of a stream of characters.

Finally, if you look at something like Epigram, it might begin to become apparent that when dealing with very expressive type systems, it's helpful to be able to engage in a dialogue when ambiguities in type inference arise, and it's good to be able to exploit better means of human/machine interaction than just reading streams of characters and typing streams of characters.

So I'm not at all convinced that a modern language requiring something more than a text editor to interact with it is a priori a bad thing.

What we hand to the compiler should already be an abstract syntax tree instead of a stream of characters.

I very much agree with this statement. However, it somewhat implies blurring the distinction between editor and compiler, doesn't it? I mean, the editor has already "compiled" the code to an AST. Alternatively, the concrete syntax can be seen as just a "view" of the AST provided by the editor. Which leads to the idea that it should be possible to have multiple, customised, views (concrete syntax) for the same abstract language. In the same way that I can currently set up my editor to display keywords in green, or strings in bold and red, I should be able to display my Set type with curly-braces and commas, while someone else's view represents them as the keyword "set" followed by a list of elements separated by whitespace, perhaps. Of course, it's considerably more difficult to create a consistent syntax than to just pick some colours, but I think it should be possible, at least. You could package up a complete, consistent syntax definition as a "skin" for some language. If done at the right level, I think it could work quite well, and allow people to move beyond surface-syntax reasons for disliking a language. Maybe that way madness lies, but I think it would be interesting to try it. Some editors, like the new XCode allow you to see a different high-level view of the code (graphically), but being able to change the view of the low-level syntax would also be useful, I think.

As editors become more complicated, it seems that they will share quite a bit of code with compilers/interpreters. So it probably makes sense to break up the compiler and make all the parts available as libraries. This, in turn, seems to lead down the road to greater reflective and meta-programming capabilities for programming languages: if the parser, interpreter, optimiser, and compiler etc are all available as standard libraries for your language, then it seems a fairly natural step to use them on your own code.

These are all interesting thoughts by both Paul and Neil.

The current one-way street of parsing a concrete syntax representation to an abstract syntax tree would change to a two-way street of parsing and pretty-printing with these ideas. The canonical representation of code would no longer be a certain concrete syntax, but rather the abstract syntax (for which by Neil's idea more than one concrete syntax can exist).

However, I think subtle problems can arise here. Usually, you loose information when parsing concrete syntax (on purpose of course), but this also means you can not recover the exact same concrete representation but rather have to use a generic pretty-printing algorithm. This is a problem inherent to the scetched setting, but people don't tend to like it when their own markup gets lost.

Another problem is what to use as 'the' abstract syntax. If it is abstract enough, more than one construction in a given concrete syntax can be mapped on an abstract syntax construction, so you loose even more information in the parsing-pretty-printing pipeline. (e.g. the abstract syntax only comes with one type of loop construct, but a concrete syntax provides several.)

Smalltalk refactoring browsers turn a parse tree back into source code by allowing the user to specify pretty printing settings.

Anything from indentation of lines to spaces between the function name and parentheses can be configured. More information on formatting abstract syntax trees on page 89 of Dr. Don Roberts Ph.D. thesis, Practical Analysis for Refactoring.

The parse tree used in the original refactoring browser is an extended version of the built-in tree, the extended version includes comments and other information usually lost, see page 84 of the same thesis.


--Shae Erisson - ScannedInAvian.com

and I thought they were heading in the right direction: why should it be possible to make a syntax error? The editor should prevent it! What we hand to the compiler should already be an abstract syntax tree instead of a stream of characters.

In practice, this turns out to be too intrusive, as people want not just syntactically valid translations, but also wish to do the sort of syntactically invalid translations that they are used to from editing text. That's reasonable, as there are often editing "shortcuts" that take you from one valid state to another very easily, but require going through invalid states.

The state of the art in real-life-use editors is that the editor is responsible for creating the best syntax tree it can on the fly, and warning the user interactively when their code is in an invalid state. Automated refactorings can use this tree for large- or small- scale program transformations, and a parallel analysis thread is responsible for running tree traversals and highlighting possible non-compile-fatal error states found (dead code, deprecated or non-performant usages, portability concerns, likely bug patterns). A modern IDE may ship with dozens of automated transformations and hundreds of automated error detectors ("inspections" or "audits", in marketing-speak) available to the user. "Structural" search and replace is available for user-created parse-tree search or transformation, but good old textual search-and-replace is supported as well.

Best of both worlds, really

In practice, this turns out to be too intrusive, as people want not just syntactically valid translations, but also wish to do the sort of syntactically invalid translations that they are used to from editing text.

I just finished reading Generative Programming and the chapter on Intentional Programming was, essentially, non-stop praise for the idea that programmers don't enter text in the traditional sense. I found the whole idea unsettling for the same reasons you mentioned.

You have to allow me to make mistakes! :)

As Paul Snively said earlier, see Epigram for a best-of-both-worlds approach to free text editing and syntax directed editing (and a very cool typesystem that makes it all possible).

--Shae Erisson - ScannedInAvian.com

I know I'm not the target audience for this language but it seems like a language that was designed without the kind of external validation that only real code can give you. I went through the spec and every time I came across yet another really neat feature I found myself pitying anyone asked to maintain code written in a language with this many features in version 1.0. Given that historically it's been easier to _add_ features to languages rather than remove them then adding all these features seems like a mistake. It feels like the kind of premature optimisation that is going to make it hard to change this language when real users get their hands on it.

Real users are likely to ask for even more features and Fortress seems doomed to become a baroque concoction of really neat ideas. That's assuming that anyone is ever able to implement all these features. The world doesn't need another Perl 6 no matter how celebrated the inventors.

Just once I'd like to see a small clean language (like Steve Dekorte's Io) get this kind of corporate backing.

I wonder, how it's possible to make mistake.
Make no mistake - the number of constructs and themes attacked in this language is certainly ambitious (and impressive), but I can't shake the feeling that putting all of this stuff together seems to make the language really cluttered. There seems to be no unifying structure or elegance. Half of me says that this is actually a good thing - certainly a system that might initially seem cluttered has much space for finding Alexander's "Quality Without a Name". But the other half says that sometimes clutter is just clutter.
[Spam deleted. -- Ehud]

I guess they only made division a lower precedence than the invisible multiplication operator, which is normal in mathematical notation.

Do you have a citation for this? I've never heard of anyone treating "invisible" multiplications any differently, and would find it very surprising indeed. It's certainly not the case in established languages like, say, Mathematica that follow standard mathematical notation very closely.

I'd also find the language to be pretty (surprising|untrustable) if it completely changed its behavior if you switched an implicit multiplication to be explicit.

You are very correct in the primal importance of the gui/edtor in the path toward Fortress really shining as a glyphical language.

I have some conceptual work here regarding a similar environment for Common Lisp, for implementation with Cocoa:

http://nimbusgarden.com/ben/_HCI_/SeeLisp/SeeLisp_files/SeeLisp.038-004.png

http://nimbusgarden.com/ben/_HCI_/SeeLisp/SeeLisp_files/SeeLisp.033-001.png

http://nimbusgarden.com/ben/_HCI_/SeeLisp/

http://nimbusgarden.com/ben/_HCI_/

...and would like to repurpose this work toward a Bidirectional Unicode MathML-based editor for use as a pretty-print Fortress editor/environment.

Is anyone familiar with the most active projects along these lines (MathML&vector graphics Fortress editors)? My initial survey did not reveal lots of activity. The Eclipse plugin perhaps?

Is it too early for such an effort?

I dont't think I've seen this mentioned on LtU yet: The Soul of a New Programming Language, an interview with Guy Steele.

I guess it was mentioned. The OP contained this link, or did you mean something else?

"We were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp." - Guy Steele, co-author of the Java spec (link)