> Many mechanisms exist to make perl code and data persistant. They should
> be cleaned up, unified, and documented widely within the core
> documentation.
>
But doesn't this go against TMTOWTDI. :)
Different people might have different requirements. Portability would want
all ASCII, large app
> my/our @array :hashsyntax;
>
> would hide the definition of %array in the same way that
>
> my/our %array
>
> would hide a prior definition of %array. And references to %array
> would thenceforth actually be references to the keyed array @array.
I can see massive confusion from th
I'll be brief because windows just crashed on me.
First, the current debugger allows multi-lines if you use "\" at the end of
the line ( a la C ).
Second, lexically scoped variables will dissapear on subsequent debugger
lines since their scope is wrapped in an eval. For the most part, the
debug
> More functions from set theory to manipulate arrays
>
> I'd like to use these functions in this way :
>
> @c = union (@a, @b);
> # wich is different from @c = (@a, @b) because union do not duplicate
> same elements
>
> @c = intersection (@a, @b);
> @c = diff(@a, @b);
>
Elements of this ar
- Original Message -
From: "Perl6 RFC Librarian" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, August 29, 2000 8:59 PM
Subject: RFC 2 (v3) Request For New Pragma: Implicit
> Request For New Pragma: Implicit
Good idea, but you have it backwards.. If
Personally, I prefer a python, or matlab implementation:
array1 = array2[ start : stop ].
Of course, In perl we have the .. operator. This method has just always
seemed intuitive to me. Granted an explicit function call (or gasp, another
reg-ex like call), aids the newbies eyes. The trick in
> my var; # declaring a scalar
> my array[]; # declaring an array
> my hash{}; # declaring a hash
Though the declarations seem fine, I assume that you propose this to be
optional at usage time, since variable interpolations such as
"xxx${var1}xxx${var2}xxx" really need the prefix. One of