et unpacked in different ways, but I'm not sure there's
enough of an underlying unification to be made.
-David
the value matches;
but given a function, you check the value by passing it to the function and
seeing whether it says yea or nay.
I'm not sure "validation" or "validity" is the best name, but it conforms
better to what smart-"matching" does. Or "conformance" Hm. But
terminology that sets up the appropriate expectations is a good thing.
-David
= ~22/7 :within($epsilon). (Except
"~" is already taken!)
[I was going to suggest that as a way to handle stopping points in a sequence:
1, 3, 5 ... ~10, but that still wouldn't work without treating the Num::Approx
values as a special case, which defeats the purpose. Though with a postfix "up
from" operator, you could say: 1, 3, 5 ... 10^.]
-David
the entire match.
I was thinking of that too.
> I suspect :full would almost always be associated with TOP, in fact. Boy am
> I tired of typing ^ and $ in TOP ;-)
Does it make sense for ^[...]$ to be assumed in TOP by default? (Though not
necessary if there's a shortcut like //...//.)
-David
omatically. Isn't handling such versioning
worries one of the best features of P6? (After all, docs aren't special to Perl
— it's all just "code" that it will parse and process any way you tell it to.)
Darren:
> Explicit versioning is your friend.
Yes, always!
-David
ust as Z can act as an operator by itself, so plain "_" could stand
for the default topic-op, ~~. Hence "$_ ~~ $X" would just be "_$X" (unless you
changed the default default topic-op to something else.)
I really like the idea of being able to take the topic-shortcut anywhere. I'm
less thrilled about the idea of having to say "when _ $blah" all over the
place But it is more consistent and more general. And it's making me
think of ".foo", which reminds me of another catch with the current spec: "when
.foo" means "when $_ ~~ $_.foo" — unless the .foo method happens to return a
Bool, of course — but it's more likely that it ought to be "when *.foo" or
"when ?.foo". So that's a pretty plausible case for catching people out.
-David
the word "index" (or "counter" or "n"?) in
a loop or series or anywhere else suitable, it could be detected at
compile-time. It shouldn't be any worse than making your own counter, and
might even be better (since Perl needs its own counter for some loops, maybe it
could make it available rather than having to define one of your own as well).
-David
it would be rather amusing to have to shout at
> Perl 6 to make it shut up:
> my $x = QUIETLY 0123;
Call it "sh"? (for "suppression handler", of course)
Using comments doesn't feel quite right to me either, but on the other hand,
almost anything else seems distracting for something that is supposed to avoid
drawing attention. Maybe a statement suffix?
-David
On 2010-07-31, at 2:00 pm, TSa (Thomas Sandlaß) wrote:
> On Saturday, 31. July 2010 18:56:47 David Green wrote:
>> given $who-knows-what {
>> when True { say "It's a true thing!" }
# ^--oops, this still shouldn't come first!
>> when 42 { say
block. Maybe the comparison could be indicated another way,
leaving 'when' and 'if' to differ in breaking out or not. Suppose a colon
indicated "compare against $_ using ~~, or whatever the default operation is"
(we're not using the colon for anything else, are we?!?):
when $a > $b { ... }
if $foo.does($bar) { ... }
when: /foo/ { ... }
if: .defined { ... }
-David
$anything-else", I
will take away "Perl DWIM". And then I'll expect it to DWIM in
"$true-false-queston ~~ $bool-answer".
-David
On 2010-07-31, at 12:47 pm, Patrick R. Michaud wrote:
> On Sat, Jul 31, 2010 at 10:56:47AM -0600, David Green wrote:
>> given $something {
>> when True { say "That's the truth!" }
>> when 42 { say "Good answer!" }
>> when "via
{ say "It's a true thing!" }
when 42 { say "It's numbery!" }
whenever timeout() { say "Who cares what you say, time's up!" }
whenever $override { say "Whatever, switching to automatic
override" }
}
This way (or something similar) is just as clear when reading something in
context, but also makes it clear(er) when the context doesn't help (like 'when
who-knows()') or when you reasonably expect more consistent matching. [Or do I
mean "whenever"??]
-David
ms at the
first positional arg. Of course, some commands continue to process named
params either way. For programs like Perl itself, e.g. "perl --args --for
--perl some-script.pl --args --for --script", continuing past the positional
arg would not do the right thing. But is this common enough to be the default?
You can always use "--" to force positional treatment, but not the other way
around.
-David
whether two things can be expected to
work the same way, so perhaps there can be an adverb for eqv that says to pay
attention to ad-hoc changes (or vice versa). Since 'but' is special syntax,
maybe there's even a way to compare snapshots of all the types that were
'but'ed in to the base type, but I don't know how feasible that is.
-David
ay "Time's up!" }
when $answer { say "That is correct!" }
default { say "Sorry, wrong answer" }
}
-David
On Feb 10, 4:38 pm, dam...@conway.org (Damian Conway) wrote:
> I sincerely hope that the future community of designers of Perl 6 's
> documentation format will find a way to honour and support the very
> different needs of *all* the creators and users of Perl, not just the
> needs of the most prom
Jan 21, 2010 4:04 PM, "Darren Duncan" wrote:
David Brunton wrote:
> I notice that C returns False and deletes the key for a key
> whose value goes to zero or less than zero, issuing a warning in the
> latter case. Is it the case that C always evaluates to False
> in Boolean con
I notice that C returns False and deletes the key for a key
whose value goes to zero or less than zero, issuing a warning in the
latter case. Is it the case that C always evaluates to False
in Boolean context when negative?
have an adverb to control its strictness too,
come to that. But not requiring "but" to change behaviour seems
reasonable -- I would read it as "but make sure that X", where you
want to draw attention to X even though it might technically be
redundant.
-David
. Since
the Bool(Int) method already exists, "but" is indeed the appropriate
choice to override it.
-David
of things will have default stringifications, say, that
may not always merit the contrary force of "but". Maybe "but" should
be needed only when a method has already been mixed in anonymously.
So: $x = Tue with "Today"; $y = $x but "Tomorrow".
-David
ot;.
(At first I wrote "?Day(3)", but that wouldn't work if there was value
that was false. On the other hand, shouldn't enums typically be
true? Does it fit the common case better for enums to start at 1
instead of 0, or maybe start at 0 but true?)
-David
;" syntax to feed args into a slurpy parameter. But in
your angle example, we really do want an assignment because the net
result is to assign stuff. Perhaps "method angle is setting ($.x,
$.y) ..." to indicate that whatever is done to "angle" should really
affect $x and $y, and any other attributes that aren't specified may
not be used.
-David
_ ~~ Y and $_ ~~ Z }:
Int $a, Int $b) { ... }
I would expect "$foo where {$_ ~~ X}" and "X $foo" simply to be
different ways of writing the same thing, but whatever works!
-David
On 2009-Oct-19, at 5:50 pm, Jon Lang wrote:
In "Aiasing methods in CPAN roles", David Green wrote:
I don't want my special log() method to work only for other types
that explicitly do NumLog; I want it to work for any type that
directly "does Numeric does Logging".
On 2009-Oct-18, at 3:44 pm, Jon Lang wrote:
David Green wrote:
I would expect that role Logging { method log(Numeric $x:) {...} }
means the invocant is really of type Numeric & Logging, without
Logging having to do Numeric. On the other hand, I can see that
strictly that might not
ame inside the
block as the one being passed in? That would be useful in cases like
this where we don't particularly want to rename $x.)
$x.log:(Logging:);
And I like this way because it's the most compact, "inline" way to
indicate it.
-David
be used where unambiguous.
(I guess this parallels what we already have for subs, etc., except
methods would be automatically "exported" into new roles or classes so
that we can use short names. I don't know what the actual syntax
should be -- I only used ` above for lack of anything better, since
the obvious .Logging::log means something else.)
-David
On 2009-Oct-14, at 2:00 pm, Jon Lang wrote:
David Green wrote:
On the other hand, $dogwood.Dog::bark cannot be simplified by
leaving out the "Dog::" because then it would be ambiguous.
On the gripping hand, if we have a function "train(Dog $d)", then we
can safely as
how bark() works
(either one), nothing needs to be rewritten. If you want to change
from Tree::bark-ing to Dog::bark-ing, then you *should* be rewriting
code, because you're completely changing what is going on, no less
than if you changed from bark()ing to fetch()ing.
-David
and avoid this problem:
+sub say-or-print {
+if $SAYIT {
+say @_; # WRONG
+}
+else {
+print @_; # WRONG
+}
+}
Or am I merely not yet used to situations where you'd want @_ to grab
args passed in by "if"?
-David
der" that is intended.
(And perhaps "Discrete" should be a different type from "Set" even if
they do work out the same, simply to better document one's intent.)
-David
l syntax or not).
It also might be worth inventing a whole new syntax design for parsing
and manipulating data structures, but your suggested extensions seem
pretty good to me.
-David
especially obvious choice (because .inc probably wants an ordered
type). Would it add 1? or 1+i? Better to spell it out explicitly.
Well, Real implies ordering (at least to me ;-), I don't think we
have a
class or role for countability.
A Discrete role would be useful, but is Set good enough for that?
-David
"and so on".
Oh, nice! In fact (no surprise) I like all the changes.
-David
don't see that we would lose any functionality (make
the :by features work with "..."; or keep ".." and "..." as two ways
to make series, and use infix: for Ranges; or anything else that
distinguishes ranges from iterators). What's the big advantage in
keeping it the way it is?
-David
On 2009-Sep-19, at 5:53 am, Solomon Foster wrote:
On Sat, Sep 19, 2009 at 6:48 AM, Carl Mäsak wrote:
David (>>>),
It sounds like the split personality of Ranges strikes again. I
still think
it makes more sense to have one Series-only type and one Range-
only type,
rather than o
seems confusing.
It sounds like the split personality of Ranges strikes again. I still
think it makes more sense to have one Series-only type and one Range-
only type, rather than one Series type and one Range-plus-Series type.
-David
$range. If a Range is not a Series, then there's
no confusion as to whether being in the range means being in the
series or not.
S03:
Alternately, we could treat an ellipsis as special when it follows a
comma to better support traditional math notation.
That seems like an easy mistake to make, so treating it specially
would be a good quirk.
-David
vailable so you can instruct Perl not to use any alpha modules, or so
on.
-David
rd "range" suggests ordering (like the
related word "rank"), so perhaps Range is the right name for the
interval-type, and "Series" should be the type that produces a series
of values that may or may not have an innate ordering. (For example,
you could produce a Complex series with: 5+5i .. 10+10i :by(1+1i).)
-David
ilesystem.
I should've mentioned, though, we're currently using the smartmatch
operator for this, so I'm thinking maybe I'll just stick with that.
Or $f1.id ~~ $f2.id, since whatever identifier the FS uses might not
be numeric, yes.
-David
oked. E.g.
my DateModule $d .= new('2007-03-12');
My first thought is also coercion: say my DateModule $d = '2007-03-12'
and let DateModule::&.(Str) worry about making the new object.
(Or does that need to be my DateModule $d = DateModule('2007-03-12')?
That seems unnecessarily redundant.)
-David
On 2009-Aug-18, at 7:20 am, Timothy S. Nelson wrote:
On Tue, 18 Aug 2009, David Green wrote:
Some ways in which different paths can be considered equivalent:
Spelling: ... Simplification: ... Resolution: ... Content-wise: ...
Ok, my next commit will have "canonpath" (stolen direct
d dirs, and you
should be able to import them:
# Assume I'm running on a Mac, so $IO::DOI::MacOSX is
automatically loaded
use IO::DOI ; # names that ::MacOSX makes
available
say $Home; # /Users/david
say $Music;# /Users/david/Music
say $Downloads;
parseness just means perl is smart enough to do
@foo[1]=$bar without trying to suck up a zillobyte of
RAM.
-David
for the user to add "use
IO::Encoding $volume => ", and at least that way naive users
will be alerted to the fact that something's going on. It's up to
them how much effort they think is worth devoting to the issue, but at
least they will be warned that there's an issue there to grapple with.
-David
t should disallow / \ ? * $ @ % ☹ unless preceded by (##`=☞,
and not run any executable code when you're looking at it. And
there's a magic plural-\s (s/:/>/g), but it works only if the
attributee is Larry Wall.
-David "is it bedtime yet?" Green
outside
the official library location). Having perl-doc run in lock-down
mode, or run in display-precompiled-static-file-only mode by default
might be a good idea, though I'm not convinced it's completely
necessary.
-David
On 2009-Aug-18, at 5:48 am, Jan Ingvoldstad wrote:
On Tue, Aug 18, 2009 at 1:02 PM, David Green
wrote:
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 some
ig deal. Nevertheless, there's more to respecting other
systems than simply doing without punctuation. For example, a
suitable pathname on Unix might be:
~/.foorc
Whereas on a Mac, it might be more polite to use:
~/Library/Application Support/Foo/Startup Settings
which is certainly beyond the scope of p{}-quoting.
-David
d" in front of it. (Of
course, I suspect that $*CWD should be able to be set to a plain Str,
but the Str will be cast to an IO::Path because that's what
$*CWD.STORE() will take in its signature.)
-David
ding information extrapolated from the contents. A byte-
order mark is metadata (it tells you something *about* the file) even
though it's inside, right? Or a char-set declaration inside an HTML
file, or -T
Philosophically, there's no hard distinction; only whatever point of
view is useful for the task at hand. If you "use
IO::Filesystem::Gzip" then you should be able to treat "a" gzip file
as a bunch of separate files with separate contents and metadata [even
though when you look at it from a different perspective, it's all just
"data" in a single .gz file].
-David
On 2009-Aug-18, at 3:27 am, Timothy S. Nelson wrote:
On Tue, 18 Aug 2009, David Green wrote:
Maybe setting $*CWD just calls chdir() under the hood? Same
implementation, brand new shiny Perl-style interface!
That was my intent, but we had some discussions on IRC about the
whys and
-style interface!
-David
ites like CPAN will probably make a static doc file a requirement,
and even the cpan shell could warn users about any modules that don't
include static docs -- in fact, I think it would be reasonable to
refuse to install such modules by default.
-David
discussion can
dislike equally. ;-)
I like it very much. But don't worry, I'll think of something to
quibble about!
-David
P.S. to format it using perldoc2xhtml, I had to change the "=begin
item" at line 589 to "=for item".
$file.type ~~ MIME("text/plain") {...}
or just:
if $file.type ~~ "text/plain" {...}
since .type() presumably returns a Data::Type::MIME object to begin
with. (Or even better, a Data::Type::UTI object, since UTIs are a
more useful superset of MIME. Is there any system that would be even
better than UTIs?)
<http://en.wikipedia.org/wiki/Uniform_Type_Identifier>
<http://developer.apple.com/documentation/Carbon/Conceptual/understanding_utis/understand_utis_conc/understand_utis_conc.html
>
-David
ithout re-encoding them the "P6 way".
Maybe it's more practical to permit only URIs with little to no
punctuation to be unquoted, and quote anything else? Not that quoting
is such a great hardship anyway
On 2009-Aug-14, at 7:41 am, Timothy S. Nelson wrote:
And in res
On 2009-Aug-14, at 4:34 am, David Green wrote:
There's a lot of scope for a nice, friendly, high-level IO view;
perhaps we need an IO-working group to assemble knowledge about what
is and isn't possible with different filesystems and design an
interface around it all.
I
liminating the need for doublets like "eval" and
"evalfile".
There's a lot of scope for a nice, friendly, high-level IO view;
perhaps we need an IO-working group to assemble knowledge about what
is and isn't possible with different filesystems and design an
interface around it all.
-David
eason we couldn't view the same file in "code mode" and
"doc mode"... but it's no fun writing features that people can't use.
On the other hand, nobody writes tools for features that don't exist,
so you have to start somewhere.)
-David
quite-so-lite"?
Rakudo ** (aka "Rakudo Exponentiation")? Though I think Patrick is
optimistic that development will proceed exponentially enough that a
single interim release will be enough to hold us over until Christmas.
-David
around sounded useful too, but perhaps you think in practice it
wouldn't be worth it?
-David
e usual idea
of casting or coercing an object to a different type. Soft casting
would be focussing on the requested Role and ignoring anything else
the object does, but still leaving the other roles available if you
really want them. Foo($x) would then do a "hard" cast, while passing
$x to sub(Foo) would merely soft-cast it.
-David
design.)
Either that, or just have suitable warnings that can be toggled on or
off depending on what sort of policies you need. That was actually my
first thought, and I think we should have adjustable warnings for
everything anyway, but the more I look at the above example, the more
it's growing on me.
-David
arg mandatory -- then as long as your status logging doesn't
have a :base, you can have both.
-David
obably be a good idea to
pick a different name!) Or else, it could mean a consolidation of the
two mixed-in .bark's, i.e. $dw.Canine::bark and $dw.Tree::bark would
both now be implemented by plain $dw.bark, aka $dw.Dogwood::bark (all
three full names would mean the same thing for Dogwood objects).
-David
o" or "%foo ∋ $bar".
I think that one's ambiguous as to whether $bar exists as a key or a
value.
$bar ∈ @foo; $bar ∈ %foo.keys; $bar ∈ %foo.values; ∃ %foo{bar}
-David
On 2009-May-30, at 12:06 pm, David Green wrote:
...what "Perl6" is today, let alone what it will be tomorrow.
Actually, we do kind of know what Perl will look like a decade from
now, because P6 is deliberately extensible enough that we may never
need a Perl 7. But that simply
27;re prerogative.
Sure, it's always possible to go too far. But on the other hand,
isn't Perl 6 all about being too clever by half? It's certainly about
being vastly extensible, anyway.
-David
then by
value; but that should probably be a different operation.
say sort { $^a.WHAT leg $^b.WHAT || $^a cmp $^b }, "a", 1, "b",
2 , "c", 3, "d", 4;
-David
]
The other question is: given $choice as defined above, how do I find
out which type of junction it is?
I guess really Junctions need two public methods: .eigenstates for the
values, and, er, .eigenop(?!) to return how they're joined -- I'm
thinking it would return a code ref, i.e. &any, &all, etc.
-David
:YAML;
print $resultset.as_string;
}
I suppose, but is there a reason why you want to apply roles instead
of coercing the results?
$x = Role::Serializable::XML $resultset;
$y = Role::Serializable::YAML $resultset;
-David
ne their own special distinctions between
printing and saying (presumably because simply adding a newline
wouldn't be suitable)?
In that case, all the object would need to do is to define its own
record-separator.
-David
Feb 24, 2009 at 11:16 AM, Ruud H.G. van Tol > wrote:
David Green wrote:
my $foo is limited(100..200);
$foo = 5; # really does $foo = 100
Where does that MySQ smell come from? Why not undef (or NaN)?
How about Failing instead of any of the above? Silently replac
y a better way to approach it anyway: setting limits at
declaration rather than repeating them every time the variable is
assigned to:
my $foo is limited(100..200);
$foo = 5; # really does $foo = 100
-David
"$x==$y" is probably not DWIM. Of course, there
should also be an easy way to set epsilon across a scope, like:
use Num :precision(0);# force exact matches in this block
-David
erb and dispense
with gmtime() and localtime()?
If an Instant object also represents a point in time irrespective of
location, then there's likewise no point in a :tz adverb.
Oh, of course, I was even thinking that the TZ would only be need to
be specified for times coming from somewhere else.
-David
we can say
sleep(5`min), etc. That would mean we can always take time-types, and
avoid the "$t*1000*60*60*24" idiom to boot.
[...]I suppose Temporal is as good a module name as any, though
Temporal::Instant
does seem a bit redundant...
Well, it distinguishes it from Coffee::Instant...
-David
hile we're at it, why is "time zone" still officially two words?
Usually I like to side with the dictionary, but I can't figure out how
"timezone" has escaped becoming de facto standard English.)
((I also prefer "Instant" to "DateTime" unless we end up using both,
as in Darren Duncan's suggestion.))
-David
icit
conversion via $date.morning or $date.evening or something. (Maybe
require $time ∩ $date or $time ⊂ $date?)
-David
like that, but I thought the point
was that you wanted some kind of block or something that could be
syntactically distinct?
-David
ke a snapshot of @foo, or
can you change the bounds by changing @foo while the loop is running?
In which case trying to count back from * might be an error for
anything except constant bounds.
-David
s LOOP would occur
inside. But perhaps you could have LOOP blocks inside ENTER/LEAVE
blocks?)
-David
nally, I can't think of any.
say $pair;
I can't really think of a great example where you'd want to numify a
pair, but I would expect printing one to produce something like "a =>
23" (especially since that's what a one-element hash would print,
right?).
-David
@stuff.sort { .Num } # numerically
@stuff.sort { ~ .name.uc } # stringwise
@stuff.sort { Foo(%x{$_}) } # foo-wise
I don't know what cmp returns for two values of different types.
(Failure?)
-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
ll not up front, but if the first block is really long, you
can always... add a comment!)
-David
eturn some other special compound type that numifies to
the quotient.
-David
lasses need to indicate their family
resemblances somehow.
Now, which is more useful? Is it worth having "===" and "syn"?
-David
ay, e.g. "floor($i/$j)", forces
you to be blatantly clear that you're disposing of the remainder and
how.
-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
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
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
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
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-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
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
1 - 100 of 1041 matches
Mail list logo
