On Fri, Nov 17, 2006 at 04:57:59PM +0100, TSa wrote:
: But I don't understand exactly how the coercive semantics
: of the numeric and string comparisons are achieved. I assume there
: are protos defined with signature :(Any,Any) that coerce the args
: to numeric or string and re-dispatch. Right? I
HaloO,
Smylers wrote:
TSa writes:
... one question remains that might actually make Duncan's proposal
pointless.
Didn't Larry actually accept Darren's proposal and add the C and
C operators?
He did. But I don't understand exactly how the coercive semantics
of the numeric and string compar
> Yes. He also accepted the proposal to add min and max operators -
> although I'm unsure why they weren't included as functions/methods
> instead. It seems more natural to me to say 'max($a, $b, $c)' or
> '($a, $b, $c).max' instead of '[max] $a, $b, $c' or '$a max $b max
> $c'. Although it _doe
Smylers wrote:
Didn't Larry actually accept Darren's proposal and add the C and
C operators?
Yes. He also accepted the proposal to add min and max operators -
although I'm unsure why they weren't included as functions/methods
instead. It seems more natural to me to say 'max($a, $b, $c)' or
'(
TSa writes:
> ... one question remains that might actually make Duncan's proposal
> pointless.
Didn't Larry actually accept Darren's proposal and add the C and
C operators?
> Are the comparison operators available for overloading just like any
> other operator
Yes. This feature is used often e
HaloO Larry,
you wrote:
You guys should read The Search for the Perfect Language, by Umberto Eco.
It would disabuse you of the notion that perfect orthogonality is possible
or even desirable.
I'm sorry if my contributions to this thread are annoying. But one
question remains that might actuall
You guys should read The Search for the Perfect Language, by Umberto Eco.
It would disabuse you of the notion that perfect orthogonality is possible
or even desirable.
Larry
HaloO,
Jonathan Lang wrote:
I agree that the distinctions between the five different equality
tests (=:=, ===, eqv, ==, eq) are rather difficult to grasp (I'm still
having trouble getting the difference between '===' and 'eqv', and
would appreciate some help).
So let's try to join our half kno
HaloO,
Smylers wrote:
BTW, could we define that the arithmetic shift ops do just that,
whereas the string ones do logical shift? And in addition that for
the bit inversion +^$a == -1 - $a holds? Note that -1 == +^0.
Does that assume a two's complement system? Is that a safe assumption
to mak
Smylers wrote:
Bzzzt, wrong language!
But Perl isn't an orthogonal language, it's a "diagonal" language.
http://www.oreilly.com/catalog/pperl2/excerpt/ch01.html
In the section quoted, it was indicated that "orthogonal" and
"diagonal" are being used to mean "minimalist" and "loaded with
spec
TSa writes:
> Darren Duncan wrote:
>
> > For the record, my preference is to have the generics be the
> > shortest, [==,!==,<=>,<,>,<=,>=], and use [+,~] prefixes for Num or
> > Str casting versions. And lengthen the bit-shift operators to use
> > thin-tailed arrowheads as you suggested.
>
> I l
HaloO,
Darren Duncan wrote:
For the record, my preference is to have the generics be the shortest,
[==,!==,<=>,<,>,<=,>=], and use [+,~] prefixes for Num or Str casting
versions. And lengthen the bit-shift operators to use thin-tailed
arrowheads as you suggested.
I like this proposal for its
At 10:30 PM -0800 11/11/06, Jonathan Lang wrote:
Note that this is two competing suggestions: one where '==' means
'generic equivalence', '+==' means 'numeric equivalence', and '*=='
means 'string equivalence'; and another where '*==' means 'generic
equivalence', '==' means 'numeric equivalence',
Darren Duncan wrote:
Jonathan Lang wrote:
>In terms of ordinal types, '>', '<', '>=', and '<=' would be the
>"generic" ordinal comparators, and you'd do the same sort of implicit
>or explicit type coercion that's done with '=='. Mind you, if you go
>with the ('==', '+==', '~==') set of equivalen
At 5:24 PM -0800 11/11/06, Jonathan Lang wrote:
Remind me again why it's a good idea to have distinct eqv, ==, and eq
operators, and for == to represent the numeric equivalence test
instead of an argument-based equivalence test?
Personally, I'd rather replace ('eqv', '==', 'eq') with either ('==
Darren Duncan wrote:
Considering this context of comparison operators:
Generic Num Str
---
=:= # equality (container)
!=:= # negated equality (container)
=== # equality (value, eternal semantics)
# negated smart match
It stands out that there seems to be no generic ordinal-relevant
operators specifically for less-than, greater-than, etc, while there
are such that cast their arguments as Num or Str.
While one can still emulate such operators on generic types using cmp
(whose exist
17 matches
Mail list logo
