[perl6/specs] f64807: it's illegal to assign/bind a non-existing dynvar
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: f648072e0447cffa95bd320583a1f527bebe3577 https://github.com/perl6/specs/commit/f648072e0447cffa95bd320583a1f527bebe3577 Author: TimToady Date: 2010-11-19 (Fri, 19 Nov 2010) Changed paths: M S02-bits.pod Log Message: --- it's illegal to assign/bind a non-existing dynvar You must use the GLOBAL:: package explicitly in this case.
Re: exponentiation of Duration's
Darren (>>>), Carl (>>), 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 this >> that led to us getting a Temporal spec that made sense and could be >> implemented. > > How so? All I'm proposing is having top level markers that aren't too > constraining, but everything specced below that can be quite specific and > implementable. -- Darren Duncan Happy to hear that. Because in the case of spec that is so stable that it's even found its way into Rakudo in a very complete form, proposing radical spec changes like yours practically *requires* working code in the form of a patch or a completely new Temporal module, if it's to be anything more than empty talk. The Temporal module in Rakudo is written in Perl 6. It's very accessible for experimenting of the type you suggest above. Go for it. // Carl
[perl6/specs] dd9966: [S02] do not autocurry sequence operators at all
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: dd9966d1193b10e8f3bc9f31754dc87517b7fc8f https://github.com/perl6/specs/commit/dd9966d1193b10e8f3bc9f31754dc87517b7fc8f Author: Moritz Lenz Date: 2010-11-19 (Fri, 19 Nov 2010) Changed paths: M S02-bits.pod Log Message: --- [S02] do not autocurry sequence operators at all
Re: Parrot 2.10.1 released!
On Thu, 18 Nov 2010, Gerd Pokorra wrote: > 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. > > New in 2.10.1 > - This is a bugfix release to run "perl Configure.pl" without noise > from git_describe and SHA1 Thank you for doing this. Incidentally, the actual problem wasn't the noise (for example there's been similar @noinline@ noise for a while). The serious problem is that (if the user has git installed) Configure.pl exits with an error status. This will stop various build tools, such as ones that one might use to make a .deb or .rpm package. Hence building packages is likely to be broken. Unfortunately, there still seems to be an error in the package (some confusion over 2_10_0 vs. 2_10_1). It needs my patch in TT #1856 in order to build. Even after that, rakudo is still unhappy and won't build off an installed parrot-2.10.1 built from the tarball. See TT #1852 for the error messages. I don't know whether rakudo is querying the wrong key for a release or parrot is not supplying the correct key, but it ought to be straightened out. -- Andy Dougherty dough...@lafayette.edu
Re: dimensionality in Perl 6
Am 19.11.2010 05:45, schrieb Jon Lang: 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 for someone to write such a module. Incidentally, your phrase "a complication that we needn't deal with up front" is exactly why there's no pressing need to put this in Perl 6 "core" (fsvo "core"). I'm suggesting this because the recent thread about Duration indicates to me that there _is_ a need to put at least a minimally-featured unit handling system into the core, That's not what I learned from that discussion. My conclusions from the discussions about Durations where that * the old attempt to forbid some operations as part of dimensionality analysis were a bad idea * if there should be a dimensionality type system in Perl 6, it must be more powerful than simply forbidding some operations that do make sense Nowhere have I seen the need for a unit handling system in core. Just because we happen to know the units/dimensions of a single type (Duration) doesn't mean we have to ship a system that can enforce correct dimension handling. I've read that some people like that idea, but I've seen no *need*. Iff somebody comes up with a nice, small unit handling system (*), and can demonstrate how well it can integrate with Durations and the rest of the type system, I (and the other sceptics) might reconsider my objection. (*) runnable code please. Cheers, Moritz
