Wh<[ie]>ther Infix Superposition ops
Piers Cawley
say that I'm really not sure of the utility of the proposed infix
superposition ops. I'm a big fan of any/all/one/none, I just think
that
one(any($a, $b, $c), all($d, $e, $f))
Is a good deal more intention revealing than the superficially
appealing than
($a & $b & $c) ^ ( $d | $e | $f )
which takes rather more decoding. And if you *do* want to use such
operators, surely you could just do
use ops ':superpositions';
in an appropriate lexical scope. Am I missing something?
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Piers Cawley
> On 29 Oct 2002 at 5:45, Piers Cawley wrote:
>
>> Whilst I don't wish to get Medieval on your collective donkey I must
>> say that I'm really not sure of the utility of the proposed infix
>> superposition ops. I'm a big fan of any/all/one/none, I just think
>> that
>>
>> one(any($a, $b, $c), all($d, $e, $f))
>>
>> Is a good deal more intention revealing than the superficially
>> appealing than
>>
>> ($a & $b & $c) ^ ( $d | $e | $f )
>>
>> which takes rather more decoding. And if you *do* want to use such
>> operators, surely you could just do
>>
>> use ops ':superpositions';
>>
>> in an appropriate lexical scope. Am I missing something?
>
> appealing. There are less chars and paretheses are seen much more
> easily. The 'one(...)' especially seems to be superficial, as it's
> just 'this or that' operation in this case, and so single operator
> fits perfectly.
>
> Also the idea of allways using 'function' style for something so
> basic like superpositions doesn't appeal to me. Of course this might
> just be that I'm too used to use strange mathematical symbols.
> (Nobody ever understood my solutions in high-school...)
But they *aren't* 'strange mathematical symbols', they're well
understood symbols in algol style programming languages, and they mean
'bitwise logic'. I'm not agin the using the operators to mean
'superposition builder', but I do think there's a case for having to
introduce them in a lexical scope with an appropriate USE statement.
Markus Laire
> Whilst I don't wish to get Medieval on your collective donkey I must
> say that I'm really not sure of the utility of the proposed infix
> superposition ops. I'm a big fan of any/all/one/none, I just think
> that
>
> one(any($a, $b, $c), all($d, $e, $f))
>
> Is a good deal more intention revealing than the superficially
> appealing than
>
> ($a & $b & $c) ^ ( $d | $e | $f )
>
> which takes rather more decoding. And if you *do* want to use such
> operators, surely you could just do
>
> use ops ':superpositions';
>
> in an appropriate lexical scope. Am I missing something?
In this case I find the latter to be easier to decode and more
appealing. There are less chars and paretheses are seen much more
easily. The 'one(...)' especially seems to be superficial, as it's
just 'this or that' operation in this case, and so single operator
fits perfectly.
Also the idea of allways using 'function' style for something so
basic like superpositions doesn't appeal to me. Of course this might
just be that I'm too used to use strange mathematical symbols.
(Nobody ever understood my solutions in high-school...)
--
Markus Laire 'malaire' <markus...@nic.fi>
Luke Palmer
> From: Piers Cawley <pdca...@bofh.org.uk>
> Date: Tue, 29 Oct 2002 05:45:01 +0000
> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
>
> Whilst I don't wish to get Medieval on your collective donkey I must
> say that I'm really not sure of the utility of the proposed infix
> superposition ops. I'm a big fan of any/all/one/none, I just think
> that
>
> one(any($a, $b, $c), all($d, $e, $f))
>
> Is a good deal more intention revealing than the superficially
> appealing than
>
> ($a & $b & $c) ^ ( $d | $e | $f )
>
> which takes rather more decoding. And if you *do* want to use such
> operators, surely you could just do
>
> use ops ':superpositions';
>
> in an appropriate lexical scope. Am I missing something?
Uh huh. This:
if $x == 1 | 3 | 6 { print "Small triangular" }
I imagine it will not take long for these to sink in to people's
brains, and become used in very clever (and readable) ways.
If you read | as "or," and & as "and," instead of trying to translate
them to "any" and "all," things get very nice.
Plus, a scripting (or, in the case of P6, high level) language with
such small bitwise ops gives me the shivers. C, sure, they're common.
Perl, no, not usually. I was even dissatisfied with them in C++,
which is a high- low-level language.
Luke
Piers Cawley
>> Mailing-List: contact perl6-lan...@perl.org; run by ezmlm
>> From: Piers Cawley <pdca...@bofh.org.uk>
>> Date: Tue, 29 Oct 2002 05:45:01 +0000
>> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
>>
>> Whilst I don't wish to get Medieval on your collective donkey I must
>> say that I'm really not sure of the utility of the proposed infix
>> superposition ops. I'm a big fan of any/all/one/none, I just think
>> that
>>
>> one(any($a, $b, $c), all($d, $e, $f))
>>
>> Is a good deal more intention revealing than the superficially
>> appealing than
>>
>> ($a & $b & $c) ^ ( $d | $e | $f )
>>
>> which takes rather more decoding. And if you *do* want to use such
>> operators, surely you could just do
>>
>> use ops ':superpositions';
>>
>> in an appropriate lexical scope. Am I missing something?
>
> Uh huh. This:
>
> if $x == 1 | 3 | 6 { print "Small triangular" }
>
> I imagine it will not take long for these to sink in to people's
> brains, and become used in very clever (and readable) ways.
So, if that's the way you're going to be using | in your code, just do
C<use ops ':superposistions'> at the top of your file, in the same way
as you do C<use strict> now. Or wrap it up in a policy file and do
C<use policy '...'>.
> If you read | as "or," and & as "and," instead of trying to translate
> them to "any" and "all," things get very nice.
Again, I'm not denying the usefulness, just worried that we're jumping
through an awful lot of more or less ugly and complex syntactic hoops
to get this particular chunk of behaviour into perl 6, when you could,
instead, allow the behaviour to be pragma selectable without bending
the rest of the syntax to accommodate.
> Plus, a scripting (or, in the case of P6, high level) language with
> such small bitwise ops gives me the shivers. C, sure, they're common.
> Perl, no, not usually. I was even dissatisfied with them in C++,
> which is a high- low-level language.
Catch is, they're there now and useful, especially when you start
dealing with the outside world (C<O_RDWR | O_CREAT> anyone?)
Simon Cozens
> In this case I find the latter to be easier to decode and more
> appealing. There are less chars and paretheses are seen much more
> easily.
Ack, I guess that means we need a one character DWIM operator.
Although "..." comes pretty close, I suppose.
> something so basic like superpositions
Now I'm just scared.
--
I knew that a goodly number of train operating companies had
introduced quiet coaches, but I was still a little concerned
to find that my tickets were prominently marked NOT READING.
- Geraint Jones
Luke Palmer
> From: Piers Cawley <pdca...@bofh.org.uk>
> Date: Tue, 29 Oct 2002 09:36:12 +0000
Heh, I don't C<use strict>... or C<warnings>. :)
As far as frequency goes, though, I think C<use ops ':cbitwise'> would
would be more needed. I mean I'm not sure of that: I'm using a sample
size of 1. But that's my best guess.
You have a point. The larger programs will make use of the
superpositions, and the smaller ones will make use of the bitwises.
Better to make the bigger programs use pragmas, and the little ones be
one-linerable. But who knows, superpositions could often be useful in
scripts, too:
find | perl -nle 'print join "\n", (s+\.++ | s/~$//).states'
Ok, that was a terrible example. But you know what I mean....
> > Plus, a scripting (or, in the case of P6, high level) language with
> > such small bitwise ops gives me the shivers. C, sure, they're common.
> > Perl, no, not usually. I was even dissatisfied with them in C++,
> > which is a high- low-level language.
>
> Catch is, they're there now and useful, especially when you start
> dealing with the outside world (C<O_RDWR | O_CREAT> anyone?)
Hopefully there won't be a need for that C<sysopen> stuff. The I/O
system better be good enough to allow me to specify those flags
without "jumping through syntactc hoops" in terms of those ugly C
constants.
Plus, who says C<O_RDWR> and C<O_CREAT> can't just be constants, and
C<O_RDWR | O_CREAT> a superposition of them. It could mean the same
thing :)
Additionally, bitwise ops sure are useful... in a small amout of code.
Three or four lines per program. That's why we're not getting rid of
them, just making them longer. Superpositions will turn out to be
unimaginably handy, possibly used in 10% or 15% of the code, so they
get shorter names.
In my mind, Perl is stepping away from being a direct derivative of C;
rather, a derivative of Perl. And it doesn't seem that the bitwise
ops are used enough anymore to get a single character. If they get a
single character, surely =~ (~~) should have one.
Luke
Austin Hastings
--- Piers Cawley <pdca...@bofh.org.uk> wrote:
> >>
> >> one(any($a, $b, $c), all($d, $e, $f))
> >>
> >> Is a good deal more intention revealing than the superficially
> >> appealing than
> >>
> >> ($a & $b & $c) ^ ( $d | $e | $f )
Would it be practical/meaningful to say
$result = bitwise ($a & $b & $c) ^ ($d | $e | $f);
$result = superpose ($a & $b & $c) ^ ($d | $e | $f);
And allow a use operation to select defaulting behavior? (With an
appropriate warning if the code used one of these operators without
specifying the use directive, even though <crab-style> is the default?)
[ But it's crucial not to require more quotes and stuff. Just change
the mode for the remainder of the subexpression. ]
=Austin
__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/
Jonathan Scott Duff
> Also the idea of allways using 'function' style for something so
> basic like superpositions doesn't appeal to me.
Superpositions are "basic" in a fabric-of-the-universe kind of way, but
they are hardly basic in the everyone-learns-them-in-grade-school kind
of way. I think the latter is more important for huffman coding of
operators for the unwashed masses. But I'm willing change my mind if we
start teaching everyone superpositions in grade school :-)
Or if someone can show that they aren't really something new and
amazing, but something old and comfortable but with a funny name and
more power.
-Scott
--
Jonathan Scott Duff
du...@cbi.tamucc.edu
Jonathan Scott Duff
> Superpositions will turn out to be unimaginably handy, possibly used
> in 10% or 15% of the code, so they get shorter names.
Statements like this bother me. Not because I don't think it might be
true, but because it's in future tense. If someone (named Damian :-)
wrote a superposition synopsis that showed the many and varied uses of
superpositions in contexts that ordinary programmers can relate to, it
would bother me less when people make claims about the usefulness of
superpositions.
I mean, if superpositions are so useful, who's using them now? How many
modules on CPAN require them? Why hasn't the word spread like
wildfire about them such that your average sysadmin is using them in
his code? I don't know of anyone using superpositions casually or in
production code.
> In my mind, Perl is stepping away from being a direct derivative of C;
> rather, a derivative of Perl. And it doesn't seem that the bitwise
> ops are used enough anymore to get a single character. If they get a
> single character, surely =~ (~~) should have one.
I agree.
Simon Cozens
> Statements like this bother me. Not because I don't think it might be
> true, but because it's in future tense. If someone (named Damian :-)
> wrote a superposition synopsis that showed the many and varied uses of
> superpositions in contexts that ordinary programmers can relate to, it
> would bother me less when people make claims about the usefulness of
> superpositions.
I'll take one of those for perl.com!
> I mean, if superpositions are so useful, who's using them now? How many
> modules on CPAN require them? Why hasn't the word spread like
> wildfire about them such that your average sysadmin is using them in
> his code? I don't know of anyone using superpositions casually or in
> production code.
I was very tempted to use a superposition in production code, but realised
a grep of an array did the same job.
--
Oh dear. I've just realised that my fvwm config lasted longer than my
marriage, in that case.
- Anonymous
Dan Sugalski
>On Tue, Oct 29, 2002 at 10:13:39AM +0200, Markus Laire wrote:
>> Also the idea of allways using 'function' style for something so
>> basic like superpositions doesn't appeal to me.
>
>Superpositions are "basic" in a fabric-of-the-universe kind of way, but
>they are hardly basic in the everyone-learns-them-in-grade-school kind
>of way. I think the latter is more important for huffman coding of
>operators for the unwashed masses. But I'm willing change my mind if we
>start teaching everyone superpositions in grade school :-)
Perhaps the best thing to do is to define a word operator for
superpositions and, if they later become really popular, snag some
generally-available* extended character to represent the operators.
*Generally available meaning in all of the Shift-JIS, Big5, and
Unicode sets, assuming there are some that aren't Kanji
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Piers Cawley
> du...@cbi.tamucc.edu (Jonathan Scott Duff) writes:
>> Statements like this bother me. Not because I don't think it might be
>> true, but because it's in future tense. If someone (named Damian :-)
>> wrote a superposition synopsis that showed the many and varied uses of
>> superpositions in contexts that ordinary programmers can relate to, it
>> would bother me less when people make claims about the usefulness of
>> superpositions.
>
> I'll take one of those for perl.com!
I keep meaning to look into nondeterministic algorithms to see if you
can use Superpositions to get them working...
Larry Wall
: --- Piers Cawley <pdca...@bofh.org.uk> wrote:
: > >>
: > >> one(any($a, $b, $c), all($d, $e, $f))
: > >>
: > >> Is a good deal more intention revealing than the superficially
: > >> appealing than
: > >>
: > >> ($a & $b & $c) ^ ( $d | $e | $f )
First I would like to point out that the & and | are backwards there
from the original. & means all(), and | means any().
: Would it be practical/meaningful to say
:
: $result = bitwise ($a & $b & $c) ^ ($d | $e | $f);
: $result = superpose ($a & $b & $c) ^ ($d | $e | $f);
:
: And allow a use operation to select defaulting behavior? (With an
: appropriate warning if the code used one of these operators without
: specifying the use directive, even though <crab-style> is the default?)
All other things being equal, I think people will find modal operators
more confusing than if we just make separate operators.
That being said, I'm still wondering whether we can finesse it. Damian's
default any() semantics in numeric context select a random element. If
we made that not the default, we could have an alternate default semantics
in numeric (or, at least, integer) context. So suppose we introduce for
the "pick one" semantics an explicit verb named, oddly enough, pick().
my int $foo = pick( 1 | 2 | 4 ); # $foo gets (1,2,4)[rand 3]
my int $bar = 1 | 2 | 4; # $bar gets 7
People can be scared if they like, but I am also of the opinion that
superpositions are more "basic" than bitops, at least in a sense.
My reasoning for that is that they don't commit to an interpretation
prematurely. A 1 | 2 | 4 means "a 1, a 2, or a 4", nothing more.
You can make other things out of a superposition depending on the
context. Damian already made them mean two different things in numeric
vs string context. We could possibly make them mean more things.
So I wonder about whether, in
$result = superpose ($a & $b & $c) ^ ($d | $e | $f);
the "superpose" is really a no-op. If you go on to say
my int $foo = pick( $result ); # random element filling "contract"
my int $bar = $result; # bitwise
then the superposition would collapses as specified.
There is one little difficulty with this approach, though. It would
have to retroactively change the meaning of non-powers-of-two. That is,
if you say
$mask = 7;
$somebits = 1 | 2;
my int $foo = $somebits & $mask;
then at the point of wave-function collapse, the 7 from $mask has to
be re-interpreted as a 1|2|4. Maybe that's okay, and maybe it isn't.
From a transactional view of QM, it's probably fine, since that view
allows for sending information back through time to entangled partners.
It's also fine from a tagmemics point of view, I think, since context
can change the meaning of both nouns and verbs.
Actually, I suppose that in contrast to int context, num context
could pick() by default. And str context could do strbitops.
Or it could do the currently specified str default of listing out
the whole shebang. That's probably more user-friendly when you print
out error messages, so I expect stringwise bitop collapse would have
to be requested explicitly. Or we need to have a bitstring type, or
some such. There are other places where distinguishing data strings
from human-readable strings would be useful.
Larry
Larry Wall
: Perhaps the best thing to do is to define a word operator for
: generally-available* extended character to represent the operators.
Sorry, I believe in the transactional model of QM, and the future
has already reached back in time and grabbed | and &. :-)
: *Generally available meaning in all of the Shift-JIS, Big5, and
: Unicode sets, assuming there are some that aren't Kanji
I believe & and | already satisfy that particular constraint. :-)
So does X, for that matter.
Now, we'd be in real trouble if we'd picked \ for xor, since that's
the yen sign in Japanese.
Larry
Michael Lazzaro
On Tuesday, October 29, 2002, at 09:08 AM, Jonathan Scott Duff wrote:
> Statements like this bother me. Not because I don't think it might be
> true, but because it's in future tense. If someone (named Damian :-)
> wrote a superposition synopsis that showed the many and varied uses of
> superpositions in contexts that ordinary programmers can relate to, it
> would bother me less when people make claims about the usefulness of
> superpositions.
I think superpositions will, indeed, be extensively used, but I don't
think they'll be called "superpositions" by most of the people that use
them. They're typically used more like "set operations". Something as
basic as
if any($x,$y,$z) > 10 # if ($x | $y | $z) > 10
is pretty useful, even in simple code. As is
my $n = (1..100) | "don't care";
The collapsification to a discrete value would, I imagine, be typically
used to select a random entry from a set.
my $r = any(@set);
print $r; # assuming this _does_ collapse
And I'm *really* looking forward to having union/intersection
operations, because it solves lots of the typical Cookbook recipes for
lists and hashes as one-liners.
This is why I am nervous about introducing terms like eigenbunny, etc.,
into the general vocabulary of the language. It attempts to make it
sound harder than it is, I think -- there are plenty of uses for these
operators outside the "collapsing" dynamics they allow. If we focus
first on an explanation that does not take directly from quantum
mechanics, but rather sort of ...slide... into the QM meanings after
explaining the more easily understood "set" meanings, I think it will
be quite quickly adopted by newbies.
MikeL
Simon Cozens
> So I would look favorably on finding a replacement for "superposition".
Predicate calculus? :) Seriously, I see no problem with calling them
"set operators".
--
For true believers, LORD would be K\textsc{nuth} in TeX, and
L\textsc{amport} in LaTeX. Atheists prefer \phantom{LORD}. Agnostics
may need to use the ifthen package.
- Chris Boyd, comp.text.tex
Larry Wall
: On Tue, Oct 29, 2002 at 10:13:39AM +0200, Markus Laire wrote:
: > Also the idea of allways using 'function' style for something so
: > basic like superpositions doesn't appeal to me.
:
: Superpositions are "basic" in a fabric-of-the-universe kind of way, but
: they are hardly basic in the everyone-learns-them-in-grade-school kind
: of way. I think the latter is more important for huffman coding of
: operators for the unwashed masses. But I'm willing change my mind if we
: start teaching everyone superpositions in grade school :-)
That won't happen, because they don't *have* to be taught in grade
school. You learn any() and all() as part of language before you
ever get to grade school. What kindergartener can't understand a
logically entangled list of nouns?
I want a tricycle or a video game or a teddy bear for Christmas.
I want a tricycle and a video game and a teddy bear for Christmas.
That's no different from:
$self.want($tricycle | $video_game | $teddy_bear);
$self.want($tricycle & $video_game & $teddy_bear);
Logically entangle nouns *are* more basic than grade school. Kids are
even sophisticated enough to disambiguate "xor" from "or" by context,
despite the fact that English has no "xor" operator:
Which do you want? A popsicle or a Mickey Mouse hat?
That's something like:
$you.pick($popsicle X $hat);
: Or if someone can show that they aren't really something new and
: amazing, but something old and comfortable but with a funny name and
: more power.
Well, "quantum superpositions" really is a very funny name. I've been
reducing that to "super" lately, but even that's misleading, because
it's hard to think of something "super" as basic. I prefer to think
of them as logically related nouns like we use all the time in English.
Logic for nouns rather than verbs. Something a toddler can understand.
So I would look favorably on finding a replacement for "superposition".
Larry
Garrett Goebel
> la...@wall.org (Larry Wall) writes:
> > So I would look favorably on finding a replacement for
> > "superposition".
>
> calling them "set operators".
Great minds think alike. Or in this case even me ;) I was just describing
superpositions as set operations to one of our developers...
I'm left wondering what the relationship between Perl6 and relational
databases will be. Where one will leave off and the other will begin.
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.384.1008
Mission, KS 66202 Fax: 913.384.2180
www.scriptpro.com gar...@scriptpro.com
Dan Sugalski
>On Tue, 29 Oct 2002, Dan Sugalski wrote:
>: Perhaps the best thing to do is to define a word operator for
>: superpositions and, if they later become really popular, snag some
>: generally-available* extended character to represent the operators.
>
>Sorry, I believe in the transactional model of QM, and the future
>has already reached back in time and grabbed | and &. :-)
Well, I suppose when people use them as bitwise operators they won't
be any more confusingly wrong then they often are now...
>: *Generally available meaning in all of the Shift-JIS, Big5, and
>: Unicode sets, assuming there are some that aren't Kanji
>
>I believe & and | already satisfy that particular constraint. :-)
>
>So does X, for that matter.
I was thinking more of the double-vertical bar or one of the stars. I
admit I'm really not sure that the quantum operations will be used
enough to warrant blowing people's expectations of bitwise
operations, even if the bitwise operations aren't used that much. Not
my call, though--it's all assembly as far as I'm concerned. :)
Brian Ingerson
How about "christmasgift" or "gift"?
You don't know what it is until you open it. It could be any, all or none of
what you expected.
How about "envelope"? (noun)
Or better yet "pocket". What has it gots in its pocketses my precious?
To keep that QM feel you could call it a "hotpocket".
Cheers, Brian
Jonathan Scott Duff
> On 29/10/02 09:58 -0800, Larry Wall wrote:
> > On Tue, 29 Oct 2002, Jonathan Scott Duff wrote:
> > : On Tue, Oct 29, 2002 at 10:13:39AM +0200, Markus Laire wrote:
> >
> > So I would look favorably on finding a replacement for "superposition".
>
> How about "christmasgift" or "gift"?
>
> You don't know what it is until you open it. It could be any, all or none of
> what you expected.
Then we should definitely call it "cat" ;-)
Jonathan Scott Duff
> This is why I am nervous about introducing terms like eigenbunny, etc.,
> into the general vocabulary of the language. It attempts to make it
> sound harder than it is, I think -- there are plenty of uses for these
> operators outside the "collapsing" dynamics they allow.
I like the eigen- prefix. It adds to the unique flavor of perl jargon
(where else will you see the term "sigil" bandied about?). If we called
yadda*3 "gedanken code" that wouldn't bother me either. :-)
David Wheeler
> What kindergartener can't understand a
> logically entangled list of nouns?
>
> I want a tricycle or a video game or a teddy bear for Christmas.
> I want a tricycle and a video game and a teddy bear for Christmas.
>
> That's no different from:
>
> $self.want($tricycle | $video_game | $teddy_bear);
> $self.want($tricycle & $video_game & $teddy_bear);
I think that this (and the remainder of your message) is a beautiful
demonstration of the utility of the superposition operators. I notice
that the naysayers suddenly quieted down after this message.
> So I would look favorably on finding a replacement for "superposition".
Well, I like "set operators," too, but what's the grammatical term for
the above "logically entangled list of nouns"?
Regards,
David
--
David Wheeler AIM: dwTheory
da...@wheeler.net ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: The...@jabber.org
Austin Hastings
I think this may be in response to an earlier message of yours looking
for a replacement for "superposition." But I recall getting a Dilbert
calendar for Xmas some years back with a cover featuring the PHB saying
"I'm not indecisive - I'm flexible!"
Thus, flexops. And flexpressions (flexprs, for short). With
operator:flexible|, operator:flexible&, and operator:flexible^.
And
$result = flexible ($a & $b & $c) ^ ($d | $e | $f);
instead of
$result = bitwise ($a & $b & $c) ^ ($d | $e | $f);
(Of course, flexprs are the default, so you won't need to specify that.
See below.)
--- Larry Wall <la...@wall.org> wrote:
> On Tue, 29 Oct 2002, Austin Hastings wrote:
> : --- Piers Cawley <pdca...@bofh.org.uk> wrote:
> : > >>
> : > >> one(any($a, $b, $c), all($d, $e, $f))
> : > >>
> : > >> Is a good deal more intention revealing than the superficially
> : > >> appealing than
> : > >>
> : > >> ($a & $b & $c) ^ ( $d | $e | $f )
>
> First I would like to point out that the & and | are backwards there
> from the original. & means all(), and | means any().
Which implies, since no one else has pointed this out, that
<function-style> is not as clear as <operator-style>.
(FYI: The little <>'s around -style descriptors is shorthand for some
sort of Saturday afternoon "Kung Fu Theatre" combat pose. As in, "Your
<stork> is no match for my <drunken guppy>. My sister will be
avenged!")
>
> : Would it be practical/meaningful to say
> :
> : $result = bitwise ($a & $b & $c) ^ ($d | $e | $f);
> : $result = superpose ($a & $b & $c) ^ ($d | $e | $f);
> :
> : And allow a use operation to select defaulting behavior? (With an
> : appropriate warning if the code used one of these operators without
> : specifying the use directive, even though <crab-style> is the
> default?)
>
> All other things being equal, I think people will find modal
> operators
> more confusing than if we just make separate operators.
To quote Rene Descartes, "I think not! (poof!)"
From what everyone has chipped in thus far, the discussion is between
the "conservatives" who feel that since everyone knows 'C', we should
keep the 'C' operator semantics when possible, and the "avant garde"
who feel that "bitops are dead, long live flexops!"
Frankly, I have a hard time imagining a perl program where bitops are
generally useful. (In functions, yes. But will they permeate the
code?)On the other hand, flexops may well be. So I propose that we give
the "nervous" types a way to clearly specify both, and provide a
default (<new-style>).
There's no going back, of course. But the ability to give warnings on
unspecific ops and the ability to override the default should satisfy
the conservatives long enough to get them addicted to qrack..
> That being said, I'm still wondering whether we can finesse it.
> Damian's
> default any() semantics in numeric context select a random element.
> If
> we made that not the default, we could have an alternate default
> semantics
> in numeric (or, at least, integer) context. So suppose we introduce
> for
> the "pick one" semantics an explicit verb named, oddly enough,
> pick().
>
> my int $foo = pick( 1 | 2 | 4 ); # $foo gets (1,2,4)[rand 3]
> my int $bar = 1 | 2 | 4; # $bar gets 7
It seems to me that flexible results are more like NaN than anything
else. Once they go into an expression, they corrupt the expression.
my $var = 1 | 3;
print $var * 2 - 1;
Should print something like:
ANY-SCALAR(1|5)
Or perhaps it should give a warning:
"Doubleplusungood: Eigenbunny at line 3. Scalar expected."
> People can be scared if they like, but I am also of the opinion that
> superpositions are more "basic" than bitops, at least in a sense.
> My reasoning for that is that they don't commit to an interpretation
> prematurely. A 1 | 2 | 4 means "a 1, a 2, or a 4", nothing more.
> You can make other things out of a superposition depending on the
> context. Damian already made them mean two different things in
> numeric
> vs string context.
Can I say
bitwise $str ^~^= 16:20 x ...; # Each chr in $str xor= shift;
to change case? Or is one ^ enough? (Admittedly an ASCII hack, but ..)
> So I wonder about whether, in
>
> $result = superpose ($a & $b & $c) ^ ($d | $e | $f);
>
> the "superpose" is really a no-op.
I don't think so. Or at least, if it is, I'm not sure how to deal with
it. Because I fear trying to mix "eval" and whatever parser magic is
implied below. And if you don't do that, then there's property-creation
going on which will upscrew the optimizer, I think. (See next para
below.)
> If you go on to say
>
> my int $foo = pick( $result ); # random element filling
> "contract"
> my int $bar = $result; # bitwise
>
> then the superposition would collapses as specified.
What do you do for actions at a distance. That is, you say my int $foo
= (3 | 4); here, and return $foo, and store it away in a hash, and some
time later, possibly in a different module written months earlier, take
that value OUT of that hash (or, worse, read it back in from a
serialized representation).
Did you carry the flexibility with you throughout? If so, what's the
impact on performance going to be when you can't decide if a value is 7
or 3|4 (note: I'm deliberately NOT using 1|2|4. Look at some of the
flags in /usr/include/sys/*.)
> There is one little difficulty with this approach, though. It would
> have to retroactively change the meaning of non-powers-of-two. That
> is,
> if you say
>
> $mask = 7;
> $somebits = 1 | 2;
> my int $foo = $somebits & $mask;
>
> then at the point of wave-function collapse, the 7 from $mask has to
> be re-interpreted as a 1|2|4. Maybe that's okay, and maybe it isn't.
> From a transactional view of QM, it's probably fine, since that view
> allows for sending information back through time to entangled
> partners.
> It's also fine from a tagmemics point of view, I think, since context
> can change the meaning of both nouns and verbs.
Yes, but if I say
$netmask = 256:255.255.255.0;
$ip_range = any(256:10.10.10.1 .. 256:10.10.10.200);
print $netmask & $value;
What will you print? Having any() (aka operator:flexible|) "taint" the
expression probably won't dwim. I don't want $netmask to be converted
into a flexpression -- it's bits! I want 200 different alternates, all
alike.
Austin Hastings
features of the new US dollar bill?
"You know that eye-in-the-pyramid looking thingy? Well, notice what
character on the COMPUTER KEYBOARD that looks like? It's not by
coincidence that many of the programmers at the Treasury Dept. are
PERLMASONS! IT'S A CONSPIRACY!!!"
And it's mostly Bavarian (German)-sounding. Better and better.
I'd prefer to be the Gnomes of Zurich, but I suppose I can play a
Discordian.
Markoff Cheney
--- Jonathan Scott Duff <du...@cbi.tamucc.edu> wrote:
> I like the eigen- prefix. It adds to the unique flavor of perl jargon
> (where else will you see the term "sigil" bandied about?). If we
> called yadda*3 "gedanken code" that wouldn't bother me either. :-)
Dan Sugalski
>This is why I am nervous about introducing terms like eigenbunny, etc.
Oh, I dunno, I kind of like it. Of course, now my kids want
eigenbunny slippers... (Though the trouble with those is they may or
may not be keeping your feet warm--you can never tell)
Miko O'Sullivan
> This is why I am nervous about introducing terms like eigenbunny, etc.
Beats the heck out of "thingy". I had to read that chapter three times
before I realized that Randal hadn't just forgotten the real word.
I still feel uncomfortable saying it in the office.
-Miko
Damian Conway
>>In this case I find the latter to be easier to decode and more
>>appealing. There are less chars and paretheses are seen much more
>>easily.
>
> Ack, I guess that means we need a one character DWIM operator.
> Although "..." comes pretty close, I suppose.
Great minds think alike.
Acme::DWIM <http://search.cpan.org/author/DCONWAY/Acme-Bleach-1.12/lib/Acme/DWIM.pm>
gave Perl5ers exactly that, 18 months ago. ;-)
Damian
Jonathan Scott Duff
> Well, I like "set operators," too, but what's the grammatical term for
> the above "logically entangled list of nouns"?
I'd call them "ents" if not for Austin Hastings' more sensible
"flexops" (unless someone wants to take a stab at relating
superpositions to tree people :-)
Damian Conway
> Whilst I don't wish to get Medieval on your collective donkey I must
> say that I'm really not sure of the utility of the proposed infix
> superposition ops. I'm a big fan of any/all/one/none, I just think
> that
>
> one(any($a, $b, $c), all($d, $e, $f))
>
> Is a good deal more intention revealing than the superficially
> appealing than
>
> ($a & $b & $c) ^ ( $d | $e | $f )
I very much doubt that most people will write either of those.
I suspect it will be quite unusual to see nested superpositions
in code. Most folks are going to be using them for simple but
very common checks like:
if ( $start & $finish < 0 } {
($finish,$start) = [-]($start,$finish); # hyper negate
}
if ( $start | $finish < 0 ) {
print "Bad index\n" and die;
}
given $start {
when 1|3|5|7|9 { print "That's odd...\n" }
when 2|4|6|8|10 { print "Even so...\n" }
default { print "Taking off shoes...\n" }
}
my $seen = $start | $finish;
for <> -> $next {
print $next unless $next == $seen;
$seen |= $next;
}
> which takes rather more decoding. And if you *do* want to use such
> operators, surely you could just do
>
> use ops ':superpositions';
>
> in an appropriate lexical scope. Am I missing something?
Yes. That superpositions are going to be so widely used once people
catch on, that users going to curse us every time they have to
write C<use ops ':superpositions';> at the start of every scope.
;-)
Damian
Damian Conway
>>If someone (named Damian :-)
>>wrote a superposition synopsis that showed the many and varied uses of
>>superpositions in contexts that ordinary programmers can relate to, it
>>would bother me less when people make claims about the usefulness of
>>superpositions.
>
> I'll take one of those for perl.com!
And I'll certainly write one, when/if it's appropriate.
Hint: we may need an Apocalypse N.5 and a corresponding Exegesis N.5
to deal with superpositions, since they don't really fit into the
existing chapter structure of the Camel.
Hmmm, I guess that, since superpositions are both value and operators,
that should be "Exegesis any(2,3)" ;-)
> I was very tempted to use a superposition in production code, but realised
> a grep of an array did the same job.
Sure. TMTOWTDI. And under the current Q::S implementation, C<grep>
almost certainly did it faster too.
But for simple cases, I suspect that using a built-in Perl 6 superposition:
if any(@values) % 2 { print "That's odd...\n" }
is more maintainable (and probably faster) than C<grep>:
if grep { $_ % 2} @values { print "That's odd...\n" }
Damian
fear...@figaro.weizmann.ac.il
maybe something containing "parallel" since that is what they are
doing : put those things in parallel universes and let them go.
( as opposed to seqential thinking in "Classical" language )
parallel
parallel_ ??? # do not know english enouth to come with something here
or maybe taking analogu from
do { ... } # immediate code
sub{ ... } # deferred code
1 or 2 immediate choice
1 | 2 choice is deferred
so
deferred logic
arcadi
Damian Conway
> would look favorably on finding a replacement for "superposition".
any(
"multivalue",
"multival",
"opval" => "andval"|"orval"|"xorval"|"nandval",
"opval" => "andval"|"orval"|"exval"|"nonval",
"opval" => "allval"|"anyval"|"oneval"|"noneval",
"set" => "andset"|"orset"|"xorset"|"nandset",
"set" => "andset"|"orset"|"exset"|"nonset",
"set" => "allset"|"anyset"|"oneset"|"noneset",
"junction" => "conjunction"|"disjunction"|"exclusion"|"rejection",
"junctive" => "conjunctive"|"disjunctive"|"exclusive"|"dismissive",
)
Damian
Damian Conway
> Well, I like "set operators," too, but what's the grammatical term for
> the above "logically entangled list of nouns"?
"Superposition".
Damian
fear...@figaro.weizmann.ac.il
maybe explicitely "Shroedinger cat" this make it ( for all those for
whom "superposition" tell little )
at the same more personal, christmas-gift-like, ( who is shroedinger ?)
and equally informative .
aracdi
John Siracusa
> I suspect it will be quite unusual to see nested superpositions
> in code. Most folks are going to be using them for simple but
> very common checks like:
>
>
> my $seen = $start | $finish;
> for <> -> $next {
> print $next unless $next == $seen;
> $seen |= $next;
> }
I just spent 2 minutes staring at that last example until I finally
understood it. While I agree that there are many common uses for this
stuff, not all common uses are "simple", IMO.
I think my hang-up mostly had to do with all the existing "knowledge" I have
about how "|" and "|=", and even "==" are "supposed" to work. Had the
example used the English versions of the operators, I would have gotten it
instantly:
my $seen = any($start, $finish);
for <> -> $next
{
print $next unless $next == $seen;
$seen = any($seen, $next);
}
(Okay, maybe I would have gotten stuck for a moment on the "$next == $seen"
part, but that's about it :)
Anyway, I think this is just a long-winded way of expressing my support for
an article explaining set operators (or "cat-bunny slippers" or whatever :)
and all their wonderful uses. And I also think the English versions of the
operators are much easier to understand, at least initially, if only due to
the historical baggage of |, &, and friends.
-John
Damian Conway
> All other things being equal, I think people will find modal operators
> more confusing than if we just make separate operators.
Agreed.
> That being said, I'm still wondering whether we can finesse it.
We can get close. But that might actually be counterproductive.
> Damian's default any() semantics in numeric context select a random element.
And I'd like to change that please! If superpositions are fundamental to the
language, we can integrate them properly with the language. So instead of:
@array[1|2|3]
randomly selecting element 1 or 2 or 3, this expression would return
any( @array[1,2,3] )
thereby propagating the superpositional nature of the index.
Note that we already do that anyway for certain numeric contexts. That is,
the numeric contexts of the arguments to:
1|2 * 3|4
don't randomly select, they propagate the superposition.
So I think that superpositions normally just propagate superpositionality
on *all* operations, but also have the following methods:
$superposition.states() # return eigenstates
$superposition.pick() # select one state at random
$superposition.serialize() # convert to a string representation
And since superpositions *do* defer evaluation of boolean expressions, there's
no technical reason why we couldn't have a:
$superposition.intbits() # evaluate superposition as integer bit ops
$superposition.strbits() # evaluate superposition as string bit ops
Then we make functions like C<sysopen> and C<chmod> call those methods automatically
when passed a superposition where they're expecting a bitset. That would allow:
my $in = sysopen $infile, O_RDONLY;
my $out = sysopen $outfile, O_WRONLY | O_APPEND | O_CREAT;
for <$in> {
my ($x, $y, $z) = split;
my $res = $x | $y & $z;
print $out: $res.intbits(), "\n";
}
chmod S_IRWXU|S_IRGRP|S_IXGRP|S_IROTH|S_IXOTH, $outfile;
And, apart from remembering to bitify on output, the finesse is complete.
Better still, we could mandate that you *can't* print a raw superposition;
that you *have* to call C<.intbits()> or C<.strbits()> or C<.serialize()> first.
That would catch the mistake of:
my $in = sysopen $infile, O_RDONLY;
my $out = sysopen $outfile, O_WRONLY | O_APPEND | O_CREAT;
for <$in> {
my ($x, $y, $z) = split;
my $res = $x | $y & $z;
print $out: $res, "\n"; # OOPS!
}
chmod S_IRWXU|S_IRGRP|S_IXGRP|S_IROTH|S_IXOTH, $outfile;
Damian
Brian Ingerson
> At 10:22 AM -0800 10/29/02, Michael Lazzaro wrote:
> >This is why I am nervous about introducing terms like eigenbunny, etc.
>
> Oh, I dunno, I kind of like it. Of course, now my kids want
> eigenbunny slippers... (Though the trouble with those is they may or
> may not be keeping your feet warm--you can never tell)
Oh! I just remembered the ultimate word for a container. It's "cozy", of
course!
Every eigenbunny needs a supercozy!
Cheers, Brian
Damian Conway
> I confess, I don't get it.
Yes, you did. :-)
> To me, it appears to iterate over the input,
> printing unique values except that two values ($start, $finish) are
> considered to have already been encountered.
>
> If that's all, then okay.
Okay then. That's all.
> But does it somehow skip all entries
> before/after the delimiter?
No. For that you'd want:
my $seen = $start & $finish;
for <> -> $next {
print $next if $next != $seen && $start < $next < $finish;
$seen &= $next;
}
Damian
Austin Hastings
printing unique values except that two values ($start, $finish) are
considered to have already been encountered.
If that's all, then okay. But does it somehow skip all entries
before/after the delimiter?
Also, in a related vein, how do flexen and rexen interact?
That is, what happens if I try to match a flexpr? Do I get flexprs in
all the match variables, or what?
=Austin
Damian Conway
> Oh! I just remembered the ultimate word for a container. It's "cozy", of
> course!
>
> Every eigenbunny needs a supercozy!
The plural of which is, presumable, "supercozens".
Now *I'm* really scared!
;-)
Damian
Dan Sugalski
Absolutely. Eigenbunnies in supercozens. Sounds like we've found the
mascot for Perl 6!
Simon Cozens
> Well, I like "set operators," too, but what's the grammatical term for
> the above "logically entangled list of nouns"?
Conjunctions and disjunctions.
--
Wouldn't you love to fill out that report? "Company asset #423423
was lost while fighting the forces of evil."
-- Chris Adams in the scary.devil.monastery
Dave Storrs
On Tue, 29 Oct 2002, Dan Sugalski wrote:
> At 1:34 PM -0800 10/29/02, Brian Ingerson wrote:
> >Every eigenbunny needs a supercozy!
>
> Absolutely. Eigenbunnies in supercozens. Sounds like we've found the
> mascot for Perl 6!
I really want to work a "pear pimples for hairy fishnuts" reference in
here somewhere, but I can't quite make it work.
Dave Storrs
Martin D Kealey
> Logically entangle nouns *are* more basic than grade school. Kids are
> even sophisticated enough to disambiguate "xor" from "or" by context,
> despite the fact that English has no "xor" operator:
>
> Which do you want? A popsicle or a Mickey Mouse hat?
Hmmm...
I've heard that this is a culturally driven thing: that whilst people can
all disambiguate it, people from different cultures may do so differently
In a "western" culture, exclusive-or is the assumed default unless context
implies otherwise. But in many Pacific island cultures (*), if one offers
"kava or coffee" one would be expected to provide both if answered "yes".
-Martin
(* This from annecdotal memory of 20 years ago, so I don't vouch that it
still applies in any particular culture, but the essential point remains
that the disambiguation is not as universal or consistent as may seem to us
sitting here in Australasia, USA or Europe, speaking English.)
Piers Cawley
> Larry wrote:
>
>> All other things being equal, I think people will find modal operators
>> more confusing than if we just make separate operators.
>
> Agreed.
>
>
>> That being said, I'm still wondering whether we can finesse it.
>
> We can get close. But that might actually be counterproductive.
>
>
> > Damian's default any() semantics in numeric context select a random element.
>
> And I'd like to change that please! If superpositions are fundamental to the
> language, we can integrate them properly with the language. So instead of:
>
> @array[1|2|3]
>
> randomly selecting element 1 or 2 or 3, this expression would return
>
> any( @array[1,2,3] )
>
> thereby propagating the superpositional nature of the index.
Yup. If this doesn't happen some of the weirder non deterministic
algorithms I've been thinking about won't work properly, and that
would be bad.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Piers Cawley
But given a decent Collection hierarchy:
my $seen = Set.new($start,$finish);
for <> -> $next {
print $next unless $next =~ $seen;
$seen.insert($next);
}
Which is somewhat more explicit about what's going on. But I'll grant
you, the comparator stuff is rather neat...
>> which takes rather more decoding. And if you *do* want to use such
>> operators, surely you could just do use ops ':superpositions'; in
>> an appropriate lexical scope. Am I missing something?
>
> Yes. That superpositions are going to be so widely used once people
> catch on, that users going to curse us every time they have to write
> C<use ops ':superpositions';> at the start of every scope.
I think we could really use a 'science fiction' article about
superpositions. Sort of like the Q::S talk, but without the 'in
constant time' jokes.
Jonathan Scott Duff
> da...@wheeler.net (David Wheeler) writes:
> > Well, I like "set operators," too, but what's the grammatical term for
> > the above "logically entangled list of nouns"?
>
> Conjunctions and disjunctions.
The only thing this inspires in my brain is Schoolhouse Rock
flashbacks.
o/~ Conjuction Junction, what's your function? o/~
Austin Hastings
a "train". But that's just nasty.
=Austin
We've got "when," we're just missing "where". Maybe Dave Frishberg
should be on this list?
Lyrics & Music: Dave Frishberg
Performed by: Jack Sheldon
"Conjunction junction, what's your function?
Hookin' up words and clauses and phrases...
Conjunction junction, how's that function?
I've got three favorite cars that get most of my job done.
Conjunction Junction, what's their function?
I've got and, but, and or.
They'll get you pretty far.
And!
That's an additive, like this and that.
But!
That's sort of the opposite,
not this but that.
And then there's Or. O-R,
when you have a choice like this or that
And, but, and or get you pretty far!
Conjunction Junction, what's your function?
Hooking up two boxcars and making 'em run right.
Milk and honey, bread and butter, peas and rice,
(Hey that's nice)
Dirty but happy, digging and scratchin'.
Losing your shoe and a button or two,
He's poor but honest, sad but true,
Boo-hoo-hoo-hoo-hoo!
Conjunction Junction, what's your function?
Hooking up two cars to one
When you say something like this choice
Either now or later
Or no choice:
Neither now nor ever.
(Hey that's clever)
Eat this or that, Grow thin or fat
Never mind, I wouldn't do that
I'm fat enough now!
Conjunction Junction, what's your function?
Hookin' up phrases and clauses that balance, like:
Out of the frying pan and into the fire.
He cut loose the sandbags,
but the balloon wouldn't go any higher.
Let's go up to the mountains or down to the seas.
You should always say Thank you,
Or at least say Please!
Conjunction Junction, what's your function?
Hookin'-up words and phrases and clauses
in complex sentences like:
"In the mornings, when I am usually wide awake, I love to take a walk
through the gardens and down by the lake, where I often see a duck and
a drake, and I wonder as I walk by what they would say if they could
speak, although I know that's an absurd thought."
Conjunction Junction, what's your function?
Hookin'-up cars and making them function.
Conjunction Junction, how's that function?
I like tying up words and phrases and clauses.
Conjunction Junction, watch that function!
I'm going to get you there if you're very careful.
Conjunction Junction, what's your function?
I'm going to get you there if you're very careful."
--- Jonathan Scott Duff <du...@cbi.tamucc.edu> wrote:
__________________________________________________
Yahoo! - We Remember
9-11: A tribute to the more than 3,000 lives lost
http://dir.remember.yahoo.com/tribute
Markus Laire
> On Tue, Oct 29, 2002 at 10:13:39AM +0200, Markus Laire wrote:
> > Also the idea of allways using 'function' style for something so
> > basic like superpositions doesn't appeal to me.
>
> Superpositions are "basic" in a fabric-of-the-universe kind of way,
> but they are hardly basic in the everyone-learns-them-in-grade-school
> kind of way. I think the latter is more important for huffman coding
> of operators for the unwashed masses. But I'm willing change my mind
> if we start teaching everyone superpositions in grade school :-)
You are making the fundamental mistake of thinking superpositions as
superpositions. When thinking them as another-kind-of or/and, their
usefulness comes a lot clearer.
perl5: if $x == 5 || $x == 7 || $x == 99
perl6: if $x == 5 | 7 | 99
perl5: ...loop to test every value in an array...
perl6: if ! 28 <= any(@days_in_months) <= 31 { ERROR }
(this probably has slight syntax error)
perl5: if $x > 0 && $x < 20 && $y > 0 && $y < 20 && $z > 0 && $z < 20
perl6: if 0 < $x & $y & $z < 20
perl5: if ($x >= 10 && $x <= 20) || ($x >= 30 && $x <= 40)
perl6: if $x ~~ 10..20 | 30..40
--
Markus Laire 'malaire' <markus...@nic.fi>
David Wheeler
> The only thing this inspires in my brain is Schoolhouse Rock
> flashbacks.
>
> o/~ Conjuction Junction, what's your function? o/~
Heh. That's what I heard, too.
David
--
David Wheeler AIM: dwTheory
da...@wheeler.net ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: The...@jabber.org
Dave Storrs
In the "Re: Wh<[ie]>ther Infix Superposition ops" thread
On Wed, 30 Oct 2002, Piers Cawley wrote:
> But given a decent Collection hierarchy:
>
> my $seen = Set.new($start,$finish);
>
> for <> -> $next {
> print $next unless $next =~ $seen;
> $seen.insert($next);
> }
Just a thought...are sets (or other Collection types) something that we
use often enough that they would deserve to be in the core language? I
know I've used hashes as no-repeats-allowed sets many times, so clearly
they are commonly useful. On the other hand, since this can be done,
maybe there is no need to implement a new core feature for them.
I suspect the answer is "no, we don't need them" but I just thought I'd
ask; I'm curious about the design reasons either way.
--Dks
Larry Wall
: In the "Re: Wh<[ie]>ther Infix Superposition ops" thread
The set features are a side effect of junctions, just as they're a side
effect of hashes. An "any" junction might well be implemented underneath
as a hash without values.
Possibly we might even extend the notion of hash to any "junk".
%hash = 1 | 2 | 3;
Then it's clearer that something junctional is going on when you say:
if $val ~~ %hash
I could see % becoming the sigil of choice for junks just for the
documentational value.
Larry
Piers Cawley
Personally, I'd love to see something like the whole Smalltalk
Collection hierarchy available complete with Bags, Sets, Dictionaries,
OrderedCollections and the whole deal. I note, for instance that
Christian Lemburg has implemented Set::Object, and it's substantially
faster than a hash based implementation for insertion, and marginally
faster for lookup. See
http://search.cpan.org/author/JLLEROY/Set-Object-1.02/Object.pm#PERFORMANCE
for Christian's numbers. I would hope that we could see other
performance gains for other Collection classes.
Taking a quick glance at a handy Smalltalk image, it seems that,
ideally one would want to have Collections in the core so that Hash
could inherit from Collection via Set. But then, anything's possible
at compile time, so one could probably set something appropriate up by
doing 'use Collections'.
Piers Cawley
> Personally, I'd love to see something like the whole Smalltalk
> Collection hierarchy available complete with Bags, Sets,
> Dictionaries, OrderedCollections and the whole deal. I note, for
> instance that Christian Lemburg has implemented Set::Object, and
That's Jean-Louis Leroy, obviously. Brainfade.
Larry Wall
: possession of a rich syntax must be in need of a rewrite."
: -- Jane Austen?
It is a truth universally acknowledged that a language in possession
of a rich syntax must be in need of a larger character set.
I can almost taste it: French quotes for hyperoperators...
@a «+» @b
@a«++»
@a«.anymethod(args)»
Larry
Luke Palmer
> Cc: "perl6-l...@perl.org" <perl6-l...@perl.org>
> From: Piers Cawley <pdca...@bofh.org.uk>
> Date: Wed, 30 Oct 2002 18:59:15 +0000
> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
>
> Dave Storrs <dst...@dstorrs.com> writes:
>
> > In the "Re: Wh<[ie]>ther Infix Superposition ops" thread
> >
> > On Wed, 30 Oct 2002, Piers Cawley wrote:
> >
> >> But given a decent Collection hierarchy:
> >>
> >> my $seen = Set.new($start,$finish);
> >>
> >> for <> -> $next {
> >> print $next unless $next =~ $seen;
> >> $seen.insert($next);
> >> }
> >
> > Just a thought...are sets (or other Collection types) something that we
> > use often enough that they would deserve to be in the core language? I
> > know I've used hashes as no-repeats-allowed sets many times, so clearly
> > they are commonly useful. On the other hand, since this can be done,
> > maybe there is no need to implement a new core feature for them.
> >
> > I suspect the answer is "no, we don't need them" but I just thought I'd
> > ask; I'm curious about the design reasons either way.
>
> Personally, I'd love to see something like the whole Smalltalk
> Collection hierarchy available complete with Bags, Sets, Dictionaries,
> OrderedCollections and the whole deal. I note, for instance that
> Christian Lemburg has implemented Set::Object, and it's substantially
> faster than a hash based implementation for insertion, and marginally
> faster for lookup. See
> http://search.cpan.org/author/JLLEROY/Set-Object-1.02/Object.pm#PERFORMANCE
> for Christian's numbers. I would hope that we could see other
> performance gains for other Collection classes.
Well, to generalize the notion of "array" and "hash" wouldn't be that
difficult. Change them, respectively, to "ordered" and "unordered".
I wonder if @things should have a more general interface than
numerical indices. I've wanted linked lists in perl, and every time I
do a splice on an array I cringe for speed reasons.
Heh, we could use my "linked array" implementation. Or not.
But I think we need a concept of iterators in the core. I like the
C++ STL because of it's generalization of iterators. I think it's
worth repeating, <rant>except the part about declaring them taking a
page of code:
list<actor::id_type>::const_reverse_iterator = idlist.rbegin();
That's more hideous than anything Perl haters yell about. At least
perl does something. I mean, in that many Perl characters people have
made computer algebra systems ;)
</rant>
So lets see, <...> derefrences and increments its prisoner. Perhaps
just ++ing and --ing would work. Of course, I'd hate to use <$iter-->
for a derefrence without an increment. Or, yes, of course! Would it
be possible to overload prefix:$ ? Then we could derefrence with the
derefrence operator $$iter.
Um, yeah, my mind is kinda scattered. Just a little bit.
Luke
Nicholas Clark
> You are making the fundamental mistake of thinking superpositions as
> superpositions. When thinking them as another-kind-of or/and, their
> usefulness comes a lot clearer.
> perl5: if $x > 0 && $x < 20 && $y > 0 && $y < 20 && $z > 0 && $z < 20
> perl6: if 0 < $x & $y & $z < 20
I find that really quite confusing written like that. but like this
if 0 < ($x & $y & $z) < 20
it makes more sense to me. What's the precedence?
Although as regular user of numerical bitops in C, I find it visually jarring
that & isn't what it means in C, C++, perl and most other current languages.
Nicholas Clark
--
Brainfuck better than perl? http://www.perl.org/advocacy/spoofathon/
Larry Wall
: On Wed, Oct 30, 2002 at 06:45:52PM +0200, Markus Laire wrote:
:
: > You are making the fundamental mistake of thinking superpositions as
: > superpositions. When thinking them as another-kind-of or/and, their
: > usefulness comes a lot clearer.
:
: > perl5: if $x > 0 && $x < 20 && $y > 0 && $y < 20 && $z > 0 && $z < 20
: > perl6: if 0 < $x & $y & $z < 20
:
: I find that really quite confusing written like that. but like this
:
: if 0 < ($x & $y & $z) < 20
:
: it makes more sense to me. What's the precedence?
The parens aren't required, but they certainly do help the readability there.
: Although as regular user of numerical bitops in C, I find it visually jarring
: that & isn't what it means in C, C++, perl and most other current languages.
That may well be part of why it's hard for us to group it visually
the other way. But I really don't think we want to require parens on:
if $x == 1 | 2 | 3 {...}
Larry
Markus Laire
And you could always have something else as a backup for those
unfortunates who can't use «+» - like ^[+]
What are the good reasons not to use «» ?
Larry Wall
: And you could always have something else as a backup for those
:
: What are the good reasons not to use «» ?
It would force everyone to get their act together with respect to Unicode.
Oh, wait, that's a feature...
Larry
Erik Steven Harrison
--
On Wed, 30 Oct 2002 07:13:40
Damian Conway wrote:
>Yes. That superpositions are going to be so widely used once people
>catch on, that users going to curse us every time they have to
>write C<use ops ':superpositions';> at the start of every scope.
So, I open my inbox and see that it has been stuffed with Perl 6
language. It's like a little gift. :-) But then I see this debate
over the use of superpositions. If there are those who are still
disbelieving then go look at the prior art. Icon is a fine little
programming language (though a little too "pretty" for my tastes)
that uses very similar syntax to what were talking about here. The
big difference is that Icon supports loads of (very nice and clean)
backtracking. | and & are Icon's || and &&, but Icon's backtracking
gives us a really cool idiom. Superpositions offer us the same thing
in Perl 6. Take a look at Icon over at
http://www.cs.arizona.edu/icon/ . Once I saw it I did a Piers: "This
is something I want in Perl and I want it right now!"
>
>;-)
>
>Damian
>
>
>
____________________________________________________________
Get 25MB of email storage with Lycos Mail Plus!
Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
Damian Conway
> The set features are a side effect of junctions, just as they're a side
> effect of hashes. An "any" junction might well be implemented underneath
> as a hash without values.
Yep.
> Possibly we might even extend the notion of hash to any "junk".
>
> %hash = 1 | 2 | 3;
So you're suggestion that a "normal" hash is a junction of pairs???
Or that assigning a junction to a hash takes every state of the junction
and creates an entry for it whose value is true???
Either way I worry about this notion, because of the subtle
differences between:
%hash = map {$^x=>1} (1,2,3);
%hash = any(1,2,3);
%hash = all(1,2,3);
%hash = one(1,2,3);
%hash = none(1,2,3)
I'd really rather not see junctions being the only scalar type that can be
marked with C<%>.
Unless, of course, we're deliberately *trying* to install nasty
inconsistencies for Simon to discover! ;-)
> Then it's clearer that something junctional is going on when you say:
>
> if $val ~~ %hash
>
> I could see % becoming the sigil of choice for junks just for the
> documentational value.
Curiously, the reduction of the documentational value of C<%> always
meaning "hash" is exactly why I *wouldn't* like to see it!
Damian
Leopold Toetsch
> I wonder if @things should have a more general interface than
> numerical indices. I've wanted linked lists in perl, and every time I
> do a splice on an array I cringe for speed reasons.
>
> Heh, we could use my "linked array" implementation. Or not.
Please have a look at list.c, which is the engine for *Array classes.
> But I think we need a concept of iterators in the core.
There were some patches floating around. Dunno what happened to them.
> Luke
leo
Austin Hastings
--- Damian Conway <dam...@conway.org> wrote:
> Larry wrote:
> > Possibly we might even extend the notion of hash to any "junk".
> >
> > %hash = 1 | 2 | 3;
>
> So you're suggestion that a "normal" hash is a junction of pairs???
Damian Conway admits: "Everything in Perl6 is 'Junk'"
Who can't see *this* coming on slashdot? :-)
=Austin
Larry Wall
: Damian Conway admits: "Everything in Perl6 is 'Junk'"
:
: Who can't see *this* coming on slashdot? :-)
Cool. Perl 6 "junk" gives new meaning to "Pathologically Eclectic Rubbish".
Larry