[Fortress-interest] Some observations about the 1.0a spec

[Victor Luchangco]

Jan-Willem Maessen wrote:

> On Jan 3, 2007, at 7:10 AM, Mike Atkinson wrote:
>
>> Missing? deprecated
>>
>> I think this is needed for long term maintenance of APIs
>
>
> This is more of an issue if you believe that an API can change  
> version without changing name.  Our feeling is that programs are  
> written and linked against a *particular* API version, which defines  
> what it defines.  A component can implement several API versions.
>
> That said, there's going to need to be some thought put into how we  
> manage API evolution.  First we need enough APIs to evolve.


We also think we will likely want to have some kind of "subtyping" among 
APIs, to help with API evolution, but we haven't settled on any 
specifics here yet.  We're explicitly putting this and related issues 
off for now, until we have some real experience with our component 
system.  That said, our intention is that it is APIs (or "versions" of 
APIs) that are "deprecated", not parts of APIs, so that extant code is 
not made nonfunctional by "upgrades" in run-time executives.

>> Missing? Annotations
>>
>> There seems to be no method of modifying the syntax tree after it  is 
>> generated, syntax expanders are identified and expanded before  
>> parsing occurs.
>

We have a number of ideas about syntax expanders and other mechanisms to 
extend the language.  We think we may even want different mechanisms for 
including domain-specific languages in Fortress programs and for 
allowing new "primitives" to be defined in libraries.  But we need to 
explore the issues here a  lot more, and we've pushed this off for now: 
Fortress 1.0 will probably only have a relatively simple syntax 
expansion story (though it will still need to be refined from what's in 
1.0a, which has some problems, e.g., in the handling of matching 
parentheses).

>> various places e.g. section 2.8
>> for i ??? 1 : 10 do
>>     print(i ??? ???)
>> end
>>
>>
>> It seems that juxtaposition of an object with a string converts the  
>> object to a string using the Object toString(): String methd. I  
>> couldn't find this stated explicitly anywhere. 
>

juxtaposition is an operator, which can be defined in libraries like 
other operators, except that it can only be a binary infix operator.  At 
the most basic level, it doesn't have any definition, but the standard 
library trait would probably have the following declarations, or 
something like them:

opr juxtaposition(x: String, y: String) = ... (* string concatenation *)
opr juxtaposition(x: Object, y: String) = x.toString() y
opr juxtaposition(x: String, y: Object) = x y.toString()

With these declarations, juxtaposition of a string with any nonstring 
would invoke the nonstring's toString method, as desired.

>> My experience is  that though this is OK for quick and dirty output, 
>> most of the time  formatted IO is much more useful, that is why C 
>> style formatted IO  was added to Java, it is just too useful.
>

Note that the above declarations would be in libraries, which may also 
provide functions that produce formatted strings.  There's no reason 
they couldn't all live together.  We can even accommodate incompatible 
variants in different libraries (i.e., components).  That's the beauty 
of having all this stuff be in libraries.  (Formatted I/O will probably 
use standard function syntax--not operator syntax--with commas to 
separate arguments.)

>> The range 2:5:-1 does not seem to be ruled out by the definitions  in 
>> section 13.6, but does not make sense.
>

The expression 2:5:-1 is well-formed, but will probably result in a 
thrown exception, or perhaps an empty range (the definition would also 
be in the standard library, not fixed by the core language).

>> I may have missed it but is there any way of distributing  components 
>> in other than source form? If user A creates a compound  component is 
>> there any way for him to distribute it to user B other  than in 
>> source form and a sequence of compile, link, upgrade  commands? Are 
>> these compile, link, upgrade, etc. commands  guaranteed to give the 
>> same composite component for user B?
>
>
> Components can be serialized, but I'll admit that we haven't worked  
> out all the representation details; for the moment we intend our  
> prototype to just use source code to represent components, possibly  
> with a pre-parsed AST form as an alternative.  Anything we use is  
> going to be pretty close to source code for the time being (so it  
> should be possible to do AST->AST rewriting passes on existing  
> components for example).


There's nothing in the spec that says you need to distribute components 
with source code.  We explicitly designed the component system so that 
you don't have to do so.  Indeed, you can even distribute a "component" 
that requires the fortress on which it is installed to have certain 
subcomponents, and then link to these subcomponents on installation 
rather than carry any representation of the subcomponent other than a 
means to identify it.  This is important because a vendor's component 
may require another vendor's component, which the first vendor does not 
have the right to distribute.

Of course, as Jan says, we plan to stick with open-source components as 
much as possible for now.

- Victor