Re: The last shall be last
John Williams writes: On Sun, 5 Sep 2004, Matt Diephouse wrote: Don't say -1st is the first from last. If last is the opposite of first, I would expect 1st to mean first from first, which would mean the second. Say first from the end. It matches up with perl5 C$array[-1] and is a workable interpretation of negative ordinals. So I could think that way too. @ary[ 1st .. -1st ]# hmm... But it doesn't match up. In Perl 5 the first element is indexed with zero, not 1st, and the indices wrap round -- which is convenient in some circumstances, especially when representing grids of things. Using 1st and -1st means that there's a 'gap': the wrapping-round misses a number out, which then has to be dealt with as special case. (But personally I'm quite happy with zero-based arrays, so as long as -1 continues to work for those I'm not too bothered what happens with other cases.) Smylers
Re: What Requires Core Support (app packaging)
Simon Cozens wrote: For heaven's sake. Have you even *seen* the Perl 5 internals? If you don't trust things which are self-declared scary hackery to be stable, you probably shouldn't be using Perl until Perl 6 comes out. And probably not until then. Um, on a somewhat unrelated note, having tried to get a department of mine to switch over to perl from csh and REXX of all things, I have co-workers I hope never see this. Look, we're not going to agree on this. Should we just drop the subject? I know I've seen more than I wanted to. Dan
Re: What Requires Core Support (app packaging)
[EMAIL PROTECTED] (Dan Hursh) writes: Um, on a somewhat unrelated note, having tried to get a department of mine to switch over to perl from csh and REXX of all things, I have co-workers I hope never see this. They may need to write their own operating system if they want to avoid the dodgy software rot entirely. :) -- If you give a man a fire, he'll be warm for a day. If you set a man on fire, he'll be warm for the rest of his life.
Re: What Requires Core Support (app packaging)
John Siracusa wrote: 1. The special dir of files (SDoF). Ignoring, for now, the argument for a standard way to do this, all the core needs to do to bootstrap an entire ecosystem of app packagers is support some standard starting point. Maybe it's a file names main.pl inside a *.pmx dir, or whatever. But there needs to be something, otherwise every SDoF system will have to bootstrap itself using some executable other than perl (e.g. PAR/parl) I think that's much less elegant. We can, and I think should, write a one-paragraph documentation, one-screenful implementation of this that's in perl core: As a special case, if the filename argument to perl is a directory, and the directory contains a file named main.pl, then the directory is prepended to @*INC, and main.pl is run. 2. The single-file, packaged version of the SDoF (SDoF Package). Too boostrap this, the core needs to know what to make of such a file. Maybe nothing needs to be done if a #! line and some plain old perl code at the start of the file is sufficient. But something tells me that a bit more is needed to unzip/untar/whatever the rest of the stuff in the package file before execution. Trying to inline pure perl unzip/untar at the header of each SDoF Package file doesn't seem elegant to me, but it could be technically possible to bootstrap that way using only the perl 6 executable. We can support this in several ways. We can say that core perl also supports the above if the file is a gzipped tar file, and contains a main.pl (including adding the archive to @*INC). We can ship a script with perl, and have the user use the #! mechinisim to run it, with the actual file being specified to be a #! line, ending with some combination of CR and LF, then a tarball. This is probably a lot more work for perl core, but would be quite nice. 3. The single-file, platform independent, non-source executable (P6exe). This is bytecode or some other platform neutral representation of the SDoF. I just don't see how to do this at all without core support. Parrot supports this well enough that it will be hard for perl6 to mess it up. Parrot, indeed, already supports... 4. The single-file, platform dependent, machine language executable (realexe). This is a plain old executable, that does not particularly indicate it was generated by a scripting language. It requires no odd handing vs a normal executable for the target platform, because it /is/ a normal executable for the target platform. It may be staticly or dynamicly linked to the necessary libraries. Based on the little I know of JAR, the three features listed above seem to extend a bit beyond JAR in both directions, and each either require or should have some amount of core support, even if only to bootstrap community implementations. Mostly, though, they require fairly minimal support from the core. Only 1 requires Cperl support, and that support is very minimal. The others require standard-library support, but all the major bits are things that should already be in the standard library (because a front-end to C6PAN should come with, and that means extracting some sort of .tar.gz files -- calling out to external utilities doesn't cut it too often). -=- James Mastros PS -- Unreatedly, why, oh why, do people insist on an apostrophe in 80's and postfix:'th? It's 80s and postfix:th!
Re: What Requires Core Support (app packaging)
On Tue, 7 Sep 2004, James Mastros wrote: PS -- Unreatedly, why, oh why, do people insist on an apostrophe in 80's Maybe in the 80's is like at the Jones's. Not that I care, mind you. and postfix:'th? It's 80s and postfix:th! Probably to help separate the term from the postfix operator. $foo = 3; @array[ $foo'th ];
Re: What Requires Core Support (app packaging)
John Williams skribis 2004-09-07 11:37 (-0600): and postfix:'th? It's 80s and postfix:th! Probably to help separate the term from the postfix operator. @array[ $foo'th ]; Maybe what I'm saying now is a really bad idea, because it doesn't make sense, but can't we just have an adverb that changes an integer into an ordinal? 4 :th $foo :th Obviously, the : should be optional for literal integers: 4th 3th Juerd
more ordinal discussion
On Tue, 7 Sep 2004, Juerd wrote: John Williams skribis 2004-09-07 11:37 (-0600): and postfix:'th? It's 80s and postfix:th! Probably to help separate the term from the postfix operator. @array[ $foo'th ]; Maybe what I'm saying now is a really bad idea, because it doesn't make sense, but can't we just have an adverb that changes an integer into an ordinal? 4 :th $foo :th No. Adverbs modify verbs (operators or functions), not terms like 4 or $foo. Obviously, the : should be optional for literal integers: 4th 3th Yes, because 3 and th parse as different tokens.
Re: What Requires Core Support (app packaging)
James Mastros wrote: We can, and I think should, write a one-paragraph documentation, one-screenful implementation of this that's in perl core: As a special case, if the filename argument to perl is a directory, and the directory contains a file named main.pl, then the directory is prepended to @*INC, and main.pl is run. Only [this] requires Cperl support, and that support is very minimal. I Agree. This is much simpler than what i came up during the recent discussion about app packaging: I touhght that it be nice to let module writers somehow associate their module with a file extention. This could also be useful for Modules that change the standart Perl 6 Syntax. The module that contains these macros could associate itself with a extension (e.g. *.klingonpl / *.kpl) In that way, its immediately clear that some macros are at work. Maybe this helps in other cases aswell, where the header is somehow predefined and its not possible to add some shebang magic or a use- clause to indicate some special treatement... Would such a feature be useful at all ? Thomas Seiler
Re: The last shall be last
Smylers wrote: (But personally I'm quite happy with zero-based arrays, so as long as -1 continues to work for those I'm not too bothered what happens with other cases.) This is an interesting point: can the perl optimizer be made to treat 0-based contiguous lists in the same way that perl 5 arrays are handled (including the streamlined code generation), while arrays with non-standard shapes get more code-heavy-yet-robust capabilities? While I'd like it if the ordinals scheme could be matched up one-to-one with the standard shape scheme, I could live without this if other factors prove to be more attractive. = Jonathan Dataweaver Lang ___ Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com
Re: Reverse .. operator
Hmm, this would suggest that in P6 the comment that unlike ++,
the -- operator is not magical should no longer apply.
On Fri, Sep 03, 2004 at 08:09:23AM -0400, Joe Gottman wrote:
-Original Message-
From: Larry Wall [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 02, 2004 8:41 PM
To: Perl6
Subject: Re: Reverse .. operator
On Thu, Sep 02, 2004 at 08:34:22PM -0400, Joe Gottman wrote:
: Is there similar shorthand to set @foo = (5, 3, 3, 2, 1) ? I know you
can
: go
:
: @foo = reverse (1 ..5);
:
: but this has the major disadvantage that it cannot be evaluated lazily;
: reverse has to see the entire list before it can emit the first element
of
: the reversed list.
I don't see any reason why it can't be evaluated lazily. The .. produces
a range object that gets shoved into the lazy list that gets bound to
the slurp array of reverse(). If you pop that, there's no reason it
couldn't go out and ask the end of the lazy list for its last element.
Just have to make .. objects smart enough to deal off either end of
the deck.
I get it. One way to implement this would to give the .. object a
.reverse member iterator that lazily iterates from right to left, and have
the reverse subroutine call the .reverse member on the list that was passed
to it (if this member exists). The advantage of this is that it can be
extended for other types, or even to arrays returned from functions. For
instance,
multi sub grep(Code $f, [EMAIL PROTECTED] does reverse) returns (Array does
reverse {grep $f, @array.reverse;}) #reverse input
multi sub map(Code $f, [EMAIL PROTECTED] does reverse) returns (Array does reverse
{map {reverse $f($_)} @array.reverse;}) #reverse input and result of each
call to $f
If it isn't possible to overload a multi sub on a .does property, we can
achieve the same effect by creating a ReversableArray class that inherits
from Array and overloading on that.
Joe Gottman
--
Re: more ordinal discussion
Juerd wrote: John Williams wrote: 4 :th $foo :th No. Adverbs modify verbs (operators or functions), not terms like 4 or $foo. Then perhaps a method? Number::th? 4.th $foo.th Again, with a bit of magic where the dot is optional when the object in question is an integer literal: 4th =:= 4.th - and probably with special synonyms for th when the literal is any of (1 or -1, 2 or -2, 3 or -3) - Number::st, Number::nd, and Number::rd, respectively. Mind you, these wouldn't _really_ be methods, since they would only be valid when used within the arguments of a list's postcircumfix:[] operator. And while I like the notion that 0th has a valid meaning and that its meaning fits into a scheme that parallels the wraparound behavior of standard lists (i.e., perl 5's 0-based contiguous lists), I can see the arguments for both 1st referring to the first element and -1st referring to the last argument (which, if both are accepted, would leave 0th out in the cold). Of the two, 1st =:= first is the more compelling argument; and if one of the two arguments has to be rejected, I'd rather it be the -1st =:= last one. So we've come up with two mutually exclusive schemes for ordinal indices, depending on which of 0th or -1st refers to the last element of a list. There's a third option where the last element isn't given an ordinal at all; but I doubt that anyone would prefer this, even as a second choice. The pros and cons of each approach have now been discussed at length, and it appears that we've reached an impasse of sorts. So let me just summarize the positions, and ask for Larry's thoughts on the issue. 0th =:= last: Lists using this type of ordinals would behave exactly like a perl 5 list, except that [$n.th] would correspond to [$n-1] rather than to [$n]. You'd read non-positive ordinals as offsets from the last element, which isn't quite symmetric with the way that positive ordinals would be read. -1st =:= last: This type of ordinal index maintains a symmetry between positive and negative indices, treating the sign of the ordinal as an indication of which end of the list to start at. C0th would be undefined, which makes some intuitive sense; but you'd have to watch out for such things as (1 + $n).th, which would throw an error if $n was -1, and would work differently for $n -1 and $n -1. Either way, I'd be in favor of being able to use Clast as a synonym for the ordinal corresponding to the last element in a list (and, for symmetry, Cfirst as a synonym for 1.th or 1.st); it's at worst one character longer than the ordinal in question, and its meaning is clear and unambiguous. The only problem with it is when you're dealing with sparse arrays: [last - 1] won't neccessarily do what you want it to, depending on what you want it to do. To avoid confusion in the discussion, let's look at the other end (where we're pretty much agreed on the meaning of 1st and first): if we want to look at the next existing element, we can say (1 + 1).th; if we want to look at the element whose index is one higher than the first index, we can say 1.st + 1. With Cfirst, we can do the latter but not the former. = Jonathan Dataweaver Lang ___ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush
Re: Synopsis 9 draft 1
On Fri, 2004-09-03 at 20:08, Larry Wall wrote: Arrays with explicit ranges don't use the minus notation to count from the end. We probably need to come up with some other notation for the beginning and end indexes. But it'd be nice if that were a little shorter than: @ints.shape[0].beg @ints.shape[0].end Suggestions? Maybe we just need integers with whence properties... :-) Actually, what you had in Perl 5, was essentially: $x[-1] == reverse(@x)[0] In Perl 6, this is actually workable because of the lazy evaluation of reverse, so if you simply re-name reverse to rev as a list method for brevity: my int @ints is shape(-10..10); @ints.rev[-10]; # assuming that @x.rev retains shape And as someone pointed out: @ints.abs.rev[0] if you had an abs that strips away shape. All that being said, I think that this (shape) is a dangerous idea at best. If used, it should probably specify a length ONLY: my int @ints is shape(10) and in that light, I think it would best be renamed to length or extent. Specifying the origin should be left to $[... that is, left out. -- 781-324-3772 [EMAIL PROTECTED] http://www.ajs.com/~ajs
Re: more ordinal discussion
Jonathan Lang skribis 2004-09-07 14:12 (-0700):
Again, with a bit of magic where the dot is optional when the object in
question is an integer literal: 4th =:= 4.th - and probably with special
synonyms for th when the literal is any of (1 or -1, 2 or -2, 3 or -3) -
Number::st, Number::nd, and Number::rd, respectively. Mind you, these
wouldn't _really_ be methods, since they would only be valid when used
within the arguments of a list's postcircumfix:[] operator.
Why would they be invalid outside? Ordinals as real possible values make
sense to me.
Say, you have an array @foo, that starts counting at 5, and @bar that
starts counting at 10. Both have 5 elements. Wouldn't this be handy?
for 1 .. 5 {
... @foo[.th] ... @bar[.th] ...
}
# or maybe even:
for 1st .. 5th {
... @foo[$_] ... @bar[$_] ...
}
$nth = 1st;
say @foo.resolve $nth; # 5 # could be useful
# In normal situations, one would of course use:
# for @foo Y @bar - $foo, $bar { ... }
# but that is besides the point.
So we've come up with two mutually exclusive schemes for ordinal indices,
depending on which of 0th or -1st refers to the last element of a list.
There's a third option where the last element isn't given an ordinal at
all; but I doubt that anyone would prefer this, even as a second choice.
I used to think I wanted 0th to be the 0th (one before the first),
because 1nd + $foo could logically only mean (1 + $foo)th. However, if
th is a method of Number, you can just use literally (0 + $foo).th, and
there is no need for a 0th in this anymore.
Still, though -1st seems more logically to me, especially since +1st
isn't 0-based either.
if we want to look at the next existing element, we can say (1 +
1).th; if we want to look at the element whose index is one higher
than the first index, we can say 1.st + 1.
I read this three times, but don't get it. Can you please explain what
the difference is between the element after the 1st and the element
whoso index is one higher than the 1st's?
Juerd
Re: What Requires Core Support (app packaging)
On Tue, Sep 07, 2004 at 06:07:24PM +0200, James Mastros wrote: 4. The single-file, platform dependent, machine language executable (realexe). This is a plain old executable, that does not particularly indicate it was generated by a scripting language. It requires no odd handing vs a normal executable for the target platform, because it /is/ a normal executable for the target platform. It may be staticly or dynamicly linked to the necessary libraries. Which parrot can already do. (Or at least could, but I don't think that anyone's been checking on it recently) This work was completed as a result of a TPF grant that Daniel Grunblatt received last year: http://www.perlfoundation.org/gc/grants/2003_q2.html Mostly, though, they require fairly minimal support from the core. Only 1 requires Cperl support, and that support is very minimal. The and as you say all this really isn't about perl 6 the language. Nicholas Clark
Re: Progressively Overhauling Documentation
Mark Overmeer [EMAIL PROTECTED] writes:
Oops, someone starts the holy war (again). Wether you put the docs
in begin or end of the file, or intermixed with the code has a lot
to do with your personal background.
Sorry for the late reply, but I can't let this stand without further
elaboration: intermixing the POD with the functions is something some
of us would really like to do, but in Perl5 the evil stupid whitespace
rules of POD make it impracticable, because it horks over the
indentation (and thus the legibility) of the whole program.
If we fix nothing else about POD in Perl6, it is *imperative* that it
become possible to indent the POD to at least the same level as the
code. Otherwise POD will never become a viable substitute for the
extensive comment blocks it ought to displace.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: Synopsis 9 draft 1
On Tue, Sep 07, 2004 at 10:34:33PM -0400, John Macdonald wrote: : If a int1 (or int2 or nybble or other sub-addressable sized : value) is being referred to, a similar issue arises since most : machines these days have byte addressing, but do not have bit : addressing. If you can't refer directly to it, the value will : have to be extracted and re-inserted to provide is rw access. Well, sure. Is this any more of a problem than vec() in Perl 5? Larry
Re: more ordinal discussion
Juerd wrote: Jonathan Lang skribis 2004-09-07 14:12 (-0700): if we want to look at the next existing element, we can say (1 + 1).th; if we want to look at the element whose index is one higher than the first index, we can say 1.st + 1. I read this three times, but don't get it. Can you please explain what the difference is between the element after the 1st and the element whoso index is one higher than the 1st's? I think (correct me) what he's getting at here is a sparse array 1=a, 3=b, 4=c where 2nd is 'b' (the second item) but 1st+1 is undefined (there is no index 2). I don't know how well that scheme works from a comprehension point of view though, it seems a little confusing. -Michael
