RE: array/hash manipulation [was :what's with 'with'?]
Sterin, Ilya [EMAIL PROTECTED] wrote: Just one question, how would merge behave on two different sized arrays. @a = (1..5); @b = (1..10); merge(@a, @b); ##Would return (1,1,2,2,3,3,4,4,5,5,?? Would it stop on the shortest array. Couldn't quite find such explanation in the RFC. I don't think I specified this in the RFC, since I remember having some debates with Damian and others about it that weren't resolved. Now that I've had a chance to think about this some more, I think the correct behaviour is for the shorter list to reset to the start and continue. It is this behaviour that is the source of J and APL's broadcasting flexibility. For details see: http://www.jsoftware.com/primer/agreement.htm -- Jeremy Howard [EMAIL PROTECTED]
Re: aliasing - was:[nice2haveit]
Bart Lateur wrote:
On Wed, 18 Jul 2001 09:00:25 -0400, John Porter wrote:
for ( $XL-{Application}-{ActiveSheet} ) {
$_-cells(1,1) = Title;
$_-language() = English;
}
(presuming lvalue-methods, of course...)
So, in this case, a with synonym for for would work.
Particularly if '$_' was implied... So with Perl 6's '.' replacing '-',
and 'with' aliasing 'for':
with ( $XL.{Application}.{ActiveSheet} ) {
.cells(1,1) = Title;
.language() = English;
}
Heh. That is nice and compact... although it's getting hard to tell it
apart from VB ;-)
--
Jeremy Howard
[EMAIL PROTECTED]
Re: one more nice2haveit
I've go tired of typing :), but if I had current index-iterator ( say under $i just as example) at hand the way I have $_ i can just type : print $_ : $b[$i]\n for @a; OR print $a[$i] : $b[$i]\n for @a; For a general solution to this see Buddha Buck's RFC on iterators: http://dev.perl.org/rfc/207.html -- Jeremy Howard [EMAIL PROTECTED]
Re: You can't make a hot fudge sundae with mashed potatoes instead of ice cream, either.
I haven't been tricked into reading MJD's article yet, but might your third option be multiple functions with parameter-type-based dispatch? We can do that with perl 5, but it isn't automatic. The problem with polymorphic functions is you have to rewrite the function N times (where N == the number of different types you want to handle). Its certainly a possiblity, it just seems rather inelegant. Rather. Why write the same function multiple times with nothing but the type specifier changed, when you could just write it once with a type placeholder? This is all that a template is. Templates have a bad rep, and fair enough too because their implementation has been pretty iffy. But think about the reasons there have been problems: - Inconsistent implementation in compilers (still no compiler supports all ANSI template features) - Frivolous 'variable name too long' warnings because of implementation SNAFUs - Frivolous 'template depth' errors and warnings - Over-enthusiastic use of generative programming (e.g. expression templates); leads to slow compilation and unearths subtle compiler bugs. Nothing here is fundamental to the concept of templates. If we stayed away from trying to use them for compile-time computation (ie generative programming) and just made them a convenience for identifying type errors, I think it could work. The next paragraph is a wild and wacky idea--feel free to ignore it as being highly eccentric... The idea of a type hierarchy is not mutually exclusive with templates, BTW. In fact, it's not hard to envisage a template syntax that allows type placeholders to indicate allowed types (or probably actually interfaces). The problem in C++ (that doesn't do this) is that the compiler won't stop you from instantiating a templated class with a type that is not supported by the class (by 'not supported' I mean that the type doesn't have an overloaded operator required by the class, resulting in an error). Imagine something like (imixed up in a strange Perl/C++ blender): my listint $iList(1,2,3); my listint $rList = reverse($iList.begin(), $iList.end()); *** compile error: function 'reverse' requires type supporting 'bidirectional iterator' interface -- Jeremy Howard [EMAIL PROTECTED]
