Darren Duncan wrote:
At 2:03 PM -0700 5/6/06, Larry Wall wrote (in reply):

>No, Range objects in Perl 6 are defined to be intervals unless used
>in a context that implies discrete increments, such as counting in
>list context. But if you say
>>
>$x ~~ 1.2 ^ 3.4
>>
>it is exactly equivalent to
>>
>1.2 <= $x < 3.4
>>
>The main point of context is to avoid an explosion of types.
At 10:19 PM +0100 5/6/06, James Mastros wrote (also in reply):

>A range listifies to a (potentially) finite list of discrete elements,
>but
>it compares as a range. 1.1 should ~~ 12; pugs thinking that's
>false is a
>bug, not a feature.
, thank you both for clarifying this.
Conceptually in my mind, a Range is entirely appropriate to represent a
mathematical interval, but I was mistaken about Range being more
constrained than it actually is.
So, there you go mAsterdam; Range is indeed the interval you are looking
for.
I hope it is also the appropriate type for implementing
relations with temporal attributes.
Thank you all for your prompt discussion.

At 3:06 PM +0200 5/6/06, mAsterdam wrote:
>Prompted by Darren Duncan's proposal on Relation type objects
>I looked at
>and wondered how Interval type objects would fit in.
>
>I couldn't imagine how. Now that isn't a surprise
>(not for lack of imagination but for lack of perl6 knowledge).
>I tried to find anything relevant but didn't succeed.
>
>Could somebody provide some clues, please?

Can we first clarify that this describes what you are referring to:

(mathematics)

From what I've read there, I don't see an existing equivalent Perl 6 type.

Some people may confuse it with a Range, but I don't think so since a
Range progresses in discrete increments, while an Interval would be
continuous.

Moreover, the existing Set wouldn't overlap it because Set deals with
a finite collection of discrete members. (Similarly, a Relation is
explicitly discrete and finite by definition.)

I assume you aren't referring to the temporal specific thing called
an interval.
-- Darren Duncan

Sat, May 06, 2006 at 01:41:41PM -0700, Darren Duncan wrote:
: Some people may confuse it with a Range, but I don't think so since a
: Range progresses in discrete increments, while an Interval would be
: continuous.

No, Range objects in Perl 6 are defined to be intervals unless used
in a context that implies discrete increments, such as counting in
list context. But if you say

$x ~~ 1.2 ^ 3.4

it is exactly equivalent to

1.2 <= $x < 3.4

The main point of context is to avoid an explosion of types.

Larry

Sat, May 06, 2006 at 01:41:41PM -0700, Darren Duncan wrote:
Some people may confuse it with a Range, but I don't think so since a
Range progresses in discrete increments, while an Interval would be
continuous.
A range listifies to a (potentially) finite list of discrete elements, but
it compares as a range. 1.1 should ~~ 12; pugs thinking that's false is a
bug, not a feature.

course, that doesn't mean implementing range in a subset of perl6 without
it isn't interesting, and possibly useful for bootstrapping.

James Mastros

At 2:03 PM -0700 5/6/06, Larry Wall wrote (in reply):
>No, Range objects in Perl 6 are defined to be intervals unless used
>in a context that implies discrete increments, such as counting in
>list context. But if you say
>
$x ~~ 1.2 ^ 3.4
>
>it is exactly equivalent to
>
1.2 <= $x < 3.4
>
>The main point of context is to avoid an explosion of types.

At 10:19 PM +0100 5/6/06, James Mastros wrote (also in reply):
>A range listifies to a (potentially) finite list of discrete elements, but
>it compares as a range. 1.1 should ~~ 12; pugs thinking that's false is a
>bug, not a feature.

, thank you both for clarifying this.

Conceptually in my mind, a Range is entirely appropriate to represent
a mathematical interval, but I was mistaken about Range being more
constrained than it actually is.

So, there you go mAsterdam; Range is indeed the interval you are looking for.
-- Darren Duncan

Darren Duncan wrote:
mAsterdam wrote:

>Prompted by Darren Duncan's proposal on Relation type objects
>I looked at
>and wondered how Interval type objects would fit in.
>>
>I couldn't imagine how. Now that isn't a surprise
>(not for lack of imagination but for lack of perl6 knowledge).
>I tried to find anything relevant but didn't succeed.
>>
>Could somebody provide some clues, please?

Can we first clarify that this describes what you are referring to:

(mathematics)

Mathematical concepts never seem to completely
survive implementation in computing, but basically yes,
that was what I was thinking about.

From what I've read there, I don't see an existing equivalent Perl 6 type.

Some people may confuse it with a Range, but I don't think so since a
Range progresses in discrete increments, while an Interval would be
continuous.

Moreover, the existing Set wouldn't overlap it because Set deals with a
finite collection of discrete members. (Similarly, a Relation is
explicitly discrete and finite by definition.)

I assume you aren't referring to the temporal specific thing called an
interval.

Date, Darwen and Lorentzos (Temporal data and the relational
model, 2003) build their temporal reasoning on top of
point types and interval types - they require them
allright - but I don't see how interval types (and point
types) require temporal stuff, i.o.w. I don't really
see how they are temporal specific (unless you are
thinking of SQL intervals).

Prompted by Darren Duncan's proposal on Relation type objects
I looked at
and wondered how Interval type objects would fit in.

I couldn't imagine how. Now that isn't a surprise
(not for lack of imagination but for lack of perl6 knowledge).
I tried to find anything relevant but didn't succeed.

Could somebody provide some clues, please?

Darren Duncan wrote:
At 12:45 AM +0200 5/7/06, mAsterdam wrote:

, thank you both for clarifying this.

Conceptually in my mind, a Range is entirely appropriate to represent
a mathematical interval, but I was mistaken about Range being more
constrained than it actually is.

So, there you go mAsterdam; Range is indeed the interval you are
looking for.
>>
>I hope it is also the appropriate type for implementing
>relations with temporal attributes.
>>
>Thank you all for your prompt discussion.

It should work just fine.

Keep in mind that your concern about relations is orthogonal to the
concern about intervals or temporal data.

I hope (and think) you are right about that regarding
implementing relations. Using them correctly is another
story though. I don't think Date, Darwen & Lorentzos
lightly took the step of introducing 6NF in 2003.

An attribute of a relation can be any arbitrary data type at all
(including another relation).

Aside, about RVA (relation valued attibutes): I read at
comp.database.theory that Hugh Darwen has introduced
gu(group/ungroup)NF a month ago.

So the only real concern here is whether there is a data type that can
represent a single piece of temporal data. But one can easily be
defined using Perl's standard class definition abilities if it isn't
pre-defined.

I really don't yet see how to define point types and interval
(range) types based on those. I think you (we) /will/ need them
(*not* neccesarily Perl 6 built-in) if

Note that I am of the opinion that Perl probably should not have
built-in data types that are specific to temporal or spacial data; it is
better for these to be extensions (like "DateTime" etc) defined over
built-ins like numbers or ranges or collections. Temporal or spacial
data in common use today is just too complicated and non-generic, I think.

(Whereas, the existing built-ins, and relations, are very generic and
simple.)

you, like I, want temporal and spacial data as simple
and generic as possible.

At 2:17 AM +0200 5/7/06, mAsterdam wrote:
>I hope (and think) you are right about that regarding
>implementing relations. Using them correctly is another
>story though. I don't think Date, Darwen & Lorentzos
>lightly took the step of introducing 6NF in 2003.
>
>Aside, about RVA (relation valued attibutes): I read at
>comp.database.theory that Hugh Darwen has introduced
>gu(group/ungroup)NF a month ago.

mAsterdam, I think we should end this sub-thread as I see these
points you are now bringing up are well beyond the scope of what the
Perl 6 language designers need to know or care about so I don't see a
need to continue it on list.

Even for me personally, I don't think this is anything to worry about.

But perhaps to explain why I think this

Ignoring 1NF, which relations are always in by definition (they
contain no duplicate tuples/rows), but things like SQL tables or
non-relation collections could possibly not be, the 2NF+ have nothing
to do with the actual definitions of relations themselves or the
ability to perform relational algebra, which is all that the Perl
language and/or extension classes to it need to know about.

The 2nd and higher "normal forms" are just formal labels applied to
certain best practices that one can follow when designing a
relational database. They are efforts to further reduce redundancy
in the collection of relations making up a relational database. Best
left to the users to make decisions about rather than the language
designers.

>>So the only real concern here is whether there is a data type that
>>can represent a single piece of temporal data. But one can easily
>>be defined using Perl's standard class definition abilities if it
>>isn't pre-defined.
>
>I really don't yet see how to define point types and interval
>(range) types based on those. I think you (we) /will/ need them
>(*not* neccesarily Perl 6 built-in) if
>
you, like I, want temporal and spacial data as simple
>and generic as possible.

You can do it simply, kind of like this:

class Point { has Real $x; has Real $y; };

subset Interval of Range where { all( .items ).does(Real) };
-- Darren Duncan

At 6:06 PM -0700 5/6/06, Darren Duncan wrote:
>You can do it simply, kind of like this:
>
>class Point { has Real $x; has Real $y; };
>
>subset Interval of Range where { all( .items ).does(Real) };

Er, you should read 'Real' as 'Num' (I originally meant Rational,
which no longer exists in the newest S06); I meant to say:

class Point { has Num $x; has Num $y; };

subset Interval of Range where } all( .items ).does(Num) };
-- Darren Duncan

Sat, May 06, 2006 at 06:15:34PM -0700, Darren Duncan wrote:
: Er, you should read 'Real' as 'Num' (I originally meant Rational,
: which no longer exists in the newest S06);

Rational still exists in S02 just don't automatically promote
anything to it currently. (A pragma could change that default in
a particular lexical scope, of course.) The main problem with
Rationals is that they tend to waste a lot of bits maintaining
precision that is of little or no use in the real world, and they
can't easily be sized in advance of the calculation if you're planning
to store them in a particular spot. Floaters win on both counts.

Larry

Darren Duncan wrote:
At 2:17 AM +0200 5/7/06, mAsterdam wrote:

>I hope (and think) you are right about that regarding
>implementing relations. Using them correctly is another
>story though. I don't think Date, Darwen & Lorentzos
>lightly took the step of introducing 6NF in 2003.
>>
>Aside, about RVA (relation valued attibutes): I read at
>comp.database.theory that Hugh Darwen has introduced
>gu(group/ungroup)NF a month ago.

mAsterdam, I think we should end this sub-thread as I see these points
you are now bringing up are well beyond the scope of what the Perl 6
language designers need to know or care about so I don't see a need to
continue it on list.

Even for me personally, I don't think this is anything to worry about.

But perhaps to explain why I think this

Ignoring 1NF, which relations are always in by definition (they contain
no duplicate tuples/rows), but things like SQL tables or non-relation
collections could possibly not be, the 2NF+ have nothing to do with the
actual definitions of relations themselves or the ability to perform
relational algebra, which is all that the Perl language and/or extension
classes to it need to know about.

The 2nd and higher "normal forms" are just formal labels applied to
certain best practices that one can follow when designing a relational
database. They are efforts to further reduce redundancy in the

No. Common misconception - but indeed not relevant to p.p6.l

collection of relations making up a relational database. Best left to
the users to make decisions about rather than the language designers.

So the only real concern here is whether there is a data type that
can represent a single piece of temporal data. But one can easily be
defined using Perl's standard class definition abilities if it isn't
pre-defined.
>>
>>
>I really don't yet see how to define point types and interval
>(range) types based on those. I think you (we) /will/ need them
>(*not* neccesarily Perl 6 built-in) if
>>
>you, like I, want temporal and spacial data as simple
>and generic as possible.

You can do it simply, kind of like this:

class Point { has Real $x; has Real $y; };

subset Interval of Range where { all( .items ).does(Real) };

How to go about about having cyclic intervals over
(weekday) points e.g. FriMon ?

If you want to discuss this off-list - the email-address
simply works :-) (huge amounts of spam though :-( )

At 12:45 AM +0200 5/7/06, mAsterdam wrote:
>>, thank you both for clarifying this.
>>
>>Conceptually in my mind, a Range is entirely appropriate to
>>represent a mathematical interval, but I was mistaken about Range
>>being more constrained than it actually is.
>>
>>So, there you go mAsterdam; Range is indeed the interval you are looking for.
>
>I hope it is also the appropriate type for implementing
>relations with temporal attributes.
>
>Thank you all for your prompt discussion.

It should work just fine.

Keep in mind that your concern about relations is orthogonal to the
concern about intervals or temporal data.

An attribute of a relation can be any arbitrary data type at all
(including another relation).

So the only real concern here is whether there is a data type that
can represent a single piece of temporal data. But one can easily be
defined using Perl's standard class definition abilities if it isn't
pre-defined.

Note that I am of the opinion that Perl probably should not have
built-in data types that are specific to temporal or spacial data; it
is better for these to be extensions (like "DateTime" etc) defined
over built-ins like numbers or ranges or collections. Temporal or
spacial data in common use today is just too complicated and
non-generic, I think.

(Whereas, the existing built-ins, and relations, are very generic and simple.)
-- Darren Duncan