Home » forums » LtU Forum

New Fortress Specification

I was just doing a search for the Fortress language specification that Sun's working on, and found that they released a new version of the specification (version 0.707) a couple of days ago.

I haven't read over it in much detail, but I've noticed that they made some changes to their interesting "do what I mean" unit manipulation fixups. For example, one of their samples that I questioned before now reads:

w: radian/s := 2 pi radian / 226 million year in s

Of course, parsing this the way they intend breaks a lot of normal mathematical precedence rules, and violates the recommendations of the SI. I'd sure like for them to list the rules that they use to "do what I mean" and perform "context-sensitive disambiguation." In my opinion, such things are equivalent to reading minds. And can "in" also mean "inches"? What's "3 in in in?" Or "1 foot^2 in in in?" Or, equivalently, "144 in in in in in"? Hmmm... It's still my bet that the final language will have to follow normal precedence rules more closely, because these "fixups" tend to paint you into an indefensible, surprising, and ugly corner, and they punish those who understand and write normal mathematical notation perfectly in favor of the dumber people who might make mistakes. I've taken the tactic of "err on the side of being pedantic, and try to teach correct, unambiguous usage" in my Frink language.

As an example, a friend just pointed me to the following scary differences in the Google calculator, which gives results not even having the same dimensions:

1/2 seconds
-1/2 seconds

Try these. Gah! Also see the Frink FAQ about this issue.

By Alan Eliasen at 2005-08-01 07:15 | LtU Forum | previous forum topic | next forum topic | other blogs | 9940 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

I just had brilliant goofy idea

can "in" also mean "inches"

For the cost of binding the language tightly to a set of input methods, why not make all of the keywords a certain font/style/face, and all of the user-code something different.
Syntax highlighting isn't a terribly new idea, but it gets applied on the back end of the input.
If you could specify hilighting as you type, and the parse/lexical analysis were aware of it, you could have for be a keyword, and for be available for frobincation (he said, veering away from the non-general-audience possibilities).
This has likely been done already, but I've never seen it.

By Chris at Mon, 2005-08-01 13:41 | login or register to post comments

This would cause me so much p

This would cause me so much pain I would have to change profession. Oh wait, that happened already.

By Marcin Tustin at Mon, 2005-08-01 14:19 | login or register to post comments

I think you can do that in Co

I think you can do that in Color Forth. to be more specifik, words have diffrent meaning depending om wich color you type them in.

By Felicia Li Svilling at Mon, 2005-08-01 14:46 | login or register to post comments

Unicode

It's possible that you'll need a fancy editor to write Fortress programs, so some sort of visual cue like color or boldface might not be too far off. They use a lot of Unicode characters as part of their syntax, and allow things like subscripts to denote the radix of numeric literals. (It looks like subscripting can be faked by the operator [ ] and such.)

It's also interesting to see how significant they've made whitespace. In some cases, whitespace between "enclosing" operators like [ ] has to be balanced, or it's an error. "Tight" fractions, that is the use of the / operator with no whitespace on either side, binds tighter than other operators, but it can't be used more than once in a "tight" fraction.

They also have "loose" and "tight" juxtaposition, where expressions can be placed next to each other and bind tighter or looser depending on intervening whitespace. The surprising thing about this is that the tightness of associativity depends on the types involved and is different for loose and tight associativity.

By Alan Eliasen at Mon, 2005-08-01 23:29 | login or register to post comments

Algol: a great improvement on its successors

Both Algol and Algol 68 distinguished between boldface keywords and lightface identifiers. On machines, boldface was implemented in a variety of ways: BEGIN, .begin, 'begin', all distinct from the plain identifier begin.

By johnwcowan at Mon, 2005-08-01 19:04 | login or register to post comments