Re: Proposal for a new Temporal time-measurement paradigm
I recommend not to open this up for 6.0.0 core. Calendar conversion is easy to do in a module, and the Date class has an absolute day count, which is really all you need everything for an intermediate representation. It wouldn't be hard to port Calendrica, for instance. Also, the difference between the secular and religious calendars in Russia is not fixed. It's currently 13 days, but only since 1900, before which it was 12 days, and after 2100 it will be 14 days. Calendar conversion can be tricky - which is another reason to leave it out of core. IMO. On Wednesday, April 21, 2010, Matthew wrote: > I whole-heartedly agree that we need to make a system independent of any sort > of time measurement system. I think the conclusion reached on IRC was that > most of the world uses or is at least familiar with the Gregorian system. > > Now, I can't help but think how we would define an Instant. The best > (reasonable) choice is something like TAI or Unix Epoch (I could argue that > seconds are not independent, but don't trust me; I'd suggest tapping into the > cosmic timeline :) ). I also hope there aren't going to be any leap Instants. > (the filter should take care of leaping, after all the calendar has an issue > with leaping.) > > If there isn't a standard defining how many seconds are in a year (i.e. as > defined by TAI or the metric system or some other international standard), I > propose it'd be about 365.25 Gregorian days (although I'd much prefer an > international standard to my Indo-European ways :) ). > > Overall, I think you have a great idea. As long as the filters are > implemented simply, I think it will prove to be the best option. > > -- > Don't Panic! > > -- Mark J. Reed
Re: Methodicals: A better way to monkey type
On Wed, Apr 21, 2010 at 12:35:11PM -0300, Daniel Ruoso wrote: > Em Qua, 2010-04-21 às 00:16 -0700, Stefan O'Rear escreveu: > > Normally, when you write a method call, the definition of the method is > > entirely in the domain of the receiver's class: > > $object.make-me-a-sandwich; # $object gets to decide what this means > > Actually, this is delegated to the dispatcher, which is composed in at > least three different parts: > > 1 - The general dispatching mechanism which iiuc, is lexically > defined and which, by default, implements something like: > > @*current_invocation_candidates = $object.^can($capture); > @*current_invocation_candidates.shift.postcircumfix:<( )>($capture); > > 2 - The MRO resolver, which is implemented inside ^can, and is > completely internal to the class. > > 3 - The actual routine invocation, which is internal to the actual > method object. I failed to find this in the spec, would you give a reference? It looks very interesting. > > However, this is not always how things work. > > $object.WHAT; # Larry says that WHAT should return the protoobject > > WHAT, WHENCE, postcircumfix:<[ ]>, and similar operators have semantics > > (although not implementation) defined by the language itself. > > Actually WHAT, WHENCE and the like are considered macros, not method > calls. S03 calls WHAT et al macros, S02 calls them methods. This proposal is somewhat related to macros, in that it can be emulated with them, much as you can emulate user-defined infix operators by macroing them to ordinary subs. > Postcircumfix:<[ ]> is actually an operator, not a method, so they are > always lexically dispatched. Treating syntactic categories as subs regardless of call syntax is cruft which could be eliminated with a more general system. > > Currently, Perl 6 fakes this by having all values inherit from Any or > > Mu or Cool, which define the basic, overridable versions of these > > method-like operators. > > Hmm... I never thought of it as a fake, it's a simple fact, every value > in Perl 6 should derive from Mu, every non-special type is derived from > Any. > > > This cheat actually works pretty well in a homogeneous environment, > > but it fails if we have to consider objects from outside Perl 6. > > $parrot-array.WHAT; # Method WHAT not found for invocant of type ... > > This is actually a rakudobug, a $parrot-array should be properly boxed > into a value that provides a protoobject... Again, .WHAT is not a > method. Autoboxing at language boundaries works very badly in the real world. I speak as a Blizkost maintainer, where autoboxing is technically required. I would hate to see Rakudo follow me in the trail of tears. > > The problem here is that scopes are conflated - WHAT is defined by the > > language, which is approximately a lexical scope, while methods on an object > > are in some entirely different scope. > > AFAIU, method dispatch is also lexically controlled - to some extent. I'd love a Sxx: on that, sounds like an interesting section. > > A methodical is an operator which syntactically behaves as a method but is > > subject to scoping rules. Methodicals are defined using the ordinary method > > keyword, qualified with my or our. (TODO: This seems the most natural > > syntax > > to me, but it conflicts with existing usage. Which is more worth having on > > it?) Methodicals do not need to be declared in classes, but they should > > generally have declared receiver types. > > Thoughts? > > Apparently you're trying to override the default dispatching mechanism > which, I think, is something already supported by Perl 6 (although not > yet fully spec. Then perhaps this could serve as the start of a spec. -Stefan signature.asc Description: Digital signature
Re: Proposal for a new Temporal time-measurement paradigm
I whole-heartedly agree that we need to make a system independent of any sort of time measurement system. I think the conclusion reached on IRC was that most of the world uses or is at least familiar with the Gregorian system. Now, I can't help but think how we would define an Instant. The best (reasonable) choice is something like TAI or Unix Epoch (I could argue that seconds are not independent, but don't trust me; I'd suggest tapping into the cosmic timeline :) ). I also hope there aren't going to be any leap Instants. (the filter should take care of leaping, after all the calendar has an issue with leaping.) If there isn't a standard defining how many seconds are in a year (i.e. as defined by TAI or the metric system or some other international standard), I propose it'd be about 365.25 Gregorian days (although I'd much prefer an international standard to my Indo-European ways :) ). Overall, I think you have a great idea. As long as the filters are implemented simply, I think it will prove to be the best option. -- Don't Panic!
Re: Methodicals: A better way to monkey type
Em Qua, 2010-04-21 às 00:16 -0700, Stefan O'Rear escreveu: > Normally, when you write a method call, the definition of the method is > entirely in the domain of the receiver's class: > $object.make-me-a-sandwich; # $object gets to decide what this means Actually, this is delegated to the dispatcher, which is composed in at least three different parts: 1 - The general dispatching mechanism which iiuc, is lexically defined and which, by default, implements something like: @*current_invocation_candidates = $object.^can($capture); @*current_invocation_candidates.shift.postcircumfix:<( )>($capture); 2 - The MRO resolver, which is implemented inside ^can, and is completely internal to the class. 3 - The actual routine invocation, which is internal to the actual method object. > However, this is not always how things work. > $object.WHAT; # Larry says that WHAT should return the protoobject > WHAT, WHENCE, postcircumfix:<[ ]>, and similar operators have semantics > (although not implementation) defined by the language itself. Actually WHAT, WHENCE and the like are considered macros, not method calls. Postcircumfix:<[ ]> is actually an operator, not a method, so they are always lexically dispatched. > Currently, Perl 6 fakes this by having all values inherit from Any or > Mu or Cool, which define the basic, overridable versions of these > method-like operators. Hmm... I never thought of it as a fake, it's a simple fact, every value in Perl 6 should derive from Mu, every non-special type is derived from Any. > This cheat actually works pretty well in a homogeneous environment, > but it fails if we have to consider objects from outside Perl 6. > $parrot-array.WHAT; # Method WHAT not found for invocant of type ... This is actually a rakudobug, a $parrot-array should be properly boxed into a value that provides a protoobject... Again, .WHAT is not a method. > The problem here is that scopes are conflated - WHAT is defined by the > language, which is approximately a lexical scope, while methods on an object > are in some entirely different scope. AFAIU, method dispatch is also lexically controlled - to some extent. > A methodical is an operator which syntactically behaves as a method but is > subject to scoping rules. Methodicals are defined using the ordinary method > keyword, qualified with my or our. (TODO: This seems the most natural syntax > to me, but it conflicts with existing usage. Which is more worth having on > it?) Methodicals do not need to be declared in classes, but they should > generally have declared receiver types. > Thoughts? Apparently you're trying to override the default dispatching mechanism which, I think, is something already supported by Perl 6 (although not yet fully spec. daniel
Re: Methodicals: A better way to monkey type
That's lifetime of the object, which is still monkeytyping, just on a less
global level than modifying the class directly.
Compare the Ruby example to this: (syntax is entirely made up):
my $foo = SomeClass.new;
{
methodical bar(SomeClass) { say "Hello, world!" }
$foo.bar # "Hello, world!"
}
$foo.bar # Error, undefined method bar. Or reverts to SomeClass's bar if it
exists.
But doesn't Perl 6 already have this with lexical multimethods ("my multi")
?
On Wed, Apr 21, 2010 at 10:11 AM, John Harrison wrote:
> Ruby has a similar functionality that lets you define methods on an
> instance
> object. Really, its how class methods are specified, you just put the class
> name as the name of the object. Here is an example:
>
> a = Object.new
> def a.foo
> puts "foo and #{self}"
> end
>
> They will stay on the object as long as the object exists. So, if its a
> scoped variable, it will go away when you leave the scope.
>
> --
>
> John Harrison
>
>
> On Wed, Apr 21, 2010 at 7:49 AM, Andrew Whitworth >wrote:
>
> > This idea strikes me as being extremely similar to C#'s extension
> > methods, a feature that I've found to be particularly beneficial in
> > many cases. The fact that these methodicals are lexically-scoped is
> > especially nice, and the fact that they can be applied post-hoc to
> > arbitrary data items that have no prior support for them (like Parrot
> > objects) would be very nice to have on Parrot in particular where
> > language interoperation could be a big deal in the future.
> >
> > +1
> >
> > --Andrew Whitworth
> >
> >
> >
> > On Wed, Apr 21, 2010 at 3:16 AM, Stefan O'Rear wrote:
> > > (The following describes a proposed extension to Perl 6, methodical
> > scoped
> > > operators or methodicals for short. It is written in the present tense
> > for
> > > simplicity but should be understood as the future conditional.)
> > >
> > > Normally, when you write a method call, the definition of the method is
> > > entirely in the domain of the receiver's class:
> > >
> > >$object.make-me-a-sandwich; # $object gets to decide what this
> means
> > >
> > > However, this is not always how things work.
> > >
> > >$object.WHAT; # Larry says that WHAT should return the protoobject
> > >
> > > WHAT, WHENCE, postcircumfix:<[ ]>, and similar operators have semantics
> > > (although not implementation) defined by the language itself.
> Currently,
> > Perl 6
> > > fakes this by having all values inherit from Any or Mu or Cool, which
> > define
> > > the basic, overridable versions of these method-like operators. This
> > cheat
> > > actually works pretty well in a homogeneous environment, but it fails
> if
> > we have
> > > to consider objects from outside Perl 6.
> > >
> > >$parrot-array.WHAT; # Method WHAT not found for invocant of type
> ...
> > >
> > > The problem here is that scopes are conflated - WHAT is defined by the
> > > language, which is approximately a lexical scope, while methods on an
> > object
> > > are in some entirely different scope.
> > >
> > > A methodical is an operator which syntactically behaves as a method but
> > is
> > > subject to scoping rules. Methodicals are defined using the ordinary
> > method
> > > keyword, qualified with my or our. (TODO: This seems the most natural
> > syntax
> > > to me, but it conflicts with existing usage. Which is more worth
> having
> > on
> > > it?) Methodicals do not need to be declared in classes, but they
> should
> > > generally have declared receiver types.
> > >
> > >{
> > >my method make-me-a-sandwich(Num:) { ... }
> > >
> > >2.make-me-a-sandwich; # calls our method
> > >
> > >"ham".make-me-a-sandwich; # either an error, or method dispatch
> > >}
> > >
> > >2.make-ma-a-sandwich; # ordinary method dispatch
> > >
> > > The primary use case for methodicals is naturally in the setting. Many
> > of the
> > > methods which are currently defined on lower-level types could become
> > > methodicals and they would be available on all values, in any code
> > compiled
> > > within the Perl 6 setting, without polluting the referencing
> environments
> > of
> > > non-Perl 6 code in the same object environment.
> > >
> > >my method WHAT($thing) { ... }
> > >
> > > Rakudo already uses something very much like an ad-hoc direct
> > implementation of
> > > methodicals to handle postcircumfix operators.
> > >
> > > Methodicals are also useful in user code where the most natural
> phrasing
> > of a
> > > calculation is as a property of a system type, for instance from the
> > Mandelbrot
> > > Advent example:
> > >
> > >my method mandel(Complex:) {
> > >my $z = 0i;
> > >for ^$max-iterations {
> > >$z = $z * $z + self;
> > >return 1 if ($z.abs > 2);
> > >}
> > >return 0;
> > >}
> > >
> > > Since methodicals do not pollute global referencing environments, and
> do
> > not
> > > compromise encapsulation, MONKEY_TYPING is not needed here.
Re: Methodicals: A better way to monkey type
Ruby has a similar functionality that lets you define methods on an instance
object. Really, its how class methods are specified, you just put the class
name as the name of the object. Here is an example:
a = Object.new
def a.foo
puts "foo and #{self}"
end
They will stay on the object as long as the object exists. So, if its a
scoped variable, it will go away when you leave the scope.
--
John Harrison
On Wed, Apr 21, 2010 at 7:49 AM, Andrew Whitworth wrote:
> This idea strikes me as being extremely similar to C#'s extension
> methods, a feature that I've found to be particularly beneficial in
> many cases. The fact that these methodicals are lexically-scoped is
> especially nice, and the fact that they can be applied post-hoc to
> arbitrary data items that have no prior support for them (like Parrot
> objects) would be very nice to have on Parrot in particular where
> language interoperation could be a big deal in the future.
>
> +1
>
> --Andrew Whitworth
>
>
>
> On Wed, Apr 21, 2010 at 3:16 AM, Stefan O'Rear wrote:
> > (The following describes a proposed extension to Perl 6, methodical
> scoped
> > operators or methodicals for short. It is written in the present tense
> for
> > simplicity but should be understood as the future conditional.)
> >
> > Normally, when you write a method call, the definition of the method is
> > entirely in the domain of the receiver's class:
> >
> >$object.make-me-a-sandwich; # $object gets to decide what this means
> >
> > However, this is not always how things work.
> >
> >$object.WHAT; # Larry says that WHAT should return the protoobject
> >
> > WHAT, WHENCE, postcircumfix:<[ ]>, and similar operators have semantics
> > (although not implementation) defined by the language itself. Currently,
> Perl 6
> > fakes this by having all values inherit from Any or Mu or Cool, which
> define
> > the basic, overridable versions of these method-like operators. This
> cheat
> > actually works pretty well in a homogeneous environment, but it fails if
> we have
> > to consider objects from outside Perl 6.
> >
> >$parrot-array.WHAT; # Method WHAT not found for invocant of type ...
> >
> > The problem here is that scopes are conflated - WHAT is defined by the
> > language, which is approximately a lexical scope, while methods on an
> object
> > are in some entirely different scope.
> >
> > A methodical is an operator which syntactically behaves as a method but
> is
> > subject to scoping rules. Methodicals are defined using the ordinary
> method
> > keyword, qualified with my or our. (TODO: This seems the most natural
> syntax
> > to me, but it conflicts with existing usage. Which is more worth having
> on
> > it?) Methodicals do not need to be declared in classes, but they should
> > generally have declared receiver types.
> >
> >{
> >my method make-me-a-sandwich(Num:) { ... }
> >
> >2.make-me-a-sandwich; # calls our method
> >
> >"ham".make-me-a-sandwich; # either an error, or method dispatch
> >}
> >
> >2.make-ma-a-sandwich; # ordinary method dispatch
> >
> > The primary use case for methodicals is naturally in the setting. Many
> of the
> > methods which are currently defined on lower-level types could become
> > methodicals and they would be available on all values, in any code
> compiled
> > within the Perl 6 setting, without polluting the referencing environments
> of
> > non-Perl 6 code in the same object environment.
> >
> >my method WHAT($thing) { ... }
> >
> > Rakudo already uses something very much like an ad-hoc direct
> implementation of
> > methodicals to handle postcircumfix operators.
> >
> > Methodicals are also useful in user code where the most natural phrasing
> of a
> > calculation is as a property of a system type, for instance from the
> Mandelbrot
> > Advent example:
> >
> >my method mandel(Complex:) {
> >my $z = 0i;
> >for ^$max-iterations {
> >$z = $z * $z + self;
> >return 1 if ($z.abs > 2);
> >}
> >return 0;
> >}
> >
> > Since methodicals do not pollute global referencing environments, and do
> not
> > compromise encapsulation, MONKEY_TYPING is not needed here.
> >
> > A methodical defined inside a class functions much like a private method.
> > There may be something interesting here, but I'm not entirely sure what.
> >
> > There are two natural implementations of methodicals in terms of other
> language
> > features. First, it is possible to treat methodicals as ordinary methods
> > (monkey typing under the hood), but with generated names; the true name
> is
> > bound to the program name only within the correct scope. If possible,
> the
> > methods should be treated as anonymous, accessible only though an opaque
> name
> > object. Care must be taken to prevent incorrect exposure of private
> fields and
> > methods.
> >
> > Alternatively, a methodical can be desugared to a multi sub with the same
> scope
> > as the methodica
Re: Methodicals: A better way to monkey type
This idea strikes me as being extremely similar to C#'s extension
methods, a feature that I've found to be particularly beneficial in
many cases. The fact that these methodicals are lexically-scoped is
especially nice, and the fact that they can be applied post-hoc to
arbitrary data items that have no prior support for them (like Parrot
objects) would be very nice to have on Parrot in particular where
language interoperation could be a big deal in the future.
+1
--Andrew Whitworth
On Wed, Apr 21, 2010 at 3:16 AM, Stefan O'Rear wrote:
> (The following describes a proposed extension to Perl 6, methodical scoped
> operators or methodicals for short. It is written in the present tense for
> simplicity but should be understood as the future conditional.)
>
> Normally, when you write a method call, the definition of the method is
> entirely in the domain of the receiver's class:
>
> $object.make-me-a-sandwich; # $object gets to decide what this means
>
> However, this is not always how things work.
>
> $object.WHAT; # Larry says that WHAT should return the protoobject
>
> WHAT, WHENCE, postcircumfix:<[ ]>, and similar operators have semantics
> (although not implementation) defined by the language itself. Currently, Perl
> 6
> fakes this by having all values inherit from Any or Mu or Cool, which define
> the basic, overridable versions of these method-like operators. This cheat
> actually works pretty well in a homogeneous environment, but it fails if we
> have
> to consider objects from outside Perl 6.
>
> $parrot-array.WHAT; # Method WHAT not found for invocant of type ...
>
> The problem here is that scopes are conflated - WHAT is defined by the
> language, which is approximately a lexical scope, while methods on an object
> are in some entirely different scope.
>
> A methodical is an operator which syntactically behaves as a method but is
> subject to scoping rules. Methodicals are defined using the ordinary method
> keyword, qualified with my or our. (TODO: This seems the most natural syntax
> to me, but it conflicts with existing usage. Which is more worth having on
> it?) Methodicals do not need to be declared in classes, but they should
> generally have declared receiver types.
>
> {
> my method make-me-a-sandwich(Num:) { ... }
>
> 2.make-me-a-sandwich; # calls our method
>
> "ham".make-me-a-sandwich; # either an error, or method dispatch
> }
>
> 2.make-ma-a-sandwich; # ordinary method dispatch
>
> The primary use case for methodicals is naturally in the setting. Many of the
> methods which are currently defined on lower-level types could become
> methodicals and they would be available on all values, in any code compiled
> within the Perl 6 setting, without polluting the referencing environments of
> non-Perl 6 code in the same object environment.
>
> my method WHAT($thing) { ... }
>
> Rakudo already uses something very much like an ad-hoc direct implementation
> of
> methodicals to handle postcircumfix operators.
>
> Methodicals are also useful in user code where the most natural phrasing of a
> calculation is as a property of a system type, for instance from the
> Mandelbrot
> Advent example:
>
> my method mandel(Complex:) {
> my $z = 0i;
> for ^$max-iterations {
> $z = $z * $z + self;
> return 1 if ($z.abs > 2);
> }
> return 0;
> }
>
> Since methodicals do not pollute global referencing environments, and do not
> compromise encapsulation, MONKEY_TYPING is not needed here.
>
> A methodical defined inside a class functions much like a private method.
> There may be something interesting here, but I'm not entirely sure what.
>
> There are two natural implementations of methodicals in terms of other
> language
> features. First, it is possible to treat methodicals as ordinary methods
> (monkey typing under the hood), but with generated names; the true name is
> bound to the program name only within the correct scope. If possible, the
> methods should be treated as anonymous, accessible only though an opaque name
> object. Care must be taken to prevent incorrect exposure of private fields
> and
> methods.
>
> Alternatively, a methodical can be desugared to a multi sub with the same
> scope
> as the methodical itself, changing statically named method calls into calls to
> the methodical. This gives reflection invisibility and privacy for free, but
> may require more work to get the multi call semantics exactly right.
>
> Thoughts?
>
> -Stefan
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkvOpjcACgkQFBz7OZ2P+dKJ4wCfUpWUDv2/PqYUF1k0hsYaiAns
> HFAAn2K5SfcJnGq5xk1PIy0QG69LMrwR
> =uvrz
> -END PGP SIGNATURE-
>
>
Re: r30425 - docs/Perl6/Spec/S32-setting-library
Ok, so no fixed epoch, and arithmetic on Dates operates in integral days. Sold. It would be handy to have some predefined constants for some common epochs, like JD, MJD, JD, etc. Those don't necessarily need to be in core for 6.0.0, though. Maybe a separate Date::Epochs module? Examples: const $JD0= Date.new(-4713, 11, 25) ; # or Date::Julian.new(-4712,1,1) ? const $MJD0 = $JD0 + 2_400_000; const $RD0 = Date.new(0,12,31); (Those are assuming a continuous numeric range for years, with 0 = 1 BCE, -1 = 2 BCE, etc. Haven't double-checked the spec, but IIRC that's how it's defined.) On Wed, Apr 21, 2010 at 4:54 AM, wrote: > Author: moritz > Date: 2010-04-21 10:54:00 +0200 (Wed, 21 Apr 2010) > New Revision: 30425 > > Modified: > docs/Perl6/Spec/S32-setting-library/Temporal.pod > Log: > [S32::Temporal] remove .daycount method - use $date - $start_of_epoch to > obtain a day count starting from a fix epoch -- Mark J. Reed
Re: r30398 - docs/Perl6/Spec/S32-setting-library
Am 20.04.2010 16:59, schrieb Dave Rolsky: On Fri, 16 Apr 2010, pugs-comm...@feather.perl6.nl wrote: +=head2 Semi-internal methods + +[This section is severely conjectural] + +For efficient implementation of arithmetics on C objects, two more +methods are exposed: + + $d.daycount + Date.new-from-daycount(Int $daycount) I'd _really_ like to see this be based on Rata Die, which is January 1, 0001. See http://en.wikipedia.org/wiki/Rata_Die Your answer made it clear to me that people are not going to like the daycount (or day-count) accessor. I consciously did not specify an epoch on which daycount was based because I didn't want to force the implemntor's hand more than absolutely necessary. Since number-of-days-relative-to-a-fixed-epoch is still available trivially as $date - $start-of-epoch I've now removed the daycount related methods. Cheers, Moritz
Proposal for a new Temporal time-measurement paradigm
In reading all of the discussion about Temporal, I have the uneasy feeling that the current development work is falling into the same traps as other languages. It seems to me that the underlying time-measurement paradigm of the developers is too tightly focused on the Christian Gregorian calendar. The following proposal concerns the time-measurement paradigm. It shows how DateTime arithmetic can be done in a unified way taking into account: - different timezones (including leap seconds and daylight savings changes); - different calendars; - different calendar systems. The paradigm does not provide any API (role/class/method name or definitions) since I could imagine a number are possible, including ones close to the DateTime module being developed. It is possible that the developers already implicitly use a time-measurement paradigm like the one suggested here. If this is the case, it would be best to make the paradigm more explicit, perhaps by including the paradigm in the 'semi-internal' section of the Temporal Spec. We start with a stream of Instants - already specified for perl6, in reality seconds from a single epoch. This stream is universal (our universe being the computers on Earth) in that in whatever time zone a person is, there is the same number of seconds from the start of the epoch. (I believe we can ignore relativity at present.) Imagine these Instants as a horizontal axis. Now we need to *name* these Instants in a conventional manner. Over the top of the Instants we have what I am calling a filter, or rather a series of filters. A filter groups the periods in the filter below it into longer periods. Hence, the first filter groups Instants into days. The day filter is like a set of windows over the Instant stream. The first - day - filter is defined for a particular jurisdiction and time zone. Eg there is a filter for the Moscow time zone. Each element - RU-Mos-day - knows its start and finish in terms of Instants. Ordinarily, the number of Instants (seconds) is fixed per day, but from time to time leap seconds are added to a day. Note that in each time zone the leap seconds may be added at different times in the universal Instant stream. That is, normally leap seconds and daylight saving changes are implemented at midnight in each time zone. The implementation of a time-zone filter would be the same for all time zones, namely an iterator that generates a new day as a fixed number of Instants after the start of the previous day, plus a list of exceptions when the *end* of a day is extended/contracted by some number of Instants (due to leap seconds of daylight saving). The difference between time zones would be that the start of the filter (the epoch of the filter) is shifted up or down the Instant stream, and the list of exceptions for time zones/jurisdictions would be different, depending on jurisdiction and daylight saving. It is conventional to refer to days in terms of a calendar system. Calendars introduce a variety of problems. Significant numbers of people on the planet use the Chinese, Muslim, Jewish and Baha'i calendars - all of which are very different in structure. In some countries, two calendar systems are used simultaneously, with people switching between them according to the function of the day. For example, in Russia there are two concurrent calendars (the secular and religious) and they are a fixed number of days apart. Hence Christmas - December 25 in both calendars - occurs on December 25 in the secular calendar, but on Jan 5 (I think) according to the secular calendar, but December 25 according to the religious calendar. For perl6 to be universal, it must be clear how these different calendar systems can be integrated. In principle I think all calendars can be adapted using the same filter technique. The description below is for the Christian Gregorian calendar as applied in many secular jurisdictions. We then consider how to adapt the approach to other calendars. Days have two sorts of name: - Day_of_week, which is a simple modulo 7 of the number of days from the start of the epoch. - Calendar_day, which is the year-month-day format. The day filter, eg., Ru-Mos-Day, provides for an arbritary Instant both a day_of_week name (eg. Monday) and an offset in days from the start of the time-zone's epoch. For each day, the filter provides the start and end positions in Instants. Next layer up is a Month filter. Just as there are leap seconds in days, so too there are leap days in Months. The Month filter keeps track of the start and end of each month in days. Just like the day filter, the month filter provides a Month_of_year name and an offset in Months from the start of the epoch. Each month 'knows' its start and end day. Similarly for the Year filter. Consider filters to be windows over the Instant time stream. Looking up from an Instant, the filters provide names for days, months, year
r30425 - docs/Perl6/Spec/S32-setting-library
Author: moritz
Date: 2010-04-21 10:54:00 +0200 (Wed, 21 Apr 2010)
New Revision: 30425
Modified:
docs/Perl6/Spec/S32-setting-library/Temporal.pod
Log:
[S32::Temporal] remove .daycount method - use $date - $start_of_epoch to obtain
a day count starting from a fix epoch
Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod
===
--- docs/Perl6/Spec/S32-setting-library/Temporal.pod2010-04-20 23:47:57 UTC
(rev 30424)
+++ docs/Perl6/Spec/S32-setting-library/Temporal.pod2010-04-21 08:54:00 UTC
(rev 30425)
@@ -236,22 +236,6 @@
$d + 3 # Date.new('2010-12-27')
3 + $d # Date.new('2010-12-27')
-=head2 Semi-internal methods
-
-[This section is severely conjectural]
-
-For efficient implementation of arithmetics on C objects, two more
-methods are exposed:
-
-$d.daycount
-Date.new-from-daycount(Int $daycount)
-
-The C method returns the difference of number of days between the
-current object and an arbitrary start of epoch. This epoch is arbitrary and
-implementation dependent, and is even allowed to change between invocations of
-the same program. The C constructor creates a new C
-object with a given daycount.
-
=head1 Additions
Please post errors and feedback to C. If you are making
Methodicals: A better way to monkey type
(The following describes a proposed extension to Perl 6, methodical scoped
operators or methodicals for short. It is written in the present tense for
simplicity but should be understood as the future conditional.)
Normally, when you write a method call, the definition of the method is
entirely in the domain of the receiver's class:
$object.make-me-a-sandwich; # $object gets to decide what this means
However, this is not always how things work.
$object.WHAT; # Larry says that WHAT should return the protoobject
WHAT, WHENCE, postcircumfix:<[ ]>, and similar operators have semantics
(although not implementation) defined by the language itself. Currently, Perl 6
fakes this by having all values inherit from Any or Mu or Cool, which define
the basic, overridable versions of these method-like operators. This cheat
actually works pretty well in a homogeneous environment, but it fails if we have
to consider objects from outside Perl 6.
$parrot-array.WHAT; # Method WHAT not found for invocant of type ...
The problem here is that scopes are conflated - WHAT is defined by the
language, which is approximately a lexical scope, while methods on an object
are in some entirely different scope.
A methodical is an operator which syntactically behaves as a method but is
subject to scoping rules. Methodicals are defined using the ordinary method
keyword, qualified with my or our. (TODO: This seems the most natural syntax
to me, but it conflicts with existing usage. Which is more worth having on
it?) Methodicals do not need to be declared in classes, but they should
generally have declared receiver types.
{
my method make-me-a-sandwich(Num:) { ... }
2.make-me-a-sandwich; # calls our method
"ham".make-me-a-sandwich; # either an error, or method dispatch
}
2.make-ma-a-sandwich; # ordinary method dispatch
The primary use case for methodicals is naturally in the setting. Many of the
methods which are currently defined on lower-level types could become
methodicals and they would be available on all values, in any code compiled
within the Perl 6 setting, without polluting the referencing environments of
non-Perl 6 code in the same object environment.
my method WHAT($thing) { ... }
Rakudo already uses something very much like an ad-hoc direct implementation of
methodicals to handle postcircumfix operators.
Methodicals are also useful in user code where the most natural phrasing of a
calculation is as a property of a system type, for instance from the Mandelbrot
Advent example:
my method mandel(Complex:) {
my $z = 0i;
for ^$max-iterations {
$z = $z * $z + self;
return 1 if ($z.abs > 2);
}
return 0;
}
Since methodicals do not pollute global referencing environments, and do not
compromise encapsulation, MONKEY_TYPING is not needed here.
A methodical defined inside a class functions much like a private method.
There may be something interesting here, but I'm not entirely sure what.
There are two natural implementations of methodicals in terms of other language
features. First, it is possible to treat methodicals as ordinary methods
(monkey typing under the hood), but with generated names; the true name is
bound to the program name only within the correct scope. If possible, the
methods should be treated as anonymous, accessible only though an opaque name
object. Care must be taken to prevent incorrect exposure of private fields and
methods.
Alternatively, a methodical can be desugared to a multi sub with the same scope
as the methodical itself, changing statically named method calls into calls to
the methodical. This gives reflection invisibility and privacy for free, but
may require more work to get the multi call semantics exactly right.
Thoughts?
-Stefan
signature.asc
Description: Digital signature
