On Aug 25, 2005, at 7:16 AM, David Formosa (aka ? the Platypus) wrote:
On Wed, 24 Aug 2005 16:13:03 +0300, Yuval Kogman
<[EMAIL PROTECTED]> wrote:
[...]
perl6 creates a new instance of the perl compiler (presumably an
object). The compiler will only compile the actual file 'f
On Aug 28, 2005, at 5:52 AM, Yuval Kogman wrote:
On Sun, Aug 28, 2005 at 05:18:42 -0400, David Storrs wrote:
On Aug 28, 2005, at 5:12 AM, Yuval Kogman wrote:
On Sun, Aug 28, 2005 at 05:02:25 -0400, David Storrs wrote:
nested_call.wrap(), maybe?
It's not 100% the same thing... Wrappi
On Aug 28, 2005, at 5:52 AM, Yuval Kogman wrote:
oops... Can I forward our correspondence to the mailing list?
Sure. I was wondering why you took it private. :>
--Dks
On 9/1/05, Rafael Garcia-Suarez <[EMAIL PROTECTED]> wrote:
> I just commited into bleadperl a patch that implements this :
>
> $ ./perl -e 'no 5'
> Perls since v5.0.0 too modern--this is v5.9.3, stopped at -e line 1.
> BEGIN failed--compilation aborted at -e line 1.
>
> That is, the e
On Sep 22, 2005, at 3:08 AM, Luke Palmer wrote:
On 9/22/05, Carl Mäsak <[EMAIL PROTECTED]> wrote:
FWIW, to me it looks fairly intuitive. undef here means "don't alias
the element, just throw it away"... gaal joked about using _ instead
of undef. :)
Joked? Every other language that has pat
On Sep 26, 2005, at 4:19 PM, Juerd wrote:
Perl 5's $& is inefficient because of this. If the variable is used
anywhere, Perl will for every regex used capture everything.
My understanding is that this died with 5.10. Is that right?
--Dks
So, I was thinking about how $Larry's original plan for doing the
Perl6 design was something along the lines of "write a series of
Apocalypses, one for each chapter of the Camel book". I know that
the latest version of the Apocalypses are in SVN, but I checked
dev.perl.org just to see what
Both Luke and I missed the fact that my mail and his response went
only to each other so, with his permission, here it is as a forward.
--Dks
Begin forwarded message:
From: Luke Palmer <[EMAIL PROTECTED]>
Date: October 5, 2005 1:48:54 AM EDT
To: David Storrs <[EMAIL PROTECTED]>
From: Luke Palmer <[EMAIL PROTECTED]>
Date: October 5, 2005 1:48:54 AM EDT
To: David Storrs <[EMAIL PROTECTED]>
Subject: Re: zip: stop when and where?
Reply-To: Luke Palmer <[EMAIL PROTECTED]>
On 10/4/05, David Storrs <[EMAIL PROTECTED]> wrote:
How about:
@foo = (&
On Oct 5, 2005, at 7:49 PM, Damian Conway wrote:
Providing a :fillin() adverb on C is a suboptimal solution,
because it implies that you would always want to fill in *any* gap
with the same value. While that's likely in a two-way zip, it seems
much less likely in a multiway zip.
I actual
On Oct 13, 2005, at 6:45 PM, Dave Whipp wrote:
I started thinking about the "in general, unverifiable
programmatically" bit. While obviously true, perhaps we can get
closer than just leaving them as comments. It should be possible to
associate a unit-test-generator with the theory, so I ca
On Oct 15, 2005, at 7:39 AM, Rutger Vos wrote:
Good idea. A fat new O'reilly tome will go some way to capturing
mind share
for perl6. Gathering ideas wiki-style is also very Web2.0. Perhaps
perl6
could be marketed as such, what with the development style -
"Perl6, the
first Web2.0 program
Drat, thought I was sending this to the list:
Begin forwarded message:
On Nov 17, 2005, at 8:31 PM, Ilmari Vacklin wrote:
Hi all,
I think that grep should be renamed to something English and more,
well,
semantic. 'Filter' comes to mind as a suggestion. I realise there's a
lot of cultural
terface versions', but
I think (for today, anyway) that we don't care much what goes in the
API identifiers at all. The names don't even have to be explanatory
(it works for Theorem::Pythagoras) -- we could rely on the module to
supply a list of keywords to explain what it's for or to use in
searching.
-David
le when trying to
walk. It's just too low a level.
Having an unknown/danger value, as well as the good ol' undef/none
value, could be useful though. But I think you should have to
deliberately use it ("my $x=unknown;") to show that something
unnatural is going on.
-David
;3 ..." and expect it to Do the Right Thing regardless of
whether $x happens to be an ordinary number or a junction -- I have
to split up the two cases and handle them separately. That's surely
going to reduce the happy-go-lucky usefulness of junctions.
Besides, don't we have a "no junctions" pragma that you can stick
into any scope where you need exact mathematical purity?
-David
ake an argument that the default OFS should be a
space or a tab, but I think OFS="" and ORS="\n" are probably what
most people want most of the time. That certainly fits my typical
uses of 'print' and 'say'.)
-David "say what?" Green
ell, the ~~ table includes both:
Any Code<$> scalar sub truth match if $b($a)
Any Code<>simple closure truth match if $b() (ignoring $a)
so if the code takes a single argument, it will use $a; if it
doesn't, then, well, it won't.
-
verb were available, then I could have a rule that doesn't include
two other rules:
line:without(&&) {
^^ [.*] $$
}
The rule above would match a line with a or , but not a line with
both. Like I said before, I don't know if this is the best way to do stuff
like this, or if I'm thinking about these problems the wrong way, so *any*
help would be great.
Thanks,
David
On 2/14/06, Luke Palmer <[EMAIL PROTECTED]> wrote:
> On 2/14/06, David Romano <[EMAIL PROTECTED]> wrote:
> > I don't want to just skip tags wholly, because they do serve a purpose,
> > but only in a particular context. (Can be changed back to a "default"
which you could choose to
get lists or to get junctions when there's more than one possible
result.
(Perhaps if you , the default might be to return
junctions or lists on the grounds that you're trying to be more
mathematical?)
-David
e Comments::Boxchars" line first.
#==#
# -David Green #
#==#
be more like ...+\s*...+ so you can say:
foo[32],
bar.[0],
sphygmomanometry...[120/80];
-David "probably not serious about that" Green
On 6/11/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
(Operators that imply list operations are excluded: C<@>, C<%>,
and C, for instance. Hyper operators are also excluded, but
-post-assigment forms such as C is allowed.)
+post-assigment forms such as C are allowed.
while the nits are bei
isappeared.
Yeah, my bad. I meant to have the paren after the period. Thanks :-)
David
values?
Because Perl 6 uses a false .id to signify a non-instantiated
prototype, all instances should arrange to return a .id that
boolifies to true.
Does that mean all non-instances are equivalent? I can see that two
non-existent Dog's might be considered the same thing, but not a
non-existent Dog and a non-existent Cat.
Or will $uninstantiated.id return something unique C?
-David
e
something that doesn't have a name cannot, by definition, have the
same name as something else... although even there, it arguably makes
sense to consider equivalent anonymous values as "bound" to the same
place. There's only one unique [1,2] in platonic heaven, I'm just
mentioning it directly instead of dropping a name.)
-David
thing else "Str" could reasonably mean other than "string"
(just as I don't think "regex" can very reasonably mean anything
other than "regular expression").
-David
; #true, same elements therefore same values
$a =:= $d; #false, different variables
$a === $d; #false, [EMAIL PROTECTED] and [EMAIL PROTECTED] are
different refs
$a eqv $d; #true, values of @x and @y happen to be the same
-David
Way back on 7/14/06, Larry Wall wrote:
On Thu, Jul 13, 2006 at 10:19:24PM -0600, David Green wrote:
[...]
No, === is also deep. It's only shallower (or potentially shallower)
in the sense that it treats any mutable object node as a leaf node
rather than changing to "snapshot"
On 8/14/06, Smylers wrote:
David Green writes:
Thanks for that. In summary, if I've understood you correctly, it's that:
=:= two aliases to the same actual variable
=== one variable contains a copy of the other's actual contents
eqv both contain contents which represent
On 8/14/06, Smylers wrote:
David Green writes:
I guess my problem is that [1,2] *feels* like it should === [1,2].
You can explain that there's this mutable object stuff going on, and I
can follow that (sort of...), but it seems like an implementation
detail leaking out.
The curr
-offs are a fact of life. But nobody's actually
said that, so I don't know whether I'm misunderstanding something
still, whether I just haven't clearly explained what the heck I mean
(or both, always a distinct possibility!).
-David
that's a natural way to frame examples, but the language of
examples doesn't seem to be that good for explaining the concepts.
Whether stuff may or may not change isn't the point; what it comes
down to is referring to a variable itself vs. evaluating it.
-David
On 8/15/06, Darren Duncan wrote:
At 2:51 PM -0600 8/15/06, David Green wrote:
[...]
You are right, but we have both Seq and Array types, so depending
which one you use, you want either the === or eqv operators to do
what you want. There is no reason that === should say 2 Array are
equal; we
On 8/16/06, David Green wrote:
$a=[1, 2, [EMAIL PROTECTED];
$c=[1, 2, [EMAIL PROTECTED];
$d=[1, 2, [EMAIL PROTECTED];
$a =:= $c; #false, different variables
$a === $c; #true, same elements make up $a and $c
$a eqv $c; #true, same elements
On 8/17/06, Darren Duncan wrote:
At 11:16 PM -0600 8/16/06, David Green wrote:
I just want [1,2] to be === to [1,2], or [1,2, [EMAIL PROTECTED] to be equal to
[1,2, [EMAIL PROTECTED] but !=== [1,2, [EMAIL PROTECTED] -- eqv won't work in the latter case
(regardless of Seq vs. Array -- I d
e go from
3 up to 4.
However, what I'm wondering is whether Order::Same is "but true" and
the others "but false"? (Which makes cmp in boolean context the same
as eqv, but it seems to make sense that way.)
-David
On 8/16/06, David Green wrote:
$a=[1, 2, [EMAIL PROTECTED];
$c=[1, 2, [EMAIL PROTECTED];
$d=[1, 2, [EMAIL PROTECTED];
$a =:= $c; #false, different variables
$a === $c; #true, same elements make up $a and $c
$a eqv $c; #true, same elements
s
it broke?
Am I missing anything else?
Best,
David.
.
In that case, .WHO definitely makes more sense for the name.
-David
Aaron Sherman wrote:
>Is the goal to avoid namespace pollution? If so, shouldn't there be a
>truly "metaish" way of getting at the internal namespace so that someone
>doesn't accidentally render an object unusable by defining the wrong
>method name (which you can prevent with an error if the ob
d assertions are defined? It would make it easier to link the tests, and
to tell the difference between examples like and builtins like .
Last, but not least, should any of these be crossed off the list?
Best,
David.
at, etc., or whether 0 should be the first
element or the last, and so on.
(And of course, if arrays can be indexed with {}, then hashes can be
indexed with [] -- dunno if there's any point for ordinary hashes,
but it certainly could be useful with ordered ones.)
-David
On 2/5/07, David Green wrote:
Then we wouldn't need * to count backwards, although it's still
useful to allow us to count past the end of an array. There are all
sorts of variations on this scheme, such as whether * is the last
element or the one after that, etc., or whether 0 sho
funny" indices (and the related issues of
wrap-around), you can count past the edges, and all while preserving
familiar array behaviour (especially for P5 veterans), the meaning of
* as "everything", and uncluttered syntax.
-David
On 2/27/07, Jonathan Lang wrote:
David Green wrote:
So I end up back at one of Larry's older ideas, which basically is:
[] for counting, {} for keys.
What if you want to mix the two? "I want the third element of row
5". In my proposal, that would be "@array[5, *[2]]
.Inf if that's what you want, but otherwise how would
you get [1..^*] meaning [1,2,3,4]? Perhaps the range could note when
it's occurring in []-context, and interpret the * as count rather
than as Inf?
-David
tably for the types
involved.
-David
to
carve out your own space in the Foo universe? You should, of course,
unless your module also is compatible with module Bar. It can't have
two names, but it can advertise itself as being compatible with two
or more other modules.)
-David
a known good version.
Does "allowed to run anyway" mean because older versions stay
installed (and thus you should be able to get an exact match), or
does it mean you might get some other module altogether, as long as
it claims to be compatible with whatever you asked for?
-David
shes, should it be called
something else? Or should file-renaming be called something else?
Or should both 'rename's be methods only, and not have any "rename"
function/multi? [I think that might already be the case, although I
can't put my finger on it at the moment.] ...
-David
trictly the same as renaming a key. Consider what would
happen if the value were a funny object that had side-effects every
time you evaluated it.
As for the name, I don't think it's a problem for hashes and IOs to
both have "rename" methods, but I do like Uri's "rekey" suggestion.
-David
on 4/11/2007 10:29 AM brian d foy said the following:
The $*ARGS variable shows up in this file, which looks like it's still
maintained:
http://svn.pugscode.org/pugs/docs/AES/S28draft.pod
That's a typo (mine). It should be @*ARGS and refers to simple access to
the command line arguments
on 4/13/2007 4:55 AM brian d foy said the following:
> Shouldn't $*ARGS still show up as the P6 counterpart to ARGV?
> S*ARGS as the filehandle shows up in S04.
Yup. Fixed now in S28draft.pod. Mention in Variable.pod will follow.
dvergin
inking of them as
Objects with built-in optimiser hints? Not that I have a good
example of why you'd want to specify a native-only type; I'm only
asking out of pedantic curiosity.
-David
I thought one of the things that Larry didn't want to do when moving
towards the next big version of Perl was to change the nature of the
language such that it wasn't Perl any more.
I feel that renaming a Hash to Dict would be one of those changes.
Personally, I don't find it difficult to
;t know
what's going on around it, but Perl does, and could say, "I've just
declared $size, and the next line starts a chunk of POD, so I'll
simply copy it into $size's 'documented' trait... would that work??)
-David
umentation is not necessary written
in order (I too like to put docs before code), so I don't see why we
couldn't have a code for succeeding aliases as well.
-David
ay, in case I'm sounding too polarised I should acknowledge that
I do agree with your underlying points about not overly restricting
things. I want rules *and* flexibility, and I believe we can have
both, just as Perl itself is very structured (more so than P5), but
is at the same time extremely flexible (also more so than P5!). I do
agree that docs should have as much freedom as code; I want them to
have as much structure too.
-David
On 6/22/07, Smylers wrote:
David Green writes:
Well, clutter like "Blah: none" seems to me to be more the fault of
the doc-formatter for not hiding lines like that.
It's more the repetition in the lines you snipped that I really object to:
Ah. (That was sneaky of me.) I
ents regarding your proposal when I
have a bit more time myself
-David
> On 9/18/07, Paul Hodges <[EMAIL PROTECTED]> wrote:
>>
>> For the Gearheads
>> We won't bore you with excess details,
>> but for more info... c.f. ...
>>
on 9/19/2007 10:19 AM Adriano Ferreira said the following:
> I am thinking about such hooks and good ways to do that.
As an eager r
ened to the suggestion of using ` to designate units? Bases
are a kind of unit (sort of -- counting the number of 10's or 2's or
16's), so if the colon-form is ambiguous, perhaps it could be
20`16==32`10?
-David
re, Perl6 is just a syntax module."
Or simply: "Perl6: there is no core."
Core-dially,
David
(Or volunteer to figure out exactly what it is that would
need organising)
The other side to this problem is coming up with good modules so
there's something to recommend. But that is a technical issue and
something for a separate post.
-David
print; # prints $_, the current loop variable
}
Yup (although I think that should be: for =$myxmlvar[etc...]).
I will stop here ... so I can put on my flame proof suit.
I find nothing to flame here, but lots to discuss.
-David
tware-transactional memory?
Hopefully I'm not inadvertently starting any kind of flame-fest about anyone's
favorite concurrency model here :-D
Best,
David.
Never miss a thing. Make Yahoo your h
Inadvertently replied to this off-list...
Moritz wrote:
>There's no need for any "keyword" to be in STD.pm. STD.pm just defines
>the grammar. Syntactically fork will be like just another sub, so it can
>safely be handled in the compiler's runtime.
>
>> * Where will C, C, and possible friends (e.g.
red ".pm"
is a "suffix" rather than an "extension" (in the Windows sense). I
think a primary raison d'etre is so you can have a module "Foo" which
is really Foo.pm and a directory "Foo" for sub-modules. But not
being allowed to have a file and a dir of the same name is itself
merely an unnecessary restriction that just happens to be implemented
by some currently-popular filesystems.
-David
t;$<" instead of "\s":
say "I'm bid $d dollar$< for @this[]$> $o @ox[]$<"
...except that I'm not crazy about calling it "$>". (If that would
even work.) But something like that. Perhaps strings should build an
array of their interpolations?
say "$a $b $c, this string contains [EMAIL PROTECTED] interpolations"
(Then again, maybe there's a time to break down and use (s)printf.)
-David
On 2008-Jan-31, at 2:38 am, Mark Overmeer wrote:
* David Green ([EMAIL PROTECTED]) [080131 08:48]:
I've always wanted a magic-S (and I don't think the anglocentrism
matters
In "the good old days" all computer OSes were anglo-centric. They are
not like that anymore
n you want to make it absolutely explicit:
open($dir fs ($filename ~ $total div $count)).
(I also expect that files will be treated more consistently in P6,
without as many issues about whether a "file" is a string or a handle
or an object...)
-David
again because "overloading" is natural to human communication.
And of course being so flexible about how to balance mapping onto the
way humans think vs. mapping onto the problem space is what makes P6
so delightful.
Which is why I like it so much more than certain of its brethren
with their Orthogonality Ueber Alles attitude. I just don't want to
see that sort of prescriptivity creep in to Perl.
(Unless it's predeclared, of course!!)
-David
12.34;# my Num $x
my * $y = "abc";# my Str $y
const * $z = $foobar; # const Foo::Bar $z
-David
for objects will be something like P5's unique memory address.
Presumably the snapshot then takes whatever an object claims to be its
"value" and reduces any mutable parts into immutable values, until it
end up with something that consists wholly of immutable values.
-David
x)
{
# explicitly create a new multi with every specialization
state %didit;
unless ++ %didit{ $x.HOW } {
my multi sub inner (T $x) { ... }
Package::<&inner> = &inner;
}
}
Well, for one thing, "Package::inner" in this example is set at run-
time, while "our sub inner" in your first example is declared at
compile-time, right?
-David
sub to do
Package.
I don't understand what a "sub doing Package" is supposed to do. I
think you get the same thing from that last example whether foo and
bar are classes or whether they're subs: either way, bar will raise a
redefinition error, and "say inner.new.x" will throw a "no 'inner' in
scope" error.
-David
ash every time it's called, you'd
have to replace the innards of the Hash type yourself anyway.
But if you did make a Hash::Sorted class, defining an "is sorted"
trait might be a nice way to use it.
-David
code more efficient to write is the job
of one's text-editor, not the language. Maybe we should work on auto-
completion files for popular editors that will expand things like
":str" into ":strictly", etc.)
-David
t it for
various reasons (and =$x refers to iteration in other contexts).
Perhaps it could be identified as "$x is assigned" -- but that doesn't
look quite right to me either. However it's written, it would be
simpler than having to use proxies.
-David
On 2008-Jun-1, at 11:20 am, Jon Lang wrote:
David Green wrote:
I thought it already did, but apparently it's something that we
discussed
that didn't actually make it into S09. I agree that .[] should
apply to
hashes just as .{} can apply to arrays. The hashes don't ev
On 2008-Jun-1, at 1:50 pm, Jon Lang wrote:
David Green wrote:
[...] assignment should work like passing args when used on a
function. Then you can easily do whatever you want with it.
[...]
If a routine is rw, you may optionally define a single "slurpy
scalar" (e.g., '*
On Mon, Jun 2, 2008 at 6:50 PM, Larry Wall <[EMAIL PROTECTED]> wrote:
>* Exception handlers run in the lexical context of the block being
>tried.
>* Exception handlers run in the dynamic context of the code that is
>failing.
the first seems dangerous, esp. considering the
On Wed, Jun 4, 2008 at 7:21 AM, Mark J. Reed <[EMAIL PROTECTED]> wrote:
> The catch block is lexically contained within the try block, so the
> inviolate nature of the curlies remains intact.
thank you.
nstead of two.
Of course, since subs are objects too, maybe all you need for an
lvalue-sub is to override the FETCH and STORE methods it already has.
But then the "is rw" stuff would simply be syntactic sugar to make
doing so prettier.
-David
s, and the return statement would need to supply each one
twice.
Couldn't these all work the same way as parameter passing does? Even
at the cost of a bit more complexity, it would be simpler overall to
have only one set of rules to learn.
-David
27;s editor; any
editor worth its salt ought to easily auto-complete "ro" into
"readonly".
-David
rn
everything, and take a slice of the result -- assuming it can be lazy
enough to calculate only what ends up getting sliced out.
-David
On 2008-Sep-23, at 5:27 pm, Michael G Schwern wrote:
David Green wrote:
Happily, brevity often aids clarity. The rest of the time, it
should be up to one's editor; any editor worth its salt ought to
easily auto-complete "ro" into "readonly".
Eeep! The "your
but not necessary. Being able
to use class info that's already there would make it easy to grab
params when I know the type of object I'm looking for, but not what
it's called.
-David
On 2008-Oct-22, at 10:03 am, TSa wrote:
David Green wrote:
One thing I would like signatures to be able to do, though, is
assign parameters by type. Much like a rule can look for
identifiable objects like a or , it would be very
useful to look for parameters by their type or class rather
r (except for symbols that are already established
with the required meaning, and the only ones that come to mind are
braces to indicate sets -- and of course Perl already uses braces for
something else).
-David
something on only
the first iteration through the loop, but there's no NOT-FIRST block
to do something on the second and subsequent iterations. Is there an
elegant way to do something on all but the first loop?
-David
tch to Int? What happens
with non-continuous enums? My vote would be to not generate any
operators
Since ++ works on strings without making them numbers, I think it
should increment from A::One to A::Two. But if that's ambiguous, we
could drop the ++ and stick with .=succ for non-numeric objects instead.
-David
ay, e.g. "floor($i/$j)", forces
you to be blatantly clear that you're disposing of the remainder and
how.
-David
lasses need to indicate their family
resemblances somehow.
Now, which is more useful? Is it worth having "===" and "syn"?
-David
eturn some other special compound type that numifies to
the quotient.
-David
ll not up front, but if the first block is really long, you
can always... add a comment!)
-David
On 2008-Dec-5, at 7:43 am, David Green wrote:
Now the condition is in the middle and is syntactically separate.
(It's still not up front, but if the first block is really long, you
can always... add a comment!)
Well, you don't need a comment -- why not allow the condition to co
101 - 200 of 1041 matches
Mail list logo
