On Mon, Feb 21, 2005 at 11:01:45AM -0800, Larry Wall wrote:
>
> But rather than that, I suspect we'll see more use of constructs
> where the object to be mutated ends up being the topic, as in:
>
> some_complicated_lvalue() but= { .sortmyway(foo($_),bar($_)) }
>
> which would presumably do t
On Mon, Feb 21, 2005 at 03:11:12PM +0100, Michele Dondi wrote:
: On Mon, 14 Feb 2005, Michele Dondi wrote:
:
: >Speaking of which, while I think that methods on the implicit topicalizer
: >and the C<.=> assignement operator are indeed cool, I wonder if any
: >provision will be made for a conveni
On Mon, 14 Feb 2005, Michele Dondi wrote:
Speaking of which, while I think that methods on the implicit topicalizer and
the C<.=> assignement operator are indeed cool, I wonder if any provision
will be made for a convenient stand in for "whatever is on the left side of
an assignment operator", e
Thomas Sandlaß wrote:
class Source[Language ::To] is Str {
multi sub *coerce:as (Any $data, To ::Lang) {
return Lang.serialize($data)
}
}
What is the return type of &*coerce:as?
Sorry, I was too lazy (well, I'd claim I was thinking at a much higher level,
but i
HaloO Damian,
you wrote:
Actually, I'd have thought that the type coercion mechanism might be a
more appropriate way to go here. After all, the serialization of a data
structure is merely a coercion to a subtype of Str. Specifically, I
imagine a parameterized Source subtype:
class Source[Langua
Larry wrote:
> Actually, I'm thinking we should just go with a single method and
> have it merely default to :lang. But .repr is rather ugly.
> How 'bout .pretty instead? If we made the language the first optional
> argument you could have $x.pretty('Lisp'), $x.pretty('C#'), etc.
Hm, maybe we
On Wed, Feb 16, 2005 at 10:12:43PM -0800, Larry Wall wrote:
: On Wed, Feb 16, 2005 at 10:07:34PM -0800, chromatic wrote:
: : On Wed, 2005-02-16 at 08:54 -0800, David Wheeler wrote:
: :
: : > And what of .c#?
: :
: : It's an alias for .java.
:
: I'm sorry, but neither of those is powerful enough
On Wed, Feb 16, 2005 at 10:07:34PM -0800, chromatic wrote:
: On Wed, 2005-02-16 at 08:54 -0800, David Wheeler wrote:
:
: > And what of .c#?
:
: It's an alias for .java.
I'm sorry, but neither of those is powerful enough to represent Perl
data structures. ;-)
Larry
On Wed, 2005-02-16 at 08:54 -0800, David Wheeler wrote:
> And what of .c#?
It's an alias for .java.
-- c
On Feb 15, 2005, at 11:16 PM, Larry Wall wrote:
I admit that calling the .brainf*ck method is problematic several
ways...
And what of .c#?
Regards,
David
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 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
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
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
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
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'
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
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
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 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
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
On Feb 13, 2005, at 3:54 PM, David Storrs wrote:
Ok, so it requires actually overriding the rand function and providing
your own implementation. I was hoping for something a bit more
automagical (probably involving a property or role, since they seem to
be the answer to everything these days), but
On Mon, Feb 14, 2005 at 10:43:21AM +1100, Damian Conway wrote:
> David Storrs OOC'd:
>
> >OOC, will there be a way to control where C gets its randomness
> >from? (e.g. perl's builtin PRNG, /dev/random, egd, etc)
>
> Sure:
>
> # Use RBR (Really Bad Randomness) algorithm...
> temp *rand
On Sat, 12 Feb 2005, Damian Conway wrote:
@xyz = uniq @xyz;
or better still:
@xyz.=uniq;
Speaking of which, while I think that methods on the implicit topicalizer
and the C<.=> assignement operator are indeed cool, I wonder if any
provision will be made for a convenient stand in for "wh
David Storrs OOC'd:
OOC, will there be a way to control where C gets its randomness
from? (e.g. perl's builtin PRNG, /dev/random, egd, etc)
Sure:
# Use RBR (Really Bad Randomness) algorithm...
temp *rand (Num ?$max = 1) {
return $max/2;
}
my $guess = @data.pick;
Damian
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 autothread into them or not?
Jonathan Scott Duff wrote:
Perhaps. I'm not so sure it's the rare case that programmers aren't
prepared to deal with implicit parallelization. :-)
Of course. But I'm saying it's a rare case where they've have to. Or, at
least, where it will bite them if they don't.
use warnings 'autothreading
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 programmer would be forced to become aware of junctions (without
> himself/h
On Sat, Feb 12, 2005 at 06:39:01PM +1100, Damian Conway wrote:
> pick - select at random from a list, array, or hash
OOC, will there be a way to control where C gets its randomness
from? (e.g. perl's builtin PRNG, /dev/random, egd, etc)
--Dks
--
[EMAIL PROTECTED]
On Sat, Feb 12, 2005 at 05:24:04PM -0600, Jonathan Scott Duff wrote:
> > >Because of this, I'd suggest that autothreading of user-defined routines
> > >not be the default, but rather enabled via a pragma of some sort (or, of
> > >course, via an "autothreaded" trait). For the built-in routines this
On Sat, Feb 12, 2005 at 03:54:57PM -0600, Rod Adams wrote:
> >>But, to extract those alternative values from an object, you do
> >>something special to it, like call a method. Whenever you evaluate the
> >>object as a scalar, you get a single value back. Quite probably a
> >>reference to somethi
Damian Conway wrote:
Rod Adams wrote:
I also find the following incredibly disturbing:
>perl6 -e "$x = 'cat'|'dog'; say $x;"
dog
cat
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.
So we ha
On Sun, Feb 13, 2005 at 09:53:36AM +1100, Damian Conway wrote:
> Jonathan Scott Duff wrote:
> >The down side is that programmers need to be more aware of
> >subroutine/method side effects and write their programs accordingly.
>
> This is a *down*-side??? ;-)
Indeed ;-)
I'm using "programmer"
Jonathan Scott Duff wrote:
Let's set aside for the moment the fact that slurpy arrays/hashes
aren't autothreaded and talk about a user-defined routine:
sub foo ($alpha) { ... }
It doesn't take much imagination to come up with a mechanism for Perl6
programmers to stop the autothreading:
sub
On Sat, Feb 12, 2005 at 12:19:46PM -0600, Rod Adams wrote:
> I reread S09, and I believe "autothreading" is the wrong term for the
> iteration that a junction incurs (Even though it appears in the section
> immediately after Junctions. Autothreading is something far weirder,
> dealing with part
Autrijus wrote:
FWIW, I also find it incredibly disturbing. Although I don't have
to deal with it yet in the side-effect-free FP6, I think one way
to solve this is for the "say" to return a junction of IO actions.
No. It just throws an exception:
Can't output a raw junction
(did yo
Rod Adams wrote:
I also find the following incredibly disturbing:
>perl6 -e "$x = 'cat'|'dog'; say $x;"
dog
cat
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.
Can a junction hold values of
Patrick R. Michaud wrote:
On Sat, Feb 12, 2005 at 01:18:53PM -0600, Rod Adams wrote:
My issue is less that lists and sets are radically different. It is much
more a matter of Junctions and Scalars are radically different. Getting
me to accept that a Scalar holds several different values at once
On Sat, Feb 12, 2005 at 02:20:45PM -0600, Patrick R. Michaud wrote:
: > And I've yet to receive a good answer for what C<3/any(0,1)> does to $!.
:
: I'm sure that 3/any(0,1) throws some sort of divide by zero exception;
: same as 3/0 would, and places the exception into $!. I don't know
: that $!
On Sat, Feb 12, 2005 at 01:18:53PM -0600, Rod Adams wrote:
> >>My issue is less that lists and sets are radically different. It is much
> >>more a matter of Junctions and Scalars are radically different. Getting
> >>me to accept that a Scalar holds several different values at once is a
> >>hard sel
Patrick R. Michaud wrote:
On Sat, Feb 12, 2005 at 12:41:19AM -0600, Rod Adams wrote:
Of course we'll always have C. But this is Perl, and I want YAWTDI.
After all, another way to test membership was just added, whereas before
you pretty much just had C.
...another way to test membership wa
Patrick R. Michaud wrote:
On Sat, Feb 12, 2005 at 03:49:02AM -0600, Jonathan Scott Duff wrote:
On Sat, Feb 12, 2005 at 01:03:26AM -0600, Rod Adams wrote:
I also find the following incredibly disturbing:
perl6 -e "$x = 'cat'|'dog'; say $x;"
dog
cat
Would that happen th
On Sat, Feb 12, 2005 at 03:49:02AM -0600, Jonathan Scott Duff wrote:
> On Sat, Feb 12, 2005 at 01:03:26AM -0600, Rod Adams wrote:
> > I also find the following incredibly disturbing:
> >
> > >perl6 -e "$x = 'cat'|'dog'; say $x;"
> > dog
> > cat
>
> Would that happen though? What's the signature
On Sat, Feb 12, 2005 at 12:41:19AM -0600, Rod Adams wrote:
> >I've given here. For example, a junction can have a value like:
> > $x = ($a & $b) ^ ($c & $d)
> >which is true only if $a and $b are true or $c and $d are true but not
> >both.
>
> That's why I allowed for virtual sets, defined by a
On Sat, Feb 12, 2005 at 01:02:45PM +0800, Autrijus Tang wrote:
> On Fri, Feb 11, 2005 at 02:12:51PM -0600, Patrick R. Michaud wrote:
> > I briefly grepped through the apocalypses/synopses and couldn't
> > find the answer -- how do I tell a scalar context to expect a
> > junction of values? In part
On Sat, Feb 12, 2005 at 04:44:04PM +1100, Damian Conway wrote:
> Patrick R. Michaud wrote:
>
> >>$x = $Value | 'Default';
> >>instead of :
> >>$x = $Value || 'Default';
> >
> >
> >Hmm, this is an interesting point. I'll let others chime in here,
> >as I don't have a good answer (nor am I at all a
On Sat, Feb 12, 2005 at 01:03:26AM -0600, Rod Adams wrote:
> I also find the following incredibly disturbing:
>
> >perl6 -e "$x = 'cat'|'dog'; say $x;"
> dog
> cat
Would that happen though? What's the signature of C? I think
it's something like
multi sub *say ($stream = $*OUT: *$data)
On Sat, Feb 12, 2005 at 03:16:20PM +0800, Autrijus Tang wrote:
> the toplevel sequencing only handles "IO of ..." types, so the junction
> above will not print anything. Instead it may raise a warning of "using a
> Junction in a void context", or something equally ominous.
Thinking about it, that
Autrijus wrote:
Is there other built-in methods not found in perl5 that you are
aware of?
Yes.
I'd like to work out declarations and implementations
of them in one sweep, if possible. :-)
Hah! Dream on! I don't think we have a canonical list anywhere (except in
Larry's head). Some non-Perl-5 Per
On Sat, Feb 12, 2005 at 01:03:26AM -0600, Rod Adams wrote:
> I also find the following incredibly disturbing:
> >perl6 -e "$x = 'cat'|'dog'; say $x;"
> dog
> cat
>
> Getting iterated executions of a statement without explicitly iterating
> it bothers me greatly. I work heavily in databases, where
Damian Conway wrote:
Patrick R. Michaud wrote:
Ultimately I don't think I agree with the notion that sets and lists
are so different, or that sets deserve/require their own sigil.
Sets shouldn't have a sigil anyway, whether they're qualitatively
different from lists or not. A set is a *value* (
Patrick R. Michaud wrote:
Rod Adams wrote:
I would argue that this sort of relational comparison is of limited
usefulness.
Well, except junctions hold more information than the simple comparisons
I've given here. For example, a junction can have a value like:
$x = ($a & $b) ^ ($c & $d
On Sat, Feb 12, 2005 at 04:44:04PM +1100, Damian Conway wrote:
> BTW, I'm pretty sure there will be built-in C and
> C methods in Perl 6. So that's just:
>
> @xyz = uniq @xyz;
> or better still:
> @xyz.=uniq;
Is there other built-in methods not found in perl5 that you are
aware of?
Patrick R. Michaud wrote:
$x = $Value | 'Default';
instead of :
$x = $Value || 'Default';
Hmm, this is an interesting point. I'll let others chime in here,
as I don't have a good answer (nor am I at all authoritative on junctions).
This is merely syntax; it doesn't really have anything to do with
On Fri, Feb 11, 2005 at 02:12:51PM -0600, Patrick R. Michaud wrote:
> I briefly grepped through the apocalypses/synopses and couldn't
> find the answer -- how do I tell a scalar context to expect a
> junction of values? In particular, is there a way for me to pass
> a junction to a routine without
Rod Adams wrote:
> I would argue that this sort of relational comparison is of limited
> usefulness.
Well, except junctions hold more information than the simple comparisons
I've given here. For example, a junction can have a value like:
$x = ($a & $b) ^ ($c & $d)
which is true only if $a
Patrick R. Michaud wrote:
For example, with the "less than or equals" (<=) relational operator,
the expression
any(2,3,4) <= 3
becomes
any( 2 <= 3,# 1 (true)
3 <= 3,# 1 (true)
4 <= 3 # 0 (false)
)
which ultimately becomes any(1,0), because <= is an operator t
On Fri, Feb 11, 2005 at 12:54:39AM -0600, Rod Adams wrote:
> Damian writes:
> >Junctions have an associated boolean predicate that's preserved across
> >operations on the junction. Junctions also implicitly distribute
> >across operations, and rejunctify the results.
>
> My brain is having trouble
Woops! I just realized I factored something wrongly...!?
On Fri, Feb 11, 2005 at 01:22:51PM -0600, Patrick R. Michaud wrote:
> # return true if $x is a factor of $y
> sub is_factor (Scalar $x, Scalar $y) { $y % $x == 0 }
> [...]
> # a (somewhat inefficient?) is_prime test for $bar
>
62 matches
Mail list logo
