Re: [perl6/specs] a7cfe0: [S32] backtraces overhaul
That kind of consistency is not much better than inconsistency in terms of usability, IMO. I'd much prefer a purely lexical convention that doesn't rely on how you assign parts of speech or define a single word that has a hyphen in it. Given that we allow hyphens in identifiers, I'd personally like to see them used everywhere, for all identifiers defined at the p6 level. Lower-level names that are just called from p6 are of course another matter. I could also see substituting underscores for hypens in all-caps names for ease of typing (at least, that'd be easier on US keyboards). On Tuesday, August 23, 2011, Parrot Raiser 1parr...@gmail.com wrote: S19 uses hyphens for all of perl6's long-form command-line flags. Command-line flags and methods are separate sets. Hyphens would be the norm for flags. In S28, we find $*EXECUTABLE_NAME and %*META-ARGS listed within 10 lines of each other. S32-setting-library_IO.pod and S32-setting-library_Numeric.pod each have public multi-word method names with hyphens. In both cases, hyphens are linking qualifying adjectives to nouns, while hyphens separate distinct words. One could argue that is not inconsistent. On 8/23/11, Patrick R. Michaud pmich...@pobox.com wrote: On Tue, Aug 23, 2011 at 05:36:27PM +0200, Damian Conway wrote: And I'd like there to be a more consistent approach than that (though I don't really care what it actually is). +1 to consistency. Pm -- Mark J. Reed markjr...@gmail.com
Re: [perl6/specs] a7cfe0: [S32] backtraces overhaul
I always think of the questions game in Rosencrantz and Guildenstern (Lenzmoritz and Damienstern?) instead of Whose Line?. 15-love, Conway! On Tuesday, August 23, 2011, philippe.beauch...@bell.ca philippe.beauch...@bell.ca wrote: Whoosh No... LOL I was making reference to another Whose Line game, (as Damian was with the all questions thing)... And the hyphen thing. :) Philippe R. Beauchamp Secure Channel | Bell Business Markets Associate Director - Application Services Phone: 613-781-8953 Cell:613-327-6928 - Original Message - From: Richard Hainsworth [mailto:rich...@rusrating.ru] Sent: Tuesday, August 23, 2011 06:28 AM To: perl6-language@perl.org perl6-language@perl.org Subject: Re: [perl6/specs] a7cfe0: [S32] backtraces overhaul If you're asking for an explanation of the humour, then it's easy. There is no word play or a significant reference to a program only available to a special audience. Seems to me that when Damian got to the end of his email he noticed that each sentence ended in a '?' That's not usual. Most emails contain assertions and questions. The humour is really when he appended a ? to his own name. Was he really questioning what he was called? Richard On 08/23/2011 02:19 PM, philippe.beauch...@bell.ca wrote: Help us always-explains-the-joke-man!!... :) Philippe R. Beauchamp Secure Channel | Bell Business Markets Associate Director - Application Services Phone: 613-781-8953 Cell:613-327-6928 - Original Message - From: Moritz Lenz [mailto:mor...@faui2k3.org] Sent: Tuesday, August 23, 2011 04:56 AM To: perl6-language@perl.orgperl6-language@perl.org Subject: Re: [perl6/specs] a7cfe0: [S32] backtraces overhaul Am 23.08.2011 10:46, schrieb Damian Conway: It's a trivial point, but why hidden_from_backtrace instead of hidden-from-backtrace? Especially given that the associated method is is-hidden, not is_hidden? The current stance seems to be that low-level things are spelled with underscores, while we reserve the minus character for user-space code. Try grepping the specs for identifiers of built-ins that have a minus in it -- I didn't find any in a quick search. And why is this entire message written in questions? Is it? I'm afraid I don't understand what you mean. See https://github.com/perl6/specs/commit/a7cfe02002f665c120cf4b735919779820194757 maybe it's a charset problem on your machine, or something. Cheers, Moritz -- Mark J. Reed markjr...@gmail.com
Re: Encapsulating the contents of container types
The whole point of objects is to encapsulate state, accepting messages which operate and report on that state. Making a new object every time the state changes sort of defeats the purpose; I certainly wouldn't call it object orientation done right. Total immutability is very powerful, but it's not the way Perl 6 is designed, and would represent a radical departure in that design. However, I do think that we need selective immutability. I firmly agree in principle that readonly all the way down should just work, without the programmer having to jump through hoops to make defensive copies. Of course, the plumbing to make that happen strikes me as likely to be complex and therefore fragile. On Sun, Aug 21, 2011 at 12:00 AM, Darren Duncan dar...@darrenduncan.net wrote: Patrick R. Michaud wrote: On Sat, Aug 20, 2011 at 04:41:08PM -0700, Darren Duncan wrote: I believe the general solution to this problem is to make all objects immutable, with the only exception being explicit references, and so mutating an object isn't an option; rather you have to derive a new object. Values of all types should be immutable, even if that type is Array or whatever, and only Variables should be mutable. ... To make sure I understand correctly, you're essentially saying that @a.push(3) should not modify @a directly -- someone would have to write something like @a = @a.push(3) # or @a .= push(3) And to do a shift, one would have to do something like ($value, @a) = @a; since @a.shift would be unable to mutate the array. (I'm not exactly sure what pop would look like.) Is that correct? Yes, that's what I'm saying. And we've already been making moves in that direction. As I recall, regular expression substitutions were already changed to work that way, returning the modified string rather than modifying the argument, so there is precedent. Moreover, thanks to meta-operators, one can typically get a mutating variant of any otherwise non-mutating operator very tersely with just a single added = character. This aids learnability as there's a relatively simple mnemonic, where nearly any given operator foo is non-mutating, but by adding an = to it you get a mutating variant, so people can look for the = to know if it would mutate. The comparison ops are the rare exception to the rule. -- Darren Duncan -- Mark J. Reed markjr...@gmail.com
Recursive lazy lists?
Sorry if this has come up before and I missed it, but I just came across this Haskell function to convert from Gray code back to normal binary (as lists of 1s and 0s; full code at http://rosettacode.org/mw/index.php/Gray_code#Haskell): gray2bin [] = [] gray2bin (x:xs) = bin where bin = x : zipWith http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:zipWith xor2 xs bin Notice how the definition of 'bin' is recursive. Does Perl6's variety of laziness support this sort of definition? It's not an infinite list; zipWith stops zipping as soon as either list is empty. But the self-reference in the definition means it still has to be computed lazily. -- Mark J. Reed markjr...@gmail.com
Re: Recursive lazy lists?
On Sat, Jul 30, 2011 at 6:02 PM, Bruce Gray bruce.g...@acm.org wrote:
Yes, Perl 6 does support laziness in this sort of definition, via run-time
binding.
Very cool. Thanks!
Here is a quick conversion of the Haskell solution into Perl 6; its output
(when run in Rakudo) exactly matches the output of my iterative Perl 6
solution
(http://rosettacode.org/mw/**index.php/Gray_code#Perl_6http://rosettacode.org/mw/index.php/Gray_code#Perl_6
):
our multi sub infix:xor2 ( $x, $y ) { ( $x + $y ) % 2 };
Why did you need to define this yourself instead of just using +^ ?
--
Mark J. Reed markjr...@gmail.com
Re: exponentiation of Duration's
I'm not convinced that the type system shouldn't be helping with dimensional analysis, but at least it shouldn't hurt. By all means, let the programmer raise a Duration to a power - but the type of the result should not also be Duration. In the absence of automatic dimension tracking, just return a plain number. On Wednesday, November 17, 2010, Moritz Lenz mor...@faui2k3.org wrote: Am 17.11.2010 14:02, schrieb Oha: On 11/17/2010 01:46 PM, Moritz Lenz wrote: Just as a data point, in physics duration squared does exist. On the other hand, i can see why an Instant can't be used as a linear value: it does not have a clear origin (or zero value). That's correct, and the reason that nobody argued for changing Instant so far. Therefore the multiplication of two Instant may results in different results based on where you place the zero, unless you first convert the Instant in a Duration (e.g. seconds since 1 jan 1970) Right. And therefore having to do the conversion explicitly is a good thing -- you immediately see which epoch was used. Cheers, Moritz -- Mark J. Reed markjr...@gmail.com
Re: base-4 literals
: Darren (): : While I haven't seen any prior art on this, I'm thinking that it would be : nice for a sense of completeness or parity to have an 0a syntax specific to : base-4 that complements the 4 that we have now for bases 2,8,16,10. : : You're joking, right? : : No, its a serious idea, just not so conventional. -- Darren Duncan The lack of base 4 numbers in Real Life seems to me to justify the convention. Do you have a use case? My reaction parallels that of Carl and Larry. Isn't the :4222 syntax sufficient? Unless you're manipulating a lot of bitstreams in pairwise increments, I don't see the point. Orthogonality for its own sake is not very Perlish... -- Mark J. Reed markjr...@gmail.com
Re: Ruby Fibers (was: threads?)
On Fri, Oct 15, 2010 at 10:22 AM, B. Estrade estr...@gmail.com wrote: Pardon my ignorance, but are continuations the same thing as co-routines, or is it more primitive than that? Continuations are not the same thing as coroutines, although they can be used to implement coroutines - in fact, continuations can be used to implement any sort of flow control whatsoever, because they are a way of generalizing flow control. Goto's, function calls, coroutines, setjmp/longjmp, loops, exception throwing and catching - these and more can all be regarded as special cases of continuation manipulation. A continuation is just a snapshot of a point in a program's run, which can then be 'called' later to return control to that point. The entire execution context is preserved, so you can call the same continuation multiple times, re-enter a function that has already returned, etc. But state changes are not undone, so the program can still behave differently after the continuation is called. -- Mark J. Reed markjr...@gmail.com
Re: Ruby Fibers (was: threads?)
On Fri, Oct 15, 2010 at 7:42 AM, Leon Timmermans faw...@gmail.com wrote: Continuations and fibers are incredibly useful and should be easy to implement on parrot/rakudo but they aren't really concurrency. They're a solution to a different problem. I would argue that concurrency isn't a problem to solve; it's one form of solution to the problem of maximizing efficiency. Continuations/fibers and asynchronous event loops are different solutions to the same problem. -- Mark J. Reed markjr...@gmail.com
Re: not using get/set (was Re: [perl6/specs] 4d77c0: ...)
On Wed, Sep 29, 2010 at 8:44 PM, Darren Duncan dar...@darrenduncan.net wrote: I would argue that naming accessors get/set is a bad idea, set in particular, because set would easily evoke thoughts of having something to do with set collection types and values. That's a valid point . . . But regardless of whatever else you do, set for this purpose has got to go. That's a much stronger statement, and I can't say I agree. The verb set is so common in this context that it's practically de rigeur. Java, JavaScript, Lisp, Python, POSIX, all have get/set pairs (getFoo/setFoo, getf/setf, __getattr__/__setattr__, getenv/setenv). Other languages use set in this way without a corresponding get (csh, VB, Postscript). Attribute accessors in general are very commonly called getters and setters, no matter what the actual name or syntax happens to be. You can certainly argue that set is confusing because of the data type, but I don't think you can make a convincing case that it's so bad it needs to be rejected out of hand. There's too much evidence to the contrary. But it's not universal, and there are alternatives. Of the ones you mentioned, I would also probably pick update in the general case. But if we're talking about implementing attribute assignments, assign might be more logical. Of alternatives you didn't mention, I like put - as pithy as get and set, with plenty of corresponding history (SmallTalk, POSIX, HTTP,...). - Mark J. Reed markjr...@gmail.com
Re: Smart match isn't on Bool
On Sun, Aug 1, 2010 at 6:02 PM, Jonathan Worthington jonat...@jnthn.net wrote: No, given-when is smart-matching. The RHS of a smart-match decides what happens. If you do True ~~ 1 then that's 1.ACCEPTS(True) which is going to do +True and thus match. OK, but what about 0 ~~ True? That's what started this thread, extricated from the complicating trappings of given/when. Right now, (anything ~~ True) is true, and IMHO that's a misfeature; it's at least surprising. I'd expect (anything ~~ True) to be synonymous with ?(anything): true only if the LHS boolifies to true. By the same token, (anything ~~ False) would be synonymous with !?(anything). I don't think the capability to use an arbitrary block/sub/method/boolean as a when condition should trump the intuitiveness of smartmatching. Instead of overloading the smartmatch, I think we need a different way of specifying a condition that isn't meant to be compared to the topic, and so doesn't invoke smartmatching at all: it's just evaluated in Boolean context as-is. I like the suggestion of whenever for that; it has the no matter what sense that goes with ignoring the topic. -Mark -- Mark J. Reed markjr...@gmail.com
Array membership test?
Possibly a FAQ, but is there a simple way of asking if an item is
contained in an array? I know of $x ~~ any(@array) and @array.grep({
$_ ~~ $x}), but those both seem a bit complicated for a conceptually
simple test, so I'm wondering if I'm missing something. In other
langs there's a keyword [item in array] or specific method
[array.include? item] or function [in_array($item, $array)]...
--
Mark J. Reed markjr...@gmail.com
Re: Array membership test?
On Thu, Jul 29, 2010 at 7:52 PM, Jonathan Worthington jonat...@jnthn.net wrote: Note that grep doesn't have to take a closure, but can also take just the value you're looking for... my @x = 1,2,3; say ?...@x.grep(2); say ?...@x.grep(4); 1 0 Hm. could have sworn I'd tried that and it didn't work. Though more efficient would be: my @x = 1,2,3; say ?...@x.first(2); say ?...@x.first(4); 1 0 Ah, perfect. Thanks! I still prefer the junction way though. :-) I love junctions, but it feels like overkill to use them for this. :) -- Mark J. Reed markjr...@gmail.com
Re: Suggested magic for a .. b
On Wednesday, July 28, 2010, Jon Lang datawea...@gmail.com wrote: Keep it simple, folks! There are enough corner cases in Perl 6 as things stand; we don't need to be introducing more of them if we can help it. Can I get an Amen? Amen! -- Mark J. Reed markjr...@gmail.com
Re: Suggested magic for a .. b
On Wed, Jul 28, 2010 at 2:30 PM, Chris Fields cjfie...@illinois.edu wrote: On Jul 28, 2010, at 1:27 PM, Mark J. Reed wrote: Can I get an Amen? Amen! -- Mark J. Reed markjr...@gmail.com +1. I'm agnostic ; Militant? :) ( http://tinyurl.com/3xjgxnl ) Nothing inherently religious about amen (or me), but I'll accept +1 as synonymous. :) -- Mark J. Reed markjr...@gmail.com
Re: series operator issues
If we expected Perl6 to be able to recognize these series and continue them based on nothing but the first few elements, that would be a dwimmy OEIS. (And an OEIS module that did that by consulting the real OEIS would be cool, outside of core.) But that's not what this is about. This is just wanting to be able to write the ones that have simple mathematical expressions (closed or not) using simple Perl 6 expressions with the series operator. On Friday, July 23, 2010, Brandon S Allbery KF8NH allb...@ece.cmu.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/22/10 11:18 , Jon Lang wrote: Second, I'm trying to think of a simple and intuitive way to write up a series expression for: triangle numbers: 0, 1, 3, 6, 10, 15, 21, etc. square numbers: 0, 1, 4, 9, 16, 25, 36, etc. factorials: 1, 1, 2, 6, 24, 120, 720, 5040, etc. I don't think anyone seriously expects the series operator to be a dwimmy OEIS. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxJLGkACgkQIn7hlCsL25X2jACeIwN4EBe96dS4WEBm1Ik14dQW JNwAoJaASMvMGVickzIgdBDclNM2KhJq =9ej6 -END PGP SIGNATURE- -- Mark J. Reed markjr...@gmail.com
Re: Radix (base) conversion
No, 42/13 is 42 over 13, which is 3 + 3/13. Let's not confuse fractions and bases, please. :13(42) means 54. That much is straightforward. :13(6*9) is less obvious, but seems to mean (1) multiply 6*9, (2) convert the resulting number to a (decimal) string; (3) interpret that string in base 13. Hence :13(54) or decimal 69. Either way, AIUI, the radix is only used to control the interpretation of the literal. The result is just a number, which doesn't know that it was entered in base 13. It's just a value, without any inherent notion of a particular radix. Or at least I thought that was the case, but in current Rakudo I notice that :13(54) is a Num while 69 is an Int. -- Mark J. Reed markjr...@gmail.com
Re: Suggested magic for a .. b
Ok, I find that surprising (and counter to current Rakudo behavior), but thanks for the correction, and sorry about the misinformation. On Wednesday, July 21, 2010, Larry Wall la...@wall.org wrote: On Tue, Jul 20, 2010 at 11:53:27PM -0400, Mark J. Reed wrote: : In particular, consider that pi ~~ 0..4 is true, : because pi is within the range; but pi ~~ 0...4 is false, because pi : is not one of the generated elements. Small point here, it's not because pi is fractional: 3 ~~ 0...4 is also false because 3 !eqv (0,1,2,3,4). There is no implicit any() on a smartmatch list pattern as there is in Perl 5. In Perl 6 the pattern 0..4 may only match a list with the same 5 elements in the same order. Larry -- Mark J. Reed markjr...@gmail.com
Re: Suggested magic for a .. b
Strike the counter to current Rakudo behavior bit; Rakudo is behaving as specified in this instance. I must have been hallucinating. On Wed, Jul 21, 2010 at 7:33 AM, Mark J. Reed markjr...@gmail.com wrote: Ok, I find that surprising (and counter to current Rakudo behavior), but thanks for the correction, and sorry about the misinformation. On Wednesday, July 21, 2010, Larry Wall la...@wall.org wrote: On Tue, Jul 20, 2010 at 11:53:27PM -0400, Mark J. Reed wrote: : In particular, consider that pi ~~ 0..4 is true, : because pi is within the range; but pi ~~ 0...4 is false, because pi : is not one of the generated elements. Small point here, it's not because pi is fractional: 3 ~~ 0...4 is also false because 3 !eqv (0,1,2,3,4). There is no implicit any() on a smartmatch list pattern as there is in Perl 5. In Perl 6 the pattern 0..4 may only match a list with the same 5 elements in the same order. Larry -- Mark J. Reed markjr...@gmail.com -- Mark J. Reed markjr...@gmail.com
Re: Suggested magic for a .. b
On Wed, Jul 21, 2010 at 3:55 PM, Darren Duncan dar...@darrenduncan.net wrote: Larry Wall wrote: On Tue, Jul 20, 2010 at 11:53:27PM -0400, Mark J. Reed wrote: : In particular, consider that pi ~~ 0..4 is true, : because pi is within the range; but pi ~~ 0...4 is false, because pi : is not one of the generated elements. Small point here, it's not because pi is fractional: 3 ~~ 0...4 is also false because 3 !eqv (0,1,2,3,4). There is no implicit any() on a smartmatch list pattern as there is in Perl 5. In Perl 6 the pattern 0..4 may only match a list with the same 5 elements in the same order. For some reason I thought smart match in Perl 6, when presented with some collection on the right-hand side, would test if the value on the left-hand side was contained in the collection. That was my thought as well. Similarly, since a range represents a set of all values between 2 endpoints, I might have thought this would be reasonable: 3 ~~ 1..5 # TRUE AIUI, that is indeed correct. Ranges smartmatch by testing for inclusion in the range. But collections don't smartmatch by testing for inclusion in the collection. Which was probably the subject of a thread I missed somewhere... For series, I think the canonical solution is to use any(). -- Mark J. Reed markjr...@gmail.com
Re: r31776 -[S32/Temporal] Make DateTime immutable.
On Tue, Jul 20, 2010 at 5:51 PM, pugs-comm...@feather.perl6.nl wrote: +CDateTime objects are immutables. + I think just the adjective works better here (are immutable)... but more to the point: +A CDateTime can also be created by modifying an existing object: It's mildly confusing to say they're immutable and then turn around and talk about modifying them. How about just saying that A new CDateTime can also be based on an existing CDateTime object: ? -- Mark J. Reed markjr...@gmail.com
Re: r31777 -[S32/Temporal] Reverted DateTime back to being mutable. I think we ought to make a big change like this only after reaching some kind of consensus to do so, not least because I just impl
component.
@@ -246,8 +268,6 @@
$d + 3 # Date.new('2010-12-27')
3 + $d # Date.new('2010-12-27')
-As temporal objects are immutable, += -= ... do not work.
-
=head1 Additions
Please post errors and feedback to Cperl6-language. If you are making
--
Mark J. Reed markjr...@gmail.com
Re: Suggested magic for a .. b
On Wed, Jul 21, 2010 at 12:04 AM, Jon Lang datawea...@gmail.com wrote: Mark J. Reed wrote: Perhaps the syllabic kana could be the integer analogs, and what you get when you iterate over the range using ..., while the modifier kana would not be generated by the series ア ... ヴ but would be considered in the range ア .. ヴ? I wouldn't object to such script-specific behavior, though perhaps it doesn't belong in core. As I understand it, it wouldn't need to be script-specific behavior; just behavior that's aware of Unicode properties. That wouldn't help in this case. For example, U+30A1 KATAKANA SMALL LETTER A - the small modifier variety of letter under discussion - is not a modifier in the Unicode sense. It has exactly the same properties as U+30A2 KATAKANA LETTER A, an actual syllable: 30A1;KATAKANA LETTER SMALL A;Lo;0;L;N; 30A2;KATAKANA LETTER A;Lo;0;L;N; So without script-specific special-case code, there's no way to distinguish them. As Aaron said, they're treated like lowercase, but that's not an accurate representation of how they're used in actual text, or of the common idea of what constitutes the set of kana. -- Mark J. Reed markjr...@gmail.com
Re: r31696 -[S32/Temporal] Permit day-of-month on Dates.
By analogy, I'd say week-of-year should work as well. On Thu, Jul 15, 2010 at 8:18 AM, pugs-comm...@feather.perl6.nl wrote: Author: Kodi Date: 2010-07-15 14:18:15 +0200 (Thu, 15 Jul 2010) New Revision: 31696 Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod Log: [S32/Temporal] Permit day-of-month on Dates. Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod === --- docs/Perl6/Spec/S32-setting-library/Temporal.pod 2010-07-15 12:12:31 UTC (rev 31695) +++ docs/Perl6/Spec/S32-setting-library/Temporal.pod 2010-07-15 12:18:15 UTC (rev 31696) @@ -15,8 +15,8 @@ Created: 19 Mar 2009 - Last Modified: 14 Jul 2010 - Version: 13 + Last Modified: 15 Jul 2010 + Version: 14 The document is a draft. @@ -246,6 +246,7 @@ year month day + day-of-month day-of-week week week-year -- Mark J. Reed markjr...@gmail.com
Re: r31696 -[S32/Temporal] Permit day-of-month on Dates.
I was just proposing an alias for week it that clarifies what it is the week *of*. The rest of what you ask is already established in Temporal.pm. 1. week returns the week number in the ISO 8601 week calendar. You can find the spec by Googling, but in summary: a. weeks begin on Monday b. weeks are numbered 1 to 52 or 53 c. week 1 is the first week containing at least four days of the new calendar year 2. week-year returns the year number, based on boundaries defined by the above principle. For instance, week 1 of this year began on January 4th, 2010, so on January 3rd, 2010, week-year would still return 2009. These are the same values returned by the %V and %G strftime(3) conversion specifications, e.g. date +%GW%V on Unixlike systems. By analogy, I'd say week-of-year should work as well. Oof, is there a generally accepted for numbering weeks within a year? A month's boundaries' always coincides with a day's boundary, but a year only occasionally begins/ends on a week boundary. Come to think of it, there isn't even consensus on what day of the week constitutes a week start, even if Perl 6 has chosen a convention. On the other hand, I won't complain about a week-of-year with a good definition of how it handles weeks 0/1, 52/53. End user can choose to use it or not. And I'm not too anxious to open up the whole calendar choice can of worms. -- Mark J. Reed markjr...@gmail.com
Re: r31696 -[S32/Temporal] Permit day-of-month on Dates.
More importantly, it's already in the spec! All I proposed was an alias to an existing attribute name. If it gets dropped out of core, that's fine, too. But I'd like to see the longer name available, in whatever module it shows up in... On Thu, Jul 15, 2010 at 5:36 PM, yary not@gmail.com wrote: On Thu, Jul 15, 2010 at 2:13 PM, Brandon S Allbery KF8NH allb...@ece.cmu.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/15/10 12:21 , Mark J. Reed wrote: By analogy, I'd say week-of-year should work as well. Wasn't the week stuff punted to a non-core module because there are too many differences in how it's handled (week starts on Sunday in the US and Israel and Monday elsewhere, differing notions of what first week of the year means, etc.) I had the same thought but as Mark pointed out, there is an ISO standard for numbering weeks within a year, which is also implemented by Unix-y systems. So that portion is defensible. -y -- Mark J. Reed markjr...@gmail.com
Re: The obligation of free stuff: Google Storage
On Thursday, June 10, 2010, Leon Timmermans faw...@gmail.com wrote: I agree it should be similar to normal FS interactoin to make matters as intuitive as possible, but I horrified by the idea of overloading open() that way But open is already overloaded in p5, with pipes etc. We don't want to repeat the mistakes of the past, and the fact that open(FH, $foo) could run an arbitrary shell command was arguably a mistake, but transparent access to storage where possible is the way to go. We can provide a way to limit the behavior when you want - a pragma, option to open(), or just sticking file:// in front of a value to force its interpretation as a plain pathname - but even then, who knows what Fuse filesystem might be mounted and doing strange things with your innocuous-looking file access? I'd rather have that flexibility directly supported in the language. Of course, different types of storage have different features; there's no completely unified interface. But to the extent that a cloud disk system or document database functions as a collection of data blobs accessed by a pathlike key, enabling the standard filesystem access pattern for it (in addition to whatever specific functionality it needs) makes sense, IMHO. . -- Mark J. Reed markjr...@gmail.com
Re: r30742 -[Spec] :() is now always signature. Use foofix:[...] as the general op form
Modified: docs/Perl6/Spec/S03-operators.pod
===
--- docs/Perl6/Spec/S03-operators.pod 2010-05-21 06:55:13 UTC (rev 30741)
+++ docs/Perl6/Spec/S03-operators.pod 2010-05-21 07:15:36 UTC (rev 30742)
@@ -2540,7 +2540,7 @@
=item *
C - becomes C., like the rest of the world uses. There is
-a pseudo C postfix:('-') operator that produces a compile-time
+a pseudo C postfix:['-'] operator that produces a compile-time
error reminding Perl 5 users to use dot instead. (The pointy block
use of C - in Perl 5 requires preceding whitespace when the arrow
^
Shouldn't that read in Perl 6?
--
Mark J. Reed markjr...@gmail.com
Re: Proposal for a new Temporal time-measurement paradigm
Absolutely ridiculous. The Gregorian calendar is in universal use for civil purposes and definitely belongs in the core. On Saturday, April 24, 2010, Darren Duncan dar...@darrenduncan.net wrote: I want to clarify that I currently believe that the Perl 6 core should only include temporal roles and *no* temporal classes. So the Perl 6 core could provide, say, 3 roles, Instant, Duration, and Calendar (or use some other name for the last one). It would also provide now(), sleep(), and calendar() routines that have signatures of Instant, Duration, and Calendar, respectively, without necessarily being more specific. And so, what now() returns would then be entirely implementation-defined; all Perl 6 guarantees is that now() would return some object that does Instant but not what class that object is nor what any of its capabilities are. Each Perl 6 implementation would be responsible for bundling at least one non-core module of its own choice that provides a class for each of the 3 core roles, such that now() can return something on that system. Or alternately, now() doesn't actually have to work at all, say if this Perl is to run say on some embedded system all of whose programs don't need a clock, in which case no implementing classes are bundled. The Calendar role would be the role composed by values that you get from introspecting the return value of now() so that you know in a more generic sense what that Instant-doing object is capable of. You could consult calendar() to introspect what classes now() and sleep() use and know about how to interpret them. All details specific to any calendar, including Gregorian, including concepts like seconds or hours or days, should be left out of the core and be provided by separate modules. Said modules can be self-contained, just say using Perl's ordinary numeric and string types for internal representation, and Perl's single core now() routine they can use to determine the current datetime, and the module can introspect its result or calendar() and figure out how to map that to the internal representation or API it wants to use, as well as figure out the proper way to invoke sleep(). -- Darren Duncan Darren Duncan wrote: Jon Lang wrote: We _should_ define a default calendar, which is the one that Perl uses when returning values from now(), etc. That is, Perl 6.0.0 should define the Instant and Duration roles as you outlined above, plus a set of classes that implement those roles according to the Gregorian calendar system. If you want to replace that with another calendar system in your implementation of Perl, the language already has the means of allowing you to do so (e.g., replacing now with a variant that returns a different type of Instant). I am more on the fence in regards to default implementations of the roles. But I think that all the messy details of particular calendars, such as Gregorian leap seconds and timezones etc, should not be bundled with Perl, and be separate, where users can upgrade them separately independent of Perl as the measurements and political declarations come in. I still suggest just letting Perl itself be minimalist as far as providing classes go, just say have a class representing a Unix et al timestamp that directly corresponds to the implementation's time system, which differs per OS, plus a means for a program to ask what the current OS's calendar is, and then let separately distributed DateTime et al modules examine this and take care of all the mapping. For example, Perl 6 should include the analogy of Perl 5's time but not an analogy to gmtime or localtime; implementing the latter should be left exclusively to separate modules. This fits in with a Perl philosophy of mainly sticking to being grammar and letting CPAN/etc be the language, especially where complexity comes in. It also means that temporal modules can be bundled with Perl, but that is a choice made by the Perl packagers, not the Perl core, same as deciding what templating or networking or database or whatever modules to bundle. -- Mark J. Reed markjr...@gmail.com
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, pugs-comm...@feather.perl6.nl 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 markjr...@gmail.com
Re: Methodicals: A better way to monkey type
. 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- -- Mark J. Reed markjr...@gmail.com
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 rnd...@gmail.com 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 markjr...@gmail.com
Re: r30398 - docs/Perl6/Spec/S32-setting-library
On Tue, Apr 20, 2010 at 10:59 AM, Dave Rolsky auta...@urth.org wrote: 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 To be clear, that's specifically January 1, 1 CE in the retrojected Gregorian calendar, which is the same day as January 1, 3 CE in the retrojected Julian calendar; noon UTC began Julian Day 1,721,426. You could also use the JD directly, but there's a subtle design decision lurking there. The JD is tied to UTC, and refers to a specific 24-hour period that is the same across the planet: JD 2,455,307 began 4 hours and 45 minutes ago as I write this, and will be over in 19 hours and 15 minutes, and that is a universal fact no matter whether it's currently Tuesday the 20th or already Wednesday the 21st where you are. An RD, in contrast, is not tied to a specific time zone, but is simply a numerical way to represent exactly the same concept as the date: whatever the Gregorian date April 20, 2010 means, RD 733,882 means the same thing. So on some parts of the planet its RD 733,882 and in others it's already RD 733,883. The RD is thus a better fit for the Date class, which is a representation of an abstract date, unanchored in spacetime. An integral JD number may be used to fit the same bill, but opens the possibility of confusion with the more typical anchored JD values (which might even be available from DateTime objects). The difference between them, or with any other epoch choice, is mostly just a matter of a constant which can be added or subtracted as needed, and to the degree that's true this is just bikeshed painting. But the part that isn't is important: I don't want to dilute what I see as the primary benefit of a Date object over a DateTime object that simply has its time fields zeroed, which is flexibility. The latter is still by implication tied to a specific swath of spacetime (e.g. midnight to midnight in some time zone), whereas the former is free to refer to whatever the human date designation can. -- Mark J. Reed markjr...@gmail.com
r30398 - docs/Perl6/Spec/S32-setting-library
I would only add that I think the DateTime constructor should accept a
Date object:
my $bday = new Date.new(1968, 5, 5);
my $specifically = DateTime.new(:date($bday), :hour(20), :minute(47));
or at least, Date should have a method that returns it's value as
pairs suitable for passing to DateTime.new.
On Friday, April 16, 2010, pugs-comm...@feather.perl6.nl wrote:
Author: moritz
Date: 2010-04-16 22:40:37 +0200 (Fri, 16 Apr 2010)
New Revision: 30398
Modified:
docs/Perl6/Spec/S32-setting-library/Temporal.pod
Log:
[S32/Temporal] spec Date type
This is heavily inspired by Date::Simple on CPAN, and mostly implemented
at http://github.com/moritz/Date/ as an external module, that currently works
fine with Rakudo (but is really compiler agnostic).
Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod
===
--- docs/Perl6/Spec/S32-setting-library/Temporal.pod 2010-04-16 15:47:23
UTC (rev 30397)
+++ docs/Perl6/Spec/S32-setting-library/Temporal.pod 2010-04-16 20:40:37
UTC (rev 30398)
@@ -8,6 +8,7 @@
Carl Mäsak cma...@gmail.com
Martin Berends mbere...@autoexec.demon.nl
+ Moritz Lenz mor...@faui2k3.org
(and others named in FOOTNOTE at bottom)
=head1 VERSION
@@ -74,6 +75,11 @@
This has the same effect as doing CDateTime.now().truncate('day'); see
'Set methods' below.
+Or if you want to extract the date as a CDate object (see below),
+you can use simple type coercion:
+
+ my $today = $datetime.Date;
+
General dates can be specified through the Cnew constructor:
my $moonlanding = DateTime.new( :year(1969), :month(7), :day(16),
@@ -195,6 +201,62 @@
Monday of the week in which it occurs, and the time components are all
set to 0.
+=head1 Date
+
+CDate objects represent a day without a time component, and allow easier
+manipulation by assuming that integers always mean days.
+
+Days, Months and days of week are 1-based.
+
+=head2 Constructors
+
+ Date.today(); # today's date
+ Date.new('2010-12-24'); # -MM-DD format
+ Date.new(:year(2010), :month(12), :day(24));
+ Date.new(2010, 12, 24);
+
+The constructors die with a helpful error message if month or day are out of
+range.
+
+=head2 Accessors
+
+The following accessors are pretty obvious, and are defined by example only.
+See the test suite for more formal definitions.
+
+ my $d = Date.new('2010-12-24');
+ $d.year # 2010
+ $d.month # 12
+ $d.day # 24
+ $d.day-of-week # 5 # Friday
+ $d.is-leap-year # Bool::False
+ $d.days-in-month # 31
+ $d.Str # '2010-12-24'
+
+=head2 Arithmetics
+
+ $d.succ # Date.new('2010-12-25')
+ $d.pred # Date.new('2010-12-23')
+ $d - Date.new('1984-03-02') # 9793 # (difference in days)
+ $d - 42 # Date.new('2010-11-12')
+ $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 CDate objects, two more
+methods are exposed:
+
+ $d.daycount
+ Date.new-from-daycount(Int $daycount)
+
+The Cdaycount 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 Cnew-from-daycount constructor creates a new CDate
+object with a given daycount.
+
=head1 Additions
Please post errors and feedback to Cperl6-language. If you are making
--
Mark J. Reed markjr...@gmail.com
Re: r30398 - docs/Perl6/Spec/S32-setting-library
On Friday, April 16, 2010, Mark J. Reed markjr...@gmail.com wrote: or at least, Date should have a method that returns it's value as pairs suitable for passing to DateTime.new. Obviously that should be its value. Thank you, iPhone, for thinking you know better than I how to punctuate. :) -- Mark J. Reed markjr...@gmail.com
Re: Temporal.pod truncate
On Tue, Apr 13, 2010 at 12:35 PM, John Williams willi...@tni.com wrote: Asking for the latest prior Sunday or any other weekday is a useful function, but it doesn't really have anything to do with 'truncation'. Asking for the first of the month is truncating to an even more arbitrary interval than a seven-day period, but we still call it truncation somehow.\ The size of the unit (and that size's variability) wasn't my point; it's that the unit is part of the fundamental identity of the date. A date is not a day; it's a particular name for a day. So when you truncate it, what you are removing precision from is the name. If the end result doesn't look like part of the name, it's not truncation. IMESHO, of course. The only reason you can truncate to the week in the proposed DateTime is because it includes support for the ISO week-based calendar, in additiion to the Gregorian. So just as you can truncate the Gregorian date April 13, 2010 to April 2010 or to 2010, you can truncate the ISO 8601 date 2010W15-2 to 2010W15 or to 2010. In each case the result of the truncation is the first day of the named period, which in the case of the ISO week calendar happens to be a Monday, but the truncation actually represents the whole period - just as truncating a real number to an integer yields a value that logically represents the entire half-open range from that integer to the next. You can imagine objects representing dates using other calendar systems. Today's Julian date March 31, 2010 could be truncated to March 2010 or to 2010; the Mayan long count 12.19.17.4.17 could be truncated to unial 12.19.17.4 or tun 12.19.17 or katun 12.19 or baktun 12. But unless I'm using a date object that has a baktun property, I wouldn't expect to be able to truncate to the baktun. The trouble with asking for the prior sunday, is that on sunday an implementation of the prior() function will return a date 7 days prior to today, while an implementation of the truncate() function will return today. True; that's why the Calendrica function is called kday-on-or-before instead of prior-kday - or actually, it may have both of those, with the difference you indicated. It's all about choosing the right name. :) Whatever you call it, it's a valuable function, I'm just arguing that it's not truncation unless you're talking about a calendar where you number Sunday-based weeks from a given epoch. -- Mark J. Reed markjr...@gmail.com
Re: A new era for Temporal
On Sun, Apr 11, 2010 at 9:47 PM, Dave Rolsky auta...@urth.org wrote: On Sun, 11 Apr 2010, Moritz Lenz wrote: I've planned to add such a module to the Perl 6 spec, but some comments on #perl6 suggested it should be kept out of core to prevent bloat. Still if the overall opinion is that Perl 6 should have such a module out of the box, I'll be happy to spec it. I think that having a standard, minimal API for this defined in core as a Date role would be ideal. Agreed. In fact, I'd like to see DateTime be defined explicitly as a superset (subrole) of Date, with a method for extracting just the Date portion built in to DateTime. -- Mark J. Reed markjr...@gmail.com
Re: A new era for Temporal
On Mon, Apr 12, 2010 at 6:38 AM, Mark J. Reed markjr...@gmail.com wrote: I think that having a standard, minimal API for this defined in core as a Date role would be ideal. Agreed. In fact, I'd like to see DateTime be defined explicitly as a superset (subrole) of Date, with a method for extracting just the Date portion built in to DateTime. Er, I meant that to read (subrole?). Not sure that inheritance is the way to go here, but I do think that logically a DateTime should be built on top of a Date, rather than having Date be a whittled-down DateTime with too-different an API. -- Mark J. Reed markjr...@gmail.com
Re: r30370 - docs/Perl6/Spec/S32-setting-library
How are quarters defined? Where do(es) the extra day(s) go?
On Monday, April 12, 2010, pugs-comm...@feather.perl6.nl wrote:
Author: masak
Date: 2010-04-12 15:12:54 +0200 (Mon, 12 Apr 2010)
New Revision: 30370
Modified:
docs/Perl6/Spec/S32-setting-library/Temporal.pod
Log:
[S32/Temporal] replaced underscores with dashes in method names
Also decided to go with 'timezone' rather than 'time_zone' or 'time-zone',
for a flurry of reasons. Saves a character; looks more like the rest of the
attributes; looks more like DateTime::TimeZone; emphasizes that it's one
concept and not two; it was already partly that way by mistake. ;-)
Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod
===
--- docs/Perl6/Spec/S32-setting-library/Temporal.pod 2010-04-12 13:00:38
UTC (rev 30369)
+++ docs/Perl6/Spec/S32-setting-library/Temporal.pod 2010-04-12 13:12:54
UTC (rev 30370)
@@ -59,7 +59,7 @@
calendar and someone's clock. You can create a CDateTime object from
the CInstant returned by the Ctime function:
- my $now = DateTime.from_epoch(time);
+ my $now = DateTime.from-epoch(time);
This is such a common use case, that there's a CDateTime.now
constructor that does this for you:
@@ -114,30 +114,30 @@
There are methods Cyear, Cmonth, Cday, Chour, Cminute, and
Csecond, giving you the corresponding values of the CDateTime
-object. The Cday method also has the synonym Cday_of_month.
+object. The Cday method also has the synonym Cday-of-month.
The method Cweek returns two values, the Iweek year and Iweek number.
-(These are also available through the methods Cweek_year and
Cweek_number,
+(These are also available through the methods Cweek-year and
Cweek-number,
respectively.) The first week of the year is defined by ISO as the one which
contains the fourth day of January. Thus, dates early in January often end
up in the last week of the prior year, and similarly, the final few days of
December may be placed in the first week of the next year.
-There's a Cday_of_week method, which returns the day of the week as a
+There's a Cday-of-week method, which returns the day of the week as a
number 1..7, with 1 being Monday and 7 being Sunday.
-The Cweekday_of_month method returns a number 1..5 indicating the
+The Cweekday-of-month method returns a number 1..5 indicating the
number of times a particular weekday has occurred so far during that
month, the day itself included. For example, June 9, 2003 is the second
Monday of the month, and so this method returns 2 for that day.
The Cquarter method returns the quarter of the year, a value between 1
-and 4. The Cday_of_quarter method returns the day of the quarter.
+and 4. The Cday-of-quarter method returns the day of the quarter.
-The Cday_of_year method returns the day of the year, a value between 1
+The Cday-of-year method returns the day of the year, a value between 1
and 366.
-The method Cwhole_second returns the second truncated to an integer.
+The method Cwhole-second returns the second truncated to an integer.
The following methods work as a sort of formatting methods:
@@ -150,7 +150,7 @@
The single argument of each of those methods is optional, but the above
shows the defaults: C'-' for dates and C':' for times.
-The Ctime_zone method returns the CDateTime::TimeZone object for the
+The Ctimezone method returns the CDateTime::TimeZone object for the
CDateTime object. The method Coffset returns the offset from UTC, in
seconds, of the CDateTime object according to the time zone.
@@ -165,7 +165,7 @@
The same methods exists for all the values you can set in the
constructor: Cyear, Cmonth, Cday, Chour, Cminute, Csecond,
-Ctime_zone and Cformatter. Also, there's a Cset method, which
+Ctimezone and Cformatter. Also, there's a Cset method, which
accepts all of these as named arguments, allowing several values to be
set at once:
@@ -175,12 +175,12 @@
values, and an exception is thrown if the result isn't a sensible date
and time.
-If you use the Ctime_zone public accessor to adjust the time zone, the
+If you use the Ctimezone public accessor to adjust the time zone, the
local time zone is adjusted accordingly:
my $dt = DateTime.new('2005-02-01T15:00:00+0900');
say $dt.hour; # 15
- $dt.time_zone = '+0600';
+ $dt.timezone = '+0600';
say $dt.hour; # 12
The Ctruncate method allows you to clear a number of time values
--
Mark J. Reed markjr...@gmail.com
Re: a more useful srand (was Re: r30369 - docs/Perl6/Spec/S32-setting-library)
On Mon, Apr 12, 2010 at 12:59 PM, Dave Whipp d...@dave.whipp.name wrote:
2a. If I spawn two threads (implicitly or explicitly), how do their RNGs
interact? I.e. are Crand and Cpick thread-safe?
I've noticed that this is a potentially-surprising source of lock contention
in Java - all threads share common RNG state, access to which is therefore
protected by locks, so if you have multiple threads generating random
numbers, things slow down tremendously. An easy way to get a per-thread RNG
would be very handy.
I think that all that is needed is to permit some sort of declaration/pragma
that creates a dynamic scope for an srand: e.g. temp srand { ... };
That seems like a reasonable solution.
--
Mark J. Reed markjr...@gmail.com
Re: underscores vs hyphens (was Re: A new era for Temporal)
Egad, no to the equivalence. We'd be back in case-insensitive-language land, only without the benefit of even that dubious tradition. And at least for me, the beef with mixing hyphens and underscores is not that the great unwashed masses can't handle it, but that there will inevitably be cases where even the elite rocket surgeons in their ivory control towers can't agree on which is correct. It's less too subtle for JAPH and more too subtle for consensus even among the cognoscenti.. The edge cases would be back to rote memorization. On Sunday, April 11, 2010, John Siracusa sirac...@gmail.com wrote: On Sun, Apr 11, 2010 at 10:54 AM, Damian Conway dam...@conway.org wrote: Hyphen/underscore equivalence would allow those (apparently elite few) who can correctly use a hyphen to correctly use the hyphen That's about the only advantage of this scheme that I can think of. The disadvantages, which affect everyone, are many and bigger: search/replace headaches, novice confusion, adding to Perl's syntax infamy, etc. (Besides, I'm sure you can Acme::-up something that implements this scheme in Perl 6 for your own devious purposes anyway… ;) -John -- Mark J. Reed markjr...@gmail.com
Re: underscores vs hyphens (was Re: A new era for Temporal)
Egad, no to the equivalence. We'd be back in case-insensitive-language land, only without the benefit of even that dubious tradition. And at least for me, the beef with mixing hyphens and underscores is not that the great unwashed masses can't handle it, but that there will inevitably be cases where even the elite rocket surgeons in their ivory control towers can't agree on which is correct. It's less too subtle for JAPH and more too subtle for consensus even among the cognoscenti.. The edge cases would be back to rote memorization. On Sunday, April 11, 2010, John Siracusa sirac...@gmail.com wrote: On Sun, Apr 11, 2010 at 10:54 AM, Damian Conway dam...@conway.org wrote: Hyphen/underscore equivalence would allow those (apparently elite few) who can correctly use a hyphen to correctly use the hyphen That's about the only advantage of this scheme that I can think of. The disadvantages, which affect everyone, are many and bigger: search/replace headaches, novice confusion, adding to Perl's syntax infamy, etc. (Besides, I'm sure you can Acme::-up something that implements this scheme in Perl 6 for your own devious purposes anyway… ;) -John -- Mark J. Reed markjr...@gmail.com
Re: underscores vs hyphens (was Re: A new era for Temporal)
I'd much rather see a single consistent style throughout the setting than backwards compatibility with p5 naming conventions. If Temporal is the first setting module to use multiword identifiers, I vote for hyphens. They're easier on the fingers and the eyes; underscores have always felt like an ugly compromise to make the compiler's job easier. On Saturday, April 10, 2010, Carl Mäsak cma...@gmail.com wrote: John (): Forgive me if this is a question the reveals how poorly I've been following Perl 6 development, but what's the deal with some methods using hyphen-separated words (e.g., day-of-week) while others use normal Perl method names (e.g., set_second)? I'd just like to point out that the current Temporal spec only does methods with underscores, including Cday_of_week. This goes against my personal preferences; I greatly prefer dashes in almost all of the code I write. But I acknowledge that most of the programmers out there seem to expect underscores -- and also, the aim was to produce a small delta from CPAN's DateTime and not change around things ad lib. // Carl -- Mark J. Reed markjr...@gmail.com
Re: underscores vs hyphens (was Re: A new era for Temporal)
In English, hyphens normally indicate an extra level of reification, where e.g. what is normally a phrase is used in a context that requires a single word: The miller gave us the run of the mill. vs. It was a run-of-the-mill event. As such, examples like day?of?week are somewhat infelicitous, as they could go either way depending on context. In fact, I'd be tempted to go with the punctuation-free weekday, despite spoiling the nice parallelism with day?of?month, year, etc. (Perhaps a generic day_of() that takes a keyword argument would be a useful addition?) But that's going off the track (or off-track). Programming statements do not, in general, read like English, and as such, trying to apply English punctuation rules will at best yield ambiguous results. On Sat, Apr 10, 2010 at 5:25 PM, Damian Conway dam...@conway.org wrote: Personally, I'd prefer to see the English conventions carried over to the use of general use of hyphen and underscore in identifiers in the core (and everywhere else). By that, I mean that, in English, the hyphen is notionally a higher precedence word-separator than the space (or than its intra-identifier stand-in: the underscore). For example: there's an important difference between: initiate_main-sequence_detonator_phase() and: initiate_main_sequence-detonator_phase() The former initiates the detonator phase for the main sequence; the latter initiates the main phase of the sequence detonator. More simply, there's a difference between: $obj1.set_difference($obj2); and: $obj1.set-difference($obj2); The first is setting a difference; the second is computing a difference-of-sets. The rule I intend to use and recommend when employing this new identifier character in multiword names is that you should place an underscore between ordinary unrelated words, and a hyphen only between a word and some modifier that applies specifically to that word. Which, if applied to Temporal, would lead to: my $now = DateTime.from_epoch(time); The Cday method also has the synonym Cday-of-month. (These are also available through the methods Cweek-year and Cweek-number, respectively.) There's a Cday-of-week method, The Cweekday-of-month method returns a number 1..5 The Cday-of-quarter method returns the day of the quarter. The Cday-of-year method returns the day of the year, The method Cwhole-second returns the second truncated to an integer. The Ctime-zone method returns the CDateTime::TimeZone object (i.e. only C.from_epoch() actually uses underscore). Oh, and the optional C:timezone argument to C.new() should probably become C:time-zone for consistency with the C.time-zone() method (or, preferably, we should jut bite the bullet and go with Ctimezone throughout). Damian -- Mark J. Reed markjr...@gmail.com
Re: underscores vs hyphens (was Re: A new era for Temporal)
Agreed. Perl borrows vocabulary almost exclusively from English, but it is not English, and its conventions are not those of English. (And the conventions around hyphens that people are citing are quite specifically those of standard written English; other writing systems, even those using the same alphabet and mostly the same punctuation, have different rules). I would personally like to see hyphens used as the standard word separator, with underscores available for exceptions - say, naming a Perl interface method exactly the same as the underlying C function it provides access to. I'd be less happy with underscores everywhere, but either of those solutions is better (IMESHO) than mixing hyphens and underscores, which should be avoided even within an API, never mind a single identifier. On Sat, Apr 10, 2010 at 8:55 PM, John Siracusa sirac...@gmail.com wrote: On Sat, Apr 10, 2010 at 8:23 PM, Daniel Ruoso dan...@ruoso.com wrote: Em Sáb, 2010-04-10 às 19:53 -0400, John Siracusa escreveu: I'm having trouble imaging any convention that involves mixing word separators being successful. But the convention Damian is proposing is simply use underscores. Basically camelCase and with_underscores are conventions on how to circunvent the fact that we can't use spaces in our identifiers. What is proposed here is that the p5 convention should be preserved. The hyphen is *not* a space, so it doesn't even get into the discussion of this convention. The basic difference is that when a programmer with sufficient communication skills have a composed word (i.e.: week-day), he will have the ability to use the hyphen instead of either supress it or use an underscore... These nuances are exactly what will be lost on people who see classes that use both underscores and hyphens in their method names. -John -- Mark J. Reed markjr...@gmail.com
Re: Unchecked versions of the setters (Re: Temporal.pod truncate)
The date still corresponds to an actual day. If I set it to Feb 31, I
should get back Mar 2 or 3 depending on the year. While I'm having
trouble thinking of a good specific example, it's a capability I've
taken advantage of many times, in holiday calculations, calendar
conversions, and such. I believe it's Python's datetime module that
has unchecked_* methods for the purpose.
Maybe in p6 the setters could do the correction if the exception is resumed?
On Friday, April 9, 2010, Carl Mäsak cma...@gmail.com wrote:
Mark ():
I do think that an unchecked version of the setters is called for, one
that silently converts out-of-range values rather than throwing an
exception. That's not an easy thing to implement outside of the library
without duplicating all the range-checking code.
Hm, true (it's not an easy thing to implement setting of out-of-range
values outside of the library). But what would it be used for? What's
the advantage of having a date corresponding to no actual day?
What I have been considering is something along the lines of
DateTime.is_valid('2010-02-29'), that returns whether constructing
such a DateTime would be legal (in the sense of 'no exceptions
thrown'). It feels comforting to always leave a way for the API
consumer to find things out without resorting to CATCHing exceptions.
// Carl
--
Mark J. Reed markjr...@gmail.com
Re: Unchecked versions of the setters (Re: Temporal.pod truncate)
Especially since we're not ignoring leap seconds; in UTC, 30 days is not always 30*86400 atomic seconds. Other units are more obviously variable-length, but you have to be careful. If you increment one month at a time with autocorrect, 4 months from Jan 31 gets you Jun 2 or 3 instead of May 31. On Friday, April 9, 2010, Mark Biggar m...@biggar.org wrote: On 4/9/2010 4:53 AM, Moritz Lenz wrote: Am 09.04.2010 13:34, schrieb Mark J. Reed: The date still corresponds to an actual day. If I set it to Feb 31, I should get back Mar 2 or 3 depending on the year. While I'm having trouble thinking of a good specific example, it's a capability I've taken advantage of many times, in holiday calculations, calendar conversions, and such. I believe it's Python's datetime module that has unchecked_* methods for the purpose. Maybe in p6 the setters could do the correction if the exception is resumed? Too much magic. Sounds to me like you want a named parameter for a setter, like :force or :unchecked or so. Anyway, I'm not sure such a feature needs to be in the core, at least not in 6.0.0. Unless forming a duration based on various units is really simple, un-checked setters makes generating new Instants from one ones simpler. It is very useful to be able to implement the operators tomorrow, yesterday, thirty_days_from_now, twelve_hours_ago, etc, just by incrementing through the appropriate setter, especially in one-liners. -- m...@biggar.org mark.a.big...@comcast.net -- Mark J. Reed markjr...@gmail.com
Re: Temporal.pod truncate
I think that :toweek should stay as-is; it truncates to whatever the .week method returns, and that's Monday-based. It would be too inconsistent for it to do anything else. Asking for the latest prior Sunday or any other weekday is a useful function, but it doesn't really have anything to do with 'truncation'. I do think that an unchecked version of the setters is called for, one that silently converts out-of-range values rather than throwing an exception. That's not an easy thing to implement outside of the library without duplicating all the range-checking code. On Thu, Apr 8, 2010 at 6:09 PM, Carl Mäsak cma...@gmail.com wrote: John (): Small feature request: $dt.truncate( :toweek ); is somewhat ambiguous, since some people start their week on Sunday, while the module truncates to Monday. Would you consider a less ambiguous week truncation? $dt.truncate( :tosunday ); $dt.truncate( :tomonday ); d; I had the same thought, actually. I see both pros and cons. Among the pros: we'll cater to both the Sunday-starters and Monday-starters out there, just as you say. Among the cons: we lose the nice symmetry wherein :today clears all values smaller than days, :toyear clears all values smaller than years, etc. :tomonday is still pretty straightforward, but it's a subtle category error. Apart from that, I wouldn't mind making the change. Though maybe we should take a step backward and just remove :toweek altogether on the grounds that it doesn't belong, and is more confusing than useful. :) // Carl -- Mark J. Reed markjr...@gmail.com
Re: A new era for Temporal
This looks much better. Thank you. When can we expect to see the new version implemented in Rakudo? Need any help on that front? On Thu, Apr 8, 2010 at 5:52 PM, Carl Mäsak cma...@gmail.com wrote: We (mberends and masak) just pushed a commit to S32::Temporal which completely replaces what we had before. The changes are rooted in hours of discussion on #perl6, and we feel rather more confident with what we have now than with what we had before. That said, discussion is very welcome. I do want to explicitly credit Dave Rolsky, whose work on the DateTime family of modules on CPAN has informed much of the current spec, sometimes to the point of verbatim copying. The change that just went in is complete in itself, but we still expect to add the following details to it: * DateTime::TimeZone * The methods strftime and strptime * DateTime::Duration * ops: $dt + $dur, $dt - $dur, $dt - $dt Expect these in the next few days or so. // Carl -- Mark J. Reed markjr...@gmail.com
Re: r30293 - docs/Perl6/Spec/S32-setting-library
On Sat, Apr 3, 2010 at 2:18 PM, pugs-comm...@feather.perl6.nl wrote: [P6 Spec] completely changed S32::Temporal What motivated these changes? +Time is just a jumbled iTem. iTem? +=item * 12hour +=item * 24hour I don't like using strings for these. Feels like they should be symbols, but they they can't start with digits. Maybe ampm for 12-hour and iso for 24-hour? (i.e. if $*CALENDAR is 'Gregorian' $*TODAY should be something like '12-31-10', depending on how things are formatted) What determines how things should be formatted? Using strings in code to construct dates is bad - see AppleScript. I'd much rather see you have to specify :year(), :month(), and :day(). +=item * Julian (the predecessor of Gregorian. NOT the astronomical Julian Year) That's an awfully loud caveat, especially since it's incorrect. The astronomical Julian year is the mean year of the predecessor of the Gregorian calendar. Since they're the same thing, confusing them is not really a concern. (Astronomers use the Julian calendar because a Julian century is a whole number of days, whereas in the Gregorian calendar you have to get to 400 years before you have a repeatable whole-day cycle).
Regex interpolation
Is there not a way to run arbitrary code and interpolate the result as
a literal string (instead of a Regex)?
I assume that {...} is intended to be where you hook in
semantics/actions mid-parse, but it seems a bit counter-intuitive that
the same syntax interpolates in double-quote context but not regexes.
Question Inspired by this Rakudo patch:
On Monday, March 29, 2010, Bruce Keeler perl6-bugs-follo...@perl.org wrote:
# New Ticket Created by Bruce Keeler
# Please include the string: [perl #73862]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=73862
The attached patch adds support for variable and block-result
interpolation into regexes.
It does so by means of a new PAST::Regex node pasttype 'interpolator'.
The following syntaxes are supported by this patch:
/ $var / -- Interpolates as literal string, unless it's a Regex object
/ @foo / -- Interpolated as ||-style alternations of literal strings
or Regex objects
/ $var / -- compiled into a Regex (unless it's already one), then
interpolated
/ @foo / -- A list of ||-style alternations of things to be
compiled into Regexes (unless they already are)
/ { ... } / -- Result of capture is interpolated as a Regex,
compiling if necessary
/ ?{ ... } / -- Unchanged
/ { ... } / -- Capture is merely executed, but not interpolated.
(Unchanged)
--
Mark J. Reed markjr...@gmail.com
Re: Where's the release announcement?
Is Copenhagen Rakudo #27? It's not mentioned on rakudo.org. On Fri, Mar 19, 2010 at 9:03 AM, Will Coleda w...@coleda.com wrote: On Fri, Mar 19, 2010 at 4:00 AM, Darren Duncan dar...@darrenduncan.net wrote: Richard Hainsworth wrote: Is there a glitch in the mail list system for p6l? I got the Copenhagen release announcement on the parrot developers list but not on p6l. Maybe there aren't Parrot release announcements on p6l because they aren't as directly relevant as say on p6c. In some ways, having Parrot release announcements on p6l is about as relevant as having Perl 5 release announcements on mailing lists for individual Perl modules, or DBI release announcements on the DBIx-Class list, say. -- Darren Duncan Darren - FYI, Copenhagen was a Rakudo release, not a parrot release. Regards. -- Will Coke Coleda -- Mark J. Reed markjr...@gmail.com
Re: numerics, roles, and naming
On Sun, Mar 14, 2010 at 11:26 PM, Doug McNutt dougl...@macnauchtan.com wrote: Anything that can be made into a list is discrete. Not quite, since you can create lists whose members belong to continuous sets, e.g. real numbers. Anything that naturally forms a list, maybe. The other option is a function in the sense of the calculus that truly has an infinite number of values. The set of integers is both discrete and infinite. Likewise rationals and all the other countable sets. The main thing that discrete sets have that continuous sets don't is the ability to map them exactly onto a sequence. Given an integer, there's a single next integer; given a real number, there's infinitely many - and infinitely many more real numbers in between the start number and whichever next you choose. Perhaps the term atomic could be discreetly considered in place of discrete. In CSland, I suspect atomic is too strongly associated with operations to be applied to a data type that has nothing to do with multithreading or transactional integrity. -- Mark J. Reed markjr...@gmail.com
Re: Functional-style pattern matching
Does the unpacking participate in dispatch? If a Hash comes in as $t with no 'left' key, will it fail to match? On Tuesday, March 9, 2010, Little Walker en...@dircon.co.uk wrote: Which is pretty powerful, really. Absolutely - I think you're referring to the 'type subset' stuff which is great. This is where Perl 6 is not the same as functional languages, since it's got an imperative OO element as well. True, there can be friction between the functional style and OO, but look at how Scala manages it with case classes. When you look at the implementation, really it boils down to syntactic sugar but then so do many of the cool new features in Perl 6! I bring this up because when thinking of what will be possible with lazy evaluation, junctions, named parameter shorthand, closures, etc., etc., somehow pattern matching screams out at me. It can be concise, expressive and unambiguous, and very complementary to Perl 6's existing feature set. I know a lot of work went into bringing functional and OO together to make Scala happen, so certainly there may be impracticalities in just 'adding pattern matching'. Scala case classes: http://www.scala-lang.org/node/107 or http://programming-scala.labs.oreilly.com/ch06.html#CaseClasses -- Mark J. Reed markjr...@gmail.com
Re: Functional-style pattern matching
Oh, wow. I was just asking about the spec; didn't know this stuff
already worked. Rakudos to the team! :)
On Wed, Mar 10, 2010 at 9:18 AM, Carl Mäsak cma...@gmail.com wrote:
Mark ():
Does the unpacking participate in dispatch? If a Hash comes in as $t
with no 'left' key, will it fail to match?
Yes.
$ perl6 -e 'sub foo(%h($left)) { say $left }; foo({ left = OH HAI })'
OH HAI
$ perl6 -e 'sub foo(%h($left)) {}; foo({ no = left key })'
Not enough positional parameters passed; got 0 but expected 1
[...]
The error message is perhaps slightly LTA, but at least Rakudo
(correctly) fails to match.
// Carl
--
Mark J. Reed markjr...@gmail.com
Re: r29976 - docs/Perl6/Spec
I think of p6 as more like the Ada of the 21st century. Whether it was a success or not depends on whom you ask, but it had similar criticisms and delays. And was commissioned to be the US federal govt's answer to Algol 68. Which may not have been a big hit, but it had a profound effect on language design, so failure may be overstating it. On Tuesday, March 9, 2010, Timothy S. Nelson wayl...@wayland.id.au wrote: On Mon, 8 Mar 2010, Carl Mäsak wrote: Meanwhile, the uncanny similarities between Perl 6 and Algol 68 continue to strike me: http://en.wikipedia.org/wiki/ALGOL_68 (]): ] ALGOL 68 [...] was conceived as a successor to the ALGOL 60 programming ] language, designed with the goal of a much wider scope of application and more ] rigorously defined syntax and semantics. Algol 68 is notorious as a failure. Let's hope things are different here. :) - | Name: Tim Nelson | Because the Creator is, | | E-mail: wayl...@wayland.id.au | I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK- -- Mark J. Reed markjr...@gmail.com
Re: r29976 - docs/Perl6/Spec
I imagine Brandon was more referring to pass-by-reference, which was
introduced into procedural HLLs by Algol-68.
On Monday, March 8, 2010, Carl Mäsak cma...@gmail.com wrote:
commitbot (), Brandon ():
+ has $!age is ref; # BUILD will automatically use ref binding, not
copy
Perl6 isn't done until it has reinvented Algol 68?
Unaware of what Algol 68 represents in programming language history, I
perused Wikipedia's article on Algol 68:
http://en.wikipedia.org/wiki/ALGOL_68 (]):
] ALGOL 68 has been criticized, [...] for abandoning the simplicity of
] ALGOL 60 [and instead] becoming a vehicle for complex or overly
] general ideas, and doing little to make the compiler writer's task easy,
] [...]
I wish I knew how to follow up that with something witty, but it would
seem the quote more than speaks for itself.
But instead of fruitlessly agreeing or disagreeing with a value
judgement, let me try to summarize the discussion on-channel that led
up to this particular spec change.
When you initialize an Int attribute with an Int, you get that Int put
inside the attribute container.
$ perl6 -e 'class A { has Int $.foo }; say A.new(:foo(42)).foo'42
Similarly, when you initialize a Hash attribute with a Hash, you get
that Hash put inside the attribute container.
$ perl6 -e 'class A { has %.foo }; say A.new(:foo(bar = 42)).foo.perl'
{bar = 42}
$ perl6 -e 'class A { has %.foo }; say A.new(:foo{bar = 42}).foo.perl'
{bar = 42}
*However*, according to the way the old spec did things, and according
to current Rakudo alpha and Rakudo master, when you initialize an
Array attribute with an Array, you get that Array put inside *another*
Array inside the attribute container.
$ perl6 -e 'class A { has @.foo }; say A.new(:foo[1,2,3]).foo.perl'
[[1, 2, 3]]
(The reason for this has to do with attribute initialization having
ordinary assignment semantics, meaning that internally it translates
to something like `...@!foo = [1, 2, 3];`, which would indeed place the
[1, 2, 3] array as the first element in @!foo rather than make that
the whole array. Hashes don't suffer from this problem because `%!foo
= { bar = 42};` does the right thing and assigns the hash to %!foo.)
The discussion, starting at [1] and continuing at [2] and [3], mostly
consisted of me repeating the same question until the above
unintuitive quirk went away. It should now just create one layer of
Array upon initialization.
[1] http://irclog.perlgeek.de/perl6/2010-03-06#i_2070655
[2] http://irclog.perlgeek.de/perl6/2010-03-07#i_2073494
[3] http://irclog.perlgeek.de/perl6/2010-03-07#i_2073717
I'm not sure what exactly the repercussions of doing attribute
initialization with 'is ref' are apart from that. Brandon, if your
oblique reference to Algol 68 meant something more than what I
uncovered above, feel free to enrich the discussion by sharing what
you know about the possible consequences of spec'ing things this way.
Now if you'll excuse me, I'll go back to doing little to make the
compiler writers' task easy. :-P
// Carl
--
Mark J. Reed markjr...@gmail.com
Re: continuation markers for long literals (was Re: r29931 - docs/Perl6/Spec)
On Wed, Mar 3, 2010 at 6:26 PM, Darren Duncan dar...@darrenduncan.net wrote:
Mark J. Reed wrote:
Doesn't unspace work for this?
It would seem that S02 says otherwise:
Although we say that the unspace hides the whitespace from the parser, it
does not hide whitespace from the lexer. As a result, unspace is not
allowed within a token.
D'oh, indeed. Never mind.
On Wed, Mar 3, 2010 at 7:00 PM, Damian Conway dam...@conway.org wrote:
At 80-columns, you can represent integers up to ninety-nine
quinvigintillion, [...]
Assuming the short scale. On the long scale, that's ninety-nine
tredecillion, nine hundred ninety-nine thousand nine hundred
ninety-nine duodecillion, etc. :)
there's always some variation on:
my $debt = +(
123456789012345678901234567890123456789012345678901234
~ 567890123456789012345678901234567890123456789012345678
~ 901234567890123456789012345678901
);
Serviceable, but feels a bit hackish. Reminds me of faking P5 qw in
PHP by using split(' ', 'words like this'). But with a reasonably
intelligent compiler, as you say, at least it still compiles to a
literal.
I note that Rakudo alpha turns the above into Inf, which seems apropos. :)
--
Mark J. Reed markjr...@gmail.com
Re: Temporal seems a bit wibbly-wobbly
On Mon, Feb 22, 2010 at 6:50 PM, Daniel Ruoso dan...@ruoso.com wrote: So why have the duration TAI-based? Simply because TAI is supposedly immutable as a scale, so it's predictable. Gregorian time is not immutable and timezone definitions are not anyhow predictable. OK, this seems to be a point of confusion. TAI *is defined in terms of the Gregorian calendar*.It is not just a sequence of anonymous seconds ticking off at the rate specified by SI. TAI specifies a name for each second, not just the amount of time between them. And that name is a date/time using the Gregorian calendar. If you like, you can convert it to a Julian Date, but that's a one-to-one mapping. You're still going to get a value that's wrong for civil purposes - that is, currently 34 seconds fast compared to an NTP-synchronized clock. If Perl's internal idea of time is just a count of atomic seconds, great. That, however, is not TAI. UTC and TAI and the proposed leap-second-free UTC-replacement TI all tick at the same rate and at the same time, and you can devise any number of time scales that do likewise, differing only in the labels. -- Mark J. Reed markjr...@gmail.com
Re: Temporal seems a bit wibbly-wobbly
On Mon, Feb 22, 2010 at 1:13 PM, Daniel Ruoso dan...@ruoso.com wrote: Em Dom, 2010-02-21 às 21:28 -0800, Larry Wall escreveu: On Sat, Feb 20, 2010 at 10:39:20AM -0500, Mark J. Reed wrote: : I just want to know what Perl 6 time zero is. Well, there's no such thing as time 0 in Perl 6, in the sense that Instant is more-or-less opaque. I'd just like to add that Instant is not more-or-less opaque. It is entirely opaque. Not according to S0, which says that an Instant will numify to the number of TAI seconds since the TAI epoch. That's not opaque. And since it apparently wasn't clear, all I'm asking for is what the TAI epoch is. Again, I *assume* it's January 1, 1958 at midnight UT2, at which point TAI was synchronized to have exactly that same value, but it's not stated as such in the spec, and there are other reasonable values (onset of UTC in 1972; switch to modern relativistic corrections to the measured SI seconds in 1977). The point is... asking for the amount of seconds since 01/01/1970 requires you to convert that date, in a particular timezone in a particular calendar (gregorian) to an instant, then ask for the amount of seconds elapsed from that instant to the current instant (and that will return you a Duration object (which conceptually only know about TAI), which in turn can be converted (provided a timezone and a calendar) to a Gregorian::Duration. Two different problems. The TAI epoch is defined as a point on the TAI scale, and the number of TAI seconds since that point is always well-defined. When asking for epoch-based time, you're not starting with a Gregorian DateTime and trying to convert it. But even if you did do such a conversion, as long as you assume that the input date is UTC, the conversion to TAI is well-defined, too. (And if you don't make that assumption, then you're opening a large can of worms; see e.g.http://www.ucolick.org/~sla/leapsecs/epochtime.html ). The problem really comes in with the fact that POSIX systems ignore leap seconds, and literally cannot distinguish them in any way from their adjacent non-leap neighbor. So you wind up with the fact that an arbitrary set of 24 (so far) POSIX time_t integer values actually cover a 2-second span of time instead of a 1-second span, with no way to identify which values those are without a lookup table, and no way to predict ahead of time which future values will be likewise stretched. -- Mark J. Reed markjr...@gmail.com
Re: Temporal seems a bit wibbly-wobbly
On Mon, Feb 22, 2010 at 1:31 PM, Mark J. Reed markjr...@gmail.com wrote: Not according to S0, which says that an Instant will numify to the ^ S02. number of TAI seconds since the TAI epoch. That's not opaque. -- Mark J. Reed markjr...@gmail.com
Re: Temporal seems a bit wibbly-wobbly
On Mon, Feb 22, 2010 at 4:38 PM, Daniel Ruoso dan...@ruoso.com wrote: And my point is precisely that the spec doesn't define it because it is implementation and architecture dependant. And what's the point of making it so? If you require arithmetic results in TAI seconds, I don't see the benefit of not specifying the epoch, since conversion to and from the epoch would be a simple addition or subtraction - much less expensive than converting from the internal TAI representation to civil time or back. The point is that you shouldn't use a number alone to represent an instant But why not? An instant is just a point on the number line (of the coordinate time in question, which we've established as TAI). A number is an eminently reasonable representation of a point in one-dimensional space. But only if you have a well-defined origin. Note that not even the TAI coordination happens in terms of number of seconds since X, but rather happens in terms of Gregorian or Julian dates. Exactly. See below. The biggest difference proposed by the use of TAI is that when you ask for the number of seconds between 2008-12-31T23:59:59+ and 2009-01-01T00:00:00+ you'll get 2 because of the leap second. But that's not true unless those two strings are given in UTC. In TAI, 2008-12-31T23:59:59Z was followed by 2009-01-01T00:00:00Z only one second later. That's because, as you say, TAI is not just a count of seconds - it is a fully-specified date/time value, with year, month, day, hour, minute, and second - and it doesn't match civil clocks. If the interface between Perl time and human time is going to be done through UTC, then I don't see the point in specifying that it's TAI behind the scenes. Especially if you're not specifying the epoch. The number of seconds between two points in time in UTC is exactly the same as the number of seconds between two points in time in TAI, by definition. Only the labels differ. And if, as you imply above, the labels will be UTC - which they pretty much have to be since that's what humans use - then Perl6 is using UTC, not TAI. It's just using *real* UTC, not POSIX's broken idea of it that claims 24 seconds out of the past 40 years never happened. -- Mark J. Reed markjr...@gmail.com
Re: Temporal seems a bit wibbly-wobbly
On Mon, Feb 22, 2010 at 4:49 PM, Buddha Buck blaisepas...@gmail.com wrote: On Mon, Feb 22, 2010 at 4:38 PM, Daniel Ruoso dan...@ruoso.com wrote: The biggest difference proposed by the use of TAI is that when you ask for the number of seconds between 2008-12-31T23:59:59+ and 2009-01-01T00:00:00+ you'll get 2 because of the leap second. But you don't need to know how many seconds there were in the TAI scale since the 1958 epoch to find that out, you just need to know when we had leap seconds. What do you mean? The number of seconds between 2008-12-31T23:59:59+ TAI and 2009-01-01T00:00:00+ TAI was 1 because TAI doesn't have leap seconds. UTC does, but TAI doesn't. Exactly. If Perl6 is thoroughly TAI, then any time you ask it what time it is you'll get an answer that's 34 or more seconds fast compared to the clock on the wall. In exchange for this, you know that you can take the number of minutes, hours, or days between two times and multiply by a constant to get an accurate count of seconds between them. If, instead, Perl6 uses UTC, then its time labels will agree with our clocks. But that means that some minutes, hours, and days will be a second longer than the rest, so you can no longer do a simple multiplication to convert to seconds. (Unless you're looking for a POSIX time stamp instead of the actual length of the interval.) I submit that if the inputs and outputs of Temporal are UTC, then Perl is using UTC, not TAI. Is it TAI internally? Well if it's manipulating years, months, days, hours, and minutes as their TAI values, then yes, but if it's just working with an absolute count of atomic seconds, then there's no reason to say that it's TAI vs. UTC, because at that level, they completely agree with each other. -- Mark J. Reed markjr...@gmail.com
Re: Temporal seems a bit wibbly-wobbly
I don't see the need for keeping UTC within a second of UT, either. I also think the Gregorian correction is a little silly, but at least it only rears its head 3 times in 400 years. Still, that horse has sailed, right? Perl 6 is using TAI, and the burden of correcting for civil time is on the implementation. I wasn't trying to re-raise the spectre of leap seconds. I just want to know what Perl 6 time zero is. On Saturday, February 20, 2010, Brandon S. Allbery KF8NH allb...@ece.cmu.edu wrote: (re subject: does it go `Ding!' when there's Stuff?) On Feb 20, 2010, at 00:30 , Larry Wall wrote: but an astronomer? But no, many millions of computers have to accommodate to the convenience of a very few people. And most computers still don't know how to do even that accommodation, since POSIX time is blissfully unaware of leap seconds... Sorry, you pushed one of my hot buttons. Grrr! :) Not just yours; quite a few of us wish NTP would return to the demesne of mad scientists and astronomers, to be replaced by a saner (i.e. non-leap-second) version of SNTP. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -- Mark J. Reed markjr...@gmail.com
Temporal seems a bit wibbly-wobbly
S02 says that if pressed, an Instant will numify into a count of atomic seconds since the TAI epoch - but what is the TAI epoch? TAI is normally expressed in the same terms as civil time - year, month, date, hour, minute, second, fraction of second, according to the Gregorian calendar, or else as a Julian Day number. As such, it doesn't really have an epoch built into the concept. (And S32 refers to TAI *as* an epoch, which is inaccurate. An epoch is a particular instant; TAI is a system of measuring time.) Using Instants as numbers is discouraged, but I still believe the epoch should be part of the spec. Once we're requiring atomic time, having the actual numeric value match is just a matter of adding a constant to whatever the natural choice might be on a given implementation. As far as I can see, there are a few reasonable values; roll out the bike shed! My first guess would be midnight on January 1st, 1958, which was when the international atomic time standard was initialized (and synchronized to universal time, specifically UT2), though it wasn't called TAI until 1971. 1 Jan 1977 was when TAI started ticking at the current speed (before that the atomic clock measurements were uncorrected for relativistic effects due to the altitude of the clocks above sea level). 1 Jan 2000 is a nice round number and corresponds to the current epoch used for astronomical calculations (though that's technically noon Terrestrial Time, which was 11:59:27.816 TAI, and I think an exact second in TAI makes more sense for an epoch.) Before that point there wasn't an atomic time standard, but of course you can continue to count atomic seconds backwards in time as far as you like. Since TAI moments are normally given using calendar dates, you could use the epoch of the calendar, though you'll get a few more digits in time values for the present. But what is the epoch of our calendar? January 1st of the year 1? Of the year 0 (a.k.a. 1 BC)? Perhaps November 30th, 1 BC (which is the normalized result of asking for day 0 of month 0 of year 0 when January is month 1)? And regardless of the above, is it that date in the Gregorian calendar we now use, or the Julian calendar which was in effect (at least in Rome) at the time? Or the incorrectly-implemented variation on the Julian calendar which was *really* in effect at that time? TAI moments are sometimes given as Julian Days, so it might make sense to use JD 0.0, though since that was noon UT on January 1st, 4713 BC in the Julian calendar (November 24, 4714 BC in the Gregorian), you'll even more digits. Alternatively you could use Modified Julian Day 0.0, which was midnight UT on November 17, 1858 (the epoch of VMS system time). I note that Rakudo currently uses the time_t value directly. I think 1 Jan 1970 is a poor choice of epoch for TAI time; having time values so close to but not the same as time_t values would create undue confusion. -- Mark J. Reed markjr...@gmail.com
Re: [perl #72914] [BUG] Rakudo doesn't treat ^$n at the end of an infix:... right
On Wed, Feb 17, 2010 at 7:32 PM, Carl Mäsak perl6-bugs-follo...@perl.org wrote: my @a = (4...^5); say @a.perl # should be 4 3 2 1 0 1 2 3 4, according to TimToady That's 4 ... ^5, right? If so, I don't see how you get that. I'd expect (4,0,1,2,3,4), without the countdown between 4 and 0. -- Mark J. Reed markjr...@gmail.com
Re: r29618 - docs/Perl6/Spec
On Tue, Feb 2, 2010 at 12:51 PM, pugs-comm...@feather.perl6.nl wrote:
The methods in this role are:
=head2 method get {...}
-Returns the next item for that iteration. The grouping of elements
-returned in each iteration is visible if this iterator is being used
-to build a slice. While building a list, the items will be flattened.
+Used to iterator over a flat list (the context supplied by a slurpy binding).
^^^ typo; should be Used to iterate.
+Returns the next element from the iterator after flattening any leading
parcel.
-When it runs out of items, it will fail with the CEMPTY exception.
+When it runs out of elements, it will fail with the CEMPTY exception.
As with most failures, it is generally returned without throwing it,
unless the calling lexical scope requests it to be thrown via use fatal.
A few too many its with different antecedents there. Might want to
toss in a noun or two.
--
Mark J. Reed markjr...@gmail.com
Re: Counting characters
What does trans return in numeric (+) context? On Wednesday, January 27, 2010, Carl Mäsak cma...@gmail.com wrote: How is character counting done in Perl 6? In Perl 5, it is `scalar tr/CG//` if I want to count the number of Cs plus the number of Gs in a string. S05 describes tr/// in terms of the .trans function, a handsome but very different beast. Specifically, it doesn't seem to have a scalar context, with which one could count things. -- Mark J. Reed markjr...@gmail.com
Re: Interactive Perl 6 shell
With rakudo, just running perl6 with no arguments drops you into the RE_L. On Tuesday, December 29, 2009, Shawn H Corey shawnhco...@gmail.com wrote: Juan Madrigal wrote: Does Perl6/Rakudo have an interactive perl shell like ruby does with irb? $ perl -ple '$_=eval' (In Windows: perl -ple $_=eval ) Enter the command `exit` to end the session. -- Just my 0.0002 million dollars worth, Shawn Programming is as much about organization and communication as it is about coding. I like Perl; it's the only language where you can bless your thingy. -- Mark J. Reed markjr...@gmail.com
Re: unusual invocants
On Wed, Oct 21, 2009 at 3:47 AM, Ovid publiustemp-perl6langua...@yahoo.com wrote: I was asking the special case where: 1. A class consumes two (or more) roles 2. Each roles provides a method with an identical signature 3. The methods are not equivalent and neither role can rely on the other's method With that, you have roles which cannot be composed. You must rewrite one (bad if you don't own it), or omit one.. Rather than disallow the composition, I'd say that any class, role, or object that does both roles must override the method in question. Which takes us back to Jon's branch of the thread: it would be nice to be able to declare such an override in a general way that will apply to any such composition that doesn't otherwise override it locally. But what should that declaration look like? -- Mark J. Reed markjr...@gmail.com
Re: unusual invocants
On Mon, Oct 19, 2009 at 11:47 PM, Jon Lang datawea...@gmail.com wrote: Because a method is part of a role, and ought to abide by the same terms by which the role abides. If Logging doesn't do Numeric, it shouldn't have any methods in it that won't work unless it does. 100% agreed. So what the OP wants to do is declare a method that is available on all those invocants - and only those invocatnts - which do all of roles X, Y, and Z. Granted, you can declare a new role XandYandZ that does X, Y, and Z, and define the method there, but that won't work on $foo unless you declare explicitly '$foo does XandYandZ' . The goal is to have the method show up no matter how $foo comes to do all three roles. This is an interesting idea. Currently, it doesn't work because there's no place for such a method to live, so perhaps there could be a way to declare a method space for arbitrary combinations of roles, a sort of meta-role. It's an odd duck, but it does sort of fall out of the multiple-dispatch semantics, which already let you base implementation chioce on arbitrary combinations of roles... -- Mark J. Reed markjr...@gmail.com
Re: r28751 - docs/Perl6/Spec
That's not grammatical; you've just created a run-on sentence. Why not leave it as a colon? On Sun, Oct 11, 2009 at 4:55 AM, pugs-comm...@feather.perl6.nl wrote: Author: jimmy Date: 2009-10-11 10:55:02 +0200 (Sun, 11 Oct 2009) New Revision: 28751 Modified: docs/Perl6/Spec/S02-bits.pod Log: [Spec/S02-bits.pod] changed colon to comma Modified: docs/Perl6/Spec/S02-bits.pod === --- docs/Perl6/Spec/S02-bits.pod2009-10-11 07:21:58 UTC (rev 28750) +++ docs/Perl6/Spec/S02-bits.pod2009-10-11 08:55:02 UTC (rev 28751) @@ -247,7 +247,7 @@ $object\ .say -But unspace is mainly about language extensibility: it lets you continue +But unspace is mainly about language extensibility, it lets you continue the line in any situation where a newline might confuse the parser, regardless of your currently installed parser. (Unless, of course, you override the unspace rule itself...) @@ -593,7 +593,7 @@ my Int $x = undef;# works -Variables with native types do not support undefinedness: it is an error +Variables with native types do not support undefinedness, it is an error to assign an undefined value to them: my int $y = undef;# dies -- Mark J. Reed markjr...@gmail.com
Re: r28213 - docs/Perl6/Spec/S32-setting-library
I think there's some confusion around the term epoch in this doc. TAI is not an epoch, and neither is a time value measured in fixed units from some starting point. The starting point is the epoch. One may speak of the UNIX epoch (January 1, 1970 at midnight GMT), but the current time_t value is not an epoch or epoch value. TAI doesn't really have a well-defined epoch. You could make a case for the logical starting point of the Gregorian calendar, 01-01-01T00:00:00 (or even 00-00-00T00:00:00, which maps to November 30, 2 BC in more conventional notation). Or you could use the instant that the original version of TAI went into effect (1958-01-01T00:00:00), or the instant that the current (relativistically-corrected for gravity) version went into effect (1977-01-01T00:00:00). The latter instant is itself used as the epoch of some astronomical time scales (Barycentric Coordinate Time, Geocentric Coordinate Time, and Terrestrial Time). But whatever epoch you choose to count your TAI seconds from, the value you wind up with for any other instant is not itself an epoch. I would change the doc to refer to TAI as a time scale, and also avoid referring to the numerical value of an Instant as an epoch. On Wed, Sep 9, 2009 at 8:33 AM, pugs-comm...@feather.perl6.nl wrote: Author: ruoso Date: 2009-09-09 14:33:35 +0200 (Wed, 09 Sep 2009) New Revision: 28213 Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod Log: [spec-S32-Temporal] uses Instant instead of Rat for the return of time(), Allow base Duration type to work with TAI-seconds delegating to Gregorian::Duration otherwise, Add some methods to Gregorian::DateTime to make the distinction of Instant vs DateTime more evident Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod === --- docs/Perl6/Spec/S32-setting-library/Temporal.pod 2009-09-09 06:46:34 UTC (rev 28212) +++ docs/Perl6/Spec/S32-setting-library/Temporal.pod 2009-09-09 12:33:35 UTC (rev 28213) @@ -30,8 +30,10 @@ repository under /docs/Perl6/Spec/S32-setting-library/Temporal.pod so edit it there in the SVN repository if you would like to make changes. -=head1 Current Time +=head1 Roles +=head2 Instant + The epoch used in Perl 6 to represent time instants is the International Atomic Time - TAI - which is independent of calendars, timezones as well as leap seconds. Of course Perl can't go beyond the @@ -39,12 +41,10 @@ platform-specific transformation to give you the most precise value it can for the TAI. - our Rat sub time() + our Instant sub time() Returns a TAI epoch value for the current time. -=head1 Roles - =head2 Calendar Every DateTime needs to follow the rules of a given calendar. The @@ -148,10 +148,11 @@ for DateTime math. It is also very calendar-dependent, in a way that only a very fundamental data is seen here. -As with DateTime, to make the most common case easier, this type -delegates the constructor to Gregorian::Duration. +The base Duration object is only TAI-seconds aware, but if you use its +constructor with any other parameters it will delegate to +Gregorian::Duration in order to make the most common cases easier. -The following method is implemented by all Duration objects. +The following attribute is declared: =over @@ -226,6 +227,20 @@ =back +The following methods provide additional information + +=over + +=item week-of-year + +=item day-of-week + +=item week-of-month + +=item year-of-week + +=back + =head2 Gregorian::Duration The gregorian Duration declares the following attributes. -- Mark J. Reed markjr...@gmail.com
Re: Perl 6 filename extensions (was Re: r28172 - docs/Perl6/Spec)
I thought I recalled seeing that the new convention was .p6m, .p6l, etc. I guess that idea was abandoned? -- Mark J. Reed markjr...@gmail.com
Re: Synopsis 02: Range objects
Shouldn't it autopromote to Bignum at that point? On 8/27/09, Michael Zedeler mich...@zedeler.dk wrote: Karl Brodowsky wrote: Michael Zedeler schrieb: Well... maybe. How do you specify the intended precision, then? If I want the values from 1 to 2 with step size 0.01, I guess that writing 1.00 .. 2.00 won't be sufficient. Trying to work out the step size by looking at the precision of things that are double or floats doesn't really sound so feasible, since there are a lot of holes in the actual representation, so 1.0001 may become 1.0, yielding very different results. That is a general problem of floats. We tend to write them in decimal notation, but internally they use a representation which is binary. And it is absolutely not obvious what the precision of 1.0001 might be. There could be a data type like LongDecimal in Ruby or BigDecimal in Java, that actually has a knowlegde of its precision and whose numbers are fractions with a power of 10 as the denominator. But for floats I would only see the interval as reasonably clear. Even a step of 1 is coming with some problems, because an increment of 1 does not have any effect on floating point numbers like 1.03e300 or so. Yes. Exactly my point. By the way, do we want to warn if someone writes 1e300 .. 1e301 :by(1) given that the number implementation yields 1e300 + 1 == 1e300? Regards, Michael. -- Sent from my mobile device Mark J. Reed markjr...@gmail.com
Re: Synopsis 02: Range objects
Given how easy chained relational ops make explicit range checking with endpoints, e.g. $a = $x = $b Imd be perfectly happy with a Range smartmatching only the elements that you get out of the RangeIterator. On 8/27/09, smuj s...@iol.ie wrote: TSa wrote: HaloO, David Green wrote: For certain discrete ordered types, like Int, both ways work out the same, and since Ints are the most common and most obvious use for Ranges, it's easy to overlook the confusion. The case with strings is a good example: it really doesn't make sense that a value not produced by a range nevertheless lies between its endpoints. Why not have a separate Interval type? I see no problem when a Range matches for values which are not produced by a RangeIterator. I expect 2.5 ~~ 1..5 to be true even though 2.5 is not in 1,2,3,4,5. I suspect that the double meaning of Ranges is going to confuse some people and bite others. If things stay as they are, I hope that the use of :by will be flagged as a syntax error if used in literal Range smart matching. Of course, that doesn't help the unsuspecting when variables are being used, ala 2.5 ~~ $myrange. (For the record, 2.5 ~~ '!'..5 is also true on my system, although I don't know why! I certainly wouldn't expect it though :) The same applies for 'aaa' ~~ 'aa'..'az'. I find this quite natural. Not sure if you're saying that's something you'd like or if you think that that's something already there. It doesn't match for me using recent(ish) Rakudo. Of course, that could just be me! :) I'd personally prefer it if Ranges just did lists, including when smart matching, but had an interval method or such like for explicit matching against the endpoints, e.g. 2.5 ~~ interval(1..5) # or 2.5 ~~ $myrange.interval I'm new in town though, so I'll happily admit that I don't know the full implications of such a change. Having context-insensitive Ranges DWIM's better to me, but DWIMery, like beauty, is clearly in the eye of the beholder! :) Cheers, -- smuj -- Sent from my mobile device Mark J. Reed markjr...@gmail.com
Re: Synopsis 02: Range objects
I think $a = $^x = $b is short enough, and lets you choose between and = on both ends and without having to remember how many dots each maps to. But I do like your list context for list behavior idea. I would support that happily. On 8/27/09, Jon Lang datawea...@gmail.com wrote: smuj wrote: TSa wrote: HaloO, David Green wrote: For certain discrete ordered types, like Int, both ways work out the same, and since Ints are the most common and most obvious use for Ranges, it's easy to overlook the confusion. The case with strings is a good example: it really doesn't make sense that a value not produced by a range nevertheless lies between its endpoints. Why not have a separate Interval type? I see no problem when a Range matches for values which are not produced by a RangeIterator. I expect 2.5 ~~ 1..5 to be true even though 2.5 is not in 1,2,3,4,5. I suspect that the double meaning of Ranges is going to confuse some people and bite others. If things stay as they are, I hope that the use of :by will be flagged as a syntax error if used in literal Range smart matching. Of course, that doesn't help the unsuspecting when variables are being used, ala 2.5 ~~ $myrange. Another possibility is that literal Range smartmatching works as is in the absence of :by (that is, with a Range), but becomes a set membership test in its presence (i.e., with a RangeIterator). Or not; see below. (For the record, 2.5 ~~ '!'..5 is also true on my system, although I don't know why! I certainly wouldn't expect it though :) One explanation would be that it's comparing the String 2.5 to the String-terminated Range !..5. Since 2 falls between ! and 5, so does 2.5. The same applies for 'aaa' ~~ 'aa'..'az'. I find this quite natural. Not sure if you're saying that's something you'd like or if you think that that's something already there. It doesn't match for me using recent(ish) Rakudo. Of course, that could just be me! :) I'd personally prefer it if Ranges just did lists, including when smart matching, but had an interval method or such like for explicit matching against the endpoints, e.g. 2.5 ~~ interval(1..5) # or 2.5 ~~ $myrange.interval I don't like the Huffman encoding: does $x come after $a and before $b? is a common test, and so should be short. I'd rather require you to force it into list context if your goal is to test for set membership. In fact, that might be a clean way of handling its dual nature: in item context, it behaves as a Range object; in list context, it behaves as the RangeIterator. So: 2.5 ~~ 1..5 # true: equivalent to 2.5 ~~ 1 = $_ = 5. 2.5 ~~ @(1..5) # false: equivalent to 2.5 ~~ (1, 2, 3, 4, 5). Incidently, this first example is why I think that Range is intimately related to the various order-related operators, and in particular before and after: its most common use outside of generating sequential lists is to provide a shorthand for $min before $_ before $max and similar range-testing expressions. -- Jonathan Dataweaver Lang -- Sent from my mobile device Mark J. Reed markjr...@gmail.com
Re: Synopsis 02: Range objects
On Tue, Aug 25, 2009 at 5:58 PM, Jon Langdatawea...@gmail.com wrote: Also, I want to second David Green's point: we're not talking Range and Interval here; we're talking Range and Series. But a series refers to a more general concept than a discrete range. I still think Range and Interval fit better. using Complex for your endpoints should result in an error: Complex numbers don't have a viable definition of before or after, let alone between. Slight overstatement, IMO. Sure, complex numbers don't form an ordered field: given three numbers, z0, z1, and z2, you can't ask if z0 z1 or z0 z2, at least not without imposing some artificial ordering rule. Even without defining an ordering, though, you can meaningfully ask whether z0 lies within or outside the rectangle formed by z1 and z2, which is a viable (if nonlinear) definition of between. You can only get a Boolean answer, but it's a valid question. That's just nitpicking, though. It's perfectly reasonable to fail() if someone tries to construct a Range/Series/Interval out of Complex numbers. We can use a different class for complex rectangles if we need them. -- Mark J. Reed markjr...@gmail.com
Re: $*CWD and chdir()
On Wed, Aug 19, 2009 at 2:35 AM, Darren Duncan dar...@darrenduncan.netwrote: Having read all of this thread to date, I'll state a solution which should be elegant and which I'm not sure has been stated yet. I think that's basically what we were suggesting above, except: (If Perl really must have the ability to change the non-virtual current working directory, such as because its going to spawn another non-Perl process, then this should use some separate mechanism to what all of Perl's own IO uses, and any such change would have no effect on any Perl $*CWD.) I would propose that whenever Perl spawns a non-Perl process, that process automatically executes a chdir() to the spawning thread's value of $*CWD. But this should be done without changing the parent process's external/OS working directory. In UNIX that's easy - fork(), then chdir(), then exec() - but in Windows it may be trickier. -- Mark J. Reed markjr...@gmail.com
Re: Filename literals
anyway... certainly we'll have to rely on IO::Filesystem::XXX, but I do think this is another area to defer to the OS's own type-determining functions rather than try to do it all internally. What we should have, though, is a standard way to represent the types in Perl so that users know how to deal with them. I think roles are the obvious choice: if the OS tells you that a file is HTML, then $file would do IO::Datatype::HTML, which means in turn it would also do IO::Datatype::Plaintext, and so on. Of course, if the OS tells you you've got a file that does IO::Datatype::Illudium-phosdex, and you want to *do* something with it, you'll need a module that knows what to do with that kind of file. Perl by itself knows only how to treat it as a string of raw bytes. Well, or as plain text. So you can treat your HTML file as plain text, or you can use HTML::Doc::Tree and treat it as something fancier. -David -- Sent from my mobile device Mark J. Reed markjr...@gmail.com
Re: r28017 - in docs/Perl6/Spec: . S32-setting-library
On Tue, Aug 18, 2009 at 11:04 AM, David Greendavid.gr...@telus.net wrote:
On 2009-Aug-18, at 2:29 am, Carlin Bingham wrote:
chdir provides functionality that would be quite convoluted to mimic
through manually setting $*CWD, such as changing to a relative
directory.
Maybe setting $*CWD just calls chdir() under the hood? Same implementation,
brand new shiny Perl-style interface!
If $*CWD is really a Path object and not a Str, then it should be easy
to use mutator methods to change to a relative directory and do other
chdir()ish things. Say, concatenation works in terms of path
components, for instance:
$*CWD ~= $subdir; # chdir($subdir)
With a method for getting the parent:
given $*CWD { $_ = $_.up ~ $sibling } # chdir(../$sibling)
and so on. My favorite kshism is cd old new which does a
search/replace on the current working directory; the bash equivalent
cd ${PWD/old/new} which is not quite as handy. $*CWD could make
that simple, too.
--
Mark J. Reed markjr...@gmail.com
Re: $*CWD and chdir()
It would be nice if the bikeshed had aluminum siding. Er, I mean, if chdir() changed *CWD and vice-versa, though I'm not sure offhand how best to code that in idiomatic P6 to avoid the infinite recursion. Anyway, at the very least, a readonly *CWD holding a cached idea of the current dir is good. Not having to call getcwd() is a definite performance win. And if it functions like the POSIX shell PWD in terms of tracking symlinks and translating relative pathnames to match the apparent cwd instead of the physical one, so much the better. That is, in ksh/bash, if I do mkdir -p foo/bar/baz cd foo ln -s bar/baz . cd baz Now getcwd() (via e.g. /bin/pwd) says I'm in .../foo/bar/baz. But $PWD (and the shell builtin pwd) says .../foo/baz. And even though the directory entry .. is a link to .../foo/bar, if I do cd .. I will be back in .../foo, because the shell translates it into the equivalent of 'cd $(basename $PWD) '. Of course, other programs don't apply this logic to their arguments, which can lead to confusion when e.g. cd .. cat myfile yields a different result from cat ../myfile. But in general, this potential confusion was deemed worth it for the added transparency and utility of symbolic links. So perhaps a similar distinction between $*CWD and getcwd() would be useful in P6. It would cut way down on the not getting back what you put in problem with assigning to $*CWD. We could minimize that issue even further by not allowing the assignment of relative pathnames, only absolute ones (which of course can be constructed by simple ops on the current value). On 8/18/09, Carlin Bingham car...@theintersect.org wrote: 2009/8/18 David Green david.gr...@telus.net: On 2009-Aug-18, at 3:27 am, Timothy S. Nelson wrote: On Tue, 18 Aug 2009, David Green wrote: or however that would work in P6. It may have problems, but by definition they're the same problems as chdir() has. What am I missing? chdir is a familar function with predictable behaviour. $*CWD, as a variable that magically changes to something other than what it was set to, is unfamiliar and unpredictable. Now there's nothing wrong with introducing new, unfamiliar functionality, if it provides a discernible benefit, but that doesn't seem to be the case here. -- Carlin -- Sent from my mobile device Mark J. Reed markjr...@gmail.com
Re: $*CWD and chdir()
Er, that basename down there should be a dirname, for those playing along at home. Memo to self: do not type long screeds on Blackberry... On 8/18/09, Mark J. Reed markjr...@gmail.com wrote: It would be nice if the bikeshed had aluminum siding. Er, I mean, if chdir() changed *CWD and vice-versa, though I'm not sure offhand how best to code that in idiomatic P6 to avoid the infinite recursion. Anyway, at the very least, a readonly *CWD holding a cached idea of the current dir is good. Not having to call getcwd() is a definite performance win. And if it functions like the POSIX shell PWD in terms of tracking symlinks and translating relative pathnames to match the apparent cwd instead of the physical one, so much the better. That is, in ksh/bash, if I do mkdir -p foo/bar/baz cd foo ln -s bar/baz . cd baz Now getcwd() (via e.g. /bin/pwd) says I'm in .../foo/bar/baz. But $PWD (and the shell builtin pwd) says .../foo/baz. And even though the directory entry .. is a link to .../foo/bar, if I do cd .. I will be back in .../foo, because the shell translates it into the equivalent of 'cd $(basename $PWD) '. Of course, other programs don't apply this logic to their arguments, which can lead to confusion when e.g. cd .. cat myfile yields a different result from cat ../myfile. But in general, this potential confusion was deemed worth it for the added transparency and utility of symbolic links. So perhaps a similar distinction between $*CWD and getcwd() would be useful in P6. It would cut way down on the not getting back what you put in problem with assigning to $*CWD. We could minimize that issue even further by not allowing the assignment of relative pathnames, only absolute ones (which of course can be constructed by simple ops on the current value). On 8/18/09, Carlin Bingham car...@theintersect.org wrote: 2009/8/18 David Green david.gr...@telus.net: On 2009-Aug-18, at 3:27 am, Timothy S. Nelson wrote: On Tue, 18 Aug 2009, David Green wrote: or however that would work in P6. It may have problems, but by definition they're the same problems as chdir() has. What am I missing? chdir is a familar function with predictable behaviour. $*CWD, as a variable that magically changes to something other than what it was set to, is unfamiliar and unpredictable. Now there's nothing wrong with introducing new, unfamiliar functionality, if it provides a discernible benefit, but that doesn't seem to be the case here. -- Carlin -- Sent from my mobile device Mark J. Reed markjr...@gmail.com -- Sent from my mobile device Mark J. Reed markjr...@gmail.com
Re: r28017 - in docs/Perl6/Spec: . S32-setting-library
On Tue, Aug 18, 2009 at 6:59 AM, Carlin Binghamcar...@theintersect.org wrote: 2009/8/18 Timothy S. Nelson wayl...@wayland.id.au: On Tue, 18 Aug 2009, Mark J. Reed wrote: It's not in the revised spec, but I think that, even though we've revived chdir, we should still have it so that changing $*CWD will do a chdir under the hood. You're quoting the wrong person. That wasn't me. -- Mark J. Reed markjr...@gmail.com
Re: $*CWD and chdir()
On Tue, Aug 18, 2009 at 9:26 AM, Jan Ingvoldstadfrett...@gmail.com wrote: You think it's a bug that PWD=/etc doesn't change your working directory to /etc in bash? Please tell me you're joking. It's not that unreasonable. Given a variable that magically changes depending on your working directory, having your working directory change when you set that variable is eminently plausible. Especially since the cwd is completely under the shell's control. And changing dirs by setting PWD wouldn't get you any capability you don't have anyway via the cd builtin. Notably, while many of the special shell parameters have documented set behavior (setting RANDOM seeds the random number generator; many special parameters are readonly; others lose their magic entirely when unset), the behavior of setting PWD is not specified. So a shell could have PWD= do a cd() and even be within compliance. Here's another example of something that, if I understand you correctly, you find as unexpected behaviour: j...@krakas ~ USER=root If that were going to work, it would presumably work like su(1): j...@krakas ~ USER=root Password: j...@krakas ~ # _ But USER isn't even a shell-maintained variable. It's set by login(); the shell just inherits it. A better example would be UID - which is readonly. -- Mark J. Reed markjr...@gmail.com
Re: $*CWD and chdir()
On Tue, Aug 18, 2009 at 10:26 AM, Timothy S. Nelsonwayl...@wayland.id.au wrote: Ok, so suppose we only allowed direct assignment to absolute paths? Is there an echo in here? :) -- Mark J. Reed markjr...@gmail.com
Re: $*CWD and chdir()
On Tue, Aug 18, 2009 at 10:37 AM, Jan Ingvoldstadfrett...@gmail.com wrote:
It's not that unreasonable.
I disagree, and I think I've explained why, and perhaps we won't get much
further.
I'm not claiming that it's a good idea for bash to adopt this
behavior, only that it's a reasonable expectation tohave upon
encountering the read behavior of $PWD.
Its not unlike, say, applying an UPDATE to a view in an RDBMS: it
seems like it should work. It might not, for various reasons, but
it's not an unreasonable expectation. And in many versions of SQL it
does work for the simpler view/table relationships.
But USER isn't even a shell-maintained variable.
I'm not sure what you mean by a shell-maintained variable.
I mean, it's not a parameter that is ever set by the shell. Unlike
PWD, RANDOM, LINENO, PPID, etc. which are set by the shell.
As for $UID being read-only, that's a bashism. There's nothing inherent
about $UID that makes it read-only.
Huh? I thought UID was a bashism. In my copies of ksh, it's not even
set - ATT ksh93 (version M 1993-12-28 s+ under UWIN, Version JM 93t+
2009-05-01
on Linux) and pdksh 5.2.14. . If it's POSIX, it must be a a
relatively recent addition.
In a POSIX shell, you get this:
$ ksh --version
version sh (ATT Research) 1993-12-28 s+
$ echo $UID $USER
501 jani
Not here.
bash in POSIX mode agrees:
What version of bash? bash-3.2:
$ bash --posix
bash-3.2$ echo $UID
1024
bash-3.2$ UID=500
bash: UID: readonly variable
Did you maybe export UID, so it's being inherited by these subshells?
Even Perl 5 lets me change it:
OK, you clearly exported UID. It's not exported by default, so
$ENV{UID} in Perl should be unset. Try your experiments without
exporting UID.
In any case, %ENV isn't readonly in Perl. But neither are the contents
of %ENV managed by Perl - just inherited from the parent process.
--
Mark J. Reed markjr...@gmail.com
Re: $*CWD and chdir()
The OS-level chdir() and getcwd() are not thread-safe. The usual
advice is to ignore them completely in multithreaded programs, in
favor of absolute paths (or relative paths from a fixed location,
never calling chdir()). This is part of the a reason that Apache2
recommends fastcgi for non-prefork MPMs (since the CGI spec requires
cgi scripts to start with getcwd() set to the directory containing
them).
Since qqx has to fork a new process anyway, having it chdir(*CWD)
is not a big deal - as long as it's the child, not the parent, that
calls chdir(). But any process with multiple threads should generally
avoid calling chdir() ever.
All of this is assuming that P6's chdir() just calls the OS routine,
of course. It could be made fancier and handle the thread-stuff
itself...
On 8/18/09, Timothy S. Nelson wayl...@wayland.id.au wrote:
Ok, here's a fairly significant point posted on IRC.
TimToady wayland76: the point of using $*CWD would be (and would *have*
to
be, given how context vars work) to give each thread its own working
directory, independent of the process as a whole
Now, given that chdir is an OS concept that applies to the process as
a whole, rather than individual threads, but $*CWD is designed for
individual
threads, that pretty much means that it is a really bad idea to have $*CWD
do
chdir() for us.
Now, having said that, I think the idea of a per-thread CWD is a great
idea, and I'd be in favour of using $*CWD over whatever getcwd retrns in
Perl6
as much as possible. So I think it would be cool if all relative paths
specified via p{} were relative to $*CWD, not getcwd(). So something like
this:
chdir(/usr/bin);
$*CWD = /home/username;
$path = p{Music};
say $path.canonpath();
# prints /home/username/Music
My question is, what else uses chdir/getcwd style paths? I know
qqx/$cmd @args[]/
...will pass its current dir to the child. Maybe we could have Perl6
do something like this pseudocode under the hood when someone does a qqx.
olddir = getcwd();
chdir($*CWD);
exec(qqx string here);
chdir(olddir);
That would mean that $*CWD would effectively act as a per-thread
working directory.
No doubt someone will write in and tell me how bad an idea this is. I
look forward to having my ignorance exposed :).
-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am |
-
BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V-
PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y-
-END GEEK CODE BLOCK-
--
Sent from my mobile device
Mark J. Reed markjr...@gmail.com
Re: Filename literals
On Fri, Aug 14, 2009 at 3:35 PM, Darren Duncandar...@darrenduncan.net wrote: Under Mac OS X, all drives, root or otherwise, are accessible under '/Volumes/drive-name/...', and Unix in general lets you mount drives anywhere. I imagine Windows supports more ways of denoting drives than the drive letter. Nope. Have to use the drive letter. But / is understood as a synonym for \ by the Windows API. -- Mark J. Reed markjr...@gmail.com
Fwd: Rukudo-Star = Rakudo-lite?
Wrong reply button... -- Forwarded message -- From: Mark J. Reed markjr...@gmail.com Date: Mon, 10 Aug 2009 07:36:52 -0400 Subject: Re: Rukudo-Star = Rakudo-lite? To: Gabor Szabo szab...@gmail.com That has the same problem as lots of other themes - it puts a hard limit on the number of releases before the One True Rakudo. Maybe you could call it Zeno's Camel (project motto: halfway done!) and have releases numbered 0.5, 0.75, 0.875, 0.9375,... :) On 8/10/09, Gabor Szabo szab...@gmail.com wrote: On Mon, Aug 10, 2009 at 2:02 AM, Patrick R. Michaudpmich...@pobox.com wrote: On Sun, Aug 09, 2009 at 04:35:42PM -0600, David Green wrote: On 2009-Aug-9, at 3:57 pm, Tim Bunce wrote: Perhaps it's worth asking what we might call the release after that one. Rakudo not-quite-so-lite? Rakudo ** (aka Rakudo Exponentiation)? Though I think Patrick is optimistic that development will proceed exponentially enough that a single interim release will be enough to hold us over until Christmas. I'm not sure I'm quite THAT optimistic. :-) We may end up with multiple interim releases in the Rakudo Star series before we reach Christmas. (And yes, they may even be *+1, *+2, etc.) In some ways I'm starting to think of Star (or whatever designation we end up using) as a label for a series of interim releases in the same sense that NASA used Gemini as the label for the program came between Mercury and Apollo. In other words, Star may really end up being a designation for a program of planned releases with certain major objectives that cumulatively lead up to the ultimate goal of a full Perl 6 release. The precise details are still a little ill-formed in my head at the moment, but as they come together (and are expressed in planning documents) I'll be blogging or writing about them appropriately. my bikeshed would go along the lines of @rakudo[*-100] @rakudo[*-99] ... Gabor -- Sent from my mobile device Mark J. Reed markjr...@gmail.com -- Sent from my mobile device Mark J. Reed markjr...@gmail.com
Re: Rukudo-Star = Rakudo-lite?
Given the Japanese behind the name Rakudo, rakudone looks like a question: Rakudo, right? Beats rakuod, though. On 8/10/09, James Fuller james.fuller.2...@gmail.com wrote: how about 'raku' then the final version could be called 'rakudone' Jim Fuller -- Sent from my mobile device Mark J. Reed markjr...@gmail.com
Re: Embedded comments: two proposed solutions to the comment-whole-lines problem
On Mon, Aug 10, 2009 at 4:57 PM, Jon Langdatawea...@gmail.com wrote: I'd recommend '#='; but if that isn't already being used by pod, it should be reserved for use by pod (and it's visually heavy). Commenting out lines that include pod will generate #= at the beginning of a line, which is tantamount to the problem we're trying to avoid. What other symbols are reasonably easy to type, are visually lightweight, and are unlikely to be found at the start of a line and immediately followed by an open bracket? Hmm... how about '#.'? Too visually lightweight, IMO Almost disappears entirely in this font next to the heavy #, making the third and fourth lines below easily confusable. #line comment #.line comment #(line comment) #.(inline comment) Besides which, Perl 6 teaches us that $foo() and $foo.() are usually interchangeable. :) I still like the double-bracket idea. I don't much mind the extra character; 5 characters total still beats the 7 of HTML/XML. -- Mark J. Reed markjr...@gmail.com
Re: confusing list assignment tests
My understanding is that the P6 way to do that is to return a Capture containing the desired return values (which can lazily do things only when accessed) in the appropriate slots. On 7/28/09, Jon Lang datawea...@gmail.com wrote: Larry Wall wrote: Moritz Lenz wrote: : Either it's parsed as '@a[0] = (W, W)' (list assignment), then @a should : get both elements, and so should @z. Not according to S03, at least by one reading. �...@a[0] as a scalar container only wants one item, so it only takes the first item off the list, and the list assignment produces a warning on the second because it's discarded. Since an assignment returns its left side, only one element is available to @z from @a[0]. So, do we still have p5's 'want_array' (or whatever it was called)? That is, the predicate that tells the you whether the function is being called in item or list context? I know that the generalized 'want' function proved to be unworkable; but I'd expect p6 to at least be able to do everything that p5 can do; and that includes functions that are aware of whether they're being used as singular or plural. -- Jonathan Dataweaver Lang -- Sent from my mobile device Mark J. Reed markjr...@gmail.com
Re: indentation with multiple languages
On Sat, Jul 25, 2009 at 5:03 AM, Moritz Lenzmor...@faui2k3.org wrote:
Presumably you want here-docs, which can be indented in Perl 6:
perl 6 code
perl 6 code
$script.say(Q:toEND);
output code
output code
END
The leading whitespace will be pruned from the string.
All of the leading whitespace, or only up to the amount on the first
line? That's always been the problem with here-docs. Rakudo doesn't
seem to support Q:to yet, so I can't test, but if I do this:
say(Q:toEND);
line 1
line 2
line 3
END
I would want line1 to be flush left, while line 2 is indented, and
line 3 indented more.
The solutions to do this in Perl5 are a bit hacky and fragile,
something like replacing the simple
print END;
with
(my $str = END) =~ s/^\s{4}//gms; print $str;
or similar, which is a lot of work just to get more-legibly-formatted
source code.
--
Mark J. Reed markjr...@gmail.com
Re: Huffman's Log: svndate r27485
ln() for log(:base(e)) is fine. ln() for log to any other base is
Just Plain Wrong.
The clash between 'log' for 'logarithm' and 'log' for 'write to log
file' is unfortunate, but since you have to define logging parameters
somewhere anyway, I'm OK with having to call that sort of log as a
method on a logger object instead of as a top-level sub.
All's fair if you predeclare, so you could use MMD to define log(Str)
as a shortcut for writing to the log, but that's going to surprise
folks who are used to log('1') returning 0.
On Fri, Jul 10, 2009 at 3:16 PM, yarynot@gmail.com wrote:
+1 on using ln() instead of log()
Also, systems I know of that implement both log() and ln() default
ln() with base e, as perl6 does, log() uses base 10.
--
Mark J. Reed markjr...@gmail.com
Re: Huffman's Log: svndate r27485
I'm all for not having any variety of log() in the default namespace. Regardless, mathematical functions should follow mathematical norms. Changing Perl tradition is one thing, but we have centuries, sometimes millennia, of tradition to deal with in the mathematical realm. It should not be violated lightly. On 7/10/09, Austin Hastings austin_hasti...@yahoo.com wrote: David Green wrote: It occurs to me that log is a pretty short name for a function I rarely use. (In fact, I'm not sure I've ever used it in perl.) On the other hand, I -- and a thousand or so CPAN modules -- are always logging stuff in that other popular computer sense. (All right, that number isn't exactly the result of a rigourous study... I did find 57 modules that mentioned logarithms.) The inertia of tradition weighs heavily here, but perhaps we could call it ln(). (If anyone asks, I'm prepared to say with a straight face that it stands for log (numeric).) And/or log(), but with the :base arg mandatory -- then as long as your status logging doesn't have a :base, you can have both. Umm. At the risk of pointing out the obvious, P6 has redefined the syntax of regular expressions, converted bitwise negation into a stringification unary and a binary catenation operator, and torqued a bunch of other keywords and line noise^W^Woperator characters out of shape. Do we really give a rat's posterior about the historical legacy of a mathematical function that (statistically) never gets called? Like everything else mathematical, jam it into a Math:: class and clean up the default namespace. (FWIW: My perl scripts don't do logs, in EITHER sense of the word. I don't want to replace one bit of namespace clutter with another one. All you web guys can use the Apache::log method, or whatever.) =Austin -- Sent from my mobile device Mark J. Reed markjr...@gmail.com
Fwd: Re-thinking file test operations
My reply to the message Aaron sent directly to me by mistake...
-- Forwarded message --
From: Mark J. Reed markjr...@gmail.com
Date: Fri, Jul 10, 2009 at 7:23 PM
Subject: Re: Re-thinking file test operations
To: Aaron Sherman a...@ajs.com
You replied just to me, you know.
In re-thinking it, we don't need to do either. It's already built in:
$str does Path;
if $str.e {
say($str exists);
}
Sure, but I was thinking that particular case might be common enough
to warrant something with a better Huffman encoding.
I think stringish classes are common and useful enough to have
special literal support available without having to customize the
grammar. Maybe there's a registry of prefixes that can be put in
front of the opening quote, like p'' for a pathname, or maybe you
have to use a q operator with a modifier.
You've made contradictory statements, there.
No, I just wasn't clear.
Either you want to change the
grammar to add new quoting styles (then the argument ensues: is YOUR key
type common enough to deserve a quoting semantic?) or you think that you
shouldn't have to customize the grammar.
No, what I was talking about was changing the default grammar, but in
a general way, so that users who wanted their own literal syntax for
such things wouldn't have to customize the grammar themselves. That
is, I'm arguing for a change in the design to avoid programmers having
to customize the grammar for this particular case.
I'm in favor of NOT customizing the grammar, but at the same time, I readily
admit that strings aren't always strings, and might have much more semantic
baggage that it would be good to be able to associate with them easily.
Agreed.
--
Mark J. Reed markjr...@gmail.com
--
Mark J. Reed markjr...@gmail.com
Re: Re-thinking file test operations
A few months ago (or maybe more) I proposed making pathnames their own type, distinct from (or perhas a subclass of) strings, but easily constructed from strings, maybe with an operator. Having those 29 single-letter methods on such a class would not bug me as much as having them on Str. On 7/9/09, Aristotle Pagaltzis pagalt...@gmx.de wrote: * Moritz Lenz mor...@faui2k3.org [2009-07-10 00:25]: stat($str, :e) # let multi dispatch handle it for us This gets my vote. -- Aristotle Pagaltzis // http://plasmasturm.org/ -- Sent from my mobile device Mark J. Reed markjr...@gmail.com
Re: XOR does not work that way.
On Mon, Jun 22, 2009 at 4:12 PM, Minimiscienceminimiscie...@gmail.com wrote: I don't think natural language -- especially the abomination that is English -- is the best guide for understanding logical operations (why, yes, I *do* speak Lojban; how did you know?). To which Jon Lang replied: You're aware that Perl was designed by a linguist, with an eye toward incorporating natural language concepts, right? Let me make a small digression to expand upon what Jon said. There's a reason natlangs don't work like loglangs: human thought isn't based on logic. Instead, logic is an artificial construct which, while quite useful within its domain, is not necessarily optimal for communicating with humans - not even when the other end of the communication is a computer. Computers are built around logic, of course. But while traditional programming was based on teaching humans to think like the computer, the progression from machine code to assembly to ever-higher-level languages has been about making the computers accept programming languages with increasingly natural human language features. Perl has synonyms (TMTOWTDI), homonyms (context, MMD), other sorts of ambiguity just like natlangs. (And no need to pick on poor English especially; it's a perfectly cromulent language, however suboptimal it might be from an auxlang or loglang perspective.) All of which is just by way of agreeing with Jon: formal logic is not the primary motivator behind Perl's design. So while it should be considered, it's not a knockout punch to say but logic doesn't work that way. -- Mark J. Reed markjr...@gmail.com
Amazing Perl 6
Assuming you have the right key set in the Registry, you can enter hex Unicode in Windows. Hold down alt, press the + key on the numpad and then type the hex code (using the main keyboard and/or the numpad), then release alt. On Sat, May 30, 2009 at 2:11 AM, John M. Dlugosz j...@dlugosz.com wrote: The same tradition has variations in Windows. I recall the leading zero means ANSI code page. I thought I recall a way to give more digits and specify Unicode, but I can't find it on Google. --John Timothy S. Nelson wayland-at-wayland.id.au |Perl 6| wrote: On Fri, 29 May 2009, John M. Dlugosz wrote: Ah yes, on the PC historically you hold down the ALT key and type the code with the numpad keys. At least when I used it, this was a decimal, rather than hex number, and had to be preceded by a 0 (zero). So if anyone is still on eg. Windows 98, this may be the way to go :). - | Name: Tim Nelson | Because the Creator is, | | E-mail: wayl...@wayland.id.au | I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK- -- Mark J. Reed markjr...@gmail.com -- Mark J. Reed markjr...@gmail.com
