Re: proposal: use \ as none junction delimeter

2005-02-15 Thread Thomas Sandlaß
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,

Re: Fun with junctions (was Sets vs Junctions)

2005-02-15 Thread Larry Wall
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

Containers vs Objects.

2005-02-15 Thread Rod Adams
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

Re: Fun with junctions (was Sets vs Junctions)

2005-02-15 Thread David Wheeler
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?

Re: Containers vs Objects.

2005-02-15 Thread chromatic
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 edge

Re: Fun with junctions (was Sets vs Junctions)

2005-02-15 Thread Rod Adams
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 able to

Re: Containers vs Objects.

2005-02-15 Thread Rod Adams
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

Re: Fun with junctions (was Sets vs Junctions)

2005-02-15 Thread Patrick R. Michaud
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 the

Re: Fun with junctions (was Sets vs Junctions)

2005-02-15 Thread Rod Adams
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

Re: Containers vs Objects.

2005-02-15 Thread Rod Adams
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

Re: Fun with junctions (was Sets vs Junctions)

2005-02-15 Thread David Storrs
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

Re: Containers vs Objects.

2005-02-15 Thread Luke Palmer
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

Re: Fun with junctions

2005-02-15 Thread Uri Guttman
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't try to observe them.

Re: Fun with junctions (was Sets vs Junctions)

2005-02-15 Thread Luke Palmer
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

Re: proposal: use \ as none junction delimeter

2005-02-15 Thread Luke Palmer
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. If you are

Re: Fun with junctions (was Sets vs Junctions)

2005-02-15 Thread Rod Adams
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

Junction Values

2005-02-15 Thread Rod Adams
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 =

Re: Junction Values

2005-02-15 Thread Damian Conway
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;

Re: Fun with junctions (was Sets vs Junctions)

2005-02-15 Thread Jonathan Scott Duff
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. Csay @what is just a shorthand for Cprint @what, \n. So saying a junction is the same as printing it, which is a run-time error. Could easily be achieved

Re: Junction Values

2005-02-15 Thread Jonathan Scott Duff
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]

Re: Containers vs Objects.

2005-02-15 Thread Larry Wall
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 language. : :

Re: Containers vs Objects.

2005-02-15 Thread Damian Conway
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 real

Re: Junction Values

2005-02-15 Thread Damian Conway
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

Re: Fun with junctions (was Sets vs Junctions)

2005-02-15 Thread Patrick R. Michaud
On Tue, Feb 15, 2005 at 05:49:44PM -0600, Rod Adams wrote: As you've written things above, Cfun is autothreaded (your option #3), and we'll see two Cwarn 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

Re: Containers vs Objects.

2005-02-15 Thread Larry Wall
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 : entangled so

Re: Junction Values

2005-02-15 Thread Patrick R. Michaud
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) ==

Re: Junction Values

2005-02-15 Thread Rod Adams
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

Re: Fun with junctions (was Sets vs Junctions)

2005-02-15 Thread Patrick R. Michaud
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) or the same as 5|6. The

Re: Junction Values

2005-02-15 Thread Rod Adams
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 ==

Re: Junction Values

2005-02-15 Thread Damian Conway
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,

Re: Containers vs Objects.

2005-02-15 Thread Patrick R. Michaud
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 abstract value.

Re: Junction Values

2005-02-15 Thread Patrick R. Michaud
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 distributes first. So the

Re: Junction Values

2005-02-15 Thread Damian Conway
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

Re: Containers vs Objects.

2005-02-15 Thread Rod Adams
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

Boolean literals

2005-02-15 Thread Autrijus Tang
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? Or is

Re: Containers vs Objects.

2005-02-15 Thread Larry Wall
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

Re: Boolean literals

2005-02-15 Thread Larry Wall
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) : :

Re: Fun with junctions (was Sets vs Junctions)

2005-02-15 Thread Larry Wall
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 Cstr or Crepr (ala python) method gets called and it does : something appropriate. The Crepr method is called C.perl in Perl, assuming you

Re: Fun with junctions (was Sets vs Junctions)

2005-02-15 Thread Jonathan Scott Duff
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; } $y = 3 | 4; nofun($y);