On Tue, Feb 15, 2005 at 09:34:31PM -0600, Patrick R. Michaud wrote:
> On Tue, Feb 15, 2005 at 07:20:53PM -0600, Jonathan Scott Duff wrote:
> > > Patrick R. Michaud wrote:
> > > >OTOH, what happens with...?
> > > >
> > > > sub nofun($x is rw) {
> > > > $x += 2;
> > > > }
> > > >
> > > >
On Tue, Feb 15, 2005 at 07:20:53PM -0600, Jonathan Scott Duff wrote:
: For the case where a junction is stringified, I would imagine that the
: Junction's C or C (ala python) method gets called and it does
: something appropriate.
The C method is called C<.perl> in Perl, assuming you want a
Perl r
On Wed, Feb 16, 2005 at 02:29:36PM +0800, Autrijus Tang wrote:
: Just a quick question. The prettyprinter of Pugs (the thing that
: handles the ".perl" method) currently prints out boolean true and
: false as #t and #f, which is obviously not correct.
:
: pugs> (1 > 2, 2 > 1)
: (#f, #t)
:
On Tue, Feb 15, 2005 at 10:01:52PM -0600, Patrick R. Michaud wrote:
: Uh oh, I hadn't caught that particular nuance. Is it indeed over the
: entire equi-precedential part of the operation, or just over the
: chained operators?
Just the chained operators, I think. For more general expression
thre
Just a quick question. The prettyprinter of Pugs (the thing that
handles the ".perl" method) currently prints out boolean true and
false as #t and #f, which is obviously not correct.
pugs> (1 > 2, 2 > 1)
(#f, #t)
What should I do, though? Inventing two primitives, "true" and
"false"? O
Larry Wall wrote:
But as far as English is concerned, sets are just
objects that have a singular outside and a (potentially) plural inside,
much like almost any other object. At least, that's how concrete
sets work.
Hmm. I would argue that most of the time, when English Speakers use sets
qui
Patrick R. Michaud wrote:
Uh oh, I hadn't caught that particular nuance. Is it indeed over the
entire equi-precedential part of the operation, or just over the
chained operators? For example, given
$x = -1 | 10;
$ref.meth1($x).meth2($x)
are the meth1 and meth2 calls considered to be "eq
Patrick R. Michaud wrote:
RHS distributes first. So the expansion is this instead...
Ummm, okay, but that's not what I interpreted from S09, where
it says that the "left-most" conjunction or injunction is
autothreaded first. In this I've also assumed that
$a == $b
is equivalent to
&inf
On Wed, Feb 16, 2005 at 02:53:15PM +1100, Damian Conway wrote:
> Patrick R. Michaud wrote:
>
> >>>none(none($a,$b),none($c,$d)) == none($a,$b,$c,$d)
> >>
> >>True.
> >
> >
> >H...
> >
> > -> none(none($a,$b) == none($a,$b,$c,$d),
> > none($c,$d) == none($a,$b,$c,$d))
>
> RHS distr
On Wed, Feb 16, 2005 at 01:13:53PM +1100, Damian Conway wrote:
> Larry wrote:
> >0 < $x < 10
> >after all--the problem with rewriting that as
> >0 < $x and $x < 10
> >is that it should only work as long as the two values of $x remain
> >entangled so that the always refer to the same abstrac
Patrick R. Michaud wrote:
none(none($a,$b),none($c,$d)) == none($a,$b,$c,$d)
True.
H...
-> none(none($a,$b) == none($a,$b,$c,$d),
none($c,$d) == none($a,$b,$c,$d))
RHS distributes first. So the expansion is this instead...
-> none(none(none($a,$b),none($c,$d)) == $a,
Patrick R. Michaud wrote:
none(none($a,$b),none($c,$d)) == none($a,$b,$c,$d)
True.
H...
-> none(none($a,$b) == none($a,$b,$c,$d),
none($c,$d) == none($a,$b,$c,$d))
-> none(none($a == none($a,$b,$c,$d),
$b == none($a,$b,$c,$d)),
none($c == none(
On Tue, Feb 15, 2005 at 07:20:53PM -0600, Jonathan Scott Duff wrote:
> > Patrick R. Michaud wrote:
> > >OTOH, what happens with...?
> > >
> > > sub nofun($x is rw) {
> > > $x += 2;
> > > }
> > >
> > > $y = 3 | 4;
> > > nofun($y);
>
> That's either an error ("Can't modify constant") o
Damian Conway wrote:
.values tells you what raw values are inside the junction. The other
kind of introspection that's desirable is: "what raw values can
*match* this junction". There would probably be a .states method for
that.
To see the difference between the two, consider:
my $ideal_partner
On Wed, Feb 16, 2005 at 12:17:35PM +1100, Damian Conway wrote:
> Rod Adams wrote:
> >On a slightly different topic, do the following equivalences work:
> >[...]
> >none($a, $a) == undef
> True.
Scott already caught (and Damian acknowledged) this one, it's false
if $a == undef.
> >none($a,$a,$b)
On Wed, Feb 16, 2005 at 01:13:53PM +1100, Damian Conway wrote:
: Larry wrote:
:
: >That's the basic problem with
: >
: >0 < $x < 10
: >
: >after all--the problem with rewriting that as
: >
: >0 < $x and $x < 10
: >
: >is that it should only work as long as the two values of $x remain
: >en
On Tue, Feb 15, 2005 at 05:49:44PM -0600, Rod Adams wrote:
> >As you've written things above, C is autothreaded (your option #3),
> >and we'll see two C output lines if $DEBUG is set.
>
> The case of Damian's response in a prior message:
> [...]
> Could easily be achieved with a single layer of
Jonathan Scott Duff wrote:
none($a, $a) == undef
True.
Isn't this one false in the case when $a is undef?
Yes. Apologies for not being more precise.
Damian
Larry wrote:
That's the basic problem with
0 < $x < 10
after all--the problem with rewriting that as
0 < $x and $x < 10
is that it should only work as long as the two values of $x remain
entangled so that the always refer to the same abstract value.
That's certainly true. But I think the re
On Tue, Feb 15, 2005 at 04:20:28PM -0600, Rod Adams wrote:
: chromatic wrote:
:
: >>So I'm interested in hearing what pushes Arrays and Hashes over the edge
: >>for needing their own container and sigil, whereas Junctions/Sets do not.
: >>
: >>
: >
: >Perl isn't a "pure" object-oriented langua
On Wed, Feb 16, 2005 at 12:17:35PM +1100, Damian Conway wrote:
> >none($a, $a) == undef
>
> True.
Isn't this one false in the case when $a is undef?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
On Tue, Feb 15, 2005 at 05:49:44PM -0600, Rod Adams wrote:
> Damian Conway wrote:
> >
> >That would be disturbing if that's what happened.
> >C is just a shorthand for C.
> >So saying a junction is the same as printing it, which is a run-time
> >error.
>
> Could easily be achieved with a single l
Rod Adams wrote:
Okay, so we've established that:
$x = any(3,4,5);
@l = $x.values.sort;
Leaves us with @l == (3,4,5), and that makes a fair amount of sense.
What do the following evaluate to:
@l1 = all(3,4,5).values.sort;
Same.
@l2 = one(3,4,5).values.sort;
Same.
@l3 = none(3,4,5).values.sort;
Same
Okay, so we've established that:
$x = any(3,4,5);
@l = $x.values.sort;
Leaves us with @l == (3,4,5), and that makes a fair amount of sense.
What do the following evaluate to:
@l1 = all(3,4,5).values.sort;
@l2 = one(3,4,5).values.sort;
@l3 = none(3,4,5).values.sort;
@l4 = any(all(1,2),all(3,4)).valu
Patrick R. Michaud wrote:
On Tue, Feb 15, 2005 at 03:07:53PM -0600, Rod Adams wrote:
I see it this way:
When perl sees a function call, and one of the arguments is a junction,
there are three basic options:
1) If the junction is wrapped up in some larger container, like a slurpy
list, pass it
Thomas Sandlaà writes:
> Luke Palmer wrote:
>
> >But I counter that arguability by saying that you really shouldn't be
> >putting one() in type signatures. If you want something to be an A or a
> >B, and you're not doing any checking later on in the code, then it's
> >fine if it's both A and B.
David Storrs writes:
> On Tue, Feb 15, 2005 at 11:06:51AM -0800, Larry Wall wrote:
> >
> > But what y'all are talking about above is the other end--the return
> > type. And maybe we need to enforce a newbie-friendly invariant on
> > that end as well. I suppose we could default to not accepting
>
> "DW" == David Wheeler <[EMAIL PROTECTED]> writes:
DW> On Feb 15, 2005, at 11:06 AM, Larry Wall wrote:
>> So maybe the actual pragma name is
>>
>> use qubits;
>>
>> Note: the pragma is not "use junctions", since they're already allowed
>> to use junctions, as long as they don'
Rod Adams writes:
> So I'm interested in hearing what pushes Arrays and Hashes over the
> edge for needing their own container and sigil, whereas Junctions/Sets
> do not.
Nothing. In fact, arrays and hashes aren't atomic or fundamental in any
respect, and the main thing that keeps them there is h
On Tue, Feb 15, 2005 at 11:06:51AM -0800, Larry Wall wrote:
>
> But what y'all are talking about above is the other end--the return
> type. And maybe we need to enforce a newbie-friendly invariant on that
> end as well. I suppose we could default to not accepting junctional
> return values by de
chromatic wrote:
So I'm interested in hearing what pushes Arrays and Hashes over the edge
for needing their own container and sigil, whereas Junctions/Sets do not.
Perl isn't a "pure" object-oriented language.
Rephrasing my question:
What characteristics would _any_ new structure or class
Larry Wall wrote:
Or perhaps
the problem isn't returning junctions per se, but storing them into
a variable that the user is thinking of as a simple scalar value.
That was the largest, perhaps only, reason I made my "Sets vs Junctions"
post.
Although my solution to the issue was different from
On Tue, Feb 15, 2005 at 03:07:53PM -0600, Rod Adams wrote:
> I see it this way:
> When perl sees a function call, and one of the arguments is a junction,
> there are three basic options:
> 1) If the junction is wrapped up in some larger container, like a slurpy
> list, pass it on as is.
> 2) If t
At 01:04 PM 2/15/2005 -0800, chromatic wrote:
On Tue, 2005-02-15 at 14:26 -0600, Rod Adams wrote:
> So I'm interested in hearing what pushes Arrays and Hashes over the edge
> for needing their own container and sigil, whereas Junctions/Sets do not.
Perl isn't a "pure" object-oriented language.
No a
Damian Conway wrote:
>Rod Adams wrote:
>
>> However, what if what you're calling a non-Perl Parrot based function?
>> Do we disable junctions from playing with non-PurePerl functions? Or do
>> we autothread over them? How do we tell if a non-Perl function outputs
>> to determine if we should be abl
On Tue, 2005-02-15 at 14:26 -0600, Rod Adams wrote:
> The obvious statement I expect to here is "Perl's always had Arrays
> and Hashes". While I'm not sure if they were there for Perl 1.0 (I
> started w/ Perl 4.xx)
They were.
> So I'm interested in hearing what pushes Arrays and Hashes over the
On Feb 15, 2005, at 11:06 AM, Larry Wall wrote:
So maybe the actual pragma name is
use qubits;
Note: the pragma is not "use junctions", since they're already allowed
to use junctions, as long as they don't try to observe them. :-)
To quote Noah, what's a qubit?
http://www.jr.co.il/humor/noah
In my recent unsuccessful attempt to convert junctions into sets with their
own container, perhaps the strongest argument against could be paraphrased
as follows:
Everything about junctions or sets can be represented fully as an object,
and objects are nicely stored in scalars, because it's sim
On Sun, Feb 13, 2005 at 04:10:08PM -0600, Jonathan Scott Duff wrote:
: On Sun, Feb 13, 2005 at 11:10:20AM -0600, Patrick R. Michaud wrote:
: > Autothreading, even if enabled by default, doesn't happen until a
: > junction is created and used somewhere. Thus the only time our hypothetical
: > new
Luke Palmer wrote:
But I counter that arguability by saying that you really shouldn't be
putting one() in type signatures. If you want something to be an A or a
B, and you're not doing any checking later on in the code, then it's
fine if it's both A and B. If you are doing checking later on, then
40 matches
Mail list logo
