we need more ops.
Nicholas Clark
> Whether plain cmp (as a vtable function or an op on PMCs) should be kept
> at all is questionable -- there's no way to get at it syntactically from
> Perl or any other language that has separate numeric and string
> comparisons. It might be useful for languages with a single set of
> comparisons that "do the right thing". While presumably Perl 6 will have
> "object comparisons", they'll happen by overloading either the numeric or
> the stringific operators, and therefore should be handled in the type's
> cmp_{string,num} method.
I think it was being suggested that =~ could actually "do the right thing"
in a very general case - ie (in perl5 terms)
$a = 4;
3 =~ $a;
would be numeric comparison
$a = "four";
3 =~ $a;
would fall back to string comparison (because perl6 would decide that the
string "four" can't be converted to a number)
$a = qr/1234/;
3 =~ $a
would be a regexp match. In effect =~ would be a builtin cmp with dispatch
based on the types of both sides, preferring to compare as integers, then
floating point, then strings, then regexps, then ...
But even if perl6 wants this (and I can't remember if it's been officially
suggested that it might), I'm not convinced that it's something that needs
a vtable entry in the low level types of every PMC.
Nicholas Clark
--
Even better than the real thing: http://nms-cgi.sourceforge.net/
Sean O'Rourke
> On Sat, Jul 27, 2002 at 08:07:50PM -0700, Sean O'Rourke wrote:
> > Whether plain cmp (as a vtable function or an op on PMCs) should be kept
> > at all is questionable -- there's no way to get at it syntactically from
>
> based on the types of both sides, preferring to compare as integers, then
> floating point, then strings, then regexps, then ...
>
> But even if perl6 wants this (and I can't remember if it's been officially
> suggested that it might), I'm not convinced that it's something that needs
> a vtable entry in the low level types of every PMC.
I would also guess that this logic will end up at a higher level, whether
figured out at compile time or in some non-vtable method at runtime. And
actually, the smart-match table in A4 doesn't mention anything for object
types, so I'm not sure where this one is headed. In any case, =~ doesn't
say anything about ordering, whereas cmp() does, and we already have an
unordered is_equal() vtable method that will cover =~.
/s
Nicholas Clark
D'oh. I forgot the important bit. The logical follow-through of all this is
that there would be a <~> operator. or whatever the <=> turns into when it's
~ [and I've no idea what sort of name that is]
[Maybe we should have a competition to suggest the most crazy three character
operator - ie state your sequence of three characters (not necessarily ASCII,
but it helps), state their name, and state their purpose (including whether
listop, binop, uniop, precedence, associativity or whatever else helps make
your entry more humorous. So presumably there could be a :-) operator, but
offhand I can't think of something plausible it could do. And does the
tie-fighter need an X-wing operator to complement it? (not sure what that
one would look like, let alone what it would do)]
Nicholas Clark
Melvin Smith
>[Maybe we should have a competition to suggest the most crazy three character
>operator - ie state your sequence of three characters (not necessarily ASCII,
>but it helps), state their name, and state their purpose (including whether
>listop, binop, uniop, precedence, associativity or whatever else helps make
>your entry more humorous. So presumably there could be a :-) operator, but
>offhand I can't think of something plausible it could do. And does the
>tie-fighter need an X-wing operator to complement it? (not sure what that
>one would look like, let alone what it would do)]
Thats funny, but you have a point there.
The VM and assembler does not need to provide every operator as
an new 'op'. Eventually, languages with funky operators need to start thinking
about implementing them as methods or such.
Or Parrot will end up a very fat, lazy bird waddling around eating all the
food.
-Melvin
[This means we would actually have to _implement_ methods and classes
but that's another tale]
Marc M. Adkins
> three character
> operator - ie state your sequence of three characters (not
> necessarily ASCII,
> but it helps), state their name, and state their purpose
> (including whether
> listop, binop, uniop, precedence, associativity or whatever else
> helps make
> your entry more humorous. So presumably there could be a :-) operator, but
> offhand I can't think of something plausible it could do. And does the
> tie-fighter need an X-wing operator to complement it? (not sure what that
> one would look like, let alone what it would do)]
>
> Nicholas Clark
rpw randomize passwords
randomizes all passwords on system
no operands, operates globally
(I think I've seen this opcode operating under Windows 2000)
mma
Eric Kidder
On Mon, 29 Jul 2002, Nicholas Clark wrote:
> [Maybe we should have a competition to suggest the most crazy three character
> operator - ie state your sequence of three characters (not necessarily ASCII,
> but it helps), state their name, and state their purpose (including whether
> listop, binop, uniop, precedence, associativity or whatever else helps make
> your entry more humorous. So presumably there could be a :-) operator, but
> offhand I can't think of something plausible it could do. And does the
> tie-fighter need an X-wing operator to complement it? (not sure what that
> one would look like, let alone what it would do)]
:-) the Positivity operator ("happy face")
On the left-hand side of an expression, it tests whether the
expression contains a positive value. On the right-hand side, it
transforms the results of the expression into a positive value.
How it does this is implementation dependent.
This operator has right-hand side precendence.
Other operators in this vein are :-(, the "Negativity" operator, and :-|,
the "Zero" operator.
Examples:
print :-) "-1"; # prints "0"
print "-1" :-); # prints some positive value, probably "1"
print -1 :-( :-) :-|; # prints some zero value, probably "0"
What we really need are see no evil, hear no evil, speak no evil
operators.
And on a complete aside, here is something I dug up in 'fortune'. Some of
these are actually useful!
Proposed Additions to the PDP-11 Instruction Set:
BBW Branch Both Ways
BEW Branch Either Way
BBBF Branch on Bit Bucket Full
BH Branch and Hang
BMR Branch Multiple Registers
BOB Branch On Bug
BPO Branch on Power Off
BST Backspace and Stretch Tape
CDS Condense and Destroy System
CLBR Clobber Register
CLBRI Clobber Register Immediately
CM Circulate Memory
CMFRM Come From -- essential for truly structured programming
CPPR Crumple Printer Paper and Rip
CRN Convert to Roman Numerals
DC Divide and Conquer
DMPK Destroy Memory Protect Key
DO Divide and Overflow
EMPC Emulate Pocket Calculator
EPI Execute Programmer Immediately
EROS Erase Read Only Storage
EXCE Execute Customer Engineer
HCF Halt and Catch Fire
IBP Insert Bug and Proceed
INSQSW Insert into queue somewhere (for FINO queues [First in never out])
PBC Print and Break Chain
PDSK Punch Disk
PI Punch Invalid
POPI Punch Operator Immediately
PVLC Punch Variable Length Card
RASC Read And Shred Card
RPM Read Programmers Mind
RSSC reduce speed, step carefully (for improved accuracy)
RTAB Rewind tape and break
RWDSK rewind disk
RWOC Read Writing On Card
SCRBL scribble to disk - faster than a write
SLC Search for Lost Chord
SPSW Scramble Program Status Word
SRSD Seek Record and Scar Disk
STROM Store in Read Only Memory
TDB Transfer and Drop Bit
WBT Water Binary Tree
Dan Sugalski
>At 10:45 AM 7/29/2002 +0100, Nicholas Clark wrote:
>>[Maybe we should have a competition to suggest the most crazy three character
>>operator - ie state your sequence of three characters (not necessarily ASCII,
>>but it helps), state their name, and state their purpose (including whether
>>listop, binop, uniop, precedence, associativity or whatever else helps make
>>your entry more humorous. So presumably there could be a :-) operator, but
>>offhand I can't think of something plausible it could do. And does the
>>tie-fighter need an X-wing operator to complement it? (not sure what that
>>one would look like, let alone what it would do)]
>
>Thats funny, but you have a point there.
>
>The VM and assembler does not need to provide every operator as
>an new 'op'. Eventually, languages with funky operators need to start thinking
>about implementing them as methods or such.
This is definitely true, for ease of use and maintenace if nothing
else. However, if a language does want to provide ops for its
operators, that's not really something we should care about. Also,
the one big upside to ops is that they're JITtable, where method
calls aren't.
Ultimately doing things as a (dynamically loaded) op will make the
running of the code faster, since op calls are lower overhead than
method calls. The runtime will likely be smaller as well. The
downside is a larger compiler side.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Melvin Smith
>At 10:43 AM -0400 7/29/02, Melvin Smith wrote:
>>At 10:45 AM 7/29/2002 +0100, Nicholas Clark wrote:
>>The VM and assembler does not need to provide every operator as
>>an new 'op'. Eventually, languages with funky operators need to start
thinking
>>about implementing them as methods or such.
>
>This is definitely true, for ease of use and maintenace if nothing
>else. However, if a language does want to provide ops for its
>operators, that's not really something we should care about. Also,
>the one big upside to ops is that they're JITtable, where method
>calls aren't.
Aha! You said it yourself, instructions are JITtable. So why shouldn't
we concentrate on providing enough _primitives_ to allow people to
write anything and everything in Parrot. New ops then become JITable
and the upside is there is no language specific ops file needed.
That way any language compiling to Parrot will run on any Parrot
with standard ops.
>Ultimately doing things as a (dynamically loaded) op will make the
>running of the code faster, since op calls are lower overhead than
>method calls. The runtime will likely be smaller as well. The
>downside is a larger compiler side.
The other downside is that Parrot turns into a Linux kernel and
forever accumulates custom ops, PMCs. I think of Parrot as
a CPU. When we have adequately designed the CPU, people don't need
new ops.
-Melvin Smith
IBM :: Atlanta Innovation Center
mel...@us.ibm.com :: 770-835-6984
Sean O'Rourke
> I think of Parrot as a CPU. When we have adequately designed the CPU,
> people don't need new ops.
I think of it as a VAX, in which case "adequately designed" means "just a
few microcode ops" ;).
/s
Brent Dax
# something plausible it could do. And does the tie-fighter
# need an X-wing operator to complement it? (not sure what that
# one would look like, let alone what it would do)]
>0< Move Towards Zero (the X-Wing operator)
Prefix or postfix operator, like ++ or --; if the operand
is positive, decrements; otherwise increments.
<0> Move Away From Zero (the TIE Bomber operator)
Prefix or postfix operator, like ++ or --; if the operand
is positive, increments; otherwise decrements.
--Brent Dax <bren...@cpan.org>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.