On 7/12/04, Austin Hastings wrote:
--- Larry Wall [EMAIL PROTECTED] wrote:
The hard part being to pick a random number in [0,Inf) uniformly. :-)
Half of all numbers in [0, Inf) are in the range [Inf/2, Inf). Which
collapses to the range [Inf, Inf). Returning Inf seems to satisfy the
uniform
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Larry Wall) wrote:
On Tue, Jun 29, 2004 at 10:52:34AM -0500, Jonathan Scott Duff wrote:
: :u0 # use bytes (. is byte)
: :u1 # level 1 support (. is codepoint)
: :u2 # level 1 support (. is
Luke Palmer [EMAIL PROTECTED] wrote on July 22, 2004:
Even more philosophical is what is core?
I believe the standard definition is Anything I want to use goes in
the core; anything everyone else wants goes wherever there's room
left over. ...
So making it go in the core may just mean that it's
On 7/23/04, Luke Palmer wrote:
Not necessarily. Glop, on which I'm doing a presentation at OSCON
(have to plug it sometime ;-),
Game Language on Perl, you say? Goodness, what's that??
Sorry. Got tired of English.
=)
There's a lot of stuff like that. Way too much to include in a
distribution.
On 7/21/04, Brent 'Dax' Royal-Gordon wrote:
Amen. Please don't steal unnecessary metacharacters in qq()
strings--although I still think we should keep it, @ causes a lot of
problems.
That's why my suggestion would be to use a character that already has a
special meaning in double-quoted
On 8/14/04, [EMAIL PROTECTED] (Larry Wall) wrote:
To get a Perlish representation of any data value, use the C.repr
method. This will put quotes around strings, square brackets around
list values, curlies around hash values, etc., such that standard
Perl could reparse the result. XXX .repr is
On 8/15/04, [EMAIL PROTECTED] (David Wheeler) wrote:
On Aug 14, 2004, at 5:52 PM, Larry Wall wrote:
for all $*IN # all() is junction
for each $*IN # each method wants closure if we follow Ruby
for next $*IN # next $foo is a loop exit
Hmm. Maybe the problem is that we shouldn't
On 8/19/04, [EMAIL PROTECTED] (David Green) wrote:
On Aug 14, 2004, at 5:52 PM, Larry Wall wrote:
for all $*IN # all() is junction
for each $*IN # each method wants closure if we follow Ruby
for next $*IN # next $foo is a loop exit
[...]
Each and every are the obvious choices
On 8/19/04, [EMAIL PROTECTED] (Luke Palmer) wrote:
David Green writes:
Hang on -- should we be saying for each $foo or for $foo.each
anyway? We don't say for @foo.each; the iteration is implicit. So
I'm thinking it should be for $foo or while next $foo.
Well, Cfor $foo gives you a one
On 8/19/04, [EMAIL PROTECTED] (Larry Wall) wrote:
It's hard to come up with an English word that means next in scalar
context but all in list context.
I never know whether to name my arrays singular or plural, either. =)
But couldn't there be Two Ways To Do It? One singular name and one
On 8/20/04, [EMAIL PROTECTED] (Luke Palmer) wrote:
So all the laziness goes into the array implementation. But you don't
even need to write your iterator fancily. If you just write your scalar
version of postcircumfix:, Perl will do the rest.
So if you use an iterator in list context, Perl will
In [EMAIL PROTECTED], [EMAIL PROTECTED] (Aaron Sherman) wrote:
This bit of POD made me think about POD's lack of tabular formatting, a
common idiom in technical documentation. I know POD is still in the
wings, as it were, but I wanted to say this before I forget
/me flings coffee cup
On 8/23/04, [EMAIL PROTECTED] (Rod Adams) wrote:
What if we add Cdoc attribute that the execution compiler would
discard, but POD compilers (and debuggers) could make use of? I
believe that would even allow a particularly stringent corporate
policy to create a flavor of 'strict' which required
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Larry Wall) wrote:
I'm still thinking A is the first one and Z is the last one. Someone
talk me out of it quick.
Just think of all the trouble it would cause in the summaries:
'Meanwhile, in perl6-language, there was much discussion about Z.
On 2004/9/04, [EMAIL PROTECTED] (Larry Wall) wrote:
Yow. Presumably nth without an argument would mean the last. So
@ints[1st..nth]
means
@ints[*]
Yeah, I was thinking something like that. And if the arg is an actual
array, maybe it returns the max dimension(s)? I think you'd get
On 2004/9/04, [EMAIL PROTECTED] (Jonathan Lang) wrote:
(Nice Subject change, I almost missed it!)
Larry Wall wrote:
Yow. Presumably nth without an argument would mean the last.
If it means the last, why not just use Clast?
Conflict with last LOOP? Hm, the context should be enough to
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Luke Palmer) wrote:
sub wn($n) { $n ?? wn($n-1)+1 :: $w }
$w2 = 0... + wn«0...;
assert($w2 == $w*2);
Just think of the possibilities! :-)
Hm. Needs more Unicode. =)
Seriously though, putting 1st, 2nd, nth, etc. in the language is
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Jonathan Lang) wrote:
No problem here, especially if C0th and Clast are synonyms - that is,
make ..., -4th, -3rd, -2nd, -1st, 0th, 1st, 2nd, 3rd, 4th, ... be the
underlying mechanism, and define Clast and Cfirst as synonyms for
C0th and C1st.
On 2004/9/06, Larry Wall wrote:
Another possibility is that .[] always forces the normal view of an
array as 0-based, and if you want non-0-based arrays you have to use
the .{} interface instead, on the assumption that strange subscripts
are more like hash keys than ranges of integers.
That's
On 2004/9/10, [EMAIL PROTECTED] (David Green) wrote:
If we consider a generic data structure type (which may or may not be
optimised under the hood for integral indices), then why shouldn't {} be
the index-by-name interface, and [] the index-by-ordinal interface?
(Does that mean [$x] is just
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Larry Wall) wrote:
Here's the proposal.
First the bad news:
* We accept that the C operator requires whitespace
around it, and be prepared to be burned in effigy occasionally.
I wouldn't go that far, although when I inevitably get burned
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Brent 'Dax' Royal-Gordon) wrote:
I'm going to pull a Larry and think out
loud for a minute here. Note that I speak authoritatively here,
Noted. Or not. =)
Treating it like an array is wrong.
On the other hand, what if a filehandle *is* an
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Smylers) wrote:
David Green writes:
I'm not even sure what those double-quotation marks are doing --
[...]
Look back at how Larry defined the guillemets: [...]
So the double-quotes in there are shell-like, though I guess if you
don't have a Unix
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Larry Wall) wrote:
S9 talk about it. We current have things like:
my Cat %pet is shape(Str);
and parameters to types are in square brackets, so it's more like:
my %pet is Hash[:shape(Str) :returns(Cat)];
I still prefer shaped, for
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Matt Diephouse) wrote:
What I mean is that Perl takes an array and makes an iterator out of it.
Sure, you probably don't think about it like that, but the behavior is
the same (who says arrays need to iterate starting at element zero?).
I probably
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Larry Wall) wrote:
Maybe type parameters are just subscripts? [...]
my Fight %fight does key{Dog;Cat};
I like that.
But if English-like is the criterion that'd still read better as
my Fight %fight has key{Dog;Cat};
I like that even
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Matt Diephouse) wrote:
On Sat, 04 Dec 2004 08:59:24 -0700, David Green [EMAIL PROTECTED] wrote:
Cdoes Iterate signifies a role named Iterate. Roles are sort of a
mix of interfaces and mixins (as I understand it -- I'm still waiting
for E12). So
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Smylers) wrote:
No! Avoid synonyms. They're initially tempting, because then everybody
gets to pick the one he/she wants to use, but then it turns out you need
to learn all of them so as to read other people's code, and that's worse
than not
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Luke Palmer) wrote:
But what we'd really like to do is: given the user knows what push/pop
do, what would they *guess* to mean shift (I tend to think that this
is a very good technique for naming).
And, well, I'm thinking pull. So it's a
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Luke Palmer) wrote:
David Green writes:
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Larry Wall) wrote:
Maybe type parameters are just subscripts? [...]
my Fight %fight does key{Dog;Cat};
I like that.
Yeah, me too. Except I'm
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Larry Wall) wrote:
On Mon, Dec 06, 2004 at 03:11:15AM -0700, David Green wrote:
[snip]
: I like that.
: I like that even better.
[etc.]
Um. You're so very...easy to please... I guess I'm okay with that...
=) But you'll notice we didn't hit
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Luke
Palmer) wrote:
Well, we see the same kind of thing with standard interval arithmetic:
[...]
It didn't bother me that junctions weren't ordered transitively.
(Ordering had better work transitively for ordinary numbers, but
junctions aren't
On 12/16/05, Darren Duncan wrote:
The root question of the matter is, what does undef mean to you?
To me it means nothing. (I'm so callous.)
The fact is, that in any normal program, using an undefined value as
if it were a defined one is a bug. Normally there will be a point
where such a
On 1/4/06, Luke Palmer wrote:
The other thing that is deeply disturbing to me, but apparently not to
many other people, is that I could have a working, well-typed program
with explicit annotations.
I don't think it disturbs me... but that might just be because I
don't really understand it.
On 2/8/06, Larry Wall wrote:
From: Damian Conway [EMAIL PROTECTED]
I've now been using Csay (via Perl6::Say) for some time -- testing our
collective intuition on this -- and it turns out that b. isn't the least
surprising. At least, not to me. In fact, I am regularly (and annoyingly)
On 2/8/06, Mike Guy wrote:
I obviously missed that when it went past on p5p. Surely that should read
Any Code()predicate(value) match if $b-($a)
meaning that $a satisfies the predicate implemented by the code $b?
Ignoring $a seems a completely stupid thing to do.
Well,
On 2/23/06, Jonathan Lang wrote:
(Another possibility would be to return a list of every possible
result when in list context, with the result that you'd get in scalar
context being element zero of the list. This even has its uses wrt
sqrt(Num), providing a two-element list of the positive
::Boxchars line first.
#==#
# -David Green #
#==#
On 4/6/06, Larry Wall wrote:
On Thu, Apr 06, 2006 at 10:18:48PM +0800, Audrey Tang wrote:
: TSa wrote:
: And a self($_.bar) is pretty much useless. In other words
: wrongly huffmanized.
:
: FWIW, I agree with both points.
I agree with those points too, but not necessarily the conclusion.
On 7/12/06, Aaron Sherman wrote:
There's a problem here, from my point of view. I'll take it one
assumption at a time:
* $whatever.asObject.id ~~ $whateverelse.asObject.id is true
if and only if $whatever := $whateverelse at some point in the
past, either explicitly, or
On 7/13/06, Yuval Kogman wrote:
So, Larry assisted by Audrey explained the purpose of === vs eqv vs =:=.
It makes sense now, but I still feel that as far as ergonomics go
this is not perfect.
I think I understand it... (my only quibble with the syntax is that
=== and eqv look like spin-offs
On 8/8/06, Darren Duncan wrote:
At 5:25 PM -0700 8/8/06, Darren Duncan wrote:
snip
I'm wondering if it would not be inappropriate to change the name
Str to something more descriptive of its content within the
historical or current wider context.
snip
... I have evolved my thoughts to accept
On 8/13/06, Smylers wrote:
Please could the proponets of the various behaviours being discussed
here share a few more concrete examples which start by explaning a
scenario in which there is a desire to do something, preferably one
that Perl 5 coders can identify with, and then show how
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 semantics like
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 the same thing
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 currently
On 8/16/06, Dr.Ruud wrote:
I also wondered why a simple array (for example containing only value
type objects) whould not C=== its copy.
But with .SKID that must be easy to handle.
That's what I was wondering that started off this thread. I
understand (more or less, I think), why it *does*
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 didn't
On 8/17/06, Reed, Mark (TBS) wrote:
S03, lines 418-420: [cmp] always returns COrder::Increase,
COrder::Same, or COrder::Decrease (which numerify to -1, 0, or +1).
Shouldn't Order::Increase numerify to +1 and Order::Decrease to -1? In
which case it would be clearer to put them in respective
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 9/11/06, Larry Wall wrote:
Only that I'm thinking of renaming all the meta-ish methods to use
interrogative pronouns:
.META- .HOW
.SKID- .WHO
.PKG - .WHAT
.VAR - .WHERE
.WHO and .WHAT strike me as better being swapped. Maybe...
or some such. Not sure
On 1/30/07, [EMAIL PROTECTED] wrote in [svn:perl6-synopsis] r13549
- doc/trunk/design/syn:
+It has become the custom to use negative subscripts to indicate counting
+from the end of an array. This is still supported, but only for unshaped
+arrays:
+For shaped arrays you must explicitly refer to
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 should
On 2/24/07, Jonathan Lang wrote:
In effect, using * as an array of indices gives us the ordinals
notation that has been requested on occasion: '*[0]' means 'first
element', '*[1]' means 'second element', '*[-1]' means 'last
element',
'*[0..2]' means 'first three elements', and so on - and this
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]]; in your
proposal
On 3/7/07, Jonathan Lang wrote:
summary snipped
Looks good to me.
As well, the fact that @x[-1] doesn't refer to the element
immediately before @x[0] is awkward, as is the fact that @x[*-1]
doesn't refer to the element immediately before @x[*+0]. IMHO, it
would be cleaner to have @x[n]
On 2/28/07, [EMAIL PROTECTED] wrote:
Ranges are not autoreversing: C2..1 is always a null range.
I assume the reason for not having ranges automatically go in either
direction is that it would make it easier for subtle bugs to creep in
when either end is smaller (or bigger) than you
On 3/8/07, Smylers wrote:
In Perl 5 if you rely on a feature (or bugfix) from a particular
version of a module you can specify that version and the code will
continue to work with future versions -- which is a reasonably
pragmatic approach, effectively saying until proven otherwise I'll
On 3/8/07, Larry Wall wrote:
Perl 6 is specced to keep all the old versions of modules around in
the library (unless the new version claims to emulate the old version).
Oh, good! So how does a module say that it emulates another version?
(Or perhaps another module altogether...) Does does
On 3/16/07, Darren Duncan wrote:
On Wed, 7 Mar 2007, Smylers wrote:
[...]
Perl is a better language than SQL, in general, [...]
Likewise, we shouldn't have to write in SQL, or in pseudo-Perl-SQL,
but just write in Perl.
A database is supposed to be a base for *data*, after all. I'd love
to
On 3/18/07, Darren Duncan wrote:
On Sun, 18 Mar 2007, Aaron Crane wrote:
That's easy even in Perl 5. This modifies %hash in-place:
my @values = delete @[EMAIL PROTECTED];
@[EMAIL PROTECTED] = @values;
[...]
If %hash contained keys a,b,c and @old_names was a and @new_names
was b,
On 5/29/07, Larry Wall wrote:
Note that any is considered a singular noun in English,
I started to say, Except when it means 'all', but when used that
way, it still would mean all in the singular sense. But it gives
me an excuse to point out that any can be ambiguous in English;
it's not
On 6/21/07, brian d foy wrote:
Couldn't most of this be figured out by making Pod6 extensible (or
whatever the right term is). Pod6 would be more of the syntax and
basic operation, but other people could have custom directives that
their Pod6 translators and formatters could then use.
Yeah,
On 6/21/07, Smylers wrote:
Mark Overmeer writes:
The boundary between freedom and anacharchy is faint.
Indeed. And I'd much rather we err on the side of anarchy.
I'd much rather we didn't err at all! Just because something isn't
perfect doesn't mean it's an error, or that it's not worth
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 agree
On 7/14/07, Mark Overmeer wrote:
[...] I sincerely hope that the summerizor is wrong:
. in the last week, the main people who are not happy with what I've
done have put out a document indicated what they'd like. I'm digesting
that and I'm going to try to explain how it can be made to fit
On 10/6/07, brian d foy wrote:
That looks like it might mean that these are corresponding forms:
8 = 377:8377:8(377)
Now, if I can do that, what happens to the pair form in a hash composer
when I want the key of '8' and the value of :10377?
What happened to the suggestion of using
On 11/29/07, Luke Palmer wrote:
I think you are falling into a classic builtin trap. [...]
Please, you, everyone, forget about the word core. It is an
implementation detail.
Yes! Though it's a natural mistake because people assume that The
CORE(TM) in Perl6 means something similar to the
On 11/29/07, James Fuller wrote:
but by making some fundamental xml processing available by the core
(like file access, regex, and a host of other fundamental bits n
bobs), u do promote a common and systematic approach to working with
XML in all perl modules.
As everyone else and his dog has
On 11/29/07, James Fuller wrote:
well, if my previous posts didn't attract flames this post
certainly will ;)
Nah, this is getting into the interesting language part!
(Technically, it should be perl6+xml-language... but then the goal of
perl6 is to be infinitely flexible, so I guess it
On 2008-Jan-26, at 9:58 am, Larry Wall wrote:
My first thought is that this is such a common idiom that we ought
to have some syntactic sugar for it:
say Received $m message\s.
I've always wanted a magic-S (and I don't think the anglocentrism
matters, because Perl is already pretty
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. But Perl still is.
Well
On 2008-Feb-24, at 2:28 pm, Jonathan Lang wrote:
{ use text; if $a 49 { say $a } }
...with the result being the same as Perl5's 'if $a gt 49 { say
$a }' (so if $a equals '5', it says '5'). Am I following you? If
so, I'm not seeing what's so exciting about the concept;
The whole point
On 2008-Mar-19, at 1:40 pm, Mark J. Reed wrote:
On Wed, Mar 19, 2008 at 1:01 PM, Larry Wall [EMAIL PROTECTED] wrote:
The use of + in Python or in C++ is, I think, primarily the
violation of a *linguistic* principle, not a mathematical principle.
Maybe it's just 'cause I cut my teeth on
On 2008-Apr-13, at 4:07 am, John M. Dlugosz wrote:
I'm thinking that 'constant' is more special than other variables,
and that the formal description of strong typing and static types
should say that the compiler =will= implicitly get the type for $pi
rather than making it Any.
Except if
On 2008-May-3, at 5:12 pm, John M. Dlugosz wrote:
Jon Lang dataweaver-at-gmail.com |Perl 6| wrote:
My own understanding of it is that snapshot semantics involves
looking at an immutable copy of an object (a snapshot of it)
instead of looking at the object itself. That said, my
On 2008-May-3, at 5:04 pm, John M. Dlugosz wrote:
What does this mean?
our sub outer ()
{
...
our sub inner () { ... }
}
inner; # defined?
I think this should be illegal. Nested named subs makes sense for
'my', with the rules of visibility matching the ability to clone the
On 2008-May-6, at 6:07 am, TSa wrote:
Just to ensure that I get the our behavior right, consider
sub foo
{
our $inner = 3;
}
sub bar
{
our $inner = 4; # redeclaration error?
}
say $inner;
Does this print 3 even when foo was never called?
No, it throws an
On 2008-May-27, at 8:32 pm, Jon Lang wrote:
[...]
Would it be reasonable to allow hashes to use .[] syntax as something
of a shortcut for .iterator in list context, thus allowing
autosorted hashes to partake of the same sort of dual cardinal/ordinal
lookup capabilities that lists with
On 2008-Apr-30, at 1:29 pm, Brandon S. Allbery KF8NH wrote:
On Apr 30, 2008, at 15:14 , Jon Lang wrote:
On a side note, I'd like to make a request of the Perl 6 community
with regard to coding style: could we please have adverbal names that
are, well, adverbs? is :strict Dog brings to my mind
On 2008-May-27, at 9:40 am, Dave Whipp wrote:
TSa wrote:
method inch
{
yield $inch = $.mm * 25.4;
self.mm = $inch / 25.4;
}
Would you regard that as elegant?
That looks functionally incorrect to my eyes: if the caller resumes
at the time of the yield
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 even need
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., '*$value') in its
On 2008-Jun-2, at 3:30 pm, Jon Lang wrote:
sub foo($value?) is rw($value) { ... }
Or something to that general effect. The parameter in question must
be optional and cannot have a default value, so that a test of
whether or not the parameter is actually there can be used to
determine
On 2008-Aug-9, John M. Dlugosz wrote http://www.dlugosz.com/Perl6/web/return.html
to clarify and extrapolate from what is written in the Synopses:
Third, list assignment will handle assignment to a literal pair by
accessing the names of the items inside the Capture. So list
assignment
On 2008-Sep-23, at 2:32 pm, Michael G Schwern wrote:
My other thought is that since parameters are read-only by default
it's not
thought you'd have to write it much so clarity wins out over
brevity, the flip
side of Huffamn encoding. But that doesn't work out so good for
normal
variable
On 2008-Sep-23, at 8:38 am, TSa wrote:
Moritz Lenz wrote:
In Perl 5 a negative limit means unlimited, which we don't have
to do
because we have the Whatever star.
I like the notion of negative numbers as the other end of infinity.
I think positive values and zero make sense. But I don't
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 IDE should write your verbose code
On 2008-Oct-2, at 6:15 pm, Timothy S. Nelson wrote:
The guys on IRC convinced me that the way to go might be something
like a grammar, but that does trees and tree transformations
instead of a text input stream. See the IRC log for details :).
[...]
TimToady note to treematching folks: it
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 block or ident, it would be very
useful to look for parameters by their type
On 2008-Dec-2, at 12:33 pm, Geoffrey Broadwell wrote:
On Tue, 2008-12-02 at 08:50 +0100, Carl Mäsak wrote:
Darren ():
How does one write anonymous value literals of those types?
Why is the latter method [conversion] insufficient for your needs?
Efficiency reasons, among others.
Surely the
On 2008-Dec-3, at 10:18 am, TSa wrote:
Darren Duncan wrote:
Strong typing in Perl means that Perl is conveniently and reliably
keeping track of this user-intended interpretation of the data, so
it is easy for any piece of code to act on it in a reasonable way.
Strong typing lets user code
On 2008-Dec-4, at 9:42 am, TSa wrote:
I remember the state of affairs being that [div] returns an Int
Something more explicit like idiv was suggested for integral
division. Personally, I'm happy not to have anything special provided
for it, on the grounds that having to say, e.g.
On 2008-Dec-4, at 4:41 pm, Leon Timmermans wrote:
On Thu, Dec 4, 2008 at 6:34 PM, TSa [EMAIL PROTECTED]
wrote:
And how about 'Num 1.0 === Complex(1,0) === Int 1'?
IMHO the spec on === is quite clear: two values are never
equivalent unless they are of exactly the same type.
I guess the
On 2008-Dec-4, at 3:08 pm, Mark J. Reed wrote:
Using div instead of / should make it pretty clear that you're
disposing of the remainder.
I misremembered div vs. idiv, but how standard is it? I know div
commonly means int division, but not always. On the one hand, some
things you just
On 2008-Dec-4, at 9:09 am, Aristotle Pagaltzis wrote:
And while it does seems like a closure trait, that seems somewhat
problematic in that the order of evaluation is weird when compared
to other closure traits, which I suppose is what led you to declare
the “coy” solution as the most
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 come
first
On 2008-Dec-14, at 11:21 am, Moritz Lenz wrote:
Uri Guttman wrote:
how is sort ordering specified?
Currently it is not specified, it defaults to infix:cmp. If you
can suggest a non-confusing way to specify both a transformation
closure and a comparison method, please go ahead.
how does
1 - 100 of 179 matches
Mail list logo
