Lambda the Ultimate

As much as I like the look of Fortress in comparison to other offerings in the programming language realm from big corporations in recent times, I kind of suspect that it is not going to be adopted nearly as widely as C++ or Java was. It's simply too different from the C-style paradigm.

But reading the specs and reading/hearing some of the discussion about the language from the creators, I don't think it's going to be marketed this way. It's meant to be a language that makes programming on big iron easy (with the parallelism, concurrency, contracts, etc.), as well as programming for scientific or abstract mathematical purposes easy (with extensive unicode support for mathematical characters, dimensions, etc.).

None of those are things the *average* C++/Java programmer really end up doing all that often.

However, as complex as the language might seem, I don't think it will be as bad as some people might anticipate. Using *all* of the features together would definitely require quite a mastery of the language, but many languages such as some ML dialects or Haskell for example also can be considered the same way, yet they remain quite usable on the whole.

you do know its stated goal is to take on FORTRAN, don't you? yes, completely different audience than that of java/C++...

But what I noticed was:

• improved and more examples
• better introduction (and reordered chapters)
• more detailed dispatch algorithm
• added type inference algorithm
• lists are now indexed with [] instead of <>
• numeric types are now N/Z/Q/R8/16/32/64/128 and C16-256 (Int is gone)
• dividing two integers always gives a rational number
• the supertype of all numeric types is Number (was Num)
• Object is the supertype of all types (was Any)
• added a dimensions and units list
• ranges are explained in their own section (also fixed mistakes: a#b and a:b were used incorrectly in some examples)
• dimensions/units are put behind the type (e.g.: x:R64 Length)
• added widening and coercion support for library writers
• tuple expressions are evaluated in parallel
• added section about early termination of threads
• shared data: method localizeNoCopy() renamed to localize()
• spawn takes a new parameter: 'guaranteed' which allows turning off guaranteed parallelism

I will stop here. :)

Just what I needed.

MathML input and output is a job for an IDE. The design of Fortress assumes that it will probably be used through an IDE which will make the source code look pretty and offer higher-level tools for editing code in a pretty form. Given this assumption, it's reasonable to believe that a decent Fortress IDE would allow copy-and-paste between Fortress and other systems like Mathematica.

...with excrutiating details on concrete syntax and user input encoding ("type this to get that"). Explaining how that will translate into MathML isn't asking much.

Besides, MathML covers semantics, distinguishing it from mere layout (TeX, PostScript). How mathematics interacts with programming is central to Fortress. Between that interface and layout typography are huge areas of MathML overlap. Then you have the notion of working with web browsers and math vendor software, whatever the merits of MathML.

So I don't see how Fortress can, or why it should want, to put off MathML. Avail the fine work by experts from Elsevier, INRIA, Univ. of Waterloo (Maple), IBM, American Mathematical Society, the OpenMath consortium, Wolfram Research (Mathematica), etc. Stand on their shoulders. Join their committees if appropriate. Fortress participation might expand the MathML envelope in important ways to everyone's mutual benefit.

XML syntax will hide under the IDE, but Fortress can't expect an IDE to fix systemic issues caused by today's design decisions. Now is the time for MathML compatibility design. Note that in MathML, Elements can use the definitonURL to override default semantics. There is really no excuse to ignore MathML.

Fortress won't happen very soon if it reinvents typography because that by itself constitutes a five year effort. Leave aside the task of improving FORTRAN and breaking new ground in programmable mathematics. Some time ago I suggested modifying an open source MathML editor to prototype an IDE.

Unless Guy Steele himself joins LtU to chat about his Fortress then I hope we won't see it posted again until the spec breaks 1.0 or software actually ships. A story for every 0.1 design rev is too frequent. Those who care can track Fortress on their own. Guy does participate in other groups like LL and lisp, so I don't know why he bypasses LtU. To his credit we exchanged private messages some while back and some of my feedback folded into the spec. Thank you, Guy. But I'm just one person with opinions whereas MathML is a world standard.

OK. All in all, I like the fact that someone as good as Guy Steele is actually doing something about scientific/math software under the aegis of semi-open-source. FORTRAN itself has come a very long way over the years. If Fortress plays its cards right, it can move the state of the art.

...is of course more than welcome to join LtU. Heck, I'd love to have him guest blog here.

I have a Steele Bust on top of my micro just like pianists have a Beethoven one on top of the piano. ;)

... in common English usage, per is ambiguous and context-sensitive. When you say miles per gallon, you expect it to mean the size of a mile divided by the size of a gallon. But when you write days per week, you expect to see 7, right? Well, if you follow the rule that per means division, you divide the size of a day by the size of a week, and get 1/7.

Hmm.. I expect miles per gallon to mean a quantity of miles divided by a quantity of gallons (giving the number of miles for each gallon). Does dividing the size of a mile by the size of a gallon make sense? (What units?) Likewise, I'd expect days per week to be a number of days divided by a number of weeks, e.g. those in a full year: 365/52 = 7 (well, near enough), i.e. the number of days for each week. There may be a slight difference in meaning, but I'm not sure it's a dangerous ambiguity.

I'm not sure why you ask if dividing one unit of measure by another makes sense, or what the units would be. You're effectively always dividing the size, (you could say "quantity," too,) not the count of things, as you say in your "number" sentence. (If you don't agree, I'll gladly trade your one gallon of milk for my two pints.) Quantity, taken to mean size and not cardinality, is the crucial factor. Only if everything has the same size can you divide the count.

What question are you trying to answer in your 365/52 example? You're dividing the size of a year by the number of weeks in a year, but it's not clear how this supports or contradicts the other part of the sentence.

Of course, any ambiguity where one perfectly common interpretation gives the reciprocal of another interpretation is dangerous. It's more than a "slight difference in meaning." That's why it's generally ill-advised to try and parse English sentences.

For example, note all the special-case convolutions, different interpretations of precedence, and different results that the Google calculator goes through when you enter different things like "days/week", "days per week", "1.0 days per week", "(1.0 days) per week". (Guess what each of these should return before you try them.) Yuck. An unmaintainable, unextensible, unpredictable forest of special cases. In some cases they give you a differently-arranged equation, that you have to rearrange, not a number, and they change precedence rules all around. They all come out to the same thing when you rearrange the terms ... 1/7.

But would a native English speaker still expect "days per week" to return 7? Probably. Best to leave it out.

(For even more fun with the Google calculator and wacky non-standard precedence rules, predict what you'll get when you compare "1/2 days/week" and "-1/2 days/week". Yikes!)

One needs to parse the Fortress specification to see if it's vulnerable to such unexpected precedence violations. They show just such a violation of standard mathematical precedence in their (revised since last time):

w: R64 AngularVelocity := 2 pi radian / 226 million year in sec example.)

I just think that any language which reinvents standard and unambiguous mathematical rules of precedence better think long and hard about why they're doing it, and then think again.

Besides, it's hardly more work or less legible (especially to international users) to type "/" instead of "per". It also follows the guidelines of the SI, which means that programs will read and write better internationally.

I'm not sure why you ask if dividing one unit of measure by another makes sense, or what the units would be. You're effectively always dividing the size, (you could say "quantity," too,) not the count of things, as you say in your "number" sentence. (If you don't agree, I'll gladly trade your one gallon of milk for my two pints.) Quantity, taken to mean size and not cardinality, is the crucial factor. Only if everything has the same size can you divide the count.

When discussing "per" statements you are never dividing "size".

What is the "size" of a mile, or of a gallon? These are different units of measure, and their "sizes" are not directly comparable

or divisible (in PL terms, they are values of different types).

There are well-known rules that are thousands of years old for handling multiplication and division of units of measure with different dimensions. The result may, and likely will, have yet different dimensions. Programatically and conceptually, this is simple.

What is divisible is the number (or count, or cardinality if you prefer) of these things relative to some other (common) unit of measure (since both values will have the same type: "number per common unit").

Thus we compute "miles per gallon" by dividing a number of miles travelled by the the number of gallons required to travel those miles.

This is a case of computing "miles per trip / gallons per trip", with "trip" being the common unit of measure that both miles and gallons are counted against.

A physical thing being measured is independent of a measured quantity (as you can see by factoring c out of the equation above); this is the entire intent of measurement systems. A gram is a gram whether it was measured as a gram of iron or a gram of water; a velocity is a velocity whether it was measured on photon A or photon B or neutrino C. A meter is a meter. (Nobody's allowed to make relativity arguments here.) You cannot divide one rock by another rock; you can divide measured masses of rocks. If we couldn't factor out the thing being measured, we'd never be able to compare measurements made on different things. If you wish to disagree, please start by telling me what the dimensions of "trip" are in SI units. :)

I must also add that, to compare sizes, it is not strictly necessary to postulate a "base" unit that other things are eventually counted in terms of. While Frink does that for computational efficiency, I also considered an unrooted, undirected graph where the nodes are units (e.g. "gallon" and "pint") and the edges indicate the multiplicative factor to convert between the size of these units. (e.g. to convert gallons to pints, multiply by 8. When converting joules to watts, multiply by 1 second.)

The problem with your "days per week" example is that you are using incorrect common units of measure.

You compute "days per week" as "days per day / days per week", and of course get "weeks per day" as your answer.

If you're meaning "per" to be a synonym for division, and follow normal mathematical precedence (division and multiplication are at the same precedence and performed left to right) this should be parsed as ((days/year)/weeks)/year which is days/(year² * weeks), which has dimensions of time^-2.

If instead you used "days per year / weeks per year" you would get the correct result, since the type of the values you divide has the (correct) form "number per common unit", and the common units on the denominators of each side of the division cancel correctly.

If you're meaning "per" to be a synonym for division, but at a higher precedence, (which is the only way the last part of your sentence becomes true) then this becomes (days/year)/(weeks/year) or simply (days/weeks). Again, the algebraic tautology, which introduces no new information. Introducing "year" added zero information content.

You almost make it sound convincing, but you've forgotten again that in Fortress, and the Google Calculator, and Frink, that any unit such as "day" and "year" or "days" and "years" always indicate the size of a day, or a year, (all appear to reduce these in terms of base SI units.) So (days/year)=1/365.x and (weeks/year)=0.0191. The result is still 1/7. The programming language can't read your mind to guess that you intended something different. To make it more interesting, try putting them into variables and see if the program you envision can read your mind and return 7:

a = day
b = week
a per b


What if it's "1 day"? "1.0 day"? If you can make this return the "expected" value (7) in all such cases, without messing up other uses of "per" indicating left/right, please describe your algorithm.

In any case, to address the subject line of your posting, type-checking does not resolve the ambiguity when dividing units with the same dimensions (which was the case I noted as being ambiguous); the result in both cases a/b and b/a is a dimensionless number, and type-checking doesn't help you to see if you got the right answer or the reciprocal of the right answer.

You almost make it sound convincing, but you've forgotten again that in Fortress, and the Google Calculator, and Frink, that any unit such as "day" and "year" or "days" and "years" always indicate the size of a day, or a year, (all appear to reduce these in terms of base SI units.) So (days/year)=1/365.x and (weeks/year)=0.0191. The result is still 1/7.

But how does the language know that I mean 1 day? (Or 1 week?) Being able to reduce "year" singular to 365 days seems safe, but it shouldn't assume that "days" plural means 1 day. The calculation has been changed from "x days per year" to "1 days per year", which is obviously incorrect as it is x we are trying to calculate. But in order to solve for x, we need to know more information: i.e. a common period of time for which we know the number of days and years (e.g. one whole year). Then we can write:

x days     365 days
------  =  --------
1 years     1 years

and solve as x = 365 days. Likewise, we can solve our "days per week" by doing:

x days     365 days
------  =  --------
1 weeks    52 weeks

which solves to x = 7 days (approx). "Per" is still just normal division here.

But how does the language know that I mean 1 day? (Or 1 week?)

Presumably, because you didn't tell it otherwise. I don't think it's reasonable to expect a language to read my mind and know that I meant "x days" or "14 days" when I wrote "days". If there's an unknown factor in there somewhere, it must be explicitly stated.

Being able to reduce "year" singular to 365 days seems safe, but it shouldn't assume that "days" plural means 1 day.

Nice try, but disambiguation based on name or plurality doesn't work with many names. It doesn't work for the most common ones, actually. For example, the SI symbols m, kg, s, cd, A, etc. are written the same way in the singular and plural. That is, you're never allowed to pluralize them by adding an "s" or whatever.

I don't think it's reasonable to expect a language to read my mind and know that I meant "x days" or "14 days" when I wrote "days". If there's an unknown factor in there somewhere, it must be explicitly stated.

But you are assuming that it means 1 day! That is what I am saying is wrong, as it is this number that we are trying to calculate (days per week; the number of days in 1 week). The language shouldn't have to read your mind, it should throw an error if you haven't specified a number of days (or it could allow an unbound logic variable so we can solve for the value), rather than defaulting to 1 day. Trying to calculate "days per week" by dividing the size of 1 day by the size of 1 week doesn't make any sense (to me, at least :-). Likewise, I don't see anything meaningful in dividing the size of 1 mile by the size of 1 gallon. Is there an example of usage of "per" with this interpretation? My understanding of "per" is that "x per y" generally means "a number (quantity) of x for each unit of y", e.g. miles per gallon, inches per foot, doughnuts per lunchbreak. If you specify x, then you are asserting a fact ("my car does 28 miles per gallon", or "there are 12 days in a week") rather than performing a calculation.

However, I can't say I'm overly enthusiastic about use of "per" to mean division so I won't devote any more time trying to defend it.

Ha! A chance to use my favourite units joke.

So what's an inverse acre? It's miles per gallon, obviously (L / L^3) and thus a perfectly appropriate unit of measurement for fuel efficiency.

I don't know how Frink handles this case, but it strikes me as an interesting problem in trying to type-check unit calculations. In the miles per gallon case, inverse acres is probably inappropriate because the miles and the gallons refer to different substances. (On the other hand, there is a good physical intuition as to why inverse acres is an appropriate measurement, albeit with the wrong size for most practical purposes; I generally find gigaoveracres to be more practical.)

A similar issue arises with, for example, measurements of concentration, or map scales. (Say ml/l, cm/m). These are "dimensionless" but it should be a type error to multiply a concentration by a distance or a map scale by a concentration. Shouldn't it? It would almost certainly indicate a programming error.