Re: Language design
On Tue, Jul 14, 2015 at 12:04 AM, Michael Zedeler mich...@zedeler.dk wrote: So far, almost every other language has behaved this way, and it has worked. I can see that Rats do solve a problem, but if you'd claim that it is very severe then I'd disagree. This is a minor nuisance that I'd only pay a small price to fix. People who use your lovely example – spreadsheets – tend to disagree. There was a LOT of noise about how Excel handled numbers in a very surprising manner, every time a new problem came up. There are a gazillion articles about how to avoid it, and people who deal with spreadsheets spend inordinate amounts of time to get around it. Or they take the performance hit for asking for the precision of numbers as displayed. For more information, please see here: https://support.microsoft.com/en-us/kb/78113 The minor nuisance is not so minor out there in the real world, where people use actual applications where they _expect_ WYSIWYG numbers. Now, what Rats solve for us programmers, is that it makes it easier for us to avoid these pitfalls, and thereby makes it easier for us to cater for our users. -- Jan
Re: Licensing: Perl 6 specification and test suite
On Tue, Nov 5, 2013 at 3:09 PM, Kalinni Gorzkis musicdenotat...@gmail.comwrote: Can I distribute and modify the Perl 6 specification documents and test suite under which conditions? If not, I propose that they should be distributed under the Artistic License 2.0. That is an excellent question. I've checked the git sources, and from what I can see, the examples repository is under AL 2.0, as is STD.pm, but the synopses are not. I'm unsure as to whether this is an artifact of how things got added to the git repository or not, perhaps someone else can clarify. -- Jan
Re: Licensing: Perl 6 specification and test suite
On Tue, Nov 5, 2013 at 3:36 PM, Moritz Lenz mor...@faui2k3.org wrote: I have no idea if the AL2 is well suited for sets of documents, as the specification is. I'll leave that decision to Larry. To anyone in doubt: please note that I'm not Larry, I'm not an authority, I'm just opinionated. :) Considering that the specification is sortof actually a language specification, I think there should at least be some terms regarding how this should apply. Forking the documentation, or creating derivative works, shouldn't be a problem, as long as it doesn't change the specification in itself, and thereby create confusion regarding what the Perl 6 specification is. Technically speaking, there shouldn't be a problem with pulling the Git repository, making changes, and proposing that these changes should be merged with the central Git repository for the specification – that is, after all, an approximation of how the specification is changed and developed by the community. -- Jan
Re: Underscores v Hyphens (Was: [perl6/specs] a7cfe0: [S32] backtraces overhaul)
On Wed, Aug 24, 2011 at 11:19, Smylers smyl...@stripey.com wrote: Could we have underscores and hyphens mean the same thing? That is, Perl 6 always interprets illo-figut and illo_figut as being the same identifier (both for its own identifiers and those minted in programs), with programmers able to use either separator on a whim? That would seem to be the most human-friendly approach. I'm not so sure about the human-friendliness, but it certainly would be more obfuscation-friendly and less editor- and search-friendly. -- Jan
Re: [perl6/specs] 761178: remove some some duplicate words words
On Wed, Sep 8, 2010 at 07:41, Jason Switzer jswit...@gmail.com wrote: I'm surprised anyone actually ever read the diff part of the message. I would prefer to never see that feature again. This has a link to the commit, which has a much better diff viewer than plaintext email (hello? 1997 called, they want their change notices back). In some respects, I want 1997 back, since people learned how to work efficiently rather than not. ;) I both like and can read the contextual diffs just fine. It links to the actual change and even highlights the changes. Yes, it's all very nice, and nothing that needs to go away. Having it both ways can't hurt. Now I'll actually take a moment to sift through the changes. I vote to never see those diff emails ever again. In fact, if the diffs are brought back, I'll just subscribe to the commit feed and skip the email notice all together. That seems like a reasonable solution for you, then. -- Jan
Radix (base) conversion
Hi. I was fiddling about with a small example of how nice radix adverbials are for conversion: my $x = 6*9; say :13($x); rakudo: 69 ($x = 54 in base 10, but 54 in base 13 is 69 in base 10.) Strangely enough, I cannot find a way — in the spec — of both treating a number as something in base 13 as well as displaying it in base 13. sprintf() has formats for binary, octal and hexadecimal, but there appears no way to use an arbitrary base. As a clarification, see this example form bc(1): obase=13 print What do you get when you multiply six by nine? ; 6*9 What do you get when you multiply six by nine? 42 obase=10 Am I missing something? It is also somewhat confusing that while $x stores the result of the multiplication of 6*9, the adverbial radix conversion treats the variable as a literal and no longer a value. -- Jan
Re: Proposal for a new Temporal time-measurement paradigm
On Sun, Apr 25, 2010 at 00:46, Darren Duncan dar...@darrenduncan.netwrote: 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(). I think you're taking minimalism at least two steps too far; your bikeshed has become too small to contain a bike. A standard library can and should provide reasonable functionality. We _know_ that the North-Western civilizations' common understanding of time (calendars and time-of-day), as defined in various standards, are fundamental to how we handle a lot of programming problems. I don't see any good reason not to provide the basic functionality needed, and especially not when it's already there. -- Jan
Re: Gripes about Pod6 (S26)
On Fri, Feb 12, 2010 at 14:57, Carl Mäsak cma...@gmail.com wrote: Again, thanks for your efforts so far. The discussions over the years have shown at least me what an ungrateful task it is to be redesigning Pod for Perl 6. Yep, thanks, Damian! Fortunately, doing _whatever_ for Perl 6 seems to be mostly a grateful task, AFAICT. -- Jan
Re: One-pass parsing and forward type references
On Mon, Feb 1, 2010 at 17:46, Patrick R. Michaud pmich...@pobox.com wrote:
There's a third way:
class B { ... }# introduce B as a class name without definition
class A { sub foo { B::bar } }
class B { sub bar { A::foo } }
The first line is a literal ... in the body of the class -- it
indicates that we're only declaring the name as being a type,
and that something else will fill in the details later.
It seems to me that this doesn't really solve the problems that will occur
when people start making packages independently of eachother.
Of course it can be solved by submitting patches to the other developer's
code, but it seems inelegant.
--
Jan
Re: String to Regex
On Sun, Jan 3, 2010 at 8:30 PM, Moritz Lenz mor...@faui2k3.org wrote:
But since $input can contain closures, arbitrary code can be executed.
I'd like to propose a way to compile a string to a regex which doesn't
allow code execution.
So would I.
I would also like it to be the default behaviour, since this is a place
foot on Bouncing Betty thing. :)
my $rx = Regex.new(:string('abc|d'), :safe);
I think this is too complicated for something which is likely to be the most
frequent use of regex strings.
It would be better to enforce the more complicated syntax for the less
frequent cases.
(All IMO, of course.)
--
Jan
Re: r28523 - docs/Perl6/Spec/S32-setting-library
On Thu, Oct 1, 2009 at 10:15 PM, Moritz Lenz mor...@faui2k3.org wrote: What's the 0th root of a number, then? It would be a number $y for which $y ** 0 == $x, which can only be fulfilled for $x == 1. So in the general cases the answer to the question root($x, 0) is nonsense, which is best mapped to NaN. That doesn't make sense. The answer is 1, not NaN. Think about it for a while: mathematically speaking, we would expect the 0th root of a number to be 1. By enforcing NaN for a list of roots, math code suddenly has to include a set of extraneous tests in order to coerce the result to a list of ones. And that _is_ nonsensical. -- Jan
Re: r28523 - docs/Perl6/Spec/S32-setting-library
On Thu, Oct 1, 2009 at 11:03 PM, Minimiscience minimiscie...@gmail.comwrote: On Oct 1, 2009, at 4:43 PM, Jan Ingvoldstad wrote: On Thu, Oct 1, 2009 at 10:15 PM, Moritz Lenz mor...@faui2k3.org wrote: What's the 0th root of a number, then? It would be a number $y for which $y ** 0 == $x, which can only be fulfilled for $x == 1. So in the general cases the answer to the question root($x, 0) is nonsense, which is best mapped to NaN. That doesn't make sense. The answer is 1, not NaN. Think about it for a while: mathematically speaking, we would expect the 0th root of a number to be 1. I think you're confusing root with power. Any number raised to the zeroth power is one (except, arguably, zero itself), but, given a number $num, its zeroth root is a number $base such that $base ** 0 == $num, which, as stated above, only makes sense when $num == 1. You're of course right, that was an amazing brainfart. I blame society. -- Jan
Re: Custom object constructors
On Thu, Aug 20, 2009 at 10:44 PM, Kevan Benson kben...@a-1networks.comwrote: That said, I submit that it's a very confusing part of the language as defined currently, and I haven't seen a very thorough explanation of the purpose of each method in the chain the instantiates a new object. S12 touches upon them slightly, but not in enough detail that I was able to work out where I should be adding code to appropriately make alternate constructors. Now that you apparently understand it, do you have a suggestion on how S12 might be phrased differently? I must admit that I don't quite grasp the concepts here yet, so an alternate wording might help others as well. Thanks for bringing the question up. -- Jan
Re: [perl #64566] @a[1..*] adds trailing undef value
On Wed, Aug 19, 2009 at 1:54 PM, Moritz Lenz via RT
perl6-bugs-follo...@perl.org wrote:
Since the discussion came up on #perl6 if this is really the expected
behaviour, S09 says:
As the end-point of a range, a lone whatever means to the maximum
specified index (if fixed indices were defined):
say @calendar[5..*]; # Same as: say @calendar[5..11]
say @calendar{Jun..*};# Same as: say @calendar{Jun..Dec}
or to the largest allocated index (if there are no fixed indices):
say @data[1..*]; # Same as: say @results[1..5]
It doesn't mention how the postcifcumfix:[ ] is supposed to introspect
those to find out if the WhateverCode object constructed by 1..* needs
to receive self.elems or self.elems-1 as an argument.
Which is why I CC: p6l to get some ideas or clarification, and if we
want to maintain this DWIMmy but not very consistent behaviour.
I like it the way S09 says it.
But there is a problem with sparse arrays, isn't there?
S32/Containers (S32-array) says this about elems:
our Int method elems (@array: ) is export
Returns the length of the array counted in elements. (Sparse array types
should return the actual number of elements, not the distance between the
maximum and minimum elements.)
For arrays, it appears that using end is more relevant:
our Any method end (@array: ) is export
Returns the final subscript of the first dimension; for a one-dimensional
array this simply the index of the final element. For fixed dimensions this
is the declared maximum subscript. For non-fixed dimensions (undeclared or
explicitly declared with *), the index of the actual last element is used.
Does that seem usable to y'all?
--
Jan
Re: r28017 - in docs/Perl6/Spec: . S32-setting-library
On Tue, Aug 18, 2009 at 10:01 AM, Nicholas Clarkn...@ccl4.org wrote:
On Tue, Aug 18, 2009 at 09:24:08AM +0200, pugs-comm...@feather.perl6.nl wrote:
+=head3 Default constraints
+
+The default p{} only allows / as separator and does not allow path
elements
+to contain
+characters that won't work on modern Windows and Unix like \ / ? % * : |
,
+etc. The reason for this is that portable paths are the default. If
+platform/filesystem specific behavior is really needed it should be shown in
+the code by applying different sets of constraints (see below).
Perl 5 runs on (at least) VMS and VOS too. So, if Perl 6 is to adopt a policy
of enforced portable filenames by default, it should (at least) also exclude
- as the first character, and forbid more than one . in a filename.
And, as I mentioned in an earlier post during the discussion, the
restrictions for Windows are numerous:
http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx
Enforcing truly portable filenames is unrealistic, I think, but
having a POSIX-checking default is a good thing.
--
Jan
Re: r28017 - in docs/Perl6/Spec: . S32-setting-library
On Tue, Aug 18, 2009 at 10:58 AM, Nicholas Clarkn...@ccl4.org wrote: Oh gosh yes. I forgot. AUX.TXT And all the the other CP/M device file names, with our without extensions... [And of course, IIRC, DOS filenames can't be more than 64 characters. Which means that your code thinks that it knows what it's doing by stripping of the drive letter and allowing 62 in the rest of the pathname. Except that I remember university servers with drives UX: and UY:, which always made me wonder if there was a buffer overflow waiting to happen...] Yes, lovely, isn't it? What does POSIX enforce? ASCII NUL terminated, multiple adjacent / characters fold to 1, except at the start, where // is special, but /// etc aren't? And anything else goes? POSIX doesn't enforce much. I used our friendly do-no-evil empire, and found this: http://www.dwheeler.com/essays/fixing-unix-linux-filenames.html#standards And particularly from «2.2. Standards permit the exclusion of bad filenames»: «I then examined the Portable Filename Character Set, defined in 3.276 (“Portable Filename Character Set”); this turns out to be just A-Z, a-z, 0-9, period, underscore, and hyphen (aka the dash character). So it’s perfectly okay for a POSIX system to reject a non-portable filename due to it having “odd” characters or a leading hyphen.» -- Jan
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! It may seem cool, but I don't like secondary effects like that. They break the principle of least surprise. -- Jan
Re: r28017 - in docs/Perl6/Spec: . S32-setting-library
On Tue, Aug 18, 2009 at 12:54 PM, Troels Liebe Bentsent...@rapanden.dk wrote: My idea with portable by default was only portability for modern Unix and modern Windows. So DOS and VMS limitations would not apply. The problem of enforcing truly portable filenames is that the files names get too restrictive and for most applications targeting 98% of systems out there would be enough. That's a decent enough point, but it may be unwise to ignore legacy systems that where Perl 5 is in common use, unless we want to shed that userbase. (Mark this down as a I don't know, and I don't have a stake in it, but…) With modern Unix/Windows I'm thinking about systems that support and use UCS2 or UTF8 and where . or other common characters does not have special meaning for the filesystem. We also need to keep in mind the Unicode problems between certain unixy platforms (i.e. MacOS X vs. most if not all the rest). If I recall correctly, the internal Unicode format chosen for Perl 6 is incompatible with MacOS X, because MacOS X implemented Unicode support at a time when the standard as we know it today wasn't finalized. This has bearing on filenames, and MacOS X isn't a small enough platform that it can simply be ignored, either. Besides that, a simple check on Unix for what the locale is set to might also be nice, so we don't write UTF8 files on a filesystem where the rest for the files are in Latin1. The locale doesn't say what format the filenames are on the filesystem, though, merely the current user's language preferences may be. That can't really be trusted, at least not for filename comparison purposes. But I agree that it's sensible to default to the locale's settings regarding character encoding. -- Jan
Re: $*CWD and chdir()
On Tue, Aug 18, 2009 at 1:02 PM, David Greendavid.gr...@telus.net wrote: On 2009-Aug-18, at 3:12 am, Jan Ingvoldstad wrote: It may seem cool, but I don't like secondary effects like that. They break the principle of least surprise. It doesn't seem that surprising to me, especially after seeing the docs the first time. Are there environments where you can set a variable like $*CWD and it doesn't do something like chdir? Yes, and that's normal and expected behaviour. viking...@shell:~$ uname -a Linux shell 2.4.37.5 #1 Sun Aug 16 12:47:03 CEST 2009 i686 unknown unknown GNU/Linux viking...@shell:~$ bash --version GNU bash, version 2.05b.0(1)-release (i486-slackware-linux-gnu) Copyright (C) 2002 Free Software Foundation, Inc. viking...@shell:~$ mkdir test viking...@shell:~$ touch test/testfile viking...@shell:~$ cd test viking...@shell:~/test$ ls testfile viking...@shell:~/test$ pwd /home/1/v/vikingmud/test viking...@shell:~/test$ echo $PWD /home/1/v/vikingmud/test viking...@shell:~/test$ PWD=foo/notreallyadirectory viking...@shell:foo/notreallyadirectory$ ls testfile viking...@shell:foo/notreallyadirectory$ pwd /home/1/v/vikingmud/test viking...@shell:foo/notreallyadirectory$ echo $PWD foo/notreallyadirectory j...@krakas ~ uname -a Darwin krakas.ELIDED 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386 j...@krakas ~ bash --version GNU bash, version 3.2.17(1)-release (i386-apple-darwin9.0) Copyright (C) 2005 Free Software Foundation, Inc. j...@krakas ~ mkdir test j...@krakas ~ touch test/testfile j...@krakas ~ cd test j...@krakas ~/test ls testfile j...@krakas ~/test pwd /Users/jani/test j...@krakas ~/test echo $PWD /Users/jani/test j...@krakas ~/test PWD=foo/notreallyadirectory j...@krakas foo/notreallyadirectory ls testfile j...@krakas foo/notreallyadirectory pwd /Users/jani/test j...@krakas foo/notreallyadirectory echo $PWD foo/notreallyadirectory -- Jan
Re: $*CWD and chdir()
On Tue, Aug 18, 2009 at 2:33 PM, David Green david.gr...@telus.net wrote:
Huh. Thank you, I did not know that. It makes sense (in that I
understand what's going on now that I see it, and indeed it seems almost
obvious), but I certainly couldn't call it expected because I didn't. And
I can guarantee I'm not the only one; in fact, I have no qualms about
classifying that as a bug.
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.
The environment variables are generally just descriptive variables. If you
mess with them, they may no longer have bearing on reality. That is also
expected behaviour; if you shoot yourself in the foot, you may get hurt.
It can also be said to be expected behaviour because that's the way it has
been behaving for maybe as long as environment variables have been in
existence in Unix systems.
Here's another example of something that, if I understand you correctly, you
find as unexpected behaviour:
j...@krakas ~ USER=root
j...@krakas ~ echo $USER
root
# Am i root now?
j...@krakas ~ whoami
jani
# I'm not root.
While there have been programs assuming that %ENV{USER} indicates who the
current user is, and adjusting their behaviour based on that, such behaviour
has generally been classified as a security vulnerability, and rightly so.
--
Jan
Re: Filename literals
On Tue, Aug 18, 2009 at 3:20 PM, Carl Mäsak cma...@gmail.com wrote: Let's make a solid ground to stand on; something so stable that it works uphill and underwater. People with expertise and tuits will write the facilitating modules. PerlJam To quote Kernighan and Pike: Simplicity. Clarity. Generality. moritz_ I agree. Matt-W magic can always be added with module goodness I agree with this principle. The discussion has been (and probably still will be) fruitful anyway, if only in illuminating the challenges with multi-platform and multi-filesystem support, some of the things we need to consider for that and how. -- Jan
Re: $*CWD and chdir()
On Tue, Aug 18, 2009 at 3:52 PM, Mark J. Reed markjr...@gmail.com wrote:
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.
I disagree, and I think I've explained why, and perhaps we won't get much
further.
But see below.
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.
I'm not sure what you mean by a shell-maintained variable.
As for $UID being read-only, that's a bashism. There's nothing inherent
about $UID that makes it read-only.
In a POSIX shell, you get this:
$ ksh --version
version sh (ATT Research) 1993-12-28 s+
$ echo $UID $USER
501 jani
$ USER=root
$ UID=1000
$ echo $UID $USER
1000 root
csh is no different:
j...@krakas ~ csh
[krakas:~] root% echo $USER
root
[krakas:~] root% set USER=foo
[krakas:~] root% echo $USER
foo
[krakas:~] root% echo $UID
501
[krakas:~] root% set UID=1000
[krakas:~] root% echo $UID
1000
bash in POSIX mode agrees:
j...@krakas ~ bash --posix
j...@krakas ~ echo $UID
501
j...@krakas ~ UID=1000
j...@krakas ~ echo $UID
1000
Even Perl 5 lets me change it:
j...@krakas ~ perl --version|grep v5
This is perl, v5.8.9 built for darwin-2level
j...@krakas ~ perl -e 'print $ENV{UID}\n; $ENV{UID}=1000; print
$ENV{UID}\n;'
501
1000
--
Jan
Re: Filename literals
I'll just butt in here and say that while the URI format is nice for alternate schemes, it is not nice for accessing files. The general case in most programming languages is to assume that a non-URI file name is local, specifying file://wherever/whatever/filename is unnecessary additional syntax. Also, perhaps only URLs should be permitted; they do after all specify a location. I'm unsure whether this should be part of a central specification to Perl 6 or part of a module. I think I like Hinrik's original proposal. Oh, and regarding file names in Windows, this document should be a pretty definitive guide: http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx -- Jan
