Re: no names allowed, we serve types only - 02-18-2010 , 10:47 AM
On Feb 17, 10:08*pm, Keith H Duggar <dug... (AT) alum (DOT) mit.edu> wrote:
in the Alice book.
relational operators that depend on the attribute naming.
The issue is more complex, though. The algebra with unnamed attributes
(that is Algebra of Binary Relations) is arguably much more
established construction in math. The parallels between it and
Relational Algebra (in the lattice form) are puzzling. In Algebra of
Binary Relations they have two versions of each operator: logical and
relative. Composition is relative analog of conjunction, converse is
relative analog of negation and so on. In Relational lattice there are
two versions of conjunction, two versions of negation and so on. It is
natural to extend your question and wonder if types are of any use for
Algebra of Binary Relations?
Re: no names allowed, we serve types only - 02-18-2010 , 03:43 PM
Re: no names allowed, we serve types only - 02-18-2010 , 11:33 PM
On Feb 18, 7:44*pm, David BL <davi... (AT) iinet (DOT) net.au> wrote:
elegant way is to operate units as if they are numbers, for example
the expression 10 * kg / (10 * sec^2) is multiplication/division of 4
number-like entities. One can use the laws of associativity/
commutativity and reduce it to 1 * kg/sec^2.
Re: no names allowed, we serve types only - 02-19-2010 , 02:35 AM
On Feb 19, 1:33 pm, Tegiri Nenashi <tegirinena... (AT) gmail (DOT) com> wrote:
computer manipulates these symbolic expressions so as to rearrange
them into a canonical form
value * unit
(i.e. units are moved to the right hand side of a multiplicative
How does validation fit in, if it's not part of the type system? I'm
guessing it's based on unification of symbolic expressions. Is that
I believe the design/implementation of a DBMS is normally broken up
into rather distinct "layers", one of which deals with domain support
(both built-in and user-defined types) and another that deals with the
RM itself and treats domains as generic types.
I'm struggling to understand how a domain datatype could support units
in the way you describe without the generic RM layer ending up
physically recording a unit against every recorded numerical value.
Obviously that's not practical.
If a numerical data type supports units then it must record the unit
as part of an encoded value. If it doesn't then the unit must be
associated statically with the data type itself, contrary to your
claim that types are a misguided approach to physical units. Is it
possible to evade that conundrum?
Re: no names allowed, we serve types only - 02-19-2010 , 11:00 AM
On Feb 19, 12:35*am, David BL <davi... (AT) iinet (DOT) net.au> wrote:
Re: no names allowed, we serve types only - 02-19-2010 , 01:42 PM
On Feb 19, 2:35*am, David BL <davi... (AT) iinet (DOT) net.au> wrote:
Looks like MS has recently worked this into their F# language, by
allowing units as parameterizations of types.
Interesting series of blogs that delve into it in great depth:
Re: no names allowed, we serve types only - 02-19-2010 , 09:15 PM
On Feb 20, 10:40 am, David BL <davi... (AT) iinet (DOT) net.au> wrote:
Re: no names allowed, we serve types only - 02-21-2010 , 10:30 AM
On Feb 21, 6:05 am, Jan Hidders <hidd... (AT) gmail (DOT) com> wrote:
in the context of operator specifications in general. So a type
system could allow fine grained control over the signatures that
are implicity/explicity allowed with/without coersion. In the
example below I'm going to continue using "copy" to denote the
declaration of a "strong" type alias ie it creates a distinct
type not just another name for same type. So let's suppose we
define X and Y coordinates type as copies of an Integer type
copy Integer X
copy Integer Y
and that by default the type system does not supply implicit
coersion nor the multi-sorted equality operators. Then we would
explicity add those multi-sorted signatures
= : X, Y -> bool
= : Y, X -> bool
to the type system. This would allow X and Y equality comparison.
Now suppose elsewhere we have defined a part count
copy Integer PartCount
but do not add the multi-sorted (with X and Y) equality operators.
Then PartCount will not by default be equality comparable to X and
Y. This allows one to control the semantics.
One can also easily create various groups of semantically related
types to allow convenient shortcuts. For example, if we have more
than just two coordinates say we add Z, W, T it would be annoying
to explicity define the equality signatures for all permutations
of those types even though we want them to be comparable. So we
first create a Coordinate type then copy it
copy Integer Coordinate
copy Coordinate X
copy Coordinate Y
copy Coordinate Z
copy Coordinate W
copy Coordinate T
and now explicity add implicit coersion signatures
() : X -> Coordinate
() : Y -> Coordinate
() : Z -> Coordinate
() : W -> Coordinate
() : T -> Coordinate
which now allows implicit mutual equality comparison (and any other
operators) between X, Y, Z, W, T and Coordinate since they are now
implicitly coerced to Coordinate. Here we only had to explicitly add
only a linear number of implicit coersion operators instead of a
combinatorial number of equality signatures.
Re: no names allowed, we serve types only - 02-21-2010 , 05:40 PM
Tegiri Nenashi wrote:
The differences are conceptual and logical not just physical.
Re: no names allowed, we serve types only - 02-21-2010 , 07:10 PM
Bob Badour wrote:
aspect of type theory, eg., the very mention of it usually makes me ask
myself how to record the value of one-third of a meter (which might be
why I usually try to keep out of typing discussions). Probably my own
inadequacy, not having grown up in a metric country it never occurred to
me to wonder what one-fifth of a foot is. International agreement about
25.4 mm's being an inch doesn't help. Seems to me that the application
requirement always trumps questions of precision and any practical dbms
needs to require/allow decimal places for numeric types. While I
sympathize with Keith D's wish to eliminate the 'name,type' double, I
think that practical issues require not only so-called 'possreps' but
also what I think of as a 'name,type,use' triples. What a mess!
As for having just types, I still think that Codd introduced his
attribute names because of relations that can have two 'columns' of the
same type. I think Keith D is arguing against this and if I'm right
about that, I'd like him to deal with that case, not to say it can't be
done, just that I'd like to see whether his "copy" in a language is a