[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-comment] Conceptual Problem: Ambiguity for Names usedin Formulas
Hello David, dear list-members, David A. Wheeler wrote: > Leonard Mada: > >> Thanks for the clarification. >> Though, a small nitpick if I am allowed: >> Cell references are marked/surrounded by: [...] >> I wonder IF a proper tag wouldn't be more future oriented. >> Something like: >> <ref>....</ref> >> and >> <name>...</name> >> (or something similar) >> > > We don't want to do that SPECIFIC thing. These are contained as > attributes inside an XML file, so using XML markings would probably > be confusing. In any case, it's not needed. > Well, references are currently saved as '[...]', but I would like to see more vector-capabilities in spreadsheets. Now, unfortunately square brackets ('[...]') make an excellent way to access vectors (or series, arrays and all the fun stuff). So, there might come a time, when even spreadsheets will want to have such an operator. Of course, then it becomes necessary to store references differently [storing is necessary, because otherwise it might conflict with named ranges & expressions]. Also, I already proposed some time ago to implement strong typing in spreadsheets and a lengthy discussion did ensue. Strong typing will come at some point. This creates the requirement to store the unit, so any value will have some tags associated with it. Arguably, named ranges/expressions could be evaluated at run-time, but it would be more efficient to store the unit. While this does NOT directly support my request, IF you already have to store a specific tag, why NOT have tags even for the named ranges/expressions in the first part? And then, why use a hybrid store-mechanism, and why not store everything as pure xml? [I do not understand much of xml, I'll let the experts work this out.] My main concern is however a different one. Named ranges/expressions are just 2 possible objects. Arguably, spreadsheets did NOT implement anything more advanced up to date, but professional programs do exist that permit defining more complex objects. And spreadsheets will follow at some time, too. [see the S+ language as implemented e.g. in R, http://www.R-project.org, and other mathematical and science languages] I would strongly oppose adding a new identifier (like '[', '{', what else? ) for every new type of object. Sincerely, Leonard Mada P.S. I am subscribed to this list, so there is NO need to cc me a copy ;-) >> Of course, implementations will vary in how they display it on screen, >> but ODF should remove any ambiguity and remain open for any future changes. >> > > There's NEVER any ambiguity in the exchange format: > * If it's a cell reference, it is ALWAYS surrounded by [...]. > * If it's a named expression, it is NEVER surrounded by [..]. > Most named expressions are simply referred to by name, > but if you want to begin the name itself with > '[' or include other "odd" characters, you have to start the name > with the special escape format "$$" that ALWAYS introduced > the name of a named expression. > > So you just need to look at the first character, and that determines > whether it is a cell reference or name of a named expression. > There's no need for special disambiguation rules. > > Here's an example, perhaps that will make it clear: > A1 is a named expression, whose name is A1 > [.A1] is a reference to the cell A1 > > >> My 2nd complain is about the default handling of names/ranges: >> - IF a named range/expression is defined, then >> the user most likely wants to use this named range/expression >> - not the reference the string 'points' to >> >> Therefore, I would prefer that whenever there is an ambiguity between a >> named range and an actual cell/range, the named range/expression be >> used. The user wouldn't have named it like that, IF he needs to point to >> that particular column. >> > > Again, there's no ambiguity in the exchange format, so there's > no need for a rule to disambiguate it. So if you want to create > a named expression named "A1", you can exchange it. > (It's not a good idea, because it could confuse people, but you CAN express it.) > > Now for the user interface, the rule you give is > usually a good idea, and I believe it's what most apps do already. > But the user interface is out-of-scope for the > formula spec. People can (and do) change the user interface. > In fact, in at least one spreadsheet application > (Word Perfect's Quattro Pro), the user interface > is a run-time setting you can change while running the app. > Function names tend to change based on the locale, too. > Which is why we've concentrated on the _exchange_ format, and > not the user interface - there's lots of variance in the user interface. > > --- David A. Wheeler > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]