Juerd wrote:
Juerd skribis 2005-05-14 17:23 (+0200):
Markus Laire skribis 2005-05-14 18:07 (+0300):
[+^=] (@a, @b, @c)
These arrays flatten first (otherwise [+] @foo could never calculate the
sum of the elements), so imagine that you have
$foo, $bar, $baz, $quux, $xyzzy
to let +^= operate
On Mon, May 16, 2005 at 10:18:47AM +0300, Markus Laire wrote:
: As S09 says that:
:
: At the statement level, a semicolon terminates the current
: expression. Within any kind of bracketing construct, semicolon
: notionally produces a list of lists, the interpretation of which
:
[»+^=«] reminds me of a P5 regex that has a comment saying This is
black magic. Don't touch!. --That's-- my complaint.
Indeed. There's a time and a place for that sort of black magic, and
it's usually about once per 5,000 lines of code, and so deep and well
wrapped in comments and unit tests
Adam Kennedy wrote:
And reduction? I write 25,000+ lines of
Perl a year, and if you are talking about something like
List::Util::reduce, I think I've used it maybe twice?
Which proves what? That you don't (yet) write the sort of code that benefits
from reductions? That you don't (yet) think in
On 14/05/05, Damian Conway [EMAIL PROTECTED] wrote:
Here are a few of the things I'll be using reductions for in Perl 6...
1. To add things up:
$sum = [+] @amounts;
2. To calculate the probability that I'll need to use a reduction today:
$final_prob =
Damian Conway skribis 2005-05-14 22:56 (+1000):
$leaf_value = [.{}] %hash, @keys;
$propped = [but] $value, @properties;
With the precedence of [op] being that of a normal list op, the above
are a problem. Perhaps ; or multiple == can solve this?
Juerd
--
Juerd [EMAIL PROTECTED] writes:
Damian Conway skribis 2005-05-14 22:56 (+1000):
$leaf_value = [.{}] %hash, @keys;
$propped = [but] $value, @properties;
With the precedence of [op] being that of a normal list op, the above
are a problem. Perhaps ; or multiple == can
On Sat, May 14, 2005 at 10:56:29PM +1000, Damian Conway wrote:
3. To drill down a hierarchical data structure, following the path
specified by a list of keys:
$leaf_value = [.{}] %hash, @keys;
I think this one needs to be written as:
$leaf_value = [.{}] \%hash,
Eirik Berg Hanssen skribis 2005-05-14 16:22 (+0200):
With the precedence of [op] being that of a normal list op, the above
are a problem. Perhaps ; or multiple == can solve this?
I suppose the first must just make sure not to flatten the %hash:
$leaf_value = [.{}] \%hash, @keys; # %hash
DC == Damian Conway [EMAIL PROTECTED] writes:
DC Here are a few of the things I'll be using reductions for in Perl 6...
DC 3. To drill down a hierarchical data structure, following the path
DC specified by a list of keys:
DC $leaf_value = [.{}] %hash, @keys;
Jonathan Scott Duff skribis 2005-05-14 9:49 (-0500):
Then surely $leaf = [.{}] %hash, $k1, $k2, $k3
is the same as$leaf = %hash .{} $k1 .{} $k2 .{} $k3
Then perhaps the easy way out is to make .{} $key and .[] $index valid
syntax.
Or perhaps [] can play the role of
Adam Kennedy kirjoitti:
[»+^=«] reminds me of a P5 regex that has a comment saying This is
black magic. Don't touch!. --That's-- my complaint.
I look at...
but the basic operator there is just ^, with a + modifier to indicate
numeric XOR, = to indicate an assignment operator, »« to indicate
Markus Laire skribis 2005-05-14 18:07 (+0300):
[+^=] (@a, @b, @c)
These arrays flatten first (otherwise [+] @foo could never calculate the
sum of the elements), so imagine that you have
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
Juerd skribis 2005-05-14 17:23 (+0200):
Markus Laire skribis 2005-05-14 18:07 (+0300):
[+^=] (@a, @b, @c)
These arrays flatten first (otherwise [+] @foo could never calculate the
sum of the elements), so imagine that you have
$foo, $bar, $baz, $quux, $xyzzy
to let +^= operate on.
On Sat, May 14, 2005 at 05:05:10PM +0200, Juerd wrote:
Jonathan Scott Duff skribis 2005-05-14 9:49 (-0500):
Then surely $leaf = [.{}] %hash, $k1, $k2, $k3
is the same as $leaf = %hash .{} $k1 .{} $k2 .{} $k3
Then perhaps the easy way out is to make .{} $key and .[]
On Sat, May 14, 2005 at 10:55:43AM -0500, Jonathan Scott Duff wrote:
: But perhaps the reduce operator is some of that sufficiently advanced
: technology that knows how the operator it wraps is slotted and does
: something appropriate.
Possibly. Or we just define infix .{}. and .[]. variants,
On Sat, May 14, 2005 at 09:20:21AM -0700, Larry Wall wrote:
On Sat, May 14, 2005 at 10:55:43AM -0500, Jonathan Scott Duff wrote:
: But perhaps the reduce operator is some of that sufficiently advanced
: technology that knows how the operator it wraps is slotted and does
: something
Larry Wall skribis 2005-05-14 9:20 (-0700):
Possibly. Or we just define infix .{}. and .[]. variants, or some such.
The problem is that we already have @foo[] meaning the same as @foo, and
an always allowed . that also allows you to put whitespace around it.
This means that %foo.{}.$kv should
On Sat, May 14, 2005 at 06:41:35PM +0200, Juerd wrote:
: Larry Wall skribis 2005-05-14 9:20 (-0700):
: Possibly. Or we just define infix .{}. and .[]. variants, or some such.
:
: The problem is that we already have @foo[] meaning the same as @foo, and
: an always allowed . that also allows you
Larry Wall wrote:
On Sat, May 14, 2005 at 06:41:35PM +0200, Juerd wrote:
: Larry Wall skribis 2005-05-14 9:20 (-0700):
: Possibly. Or we just define infix .{}. and .[]. variants, or some such.
:
: The problem is that we already have @foo[] meaning the same as @foo, and
: an always allowed .
On Sat, May 14, 2005 at 12:51:32PM -0500, Rod Adams wrote:
: Larry Wall wrote:
:
: On Sat, May 14, 2005 at 06:41:35PM +0200, Juerd wrote:
: : Larry Wall skribis 2005-05-14 9:20 (-0700):
: : Possibly. Or we just define infix .{}. and .[]. variants, or some
: such.
: :
: : The problem is that
Larry Wall wrote:
On Sat, May 14, 2005 at 12:51:32PM -0500, Rod Adams wrote:
: Unless, of course, there is some subtle difference between a 3-d hash
: and a hash of hashes of hashes that invalidates this.
No difference, I hope. The multidimensional notation is meant
to extend to HoH and AoA
On Sat, May 14, 2005 at 01:36:22PM -0500, Rod Adams wrote:
: Larry Wall wrote:
:
: On Sat, May 14, 2005 at 12:51:32PM -0500, Rod Adams wrote:
:
: : Unless, of course, there is some subtle difference between a 3-d hash
: : and a hash of hashes of hashes that invalidates this.
:
: No difference,
On 5/14/05, Larry Wall [EMAIL PROTECTED] wrote:
On Sat, May 14, 2005 at 01:36:22PM -0500, Rod Adams wrote:
: Larry Wall wrote:
:
: On Sat, May 14, 2005 at 12:51:32PM -0500, Rod Adams wrote:
:
: : Unless, of course, there is some subtle difference between a 3-d hash
: : and a hash of hashes
Rob Kinyon wrote:
So, does this mean that I can do something like:
@a = [ 1 .. 4 ];
$x = @a{2};
and have $x == 3? If so, is there any reason (other than clarity) to
use the @a[] notation? The @ already indicates you have an array vs.
the % which indicates hash. Is there a reason to have the
Damian Conway [EMAIL PROTECTED] wrote:
3. To drill down a hierarchical data structure, following the path
specified by a list of keys:
$leaf_value = [.{}] %hash, @keys;
When I saw this, the following happened.
*pause for a second*
Wow.
*a few more seconds*
Holy
Larry Wall skribis 2005-05-14 9:45 (-0700):
: OTOH, reduce probably just needs to be smart enough to understand
: postcircumfix. Perhaps whitespace helps, [{ }], in parallel with
: postcircumfix:{ }, to avoid a conflict with an infix {}.
Erm, I don't like tokens with spaces in the middle.
Larry wrote:
Actually, I think Damian's original formulation is sufficiently clear.
aolMe too!/aol ;-)
I think that a standard [.infix markerpostfix marker] abbreviation for all
postcircumfix operators within [op] reductions would be a useful bit of dwimmery.
Damian
On 5/15/05, Juerd [EMAIL PROTECTED] wrote:
How does [EMAIL PROTECTED] know the difference between postcircumfix:!@ #
and
postcircumfix:! @#?
Perhaps it checks how many different variations are actually
defined--if it finds only one, it can DWIM, and if it finds more than
one it can barf with
On Wed, May 04, 2005 at 10:58:22AM -0400, Rob Kinyon wrote:
: I just started following the list again after a few months (though I
: have been skimming the bi-weekly summaries) and I'm a little alarmed
: at what seems to be a trend towards operaterizing everything in sight
: and putting those
Are there any particular other operators you're worried about?
I think the current design does a pretty good job of factoring out the
metaoperators so that the actual set of underlying basic operators *is*
relatively small. Yes, you can now say something like
$x = [»+^=«] @foo;
but
31 matches
Mail list logo
