[svn:perl6-synopsis] r9126 - doc/trunk/design/syn
Author: larry Date: Sat May 6 10:04:16 2006 New Revision: 9126 Modified: doc/trunk/design/syn/S02.pod Log: Simplified # to always be comment even where a quote delim is expected. Modified: doc/trunk/design/syn/S02.pod == --- doc/trunk/design/syn/S02.pod(original) +++ doc/trunk/design/syn/S02.podSat May 6 10:04:16 2006 @@ -12,9 +12,9 @@ Maintainer: Larry Wall [EMAIL PROTECTED] Date: 10 Aug 2004 - Last Modified: 2 May 2006 + Last Modified: 6 May 2006 Number: 2 - Version: 37 + Version: 38 This document summarizes Apocalypse 2, which covers small-scale lexical items and typological issues. (These Synopses also contain @@ -79,9 +79,8 @@ Single-line comments work as in Perl 5, starting with a C# character and ending at the subsequent newline. They count as whitespace -equivalent to newline for purposes of separation. Certain quoting -tokens may make use of C# characters as delimiters without starting -a comment. +equivalent to newline for purposes of separation. Unlike in Perl 5, +C# may not be used as the delimiter in quoting constructs. =item * @@ -1354,6 +1353,8 @@ an argument to an adverb in something like C q:zfoo// . A colon may never be used as the delimiter since it will always be taken to mean another adverb regardless of what's in front of it. +Nor may a C# character be used as the delimiter since it is always +taken as whitespace (specifically, as a comment). =item *
Re: using the newer collection types - Interval
Prompted by Darren Duncan's proposal on Relation type objects I looked at http://dev.perl.org/perl6/doc/design/syn/S06.html 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?
Re: using the newer collection types - Interval
At 3:06 PM +0200 5/6/06, mAsterdam wrote: Prompted by Darren Duncan's proposal on Relation type objects I looked at http://dev.perl.org/perl6/doc/design/syn/S06.html 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: http://en.wikipedia.org/wiki/Interval_(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
Re: using the newer collection types - Interval
On 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
Re: using the newer collection types - Interval
On 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 ~~ 1..2; pugs thinking that's false is a bug, not a feature. Of course, that doesn't mean implementing range in a subset of perl6 without it isn't interesting, and possibly useful for bootstrapping. -=- James Mastros
Re: using the newer collection types - Interval
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 ~~ 1..2; pugs thinking that's false is a bug, not a feature. Okay, 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
Re: using the newer collection types - Interval
Darren Duncan wrote: mAsterdam wrote: Prompted by Darren Duncan's proposal on Relation type objects I looked at http://dev.perl.org/perl6/doc/design/syn/S06.html 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: http://en.wikipedia.org/wiki/Interval_(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).
Re: using the newer collection types - Interval
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 ~~ 1..2; pugs thinking that's false is a bug, not a feature. Okay, 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.
Re: using the newer collection types - Interval
At 12:45 AM +0200 5/7/06, mAsterdam wrote: Okay, 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
Re: using the newer collection types - Interval
Darren Duncan wrote: At 12:45 AM +0200 5/7/06, mAsterdam wrote: Okay, 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.
Re: using the newer collection types - Interval
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
Re: using the newer collection types - Interval
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
Re: using the newer collection types - Interval
On 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--we 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
Re: using the newer collection types - Interval
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.
Ok.
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. Fri..Mon ?
If you want to discuss this off-list - the email-address
simply works :-) (huge amounts of spam though :-( )
