Stevan Little wrote:
^Dog is an instance of the MetaClass, while Dog (no ^ sigil) is the
class (actually it's a prototypical instance of the class which the
metaclass ^Dog describes, but you dont really need to know that to use
it).
^Dog.can(bark) # false
Dog.can(bark) # true
Wasn't
HaloO,
this sort of follows up on the
'Re: Junctions again (was Re: binding arguments)'
thread. The point I tried to make there is that
the optimizer needs the permission to change boolean
checks in the prime boolean block controller 'if'
and its friends like unless, while etc.
Of course certain
HaloO,
I'm still trying to understand the concept of context
in Perl6 from a typing perspective. My current interpretation
let me to coin three levels of typing in Perl6: syntactic, static
and dynamic. I guess the latter two are well known but the syntactic
type is new---at least do I hope so.
HaloO,
Luke wrote:
I just proved that is not transitive.
I can do that for every boolean operator that Perl has. They no
longer have any general properties, so you can't write code based on
assumptions that they do. In particular, testing whether all
elements in a list are equal goes
HaloO,
Luke wrote:
?? !! ain't bad either.
It's definitely much better that sabotaging the
(highly useful) // operator
within (highly useful) ternaries.
I guess the thing that I really think is nice is getting :: out of
that role and into the type-only domain.
Right. To make ::
HaloO,
Luke wrote:
Okay, now why don't you tell us about this new binary :: you're proposing.
Well, not a new one. Just plain old foo::bar::blahh and 'my ::blubb $x'
with relaxed whitespace rules. The ternary ?? :: is a splinter in my
mind's eye because it is not a compile time or symbol lookup
HaloO,
I'm still contemplating how to get rid of the :: in the
ternary and make :: unequivocally available for a type
sigil and as a binary infix for symbol lookup.
Here's a possible solution:
1) ?? becomes a binary operator that behaves as follows:
a) it evaluates its lhs in boolean
Luke wrote:
Both transparent dereferencing (infinite $$foo) and
opaque dereferencing (one-level $$foo) have their uses, but they are
definitely distinct.
Well, they are more like variations on a theme.
Instead of adding different syntax for each
kind, I'll propose something different:
Luke wrote:
Both transparent dereferencing (infinite $$foo) and
opaque dereferencing (one-level $$foo) have their uses, but they are
definitely distinct.
Well, they are more like variations on a theme.
Instead of adding different syntax for each
kind, I'll propose something different: two
Luke wrote:
Both transparent dereferencing (infinite $$foo) and
opaque dereferencing (one-level $$foo) have their uses, but they are
definitely distinct.
Well, they are more like variations on a theme.
Instead of adding different syntax for each
kind, I'll propose something different: two
Juerd wrote:
The only real problem with having only infix := for binding, is that you
can't easily use an alias (aka transparent reference) in a list. You can
have an array of aliases, but it's harder to have an array or hash in
which one element is an alias. Binding can be done explicitly:
11 matches
Mail list logo
