Michele Dondi wrote:
> OTOH all these discussions seem to imply that there is some demand (by
> me, for one!) for a "set-like" builtin data-type as well as for the
> already existing hashes and junctions and of course for
> interoperability between any two of them, e.g. in terms of automatic
> c
On Tue, 22 Feb 2005, Larry Wall wrote:
On Mon, Feb 21, 2005 at 10:32:15PM -0800, Jonathan Lang wrote:
: ...then you've got the notion of Fuzzy Logic Sets, where the key would be
[snip]
But using values for degree of membership is an interesting idea.
On the other hand, if we ever have numeric datat
On Mon, 21 Feb 2005, Jonathan Lang wrote:
There are a couple of problems: first, a hash's keys are limited to
strings; a set ought to be able to handle a wider range of data types.
Well, if I had learnt something about Perl6 it is that it is no longer
necessarily so.
Michele
--
It's also amazing
On Mon, Feb 21, 2005 at 10:32:15PM -0800, Jonathan Lang wrote:
: ...then you've got the notion of Fuzzy Logic Sets, where the key would be
: the prospective element and the value would be the degree of membership.
: For fuzzy sets, hashes seem to be a better fit than junctions, which have
: no obv
Jonathan Lang <[EMAIL PROTECTED]> wrote:
> There are a couple of problems: first, a hash's keys are limited to
> strings; a set ought to be able to handle a wider range of data types.
Last time I checked, there was going to be a way to declare a
different data type for the key (which could easily
Larry Wall wrote:
> Michele Dondi wrote:
> : Jonathan Lang wrote:
> : > > If we want Sets in Perl, we should have proper Sets.
> : >
> : > I'll agree, depending on what you mean by "proper". I'd be
> : > interested in having some means to perform set operations in perl6:
> : > unions, intersectio
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:07:34PM +0100, Michele Dondi wrote:
: On Sun, 13 Feb 2005, Jonathan Lang wrote:
:
: >> If we want Sets in Perl, we should have proper Sets.
: >
: >I'll agree, depending on what you mean by "proper". I'd be interested in
: >having some means to perform set operations i
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
On Sun, 13 Feb 2005, Jonathan Lang wrote:
If we want Sets in Perl, we should have proper Sets.
I'll agree, depending on what you mean by "proper". I'd be interested in
having some means to perform set operations in perl6: unions,
intersections, differences, membership checks, and subset/superse
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
>
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 issu
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
Jonathan Lang wrote:
Maybe "set" should be an operator akin to "any", "all", "one", and "none",
at least in terms of "&" and "|". That is, if junctions are special cases
of sets, why not allow for the creation of generic sets in much the same
way? Then you could have:
# $A and $B are sets,
unio
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
Rod Adams wrote:
> Now that I've gotten some feedback from my original message (on list and
> off), and have had some time to think about it some more, I've come to
> some conclusions:
>
>Junctions are Sets. (if not, they would make more sense if they
> were.)
As pointed out elsewhere, Junc
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)
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
>
Damian Conway wrote:
Rod Adams wrote:
The overall impression I'm getting here is that we need some syntax
for saying:
$x = any(1..1000) such_that is_prime($x);
In standard Perl 6 that'd be:
$x = any(grep {is_prime $^x} 1..1000);
or, if you prefer your constraints postfixed:
$x = any( (1..100
71 matches
Mail list logo
