RE: [office-formula] Separation of concerns - Chapter 4 and Booleans too

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

I am completely aligned with Rob's responses here.

 - Dennis

PS: Tangential to the pseudo-type discussion, there are also disguised
types, that is a type that is achieved by constrained usage of another type
by applying some sort of convention.  Apropos today's discussion, there is
no type Boolean in the C Language in pre-20xy JTC1 International Standard
specifications.  However, where a boolean choice is made, numeric values of
0 are understood to represent "false" and non-zero numeric values are
understood to represent "true" (and don't ask about NaNs).  Similarly, where
a boolean choice is a result of calculation and a numeric value is required
(for storage or for further use in a formula evaluation), 0 is supplied for
"false" and 1 is supplied for "true".  Notice the way this is expressed and
how there is a similar way of handling this in OpenFormula that would make
great sense.  (No operations in Standard C Language are defined as having
boolean results, since there is no need, but describing it this way is
appropriate if there is the possibility of there being a boolean type as
well as disguised use of numeric types for representing boolean cases.)

PPS: Historically, the use of "disguise" goes back to the so-called
Hollerith Data type in Fortran 66.  The mapping of a wider-ranging type to
and from boolean cases goes back to the original LISP, which only had one
type (a.k.a SEXPR), with the atom NIL understood to represent "false" and
anything else accepted as representing "true."

-----Original Message-----
From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] 
http://lists.oasis-open.org/archives/office-formula/200912/msg00035.html
Sent: Tuesday, December 08, 2009 06:57
To: office-formula@lists.oasis-open.org
Subject: Re: [office-formula] Separation of concerns - Chapter 4

Patrick Durusau <patrick@durusau.net> wrote on 12/08/2009 09:32:09 AM:
http://lists.oasis-open.org/archives/office-formula/200912/msg00034.html
> 
> So, if we are going to separate out the concerns of parts 1 and 2 as 
> documents and formulas respectively, may I assume that all the 
> statements in chapter 4 about OpenDocument attribute values and their 
> meanings simply goes away?
> 

1) We should not be referring to office attributes

2) We not be talking about UTF-8 versus UTF-16.  OpenFormula expressions 
are syntactically defined in terms of Unicode strings.  We're in the value 
space of xsd:string, not the XML lexical representation or in the Unicode 
encoded character.  However, at the semantic level, there are a few 
specific functions that do character conversions, like CHAR().  The 
semantics of these functions will need to be defined in terms of character 
representations.

3) There are a few constraints, like : "In OpenDocument, the 
office:value-type of text (string) values is string; if the computed value 
is stored, it is stored in the attribute office:string-value.".  IMHO, 
these should be moved into Part 1, since they are independent of 
OpenFormula.  In particular, if an Extended ODF document uses another 
formula expression language, not OpenFormula, I'd expect that these 
constraints would still hold, since these are really type consistency 
constraints, not statements about Expressions or Evaluators.


> BTW, pseudotypes? (Google "pseudotypes databases" returns 82,800 "hits")
> 
> PostgresSQL uses pseudo-types.
> 
> I really don't think of "database" as a "pseudotype," however it is 
spelled.
> 
> Suggest the easier route is just to define types.
> 

I think of a pseudotype as an alias for another type, used notationally to 
simplify the specification.  They are never necessary to have.  In fact, 
if they were essentially, they would be real types.  But they can be 
useful.  For example, if two types are lexically identical, but one has 
distinct semantics.  But there would be no abuse of logic to call these 
all 'types'. 

-Rob


[ ... ]