On Sun, Oct 01, 2000 at 08:51:04AM +1100, Jeremy Howard wrote:
> > > A prototypeless-function call.
> > >
> > get rid of them all!!
>
> Please no! Anything that makes it harder to write 'quick-and-dirty' scripts
> is never going to fly--this is part of what makes Perl special.
Why? I see no pro
On Thu, Sep 28, 2000 at 11:39:51AM -0400, Karl Glazebrook wrote:
> > > so what is wrong with the statement '@y = 3*@x;' then ?
> >
> > That other constructs *also* create an array context, in which the
> > behaviour of multiplication you propose is not appropriate.
>
> for example?
A prototypel
==
> I lie: the other reason qr{} currently doesn't behave like that is
that
> when we interpolate a compiled regexp into a context that requires
it be
> recompiled,
Interpolated qr() items shouldn't be recompiled anyway. They s
==
RFC 72: The regexp engine should go backward as well as
forward. (Peter Heslin)
Peter says (edited):
:If the regexp code is unlikely to be rewritten from the ground up,
then
:there may be little chance of this feature bein
On Mon, Sep 25, 2000 at 06:30:22PM -0400, Karl Glazebrook wrote:
> > Well, this shows that you entirely miss the problem of cryptocontexts.
> > Context is determined by the "environment" of the operation, not by
> > the operation. Context is propagated:
> >
> > the-left-hand-side-of-assignment
On Sat, Sep 23, 2000 at 11:32:58AM -0400, Karl Glazebrook wrote:
> Yes this is the point. I guess another way of looking at it is
> saying that 3*@a operates in a list context not a scalar context
Well, this shows that you entirely miss the problem of cryptocontexts.
Context is determined by the
On Sat, Sep 23, 2000 at 10:41:07AM +1100, Jeremy Howard wrote:
> > a) You can *already* use vectors as scalars in Perl;
>
> That's not what RFC 82 is proposing.
Who cares? This already works...
> > b) What we are discussing is Perl, not Mathematica, J, PDL, and so
> >forth. These language
On Sat, Sep 23, 2000 at 10:01:11AM +1100, Jeremy Howard wrote:
> > It's now boiling down to a matter of opinion and we'll have to agree to
> > differ. Of course I use array arithmetic all the time as a heavy PDL
> > user.
> It's not just for number-crunchers either. Array notation greatly simplif
On Sat, Sep 23, 2000 at 09:52:51AM +1100, Jeremy Howard wrote:
> > > > $x = 3 * @_;
> > > >
> > > > suddently being equivalent to
> > > >
> > > > $x = @_;
> > > >
> > > > does not look very promising...
>
> Why are these equivalent? RFC 82 only applies in list context. Am I missing
> somethin
On Fri, Sep 22, 2000 at 05:24:55PM -0400, Karl Glazebrook wrote:
> It's now boiling down to a matter of opinion and we'll have to agree to
> differ. Of course I use array arithmetic all the time as a heavy PDL
> user.
...Do you say you are confused by using vectors (=scalars) instead of
arrays?
On Fri, Sep 22, 2000 at 11:17:40AM -0400, Karl Glazebrook wrote:
[Cryptocontext is:]
> > f(3*@a)
> >
> > would typically be a list context - and suddently instead of 3*(1+$#a)
> > you get C.
>
> This is true, what I would propose is we declare 3*(1+$#a) outmoded and
> always have it mean C in
On Thu, Sep 21, 2000 at 03:26:39PM -0400, Karl Glazebrook wrote:
> > [Aside: Why not make ternary-range operator into 10 :: 20 :: 2 ?]
>
> That would work. My point is that having a stride is a fundamental
> feature in other array languages (IDL, Matlab, PDL) and would be
> useful in the perl cor
On Tue, Sep 19, 2000 at 08:05:50PM -0700, Nathan Wiger wrote:
> > $_ is not ALLCAPS. @EXPORT_OK should die (see RFC 233). @ISA is on
> > its way to its grave already, see C.
>
> Yeah, but you're still just sidestepping my point. Your position seems
> poised on the hope that no more special vari
On Tue, Sep 19, 2000 at 07:17:20PM -0700, Nathan Wiger wrote:
> > ==
> > Either way I'm not sure it solves the problem; if each module asserts
> > that *they* are the smarter one then you either wind up with the same
> > situation you
==
> This RFC proposes a minimal efficient well-scaling mechanism for
exporting.
> Only export of subroutines and tags are supported by this
mechanism.
>
Though I'm not completely sure how the implementation works in other
compiled
On Tue, Sep 19, 2000 at 06:39:49PM -0700, Nathan Wiger wrote:
> > The presence of a method STORE is visible outside of the module, and
> > may be &required* if the module follows some published (non-Perl) API.
> > Variables are of different ilk.
>
> I think you're overlooking they can both be equ
==
What if both modules have this :override bit set at the same time?
Does the second one still win? Or does the first one win again?
==
It is wise to live the behaviour
On Tue, Sep 19, 2000 at 08:41:34AM +1200, Christian Soeller wrote:
> > Finally as an overload expert what do you think about the proposals
> > to make arrays overloadable objects so one can say things like:
> >
> > @x = 3 * @y;
>
> Is this where RFC 231's suggestion for OO slicing comes in (see
On Mon, Sep 18, 2000 at 08:56:28AM -0400, Karl Glazebrook wrote:
> Firstly does your proposal allow for a slice like 10..20:2 (i.e. with
> a stride of 2) ?
As shipped: no. But if this is made a primitive (which I would not
like), then the only change which is needed is to make the
tie::multi::r
On Mon, Sep 18, 2000 at 02:31:10PM -0400, Chaim Frenkel wrote:
> How about a Base64 to match with uuencode?
> PRL> This RFC proposes simple enhancements to templates of pack/unpack builtins.
> PRL> These enhancements do not change the spirit of how pack/unpack is used.
> PRL> The semantic is enha
On Sun, Sep 17, 2000 at 11:07:09AM +1100, Jeremy Howard wrote:
> > I repeat: what does
> >
> > $a[ $ind ]
> >
> > does if $ind is a (blessed) reference to array (1,1), but behaves as
> > if it were 11 (due to overloading)?
> >
> How $ind is implemented (ie the actual structure that is blessed)
On Sat, Sep 16, 2000 at 07:15:34PM +1100, Jeremy Howard wrote:
> Why is it important for overloaded objects to be used as array indices?
Overloaded objects should behave the same way as non-objects.
> Why
> does RFC 204 rule that out? RFC 204 simply specifies that a list reference
> as an index
On Fri, Sep 15, 2000 at 03:11:47PM -0600, Nathan Torkington wrote:
> Perl6 RFC Librarian writes:
> > This RFC proposes two-stage autoloading: one stage may be registered
> > to act when the symbol is encountered at compile time, the other
> > when the subroutine is called. Autoloading on the seco
On Sat, Sep 16, 2000 at 11:08:18AM +1100, Jeremy Howard wrote:
> > proposes a convenient syntax to slice multi-dimensional arrays;
> It is hard to evaluate this proposal without more context. In particular:
>
> - How does it relate to RFC 204? Is it an alternative, or an addition?
204 cannot b
24 matches
Mail list logo
