Re: [office-formula] Grammar

[Eike Rathke <erack@sun.com>]

Hi David,

On Tue, Mar 14, 2006 at 22:25:14 -0500, David A. Wheeler wrote:

> >> [... NLF intersection ...]
> >You need to be able to represent it different in the UI.
> A simple way is to have a different operator if it's likely to be 
> represented differently ("!!" perhaps?).

That might be an idea. Using '!!' sounds related.

> But how are the NLF names represented? As strings?

As quoted identifiers, using single quotes (apostrophes).

> If so, then you 
> probably MUST have a different operator, because you're doing something 
> different. E.G.,:
> "Sales" !! "Hamburg"

Would be   'Sales' !! 'Hamburg'   then, respectively the quotes written
as their entity '  Which makes me think whether we need a different
operator at all, since 'label1'!'label2' is already different from
name1!name2, but for clarity it may be convenient to have it.


> > [... cell "union" reference list ...]
> >IMHO 'ReferenceList' would be unambiguous, that names exactly what it
> >is, a list of references.
> 
> Unfortunately we also have function parameter lists, so the term "list" 
> is also confusing. A reference list could be a list of parameters that 
> happen to be references. Any other terminology ideas?

ReferenceConcatenation.


> >>I don't think we need to support more built-in types for constants in the 
> >>SYNTAX (except _maybe_ complex numbers).  Most types should derivable 
> >>from Number, String, and logical values, when sent through functions.
> >>    
> >
> >Do we even need Logical? Yes, I know there are implementations that
> >unnecessarily differentiate between Number and Logical, but so far
> >I don't see any benefit in defining a built-in type for it.
> >  
> I think we have to.  The MAIN reason is that unless we FORBID 
> implementations to have a separate Logical type, we have to be able to 
> at least ALLOW implementations to have them.  Many implementations, 
> including Excel, Gnumeric, and SheetToGo, have separate Logical types 
> that meaningfully CHANGE the semantics of many functions.  For example, 
> they all automatically SKIP Logical types when they are looking for a 
> NumberSequence (so SUM, AVERAGE, etc. will SKIP Logical types).

Unfortunately, yes.. it doesn't allow you to have a column of results of
logical comparisons and do a SUM or AVERAGE on it..

Ok, if we need a Logical type, we also have to define that it can be
represented with any numerical value, and that 0 means FALSE and
anything not 0 means TRUE.


> We 
> cannot express that kind of semantic without defining a logical type.  I 
> think a spec that CANNOT, and WILL NOT, be implemented by that many 
> implementations will not succeed in the marketplace, and I'd expect the 
> TC or wider OASIS votes to fail if we did that.  I'd certainly expect 
> Jody (who's on this list) to go ballistic if we tried to forbid having a 
> separate Logical type. :-)

It was never my intention to _forbid_ a logical type. Just that the
behavior it implies is implementation-defined.


> I think we'd probably be better off MANDATING a separate Logical type.  
> Most languages grow a boolean type, sooner or later.  I think there's 
> even a patch available to add that to OpenOffice.org.

I'm not aware of any.

> But if there's no 
> consensus on that (my suspicion), the best we can probably do is define 
> a Logical type, and note that it MAY be a separate type or not (and 
> define the legal semantic alternatives).

Which is what we should do.

> Besides, a vast number of functions accept or generate a logical value 
> (IF, etc.).  Even if the implementation is just a number, it's MUCH 
> easier to describe many functions if you can refer to a "logical type", 
> and I think it's easier to understand, too.

Seconded.

  Eike