Hi all. I've been thinking about stringification, forms, and things
like that.
As exegesis 7 points out, sprintf, pack, and the forms language all
essentially take data and specifies how to turn it into a "string" (I'm using
"string" loosely here). Likewise with .perl -- it takes some data
Damian Conway wrote:
> Jon Lang wrote:
>
>> For that matter, I'm not seeing a difference between:
>>
>> any( 1&2 ) # any of all of (1, 2)
>>
>> ...and:
>>
>> any( 1, 2 ) # any of (1, 2)
>
> Those two are very different.
>
> any(1,2) == 2 is true
>
> any(1&2) == 2 is false
>
>
> Nest
Jon Lang wrote:
> For that matter, I'm not seeing a difference between:
>
>any( 1&2 ) # any of all of (1, 2)
>
> ...and:
>
>any( 1, 2 ) # any of (1, 2)
Those two are very different.
any(1,2) == 2 is true
any(1&2) == 2 is false
Nested heterogeneous junctions are extremely u
Dave Whipp wrote:
> [I’d been planning to put this suggestion on hold until the spec is
> sufficiently complete for me to attempt to implement it as a module. But
> people are discussing this again, so maybe it's not just me. I apologize if
> I appear to be beating a dead horse...]
>
> Jon Lang wro
[I’d been planning to put this suggestion on hold until the spec is
sufficiently complete for me to attempt to implement it as a module. But
people are discussing this again, so maybe it's not just me. I apologize
if I appear to be beating a dead horse...]
Jon Lang wrote:
Maybe you could hav
Richard Hainsworth wrote:
The following arose out of a discussion on #perl6. Junctions are new
and different from anything I have encountered, but I cant get rid of
the feeling that there needs to be some more flexibility in their use
to make them a common programming tool.
Background: Imag
On Fri, Mar 27, 2009 at 10:39 AM, Dave Whipp wrote:
> Richard Hainsworth wrote:
>>
>> The following arose out of a discussion on #perl6. Junctions are new and
>> different from anything I have encountered, but I cant get rid of the
>> feeling that there needs to be some more flexibility in their u
Author: pmichaud
Date: 2009-03-27 20:45:51 +0100 (Fri, 27 Mar 2009)
New Revision: 26016
Modified:
docs/Perl6/Spec/S05-regex.pod
Log:
[S05]: Correct typo "by use if" ==> "by use of"
Modified: docs/Perl6/Spec/S05-regex.pod
===
--
In the case of strings and numbers, I'd recommend using leg instead of
cmp - that is, coerce both items to strings, then compare the strings.
But as far as cmp goes, "3 cmp '3'" should fail because a number
isn't a string.
--
Jonathan "Dataweaver" Lang
Richard Hainsworth wrote:
The following arose out of a discussion on #perl6. Junctions are new and
different from anything I have encountered, but I cant get rid of the
feeling that there needs to be some more flexibility in their use to
make them a common programming tool.
I strongly agree w
On 2009-Mar-26, at 10:50 pm, Patrick R. Michaud wrote:
But what to do with something like C< 3 cmp '3' >, or any
infix: where the operands are of differing types? Do we
constrain C to only work on similarly-typed operands (in which
case my sort above would fail), or am I overlooking somethi
On Fri, Mar 27, 2009 at 11:45 AM, Mark J. Reed wrote:
> Given two
> junctions $d and $p, just adding $d + $p gives you all the possible
> sums of the eigenstates. Given two sets D and P, is there an equally
> simple op to generate { d + p : d ∈ D, p ∈ } ?
Dropped a P there - should be { d + p :
On Fri, Mar 27, 2009 at 10:27 AM, Moritz Lenz
wrote:
> Mark J. Reed wrote:
>> From a high-level perspective, the blackjack example seems perfect for
>> junctions. An Ace isn't a set of values - its one or the other at a
>> time. It seems to me if you can't make it work with junctions - f you
>>
Mark J. Reed wrote:
> From a high-level perspective, the blackjack example seems perfect for
> junctions. An Ace isn't a set of values - its one or the other at a
> time. It seems to me if you can't make it work with junctions - f you
> have to use sets instead - then there's something wrong with
Em Sex, 2009-03-27 às 09:17 -0400, Mark J. Reed escreveu:
> From a high-level perspective, the blackjack example seems perfect for
> junctions. An Ace isn't a set of values - its one or the other at a
> time. It seems to me if you can't make it work with junctions - f you
> have to use sets inste
>From a high-level perspective, the blackjack example seems perfect for
junctions. An Ace isn't a set of values - its one or the other at a
time. It seems to me if you can't make it work with junctions - f you
have to use sets instead - then there's something wrong with the
implementation of junc
Em Sex, 2009-03-27 às 08:57 -0300, Daniel Ruoso escreveu:
> So I get that we do need some cool support for sets as well, I mean...
> no collapsing, no autothreading... but maybe some specific behaviors...
As an aditional idea...
multi infix:<⋃>(Set $a, Set $b) {...}
multi infix:<⋂>(Set $a, Set $b
Em Sex, 2009-03-27 às 13:36 +0300, Richard Hainsworth escreveu:
> On #perl6, rouso, masak and moritz_ explained that I am incorrectly
> thinking about junctions as sets and that for this task I should be
> using another perl idiom, namely lists.
Sorry for not taking each individual point on your
The following arose out of a discussion on #perl6. Junctions are new and
different from anything I have encountered, but I cant get rid of the
feeling that there needs to be some more flexibility in their use to
make them a common programming tool.
Background: Imagine a hand of cards. Cards ma
19 matches
Mail list logo
