Re: exponentiation of Duration's

Carl Mäsak wrote: Darren (>): Specific units, even "seconds" should not be mentioned at all in the definition of "Instant" or "Duration"; instead, any particular units or calendars or whatever would just be a property of the composing class. No disrespect, but it was the abandonment of abstrac

Re: dimensionality in Perl 6

On Thu, Nov 18, 2010 at 11:53 PM, Jon Lang wrote: > Buddha Buck wrote: >> I don't think a Num is necessary, but I could see a Rat. > > As is, is Duration implemented by means of a Num, or a Rat?  Whichever > it is, that's the type that the difference of two Instances would > return (properly tagge

Re: dimensionality in Perl 6

Jon (>>>), Carl (>>), Jon (>): >>> Here's my proposal for how to handle dimensionality in Perl 6: >>> >>> [...] >>> >>> Thoughts? >> >> The idea has come up before, everyone thinks that Perl 6 and unit >> handling are a good fit for each other, and we're basically waiting >> for someone to write su

Re: dimensionality in Perl 6

Buddha Buck wrote: > Jon Lang wrote: >> Here's my proposal for how to handle dimensionality in Perl 6: >> >> Create a "units" trait that is designed to attach to any Numeric >> object.  Dimensional information gets stored as a baggy object - that >> is, something that  works just like a Bag, except

Re: dimensionality in Perl 6

Jon Lang asked me if I intended to send this message to him privately. The answer is "No"... -- Forwarded message -- From: Buddha Buck Date: Thu, Nov 18, 2010 at 10:39 PM Subject: Re: dimensionality in Perl 6 To: Jon Lang On Thu, Nov 18, 2010 at 7:58 PM, Jon Lang wrote: > He

Re: dimensionality in Perl 6

On Thu, Nov 18, 2010 at 8:25 PM, Carl Mäsak wrote: > Jon (>): >> Here's my proposal for how to handle dimensionality in Perl 6: >> >> [...] >> >> Thoughts? > > The idea has come up before, everyone thinks that Perl 6 and unit > handling are a good fit for each other, and we're basically waiting >

Re: exponentiation of Duration's

Darren (>): > Specific units, even "seconds" should not be mentioned at all in the > definition of "Instant" or "Duration"; instead, any particular units or > calendars or whatever would just be a property of the composing class. No disrespect, but it was the abandonment of abstracty stuff like th

Re: dimensionality in Perl 6

Jon (>): > Here's my proposal for how to handle dimensionality in Perl 6: > > [...] > > Thoughts? The idea has come up before, everyone thinks that Perl 6 and unit handling are a good fit for each other, and we're basically waiting for someone to write such a module. Incidentally, your phrase "a c

Re: exponentiation of Duration's

To clarify, by "define particular methods" I mean that said 2 roles would require composing classes to define them, not to include the code themselves. -- Darren Duncan Darren Duncan wrote: I think that "Instant" and "Duration" should simply be declarational roles that don't have any implement

Re: exponentiation of Duration's

I think that "Instant" and "Duration" should simply be declarational roles that don't have any implementation code to compose. Composing "Instant" or "Duration" into a type simply says that the objects of that type represent a point on a timeline or an amount of time. Specific units, even "se

Re: dimensionality in Perl 6

At 16:58 -0800 11/18/10, Jon Lang wrote: >If this is implemented, Duration should be an alias for something to >the effect of "Num but units". Otherwise, Instant and >Duration remain unchanged. > >Thoughts? with special attention to:

dimensionality in Perl 6

Here's my proposal for how to handle dimensionality in Perl 6: Create a "units" trait that is designed to attach to any Numeric object. Dimensional information gets stored as a baggy object - that is, something that works just like a Bag, except that the count can go negative. (I don't know if

Announce: Rakudo Perl 6 compiler development release #35 ("Melbourne")

Announce: Rakudo Perl 6 compiler development release #35 ("Melbourne") On behalf of the Rakudo development team, I'm happy to announce the November 2010 release of Rakudo Perl #35 "Melbourne". Rakudo is an implementation of Perl 6 on the Parrot Virtual Machine (see ). T

Re: exponentiation of Duration's

On 11/17/2010 10:08 PM, Martin D Kealey wrote: Dimensioned numbers as restrictive types are useful, for uncovering bugs, including sometimes latent ones in ported code. Duration is a fairly clear example of a dimensioned quantity, and I think we should think twice about abandoning its dimension

Re: exponentiation of Duration's

On Wed, 17 Nov 2010, Richard Hainsworth wrote: > Once a number has been generated, viz., by obtaining a duration, that number > can be manipulated however necessary. The interpretation of the number is a > matter for the programmer, not the language designer. All true. However I'd argue that you

Parrot 2.10.1 released!

On behalf of the Parrot team, I'm proud to announce Parrot 2.10.1 "(bugfix release)." Parrot (http://parrot.org/) is a virtual machine aimed at running all dynamic languages. Parrot 2.10.1 is available on Parrot's FTP site, or by following the download instructions at http://parrot.org/download.

[perl #79356] [BUG] Issues with creating closures from WhateverCode

# New Ticket Created by Solomon Foster # Please include the string: [perl #79356] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=79356 > colomon: rakudo: * + * * * p6eval: rakudo 015d77: OUTPUT«===SORRY!===␤set_number_nativ

[perl #79340] [Bug] Unspace failed

# New Ticket Created by min...@gmail.com # Please include the string: [perl #79340] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=79340 > Hi there, It seems some bug with unspace. Sincerely, Mindos say "Hello"#`[Fnord]