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
Re: r28017 - in docs/Perl6/Spec: . S32-setting-library
On Tue, Aug 18, 2009 at 10:01 AM, Nicholas Clark 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 Clark 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, , , and (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 Green 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: S26 - The Next Generation
On Tue, Aug 18, 2009 at 3:47 AM, David Green wrote: > On 2009-Aug-17, at 12:27 pm, Moritz Lenz wrote: >> >> However it seems we have to pay a price: each act of rendering a Pod >> file actually means executing the program that's being documented (at >> least the BEGIN blocks and other stuff that happens at compile time), >> with all the security risks implied. So we'll need a *very* good >> sandbox. Is that worth it? > > Yes. Why is it worth it? In general, executable documentation is a bad thing. It's been shown to be a bad thing many times over. If we absolutely must have some sort of executable documentation, then if I could, I would insist that it wouldn't be a feature complete language. That is: absolutely no IO in the language, no way of executing code that's foreign to the doc, and so on. -- Jan
Re: r28017 - in docs/Perl6/Spec: . S32-setting-library
On Tue, Aug 18, 2009 at 12:54 PM, Troels Liebe Bentsen 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 Green 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 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 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. > > To quote Kernighan and Pike: Simplicity. Clarity. Generality. > I agree. > 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 wrote:
> On Tue, Aug 18, 2009 at 9:26 AM, Jan Ingvoldstad
> 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 (AT&T 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: [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: Custom object constructors
On Thu, Aug 20, 2009 at 10:44 PM, Kevan Benson wrote: > > > 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: r28523 - docs/Perl6/Spec/S32-setting-library
On Thu, Oct 1, 2009 at 10:15 PM, Moritz Lenz 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 wrote: > On Oct 1, 2009, at 4:43 PM, Jan Ingvoldstad wrote: > >> On Thu, Oct 1, 2009 at 10:15 PM, Moritz Lenz 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: String to Regex
On Sun, Jan 3, 2010 at 8:30 PM, Moritz Lenz 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: One-pass parsing and forward type references
On Mon, Feb 1, 2010 at 17:46, Patrick R. Michaud 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: Gripes about Pod6 (S26)
On Fri, Feb 12, 2010 at 14:57, Carl Mäsak 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: Proposal for a new Temporal time-measurement paradigm
On Sun, Apr 25, 2010 at 00:46, Darren Duncan wrote: > 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: Proposal for a new Temporal time-measurement paradigm
On Sun, Apr 25, 2010 at 02:31, Doug McNutt wrote: > Agree on a format for storing fractional atomic seconds. There are > proposals for two word integers with one of them being micro or nano seconds > and the other seconds. I prefer IEEE floating point with atomic seconds as > the unit of measure. That's a bit like MS Excel where days are used for the > unit. The Excel scheme is not as clean because it assumes 86400 seconds in a > day and it's a day off between what it thinks was Feb 29, 1900 and its epoch > at the start of 1900. > The Excel scheme is nowhere as clean as you think it is, because there is no _single_ Excel scheme. There are two epochs, one is the buggy 1900 epoch, the other is the 1904 epoch. In addition, there's an "extended" date format, which doesn't handle the Julian -> Gregorian transition very well. You'd be hard pressed to find a worse example of how to handle dates than Excel. -- 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: [perl6/specs] 761178: remove some some duplicate words words
On Wed, Sep 8, 2010 at 07:41, Jason Switzer 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
Re: Underscores v Hyphens (Was: [perl6/specs] a7cfe0: [S32] backtraces overhaul)
On Wed, Aug 24, 2011 at 11:19, Smylers 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: Licensing: Perl 6 specification and test suite
On Tue, Nov 5, 2013 at 3:09 PM, Kalinni Gorzkis wrote: > 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 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: Language design
On Tue, Jul 14, 2015 at 12:04 AM, Michael Zedeler 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
