Re: Junction Values
Brent 'Dax' Royal-Gordon wrote:
Rod Adams [EMAIL PROTECTED] wrote:
Larry Wall wrote:
That, and we'd like a novice to be able to write
given $x {
when 1 | 2 | 3 {...}
when 4 | 5 | 6 {...}
}
Or just change Cwhen to accept a list of things to compare against,
followed by a coderef.
And change if, unless, while and until to do the same thing.
Actually, upon further investigation, I believe we get this all of this
without junctions.
According to S03, The scalar comma |,| now constructs a list reference
of its operands.
Then S04 mentions that C $scalar ~~ @array is true if $scalar is in
@array.
Since C given ... when uses smart matching for it's evaluation, one
should be able to write the above as:
given $x {
when 1, 2, 3 {...} # at worst, this is: when (1,2,3) {...}
when 4, 5, 6 {...}
}
The simple if is:
if $x ~~ (1,2,3,4) {...} # parens needed here since , is lower than ~~
in precedence.
Same for unless/while/until. And all of this from the entirely useful C
~~ . The S04 code describing @Array ~~ $Scalar (for Num/Str) uses
junctions, but I'd argue a better implementation would be a short
circuiting C for loop, even if junctions exist. It's just plain
faster that way.
So what I see now for utility of junctions is thus:
- Common cases which C ~~ appears to handle for us suitably well.
- Edge cases which, IMHO, do not merit the huffman level of several
single character operators. All of which can be accomplished without the
use of junctions, though not as gracefully.
I see no need for junctions in core.
And lose the ability to say:
when none(1, 2, 3) { ... }
when 1 ^ 2 ^ 3 { ... }# More useful with classes, regexen, etc.
when 1 2 3 { ... }# Likewise
All so that a newbie doesn't confuzzle himself.
You can always write your switch statements the Perl 5 way.
Or you could write:
when ({$^a ~~ /1/ $^a ~~ /2/ $^a ~~/3/}) {...}
And the like. Look up what C $scalar ~~ $coderef does if you're not
convinced.
(side question: what is the proper syntax for using a closure as the
evaluation expression in a C when statement?)
hmm, since the $_ is set, you could likely get away with:
when ({/1/ /2/ /3/}) {...}
in the case of RE's.
Personally, I'd rather have a chain saw than a nail trimmer, even if
I'm less likely to hurt myself with the nail trimmer. And it looks
like we'll have a warning or stricture to keep newbies from chopping
their legs off anyway.
I can understand your sentiments here, but I'd be a lot more sympathetic
to your cause if the alternative ways of accomplishing these things were
actually difficult. I think it's been demonstrated that any of the
junction evaluations could be done with a call to C grep , with
numerous other ways to perform them as well.
-- Rod Adams
Re: Novice
On Wed, Feb 16, 2005 at 01:32:32PM -0600, Jonathan Scott Duff wrote: On Wed, Feb 16, 2005 at 03:09:24PM -0300, LOGGOS TI wrote: Please, where may i download this version ? Is there an usable version Greetings Roberto! You've stumbled upon the mailing list for the design of the Perl 6 language. Unfortunately an implementation does not yet exist, but we're working on it. Well, Autrijus is working on it :-) -- David Cantrell | Hero of the Information Age It doesn't matter to me if someone else's computer is faster because I know my system could smash theirs flat if it fell over on it. -- (with apologies to Brian Chase)
Re: Junction Values
On Thu, Feb 17, 2005 at 02:18:55AM -0600, Rod Adams wrote:
: The simple if is:
:
: if $x ~~ (1,2,3,4) {...} # parens needed here since , is lower than ~~
: in precedence.
That is asking if $x is a list containing 1,2,3,4.
: Same for unless/while/until. And all of this from the entirely useful C
: ~~ . The S04 code describing @Array ~~ $Scalar (for Num/Str) uses
: junctions, but I'd argue a better implementation would be a short
: circuiting C for loop, even if junctions exist. It's just plain
: faster that way.
Junctions can short circuit when they feel like it, and might in some
cases do a better job of picking the evaluation order than a human.
: So what I see now for utility of junctions is thus:
:
: - Common cases which C ~~ appears to handle for us suitably well.
Only if we make lists second-class citizens. The need for junctions
first became evident when we found ourselves filling the ~~ tables
with various sorts of weird non-symmetries.
: - Edge cases which, IMHO, do not merit the huffman level of several
: single character operators. All of which can be accomplished without the
: use of junctions, though not as gracefully.
Grace is important. Even more important is mapping naturally to human
linguistic structures, to the extent that it can be done unambiguously.
: I see no need for junctions in core.
I do, and I'm not likely to change my mind on this one. Sorry.
Larry
Re: Containers vs Objects.
On Thu, Feb 17, 2005 at 08:58:21AM +0100, Thomas Sandlaß wrote: : HaloO Larry, : : you wrote: : That would be cool. I'd like to see our community build up a pool of : theoreticians who are not allergic to the practicalities of building a : language for ordinary people to think in. It is my persistent belief : (and fond hope) that theory and practice don't always have to pull in : opposite directions. : : Well, quoting Einstein: Nothing is more practical than a sound theory! : : :)) Well, sure, but it's psychologically interesting that you personally find an appeal to authority more practical in this situation. :-) Besides, we all understand that Einstein is being disengenuous here in reducing the correlation between sound theory and practice to a single dimension. But human existence is multidimensional, and it is obvious from casual inspection of human history that having a sound theory is only moderately correlated with adaptiveness. Sure, sound theory will occasionally save you from earning a Darwin award, but the correlation breaks down anywhere a low-overhead heuristic is more efficient than a high-maintenance theory. The human psyche is a mishmash of rules of thumb, and Einstein's thumb is only two of them. Anyway, human languages have little to do with sound theory. At best you might try to develop a theory of sound, which we call linguistics. My assertion that we can do better with computer languages is a persistent belief and fond hope, but you'll note I don't actually claim to be either rational or right. Except when it's convenient. :-) Larry
Re: Junction Values
On Thu, Feb 17, 2005 at 09:06:47AM -0800, Larry Wall wrote:
Junctions can short circuit when they feel like it, and might in some
cases do a better job of picking the evaluation order than a human.
Hmm, yes, there is an interesting interaction with lazy
evaluation ranges here.
$x = any( 1 .. 1_000_000_000 );
if( $y == $x ) { ... }
It would be nice if the junction equality test here was much
smarter than a for loop (regardless of whether the for loop
short circuited - suppose $y happens to be -1!).
A range need not enumerate all of its components to be used
in a useful way.
--
Re: Boolean literals
On Wed, Feb 16, 2005 at 11:02:25PM -0600, Patrick R. Michaud wrote: : On Tue, Feb 15, 2005 at 11:03:09PM -0800, Larry Wall wrote: : 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) : : : : What should I do, though? Inventing two primitives, true and : : false? Or is there a way to annotate values with types, similar : : to Haskell's :: construct? : : : : pugs (1 2, 2 1) : : (0 as Bool, 1 as Bool) : : The latest S12 has it as bool::true and bool::false. : : S03 still indicates that boolean operators return a standard : boolean value (either 1 or 0). Are we continuing with 1 and 0 : as the standard boolean values, or bool::true and bool::false? Yes. :-) True boolean values are bits. bool::true and bool::false are just convenient names for certain values of small, 1-bit integers. : More to the point, what's the return type of something like : infix: ? Type bit, which is just a rather small subtype of int. The bit type is really an alias for uint1. If you're asking what it actually returns internally, it's perfectly fine to store a tiny integer subtype into a normal int. So to stop evading your question, it returns 0 or 1. :-) But I buy into the whole subtype/type distinction that Ada made. A compiler is always free to store a subtype value in a type location. You can keep a uint4 in an int. It's only when you assign an int value into a uint4 location that you have to worry about the subtype constraints. (And the compiler is free to optimize the subtype storage based on the constraint, so an array of bits really can be stored compactly.) But boolean context in Perl 6 doesn't enforce that it gets a uint1 subtype. It only enforces that it requires a type that knows how to play the boolean role, either because it has the .bit method, or because it's some low-level type we've hardwired to bypass the .bit method for speed. Larry
Re: Boolean literals
On Wed, 16 Feb 2005 23:02:25 -0600, Patrick R. Michaud [EMAIL PROTECTED] wrote: The latest S12 has it as bool::true and bool::false. S03 still indicates that boolean operators return a standard boolean value (either 1 or 0). Are we continuing with 1 and 0 as the standard boolean values, or bool::true and bool::false? I believe bool::true and bool::false are enums (so they are 1 and 0, respectively). -- matt diephouse http://matt.diephouse.com
Re: Fun with junctions (was Sets vs Junctions)
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 to represent Perl
: data structures. ;-)
Actually, I'm thinking we should just go with a single method and
have it merely default to :langPerl. 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.
How long before someone writes $x.ugly('Python'), I wonder...
Larry
Re: Junction Values
Larry Wall wrote:
On Thu, Feb 17, 2005 at 02:18:55AM -0600, Rod Adams wrote:
: The simple if is:
:
: if $x ~~ (1,2,3,4) {...} # parens needed here since , is lower than ~~
: in precedence.
That is asking if $x is a list containing 1,2,3,4.
Quoting S04:
$_ $xType of Match ImpliedMatching Code
== = ==
Array Array arrays are identical match if $_ »~~« $x
Array any(list) list intersectionmatch if any(@$_) ~~ any(list)
Array Rule array grep match if any(@$_) ~~ /$x/
Array Num array contains numbermatch if any($_) == $x
Array Str array contains stringmatch if any($_) eq $x
And since there are no tell tell *'s on these saying that they are _not_
reversible, I must assume they _are_.
In C if $x ~~ (1,2,3,4) {...} , if $x is type Num or Str, then I see
no way of reconciling your statement above.
: Same for unless/while/until. And all of this from the entirely useful C
: ~~ . The S04 code describing @Array ~~ $Scalar (for Num/Str) uses
: junctions, but I'd argue a better implementation would be a short
: circuiting C for loop, even if junctions exist. It's just plain
: faster that way.
Junctions can short circuit when they feel like it, and might in some
cases do a better job of picking the evaluation order than a human.
I was afraid someone was going to say that. And I now must convert my
reservations about junction autothreading from very disturbing to
you've got to be kidding.
According to Patrick, and since no one has corrected him, I will assume
he is right,
perl6 -e say1 'cat'|'dog'; sub say1 ($x) {say $x}
Should output cat\ndog\n or dog\ncat\n. Now, if we allow Junctions to short circuit, and since there is no fixed order of values in a junction, we could get any of cat\ndog\n, dog\ncat\n, cat\n, or dog\n.
What's that get us? non-deterministic output! I could handle non-deterministic *order* of output, because by the simple fact that you were using a junction, you didn't care about order.
Non-deterministic output! how fun!
Not to mention it contradicts S09:
... that routine is autothreaded, meaning the routine will be called
automatically as many times as necessary to process the individual scalar elements of the junction
in parallel.
Now there is some wiggle room in there for short circuiting, but not very much.
: So what I see now for utility of junctions is thus:
:
: - Common cases which C ~~ appears to handle for us suitably well.
Only if we make lists second-class citizens. The need for junctions
first became evident when we found ourselves filling the ~~ tables
with various sorts of weird non-symmetries.
So what other semantic makes sense for:
Str ~~ Array
Num ~~ Array
which would better appeal to your sense of symmetry?
Besides, people were telling me that my Sets were not needed, because
they could be rendered with Arrays and Hashes. I fail to see how
junctions are that different.
: - Edge cases which, IMHO, do not merit the huffman level of several
: single character operators. All of which can be accomplished without the
: use of junctions, though not as gracefully.
Grace is important. Even more important is mapping naturally to human
linguistic structures, to the extent that it can be done unambiguously.
In my experience, English tends not to superimpose several values on a
given noun at once.
: I see no need for junctions in core.
I do, and I'm not likely to change my mind on this one. Sorry.
I realized that fairly early on. The situation I'm in is that while I
don't agree with all the design initiatives that come out here, it's
been the case that the more I think about them, the more I like them. I
always achieve at least a state of ambivalence or better about it.
With Junctions, it's been the case that at first I thought they were
useful and cool, but the more I think about them, the more I dislike them.
I'll argue my case for a few more days, and if I haven't gotten anywhere
by then, I'll likely give up.
-- Rod Adams
Re: Fun with junctions (was Sets vs Junctions)
Larry wrote:
Actually, I'm thinking we should just go with a single method and
have it merely default to :langPerl. 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 shouldn't introduce oxymorons into the language. ;-)
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[Language ::To] is Str {
multi sub *coerce:as (Any $data, To ::Lang) {
return Lang.serialize($data)
}
}
Then you could just write:
my $good = $x as Source[Perl];
my $bad = $x as Source[C::Sharp];
my $ugly = $x as Source[Lisp];
And adding a new serialization would simply mean adding a new Language
subclass with an appropriate .serialize() method:
class YAML is Language {
method serialize($data) {
...
}
}
class XML is Language {
method serialize($data) {
...
}
}
# etc.
Damian
