[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-formula] Grammar
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]