Re: [office-formula] Grammar

["David A. Wheeler" <dwheeler@dwheeler.com>]

Eike Rathke wrote:
> Hi David,
>
> On Fri, Mar 03, 2006 at 15:00:09 -0500, David A. Wheeler wrote:
>
>   
>> The grammar Eike posted is happily very similar (yay!), but I think
>> it is also overly complex, e.g.,
>> data type mismatches are best handled by typing, not the syntax.
>>     
>
> Ok. We can keep the syntax quite simple then, but will probably have to elaborate a bit more on parameter typing for specific functions, which is also fine.
>   
Right.  I think that's the right place anyway; for every 
function/operation, you specify the types of its parameters.  That lets 
you handle weird cases much more cleanly.


>> We can also handle whitespace separately, and not try to
>> create a large independent set of syntax for references.
>>     
>
> Most of my whitespace approach resulted from the fact that whitespace is significant in the sense of that it should be preserved, because that is what the user expects. If we declare that somewhere and make it part of the spec then I'm fine with it.
>   
100% agree.  Let's do that.


>> One issue: neither really specifically identifies the NLF intersection
>> operator.  However, "!" is the cell intersection operator for ranges
>> in OpenFormula, e.g.:
>>  [.A1:.G20]![.A1:.Z2]
>> I don't see why NLF intersection needs a syntactically separate
>> operator.  It's the same operation (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?).

But how are the NLF names represented? As strings?  If so, then you 
probably MUST have a different operator, because you're doing something 
different. E.G.,:
 "Sales" !! "Hamburg"

If they are just:
 Sales Hamburg
How do you tell the difference from a named expression and the left hand 
side of an NLF?


>
>   
>>> Yes. In fact the cell "union" is not a union, but a list instead. A union 
>>> would unify overlapping ranges, the list does not. (A1:A3;A2) evaluates A2 
>>> twice.
>>>       
>> Yes, I even noted that in the OpenFormula text.  I don't like the term 
>> "union", it's very misleading, but that seems to be what people call it.
>>     
>
> I also call it union in informal speech, but for the spec we should call it list instead.
>   

> 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?

>> 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).  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. :-)

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.  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).  Then we can give users the 
tools they need to avoid any problems arising from these different 
approaches.  These differences are annoying spec-wise, but normally 
don't cause problems in practice.

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.


--- David A. Wheeler