Re: backticks (or slash, maybe)
Miércoles 14 Abril 2004 14:18, Juerd wrote:
I propose to use ` as a simple hash subscriptor, as an alternative
to {} and . It would only be useable for \w+ keys or perhaps
-?\w+. As with methods, a simple atomic (term exists only in
perlreftut, afaix, but I don't know another word to describe a
simple scalar variable) scalar should be usable too.
If we really need a ultra-huffman encoding for hash subscriptors, I
have always dreamt of being able to do:
%hash/key
$hashref/foo/bar/baz/quux
...
If only because of the filesystem analogy. Because a filesystem is
really just a very big tied hash, isn't it?
The idea would be be to replace the %hash{'key'} notation by the slash
one, thus making {} always mean a closure without nothing to do with
subscripting.
It would work just like with methods so we would have:
%hash/key # like $obj.method
%hash/$key # like $obj.$method
%hash/{ some_func() } # dynamic key
%hash/«key1 key2» # hash slice
%hash/['key', 'key2'] # the same
The benefits I see in terms of clarity are:
* {} means one thing (closure) and just one
* « and » have only two meanings (literal array and hyperoperator)
instead of three
* «a b» and ['a', 'b'] are always substitutable, ever
The cultural assumption of / as a subscripter is further reinforced
with the omnipresence of xpath these days. We could play some tricks
with this, too. A xml library could make every node a tied hash,
effectively embedding a good portion of xpath within perl:
my $price = $doc/books[14]/price;
for $doc/books - $book {
print Price is $book/price and title is $book/title;
}
(scalar and array context with help us to overcome the an xpath
expression always returns a sequence syndrome)
Pushing the analogy a bit too further away, one could hack the grammar
so that a leading / does indicate the root directory in the system
(and a leading ./ indicates the current directory), thus letting me
write:
for /home/angel - $file {
print $file;
}
Which looks cute for shell scripting, althought a bit dangerous maybe.
And so on...
The beauty (?) of this is not so much in that we should play these
tricks, but in that we are reusing a good deal of cultural background
in them.
Oh, and saving a few keystrokes when you are dealing with hashes the
whole day (say, because you are using DBI, or extracting some data
from an XML document, or whatever) is not totally unpleasing.
-angel
Re: Funky «vector» operator
Viernes 19 Marzo 2004 13:08, Andy Wardley wrote: I'm so happy! I just found out, totally by accident, that I can type the « and » characters by pressing AltGr + Z and AltGr + X, respectively. Apologies if this is common knowledge, but it was news to me, and I thought I'd share this little Perl6 of wisdom. Hi Andy, Well, I did not know about it, so you can be sure that your message has enlighted at least one poor soul. By the way, it has never been easy to write Perl in certain keyboards. The spanish keyboard doesn't have the so perlish character ~, and one must use a different combination depending of your OS (like Alt + 126 or Alt + ¡ or Alt + ñ). Most people know about this sequence because the ~ character is a common one in URLs, so the situation is not as bad as i may look. Neverthless, I definetly hope that a future FAQ of perl6 has a big section labeled How do I Write These Funky Chars in My OS. And making a final big show of my ignorance: does anyone know if there is a easier way to write « and » in windows than ALT + 0171 and ALT + 0187? -angel
Re: The Sort Problem (was: well, The Sort Problem)
Friday 13 February 2004 15:02, Dan Sugalski wrote: If you're *really* looking to get fancy, why not just allow the sort specification to be done with SQL? Comfortable, well-understood, already has a decade or so of stupid things welded into it [...] Heck, you could even unify map, grep, and sort [...] That would be postmodern indeed. -angel
Re: is static?
block. Perhaps we should just go with that: property $foo = 0; Or whatever word we choose, I don't care: prop $foo = 0; What about: prof $foo; $foo = 0; Is this equivalent to prof $foo = 0? If it is not, I would claim this to be a major violation of the principle of minor surprise. Maybe it would be saner to use: prop $foo is default(0); Otherwise the mythical unwarned user would think that $foo = 0 is executed on every call to the subroutine. -angel
Re: [SUMMARY] A6: Type Inference (was Re: A6: Strict signature checking)
Friday 14 March 2003 20:06, Michael Lazzaro wrote: 3) If an untyped var is used for a typed parameter, a simple dataflow analysis is used to determine whether the compiler can guarantee that, at that point, an untyped var will _always_ contain values of a known, specific type. If so, the type is inferred (silently or with a warning, according to pragma?) Otherwise, it is a compile-time error. Uhh.. I am emphatically against this. We cannot depend on the compiler data-flow analysis because: - It won't be very good (because of perl's ultra-dynamism) - It may improve as we put more effort on the compiler, so some program that works in perl6.4 may fail on perl6.2 - It may degrade as we add more (evil) features on the language. (Or otherwise it may prevent us from adding more (evil) features in the language in some future without breaking BC) - It's hard to predict. I would rather have an allways-complain or an allways-forgive policy, than to have a complain-or-forgive-depending-on-the-weather- -in-Canary-Islands policy. -angel
Re: A6: Strict signature checking - was: Complex Parameter Types
Damian Conway wrote:
But large projects -- where typing will be most important --
*can't* deal with that. That's the point of typing: to specify and
enforce interface contracts. At compile-time if at all possible.
One quick question about this. If I write:
sub foo (Bar $f) {..}
my $x = some_function_that_returns_bar();
foo($x);
Will this fail because the compiler _requires_ that the type be known
at compile-time, or will it work because it will the delay the
type-checking until run-time?
-angel
Re: L2R/R2L syntax
I have to wonder how many people actually like this syntax, and how
many only say they do because it's Damian Conway who proposed it.
And map/grep aren't specialized syntax, you could do the same
thing with a sub with a prototype of (block, *@list).
I have to say that I am not specially entusiasthic about the ~
syntax.
I'd feel more confortable with a plain OO syntax:
@out = @in.grep({...}).map({.}).grep({...});
But my prefered option would be to ban map and grep alltogether,
replacing them with a non-void context for, enhanced with a where
clause:
@out = for @in where {...} {
...
}
The simplest cases don't get so horrible:
@out = map { $_* 2 } @in; # P5
@out = for @in { $^a * 2 }; # P6
@out = grep { $_ 0 } @in; # P5
@out = for @in where { $_ 0 };# P6
(Notice the implied {$_} in the for body)
And if you are really planning to chain nine different greps/maps/.. I
am afraid no amount of beautiful or ugly syntax will help you much.
Overall, I am worried that we are putting too much effort in creating
optimal syntaxes for some very specific cases.
This happens to be also my complain about hyperoperators (sorry for
bringing this again). Too much syntax, for a so small value.
I have always favoured RFC 207[1] syntax instead of hyperoperators
because it, at least, gives you some extra power:
@mat3 = @mat1[|i,|j] * @mat2[|j,|i]
But that's a different story,
-angel
[1] http://dev.perl.org/rfc/207.html
Re: seperate() and/or Array.cull
Michael G Schwern wrote:
and that's just entirely too much work. I'd love to be able to do
it with a grep like thing.
(@switches, @args) = seperate /^-/, @ARGV;
seperate() simply returns two lists. One of elements which match,
one of elements which don't. I think Perl 6 will allow the above
syntax to work rather than having to play with array refs.
It would be nice to make it work with more than two arrays too.
Something like this:
(@upper, @lower, @mixed) = @array.sep {
when /^[A-Z]*$/ {0}
when /^[a-z]*$/ {1}
default {2}
}
But it looks a bit dangerous, because the following won't work if
@array has numbers in it:
(@false_members, @true_members) = @array.sep { $_ }; # bad
Maybe the solution is to make it hash-wise:
%hash = @array.sep {
when /^[A-Z]*$/ {'uppercase'}
when /^[a-z]*$/ {'lowercase'}
default {'mixedcase'}
}
-angel
RE: Continuations
Damian Conway wrote:
The formulation of coroutines I favour doesn't work like that.
Every time you call a suspended coroutine it resumes from immediately
after the previous Cyield than suspended it. *And* that Cyield
returns the new argument list with which it was resumed.
So you can write things like:
sub pick_no_repeats (*@from_list) {
my $seen;
while (pop @from_list) {
next when $seen;
@from_list := yield $_;
$seen |= $_;
}
}
# and later:
while pick_no_repeats( @values ) {
push @values, some_calc($_);
}
Allowing the list of choices to change, but repetitions still to be
avoided.
I understand that this formulation is more powefull, but one thing I like
about python's way (where a coroutine is just a funny way to generate lazy
arrays) is that it lets you _use_ coroutines without even knowing what they
are about.
Such as when you say:
for $graph.nodes { ... }
..nodes may be implemented as a coroutine, but you just don't care about it.
Plus any function that previously returned an array can be reimplemented as
coroutine at any time, without having to change the caller side.
In other words, how do you create a lazy array of dynamically generated
values in perl6?
Maybe it could be something like this:
$foo = bar.instantiate(1, 2, 3);
@array = $foo.as_array;
-angel
Re: perl6-lang Project Management
1) We find a team of volunteers who are willing to own the task of converting each Apocalypse into a complete design. If nobody wants to write the Perl 6 user manual, then we might as well give up and go home now. So far we only need to find four, though, so it Might Just Work. I would prefer to work from perl5 documentation. Because: - some documents can be already written, even when there is not yet an Apoc tallking about them. (for example, perlvar shoud be reasonably easy) - Apocalypses talk about a big number of issues, while perl5 pods are already structured in documents of reasonable length. - The sorther length of perl5 pods documents makes it much easier for a single person to make the specific task. People would volunteer for a document, and write and send it for review in a separate list from perl6-language. There should be someone to finally aprove the tentative version. It could be someone with experience in perl5 documentation, and not necessarily from the design team (because the task is about documenting, not creating). -angel
Re: perl6-lang Project Management
We started off with an intense RFC process. This produced many good ideas, not-so-good ideas, and ideas with potential but desperately needing polish. If you'd like a recap, you might try MJD's article on the subject (http://www.perl.com/lpt/a/2000/11/perl6rfc.html). One of the major things that was lacking from the RFC process was focus. The advantage of community contribution is that it brings out good ideas from many different perspectives. The disadvantage is that the ideas form no coherent whole. Larry was the obvious choice to provide the needed focus. The fact that the RFC process did not well as we all expected doesn't mean that the community has to remain silent for two years, or that the only authorized way to express should be perl6-language. Coding is not the only useful thing we can do while we wait for the design to finish. While Apocalypses are great to show (and justify) the changes, they are no substitute for the a language reference, or for user-oriented documentation. So, while we all wait for Larry to wait the design, is there any reason not to start working in the documentation? This would serve for: - Consolidating Perl5 documentation + Perl6 Apocalypses/Exegesis/.. and merging it all into a single reference. - Finish the details that may be not complete in the Apocalypses (there are plenty of them) - Create tentative references for boring things, that may be revised/updated with Larry's coments. We can avoid the RFC nightmare by: - Working in a structured way: for example replicating the structure of perl5 documentation. - Working _independently_ of Larry. There is no need for Larry to spend time reading or fixing the documentation generated by the Documentation Group. Discussion could be done in a separate list (perl6-documentation?) and it would be the Documentation Group's responsability to update the documentation whenever an Apocalypses invalidates it. It's like this: Larry writes the Apocalypses, Damian the Exegesis, and the community writes the Cathecism (a codified, detallied and anonymous explanation of the most boring details of the faith, written in a form that plain people can understand). -angel
Re: plaintive whine about 'for' syntax
Wednesday 30 October 2002 22:08, Michael Lazzaro escribió:
On Wednesday, October 30, 2002, at 12:48 PM, Dave Storrs wrote:
for a; b - $x is rw; $y { $x = $y[5] };
I agree that it's an eyeful. How many of your issues could be
solved if the above were just written:
for (a;b) - ($x is rw; $y) { $x = $y[5] };
Would that suffice to make it clearer?
MikeL
Then let's make the parens required when there is more than one
stream.
Sane people will put them there anyway, and it will force the rest of
us to behave.
It also solves the ;-not-a-line-seperator problem.
-angel
Re: labeled if blocks
And maybe: A bitwise operator is just a logic operator scoped to a set of bits. That's why I can't accept a characterization of ++|+X - bitwise operations on int += +|= +X= ~~|~X - bitwise operations on str ~= ~|= ~X= ??|?X - bitwise operations on booleans ?= ?|= ?X= as UME (Unnecessary Multiplication of Entities). The things you see there aren't entities--rather, they're decomposable to entities that are reused from elsewhere. The *only* new thing is the grammar rule that says you can modify a logic operator with a context operator. I would submit that some_big_long_term ~| some_other_big_long_term is much clearer than ~some_big_long_term .| ~some_other_big_long_term because you have the same problem as when you move the parenthese out front of the function--the context is further away. Plus we still have to reason out what the polymorphic operator is going to do. Could we please, please, please have bitwise operators be out of the core. We expect that they are not going to be used by the average user, so it looks fair to apply the ultimate negative huffman enconding: they need to be specially required. A simple use bitwise would be ok. That would provide a proper manpage to explain the meta-operators thing, and would shorten the main list, which is something that we desperatelly need. On other order of things: if it is about providing context to an operation, wouldn't an adverb be more natural? So it would be something like this: $c = $a | $b;# superposition $c = $a | $b : int; # integer bitwise $c = $a | $b : str; # char bitwise $c = $a | $b : bool; # bool bitwise This can be expanded to other context-requiring cases: $c = $a / $b;# float division $c = $a / $b : int; # integer division Admitedly, it's more verbose. But again this is Huffman encoding at use. Or, speaking aloud, we could move the adverb just along the operator, tying them together visually: $c = $a |:int $b; $c = $a :str $b; But honestly, that looks weird. -angel
Re: [OT] Power of Lisp macros?
Speaking about macros, I renember reading somewhere something about Scheme hygenic macros, but i didn't really understood it. Do they solve the maintenance problems of Lisp macros? Would they be applicable to perl? Thanks for any tips, -angel
Re: perl6 operator precedence table
At the moment I like like the best, actually...
like is beautiful for old-style regex matching, but I find it
confusing for the new smart abilities:
$varlike Class:Foo # $var is instance of Class:Foo
$item like %hash # %hash{$item} is true
$digit like (0..10) # $digit is in 0..10 range
array1 like array2 # array intersection
$numlike f# f($num) is true
All this ones fit more with the concept of mystical analogy hinted
by =~ than with the plain similarity that one would expect from
like
Oh, and =~ looks much more intimidating, which is good, given its..
err.. power.
-angel
Re: Indeterminate math
Mathematically, 1/0 is whatever you define it to be. Well, sure. That's as axiomatic as saying, mathematically, the number one is whatever you define it to be. But a mathematical system that has a definition which is inconsistent with the rest of the system is a flawed one. If you let 1/0 be *anything*, then ordinary algebraic logic falls apart. Those silly proofs where it is proven that 1 = 2, 1 + 1 = 1, etc., all depend on division by zero being possible (regardless of what its value is). You have to keep division by zero illegal to avoid these absurd results. Hence, to my mind at least, exception-throwing or NaN is a better solution than infinity. My point was that there is no stone-carved mandate of the ancient mathematicians saying whether the value of 1 / 0 is defined or not. I did not intend to say that you could assign it any value. It is general practice among mathematicians to say that is undefined, but it is also general practice among other respectable ocupations to say it is something like infinite, and both approaches can be formalized. But of course, as you said, this is largelly irrelevant to the actual discussion. My personal opinion is that a language that lets you add apples + oranges and get 0, shouldn't be too picky about 1 / 0 not being a proper number. -angel
Re: [ANNOUNCE] Perl6 OO Cookbook, v0.1
Hi,
Many thanks Michael, this is very useful, really. I had lost all the
OO discussion and this document is very helpful.
I really like the part of context transformations, I hope something
like this gets in.
Just a silly note:
Recipe 1.9: Using Subroutines as Objects
Problem:
You want to use a subroutine as if it were an object.
Solution:
Just do it:
sub mysub { ... };
my $var = mysub.foo;
I think it was said that the way to avoid the ambiguity here is to add
to sub name.
For example:
my $var = msyub.foo; # call foo method on mysub object
my $var2 = mysub.foo; # equivalent to mysub().foo()
Best,
-angel
Re: Passing arguments
Larry said: BTW, latest leaning is toward = rather than //= for parameter defaults, ... Horray! Sorry. Couldn't resist. :-) -angel Simple men are happy with simple presents
Perl6 currying
Hi,
I was reading Damian's new excellent diary entry in which he explains the
new currying syntax for Perl6.
(For the lazy ones it's reachable at
http://www.yetanother.org/damian/diary_latest.html)
This new feature allows to partially fill place-holder functions, such as:
my div = {$^x / $^y};
my half= div(y=2};
print half(6); # 3
This is a very neat feature, and very useful, as it's explained very well on
Damian's page.
But I am not sure I like the syntax. The problems I see are:
- You only can curry placeholder-generated functions. So if you intend to
make a function curryiable, you are forced to use place-holders, even if
that's not the cleanest way of programming it.
- This means that the creator of a function needs to impose a policy on
whether he expects the function users to use currying or not. A module
creator and user could have different point of views about it, creating
unnecessary conflict between the human race.
- From the caller point of view, the only distinction between a function
call and a currying pseudo-call, is the number of parameters.
div(6,3) # is a function call
div(6)# creates a new curryied function
So, in order to see if a expression is a function call or a magic currying,
you need to count (!) the number of parameters, without any visual clue
suggesting it.
- You cannot use advanced perl 6 features (like optional strict typing, or
default values for function parameters), on curryiable functions.
I would instead propose that every function object supports a curry
method, that performs such operation.
For example:
sub div($x,$y) {$x / $y}; # of div = {$^x / $^y}
my half = div.curry(y=2);
print half(6); # 3
This solves the unnecessary placeholder-currying marriage, and it is
certainly a more explicit syntax.
Incidentally, a newbie user would learn that there is a curry method being
called, and could google curry perl and even find some useful docs.
(In my humble opinion, this is something that is too many times forgotten in
the perl world. With the ultra-compact, idiomatic syntax, it is __very__
hard to learn perl the google way).
What do you think about it?
-angel
RE: PMCs, setting, and suchlike things [forward from p6-internals]
my Complex $c = 3+4i;
my Complex $d = 4i;
my $plain = $c / $d;
Does $plain (which is actually '3' after reducing) get promoted to
Complex, or does the result from the division get demoted?
In a related matter, computer languages with Symbolic Mathematics
capabilities, like Mapple, let you explicitly demand where do you want the
operation to take place.
This could be done naturally in perl6 using the colon meta-operator:
my $plain = $c - $d : Math::Reals # 3.0
my $plain = $c - $d : Math::Complex # 3.0 + 0i
As long it is well documented and consistent, it doesn't really matter which
one is the default.
Adding this feature is useful in a wider area of applications:
2 ^ 4 : Math::FiniteField(7) # - 1
Or even:
sqrt(2 : Math::Integers) # - exception or not-a-number
sqrt(2 : Math::FiniteField(7)) # - 3
sqrt(2 : Math::TrueReals) # - sqrt(2)
In general, any mathematical operation should be capable of taking
optionally the structure where the operations is defined, and a whole
universe of fun will open for us mathematicians.. :-)
(Just think of factoring polynomials in F[25][X] over its algebraic
closure... mmm...)
This can be implemented having operations defined as:
sub operator:DIV($a, $b : $structure) {
if $structure and $strcture.can('DIV') {$structure.DIV($a,$b)}
elsif $a.can('DIV') {$a.DIV($a,$b)}
elsif $b.can('DIV') {$c.DIV($a,$b)}
else {..throw exception..}
}
On the other hand, it is (it will be) perfectly possible to do it as an user
module, so this post it's actually a big OT, and you should better forget
it, in case you have been unfortunate enough to read until here...
Oh. Damn.
-angel
RE: PMCs, setting, and suchlike things [forward from p6-internals]
my $plain = $c - $d : Math::Complex # 3.0 + 0i sqrt(2 : Math::Integers) # - exception or not-a-number Not a bad idea,. I beleive that the perl6 adjective operator (for functions) will be a semicolon, not a colon. I'm not sure how it is planned to apply it to operators. Its also plausable to use properties: my $plain2 is Math::Complex = $c - $d. That would require overloading the '-' operator based on return type; and could get a bit nasty. The nice thing about being per-operation (or per-function) is that in some cases, the place where you want to define the operation is not alone defined by the operands. Is more like a kind of enviroment where things happen. While most cases can be handled with a rich type system, others do need explicit information about the structure where the operation is defined (although, to be honest, they are probably the lesser). [The example I've got in mind is factoring a polynomal, where the type of the object (Polynomal of real parameters) doesn't determine the place where you factor it (over Q, R, a finite extension, ...? ) ] A second one (probably more important) is that with adverbs you can use both classes (Math::Complex) and instance objects ( Math::FiniteFields::F(8) ) as long as they have the right set of methods. I don't know if you can say : my $plain2 is $structureObject = $c - $d; do you? This allows structures to be user-constructed objects if needed (and only if needed), and thus in theory (probably only in theory) you could even define an algebra of structures. And finally, I find some syntatic pleasure in: print [0,2,3] * [1,3,4] : $myEuclidianSpace; -angel who must have taken the rant pill today...
RE: Perl6::Tokeniser
Simon wrote: : Have you an idea about what will be the 'final' : parser for the Perl 6 compiler ? (LALR(1), like Perl 5 ?) : :Yep, LALR1, probably yacc generated. I recall reading somewhere that Perl6 was going to be parsed by something very much like Parse::RecDescent, just that faster. ¿has this changed, or it was never said so? -angel
RE: [dha@panix.com: Re: ^=~]
Damian Conway [mailto:[EMAIL PROTECTED]] wrote:
You *could* instead consider reversing the arguments to all the list
manipulation operators:
@result = map @data { mapping() }
@result = grep @data { selector() };
@result = sort @data { comparison() };
@result = reduce @data { combinator() };
I would love this. From an OO point of view, it looks much more natural imho
to think on map and friends as list methods that take block arguments than
as block methods that take arrays as arguments.
In other words:
@result = @data.map(mapping)
looks better than:
@result = mapping.map(@data)
Then you would have the possibility of:
@result = map @data - $x { mapping($_, $x) }
...
I am afraid I don't understand this one. ¿Which value is $_ suposed to get?
The Perl5-ish:
@sorted_by_size =
map { $_-[0] }
sort { $a-[1] = $b-[1] }
map { [$_, -s] }
@files;
would become:
@sorted_by_size =
map sort map @files
{ [$_, -s] }
{ $^a[1] = $^b[1] }
{ $_[0] };
Though I suppose the method call approach solves that nicely too:
@sorted_by_size =
@files.map( { $_[0] })
.sort({ $^a[1] = $^b[1] })
.map( { [$_, -s] });
with the operations reading left-to-right, down the page.
Mmm.. If we did reverse the order of the arguments I was expecting it to
become:
@sorted_by_size =
@files.map({ [$_, -s] })
.sort({ $^a[1] = $^b[1] })
.map({ $_[0] })
Or if that was not decided, then I would expect:
@sorted_by_size = { $_[0] }.map (
{ $^a[1] = $^b[1] }.order (
{ $^a[1] = $^b[1] }.map (@files)
)
);
By the way, assuming the order of list manipulation operators was actually
reversed, ¿would the following be correct perl6?
@sorted_by_size =
@files.map - $file { [$file, -s $file] }
.sort - @a, @b { @a[1] = @b[1] }
.map - @pair { @pair[0] }
--
Angel Faus
[EMAIL PROTECTED]
Apoc4 - A little wish
Hi all,
I have just one syntatic wish for Apoc4 (which in all other points I
find utterly fantastic).
Could we have:
foreach $item in @arr {...}
Instead of
foreach @arr - $item {...}
I find the first one:
- Much more pleasent to the eyes and less noisy on a long program.
- Easier for the newcomer to get the meaning.
- More similar to perl5's foreach $item (@arr), since at least we
preserve the order.
The multi-array foreaching could become:
foreach $item; $other in @arr; @otherarr {...} # as in Apoc4
Or maybe
foreach $item in @arr; $other in @otherarr {...}
On a totally different level of foreaching:
¿are we going to have a iterator protocol? I am talking of python's
iterators, not ruby ones (which are being discussed in a different
post). The iterator protocol allows any object that implements a .next
method to be used in a foreach loop. This is very handy for things like
filehandles, recordsets, generators, coroutines and nearly any data
structure you can imagine.
For example, filehandles can implent the iterator protocol out of the
box, so you can write:
foreach $line in $fh {print $line}
Or maybe:
foreach $line in $fh.lines {print $line}
Where $fh.lines is an object that implements the iterator protocol, not
an array of the lines (and thus much more efficient).
There was something about this in Apoc2, but I didn't get a clear
concolusion of it. The are a lot of useful applications of python-like
iterators, and perl6 is doing a great job of taking the coolest things
of other languages and integrating them into a choerent design, so i do
have a hope. [:)]
This is of course related to Ruby's iterators, that take a somehow
opposite solution to solve a similar problem.
-
Angel Faus
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
Re: Apoc4 - A little wish
Sorry for the 4 times posts, i was testing a new mail program and it didn't prove too good. Now i feel so ashamed :-[ -angel
Re: Hyperoperators and RFC 207
Jeremy Howard [EMAIL PROTECTED] wrote .. Hyper-operators (i.e. element-wise array ops) and explicit array threading are not incompatible. In fact, I wrote RFC 82 (element-wise array ops) and was heavily involved in RFC 207 (Buddha Buck and I wrote most of RFCs 202-207 together, but we had to put one of our names on the individual RFCs). RFC 207 explicitly discusses the relationship with RFC 82. Well, maybe you are right. Even if array threading was a cleaner way than hyperoperators (which I believe it is), as long as RFC 202 gets into the language (I really hope so) and I can choose which way to go I am happy. The whole point was about economy of language constructs, but that's perl, and in perl free will is more important than economy, isn'it? --- Angel Faus [EMAIL PROTECTED] vLex.com "" Description: "" Description: "" Description: "" Description: "" Description: "" Description:
Hyperoperators and RFC 207
Hi to all, I have been thinking lately about hyperoperators, and particulary about its similarity with RFC 207 (Arrays: Efficient Array Loops) For the ones that don't have the RFC in mind, I copy its abstract: This RFC proposes a notation for creating efficient implicit loops over multidimensional arrays. It introduces the notation |i for an index iterator for arrays, allowing temporary multidimensional arrays to be created on the fly. My point is that what hyperoperators express (aplying operators and methods elementwise) is just a subset of the functionality provided by RFC 207, and that the former is both simpler and more powerful. Maybe i should better explain myself with an example. @arr3 = @arr1 ^+ @arr2 @arr4 = $v ^* @arr1 $sum ^=+ @arr1 Could become: @arr3 = @arr1[|i] + @arr2[|i]# also @arr3[|i] = @arr1[|i] + @arr2[|i] @arr4 = $v + @arr1[|i] $sum =+ @arr1[|i] As an alternative and without real thought on it, i would suggest maybe a different notation (more similar to Apocalypse's one) for this RFC. @arr3 = @arr1[^i] + @arr2[^i] # also @arr[^i] = @arr1[^i] + @arr2[^i] @arr4 = $v * @arr1[^i] $sum =+ @arr1[^i] @lengths_array = @arr1[^i].length() I turns out also that RFC's semantics allows much more powerful things like: @mat3 = @mat1[^i,^j] * @mat2[^j,^i] It looks to me that hyperoperators are just a partial solution to a bigger problem, and that the cost (a whole family of new operators) is way too big for its value. On the other hand, a RFC 207-like notation adds a lot more power with a single addition to the language. Just my 5 cents ;-) Angel Faus [EMAIL PROTECTED]
