On Tue, Dec 10, 2002 at 11:37:58AM -0800, David Whipp wrote:
> I was reading the "Partially Memorized Functions" thread, and the thought
> came to mind that what we really need, is to define a different
> implementation of the method for a specific value of the arg. Something
> like:
>
> sub days_
On Tue, Dec 10, 2002 at 03:38:58PM -0800, Rich Morin wrote:
> On occasion, I have found it useful to cobble up a "little language"
> that allows me to generate a list of items, using a wild-card or some
> other syntax, as:
>
> foo[0-9][0-9] yields foo00, foo01, ...
>
> I'm wondering whether Pe
On Wed, Jan 22, 2003 at 10:16:50AM +, Andy Wardley wrote:
> On Tue, Jan 21, 2003 at 12:55:56PM -0800, Rich Morin wrote:
> > I'm not a Lisp enthusiast, by and large, but I think he makes some
> > interesting observations on language design. Take a look if you're
> > feeling adventurous...
>
>
On Fri, Jan 24, 2003 at 01:00:26PM -0500, Tanton Gibbs wrote:
> > The problem with cons/car/cdr is that they're fundemental operations.
> > Graham *has* learned from perl, and is receptive to the idea that
> > fundemental operators should be huffman encoded (lambda -> fn). It
> > would be easy to
On Tue, Jan 28, 2003 at 09:24:50AM -0800, Austin Hastings wrote:
> --- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > At 8:47 AM + 1/28/03, Piers Cawley wrote:
> > >> $ref[$key]
> > >>
> > >> an array or hash look-up???
> > >
> > >Decided at runtime?
> >
> > How? People use strings as array ind
On Fri, Feb 07, 2003 at 06:38:36PM -0500, Uri Guttman wrote:
> > "ML" == Michael Lazzaro <[EMAIL PROTECTED]> writes:
> ML> Along those lines, the closest I've been able to come so far to a
> ML> usable two-sentence definition is:
>
> ML> -- A list is an ordered set of scalar values.
>
On Wed, Mar 26, 2003 at 09:19:36AM +, Simon Cozens wrote:
> To what extent should the (presumably library-side) ability to parse a
> given markup language influence Perl 6's core language design? (which
> is what this list is nominally about.) I think this ought to
> approximate to "none at all
Apologies if I've missed some earlier discussions on multimethods. The
apocolypses, exegesises and synopses don't seem to say much other than
(a) they will exist and (b) wait for apocolypse 12 for more information.
Looking over RFC 256[*] and Class::Multimethods[**] it sounds like the
intent is t
On Sun, Jun 01, 2003 at 10:44:02PM -0600, Luke Palmer wrote:
> You must not be following Perl 6 closely enough, then. Perl 6 is a
> "real" programming language now, as opposed to a "scripting" language.
Um, I've followed Perl6 closely enough to know that the distinction
between "real langauge" an
On Mon, Jun 02, 2003 at 10:34:14AM -0600, Luke Palmer wrote:
> And I don't see what's stopping someone from writing Dispatch::Value.
>
> use Dispatch::Value;
> sub foo($param is value('param1')) {...}
> sub foo($param is value('param2')) {...}
>
> What it seems you're wanting is it to
On Mon, Jun 09, 2003 at 01:26:22PM +0100, Piers Cawley wrote:
> Multimethod dispatch?
> Adam Turoff asked if multimethod dispatch (MMD) was really *the* Right
> Thing (it's definitely *a* Right Thing) and suggested that it would be
> more Perlish to allow the progr
Damian just got finished his YAPC opening talk, and managed to allude
to dispatching and autoloading.
As it *appears* today, regular dispatching and multimethod dispatching
are going to be wired into the langauge (as appropriate). Runtime
dispatch behavior will continue to be supported, including
this is fair. It seems that, due to buffering and
other
things, print returns true even when it doesn't actually succeed. But why let
facts get in the way of rhetoric?
[4] The difference is that "no fatal" would only affect code that calls "fail"
itself. The "err" would affect code that directly calls "die", too.
--
Adam Lopresto
http://cec.wustl.edu/~adam/
Eschew obfuscation!
code like
$str .= lc;
$linkedlist .= next;
$structure .= clone(deep => 1);
and such things. Really, making it mean anything else (including nothing at all)
would be counterintuitive.
--
Adam Lopresto
http://cec.wustl.edu/~adam/
perl -le '$_=(split q,",,`$^Xdoc -q japh`)[1].".";y/pj/PJ/;print'
oolean(Complex $self:){
return $self.real || $self.imag;
}
...
then somewhere in a function
return Complex::new(0,0) but true;
Since Complex already has an implementation of whatever method decides whether
it's true or not, wouldn't just applying a property be insufficient to over
) if $id is an object? What happens to $id? Does it
> turn into some kind of limbo object? Does it become undefined? Is it
> right for $subref.unwrap($id) to be able to do that to $id? Is it right
> for $id to be able to do it to itself?
>
> Hmm. Not a very useful email really. Oh wel
turn off warnings for
> the statement it refers to.
Obviously, it's very confident about that code, so it should turn on a maximum
level of warnings for that statement (assured that it will pass).
The modifier to turn off warnings on a line would be ;), winking at us to let
us know it's u
ke eat in this case
>
>D $foo.take $foo.grab $foo.horde
D $foo.drink $foo.sip$foo.slurp
N $foo.taste
Ok, I'll stop now. But I do sort of (very minorly) like sip as a mini-slurp.
>
> That assumes folks think of grab as being singular and take as bei
d
reason to make -> {...} mean -> $_ {...}, using <-> {...} for -> $_ is rw
{...}. A good way to remove one more special case (maybe offsetting the extra
way to declare a sub, and sweeten the whole deal).
--
Adam Lopresto
http://cec.wustl.edu/~adam/
Yesterday upon the stair
I met a man who wasn't there.
He wasn't there again today --
I think he's from the CIA.
then you can't get to the original topic. I think too much
topic-clobbering will be confusing.
say chars($_) > 70 ~~ abbreviate($_) ?? $_; #oops, prints the length
--
Adam Lopresto
http://cec.wustl.edu/~adam/
[MacGyver] is the Martha Stewart of action.
--Patrick J. Mooney
already have ordinals for grammars, so I'm sure we could make 'em work
> here. (Maybe "nth()" is an operator that constructs ordinal-objects?
> (I kind of want a "th" suffix operator so I can do ($n)th. Although that
> doesn't really lend itself to cou
rs, look for archives, etc, but the perl
executable itself wouldn't need anything special (which feels a lot nicer,
since presumably updating the PAR module installed would be a lot easier than
updating perl to support a new archive type). -MPAR could also handle the
directory case, removing
sounds like a good idea, but we can't limit multiple values, so it might be
better if it returns an array. maybe the code should look more like this:
@{value}hash = key
or maybe
@%{value}hash = key
unless this clashes with something else
-Original Message-
From: raptor [mailto:[EMAIL
atic functions as $date.foo() instead of
Date.foo(), and therefore your constructor call would be simply
my Date $date .= new('Jun 25, 20002');
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
perl -le '$_=(split q,",,`$^Xdoc -q japh`)[1].".";y/pj/PJ/;print'
onstructor seems really messed up. I guess that would mean that I
could pass Date.'Sep 21, 1963' to anything expecting a Date object. I think
that might be just slightly too magical for comfort. I don't like the idea of
object types automagically converting themse
o perl 5 size, and many
> would become even shorter than in perl 5.
>
> ______
> Do You Yahoo!?
> Yahoo! Finance - Get real-time stock quotes
> http://finance.yahoo.com
>
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
Dreaming permits each and every one of us to be quietly and safely
insane every night of our lives.
--William Dement
;
> Furthermore, if the caller can pass undef for the second parameter, I
> don't see a way to distinguish in the third variant between a legitimately
> passed undef, for which we don't want $_, and a missing optional argument,
> for which we do.
>
> /s
>
>
--
Ad
any module
to accidentally untaint data. Personally, I think untainting data should
only be the result of an explicit "untaint" function, but maybe that's going
too far.
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
Her hair glistened in the rain like nose ha
tp://www.pobox.com/~schwern/
> Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
> Don't worry, baby, my wrath can be pretty groovy.
> http://www.goats.com/archive/980804.html
>
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
Who are you and what have you done with reality?
--Jamin Gray
es look anything alike. :-P
>
> Mixing OO frameworks is quite useful in some real-world situations.
> Sometimes it's more efficient to change your OO implementation than to
> try to translate your problem to fit the one you're given.
>
> MikeL
>
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
All I want is a warm bed, a kind word, and unlimited power.
stead...
my Bitwise $a = 1; #woohoo, $a and $b are no longer magical!
my Bitwise $b = 3;
print $a & $b; #prints 3
So if you really need to do a lot of bitmath, you use the special types, and
otherwise you can be barely aware that they exist.
sysopen($handle, $filenmae, O_CREAT & O_R
for nasty surprises between:
>
> $str =~ s/a/b/; substitute a for b in $str
>
> and:
>
> $str ~= s/a/b/; substitute a for b in $_ and append result to $str
>
> But I guess that's no worse than:
>
> $x-=10;
>
> and
>
>
> In typical topical string usage, that leaves us with
> >
> > if .subst/a/b/ {...}
> > $result = .where/a/b/
> >
> > That's quite livable, though the second is a bit odd, English-wise.
> > We could even keep around
> >
> > s/a/b/
> >
> > as a shorthand for .subst/a/b/.
>
> Oh, I definitely think so!
>
>
> > And maybe even add
> >
> > w/a/b/
> >
> > as a synonym for .where/a/b/.
>
> Hm. *s*ubstitute and *w*eplace. ;-)
>
> Damian
>
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
I just want a plate and a fork and a bunny...
scalar", but perl5 people
will have to get used to a lot. I think the operators should just be list
based, and if you want otherwise you can specify "scalar:op" or convert both
sides to scalars manually (preferably with .length, so it's absolutely clear
what's meant).
--
Ada
> I don't see why I'd want to do it with arrays, but...
>
> %a_students = %grades{grep /^a/i, keys %grades};
Looks like that's just the same as
%a_students = grep {.key ~~ :i/^a/}, %grades.kv;
(after adjusting for perl6 syntax for a few things)
--
Adam Lopresto
.}
>
> whereas others feel that:
>
> sub square ( Num $n ) is memoized {...}
>
> is more appropriate.
>
> Damian
>
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
"I cannot read the fiery letters," said Frodo in a quavering voice
&q
aller's topic unless it was explicitly
passed an argument.
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
Never be afraid to tell the world who you are.
--Anonymous
works well enough, but just like "unless" somehow
> simplifies the logic by removing that leading !, "purge" can simplifiy the
> array filter:
>
>@members = purge {$_->{'quit'}} @members;
>
> FWIW, I came up with "purge" because
with a :. But
now I'm trying to speculate about Larry's colon, something best left to
others).
But somehow it seems like an increase in readability, especially if things were
renamed. Imagine renaming "grep" to "where" or "suchthat". And then the
antigrep can
razy enough to write a unary comma
operator). So basically we can leave off the parentheses in the usual cases,
but they're still required when you're doing something unusual or that would
otherwise be hard to read.
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
"I have a very firm grasp on reality! I can reach out and strangle it any time!"
. But this is perl, so who cares if
anyone can read it, right?
>
> 4) Some people like the idea of having Unicode operators in perl6.
> Some don't. There are issues with it. Larry hasn't come up with a
> ruling yet. We should wait for his decision.
>
> 5) Sarcasm is, apparently, dead.
I'm not dead yet! I'm feeling much better, really.
>
> MikeL
>
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
What exactly do we mean when we use the word "semantics"?
e a philosophical objection)
> > with making them methods of Array, though, if they're valuable enough.
> > That certainly would seem the common Perl thing to do.
>
> No, namespaces were invented for a reason.
>
> Graham.
>
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
All of our customer service representatives are on vacation. Please hold for
the next available representative.
uld could match
anyway), so it seems silly to force the engine to prefer the first one.
I'm imagining that in the first example, the implementation would
probably build an FSA and process each letter as it comes, while the
second would rely on backtracking.
What think you all?
--
Adam Lopres
101 - 143 of 143 matches
Mail list logo
