On 2009-Oct-5, at 3:41 pm, Jon Lang wrote:
Concerning that last one: would it be reasonable to have a Discrete
role
that provides a .succ method, and then overload the Range role?
I think a type needs to be Discrete and Ordered for successors to make
sense (e.g. consider a discrete
Jon Lang wrote:
Concerning that last one: would it be reasonable to have a Discrete role
that provides a .succ method, and then overload the Range role? E.g.:
role Range[Ordered ::T] { ... }
role Range[Ordered Discrete ::T] {
...
method iterator ( - RangeIterator ) {
Consider a Range role that is parameterized (i.e., Range of T is a
perfectly valid thing to do). According to the spec, the definition of
Range depends on the nature of T:
* If the lower bound is Numeric, certain coercion rules are attempted on the
upper bound; otherwise, the two boundaries must
HaloO,
Larry Wall wrote:
As it stands the .() forms are a great way to stack ops after
a term. Together with knowing about the ops on the symbolic unary
level you can easily read expressions from the terms outwards.
I'm not actually parsing expressions. Or as you point out below
with respect
don't have the actual Big Idea, so it could just be a false
alarm.
At 16:24 +0100 3/26/08, TSa wrote:
I agree. But let me explain how I arrive at that. To me there is no binary
minus! -f(x) - g(x) = -f(x) + -g(x) = -g(x) + -f(x). I.e. plus is commutative.
In other words overloading unary minus
Thom Boyer wrote:
Now, I think that
$x.foo
is a method call, even if there's a postfix:foo declaration in scope.
And that's a problem, because, no matter what precedence postfix:foo
was given,
1,2,3.foo
is still going to mean
1, 2, (3.foo)
instead of the desired
Thom Boyer wrote:
And does dot always do that? If it does, then something odd happens.
Consider infix:* and postfix:!, where infix:* binds tighter than
postfix:+, and both bind more loosely than dot. Then
I meant ... tighter than postfix:!, ...
1 * 2! # means (1 * 2)!
1 * 2.!
HaloO,
Larry Wall wrote:
I deem that to be an unlikely failure mode, however. So maybe .++
is just gone now, and you have to write \++ instead. Any objections?
Please keep .++ as outlined below. Does the degenerate unspace not
collide with prefix:\? That is does foo\bar() not mean to
HaloO,
TSa wrote:
Another good use of the dot forms is to get a single character
form to tighten precedence: $x**3! != $x**3.! == $x**(3!).
BTW, is the dot form only available for postfix or for infix
as well? I.e. 3 * 2 == 3.*(2)?
Regards, TSa.
--
The Angel of Geometry and the Devil of
) and overloading ** with
non-numeric types on the right is questionable. Certain
overloads of the left side might even require the right
side to be (unsigned) integer. And of course
$any ** $int === [*]($any xx $int)
should hold.
Regards, TSa.
--
The Angel of Geometry and the Devil of Algebra fight
Jon Lang wrote:
Thom Boyer wrote:
That seems better to me than saying that there's no tab character in
say blah $x\t blah
Whoever said that?
Oops. I thought Larry did. But he didn't; I misread it. Whew.
Somehow I managed to read Larry's words and get exactly the *opposite*
meaning
Is it just me, or is all this talk about precedence and functions vs
operators vs methods creating a niggling sensation in anyone else's
head? It feels like we're in the vicinity of another one of them Big
Simplifying Idea things. Unfortunately, I don't have the actual Big
Idea, so it could just
On Wed, Mar 26, 2008 at 07:32:23PM -0600, Thom Boyer wrote:
Question: given
($x)++ # no whitespace, so postfix?
is ++ postfix, or infix?
That is postfix. Any infix that could be confused with a postfix
requires intervening whitespace.
Now, I think that
$x.foo
is a method
On Thu, Mar 27, 2008 at 01:01:27PM +0100, TSa wrote:
HaloO,
Larry Wall wrote:
I deem that to be an unlikely failure mode, however. So maybe .++
is just gone now, and you have to write \++ instead. Any objections?
Please keep .++ as outlined below. Does the degenerate unspace not
collide
On Thu, Mar 27, 2008 at 01:08:43PM +0100, TSa wrote:
HaloO,
TSa wrote:
Another good use of the dot forms is to get a single character
form to tighten precedence: $x**3! != $x**3.! == $x**(3!).
BTW, is the dot form only available for postfix or for infix
as well? I.e. 3 * 2 == 3.*(2)?
Only
On Thu, Mar 27, 2008 at 09:46:29AM -0400, Mark J. Reed wrote:
: Is it just me, or is all this talk about precedence and functions vs
: operators vs methods creating a niggling sensation in anyone else's
: head? It feels like we're in the vicinity of another one of them Big
: Simplifying Idea
Larry Wall wrote:
The .++ form is still not a method (single) dispatch, just an alternate
form of the postfix, which is a multi dispatch.
But the postfix is a unary operator, right? So that'd be multi dispatch
on one argument.
How does single dispatch differ from multi dispatch on a
, as if you'd said:
multi close (IO $self) {...}
or some such.
And since mutlis are lexically scoped, and operators are just macros
that translate to function calls, and longnames from different scopes
are interleaved, it means we have lexically-scoped overloading if
you want it.
The other
At 21:40 +0100 3/25/08, TSa wrote:
Doug McNutt wrote:
Don't allow it ( = - f($x); )to become
= f(-$x); ## wrong!
Unless of course f does Linear, then you can factor out or in the
multiplication with -1 at will. So linearity of operators and
functions is a very interesting property for
.
I agree. But let me explain how I arrive at that. To me there is no
binary minus! -f(x) - g(x) = -f(x) + -g(x) = -g(x) + -f(x). I.e. plus
is commutative. In other words overloading unary minus gives you the
binary version for free. Or even better is to deeply overload unary
plus to do the Ring role
On Wed, Mar 26, 2008 at 11:24 AM, TSa [EMAIL PROTECTED] wrote:
I agree. But let me explain how I arrive at that. To me there is no
binary minus!
I must agree with that one. In chalkboard mathematics, - is a unary
negation operator, and its use as a binary op in x - y is just
shorthand for x
On Wed, Mar 26, 2008 at 12:04:43PM -0400, Mark J. Reed wrote:
: On Wed, Mar 26, 2008 at 11:24 AM, TSa [EMAIL PROTECTED] wrote:
: I agree. But let me explain how I arrive at that. To me there is no
: binary minus!
:
: I must agree with that one. In chalkboard mathematics, - is a unary
:
HaloO,
Larry Wall wrote:
That interpretation doesn't help me solve my generic parsing problems,
which is about the relationship of op1 to op2 and op3 in
op1 a() op2 b() op3 c()
and presumably the same thing for postfixes in the other order.
My idea is to have a term re-writing stage
On Wed, Mar 26, 2008 at 1:06 PM, TSa [EMAIL PROTECTED] wrote:
1 + a(x)²!
Seems like a mathematician would be inclined to write that one as this instead:
1 + a²(x)!
But I'm not suggesting that you try to make (a**2)(x) work for
(a(x))**2 in Perl. :)
--
Mark J. Reed [EMAIL PROTECTED]
On Wed, Mar 26, 2008 at 06:06:29PM +0100, TSa wrote:
HaloO,
Larry Wall wrote:
That interpretation doesn't help me solve my generic parsing problems,
which is about the relationship of op1 to op2 and op3 in
op1 a() op2 b() op3 c()
and presumably the same thing for postfixes in the
Larry Wall wrote:
So here's another question in the same vein. How would mathematicians
read these (assuming Perl has a factorial postfix operator):
1 + a(x)**2!
1 + a(x)²!
The 1 + ... portion is not in dispute: in both cases, everything to
the right of the addition sign gets
On Wed, Mar 26, 2008 at 11:00:09AM -0700, Jon Lang wrote:
: OTOH, you didn't ask how mathematicians would write this; you asked
: how they'd read it. As an amateur mathematician (my formal education
: includes linear algebra and basic differential equations), I read the
: former as a(x) to the
Larry Wall wrote:
Now, I think I know how to make the parser use precedence on either
a prefix or a postfix to get the desired effect (but perhaps not going
both directions simulatenously). But that leads me to a slightly
different parsing question, which comes from the asymmetry of
HaloO,
Mark J. Reed wrote:
On Wed, Mar 26, 2008 at 1:06 PM, TSa [EMAIL PROTECTED] wrote:
1 + a(x)²!
Seems like a mathematician would be inclined to write that one as this instead:
1 + a²(x)!
That one is ambiguous because it could mean a(a(x)) or a(x)*a(x)
with the latter case being
HaloO,
Larry Wall wrote:
That's what I thought. Now note that ! can't easily be rewritten
as a simple binary operator (unless you do something recursive, and
then it's not simple).
Would $x! == [*]1..$x constitute simple parserwise? Admittedly
it's not a single but two ops and one of them a
On Wed, Mar 26, 2008 at 11:00:09AM -0700, Jon Lang wrote:
: all unary operators, be they prefix or postfix, should be evaluated
: before any binary operator is.
And leaving the pool of voting mathematicians out of it for the moment,
how would you parse these:
sleep $then - $now
not $a
TSa wrote:
Jon Lang wrote:
all unary operators, be
they prefix or postfix, should be evaluated before any binary operator
is.
Note that I see ** more as a parametric postscript then a real binary.
That is $x**$y sort of means $x(**$y).
That's where we differ, then. I'm having
HaloO,
Larry Wall wrote:
likewise, should these be parsed the same?
$a**2i
$a**2.i
and if so, how to we rationalize a class of postfix operators that
*look* like ordinary method calls but don't parse the same.
This is a conceptual problem that .blahh is visually nailed down on
the
On Wed, Mar 26, 2008 at 07:43:16PM +0100, TSa wrote:
HaloO,
Larry Wall wrote:
That's what I thought. Now note that ! can't easily be rewritten
as a simple binary operator (unless you do something recursive, and
then it's not simple).
Would $x! == [*]1..$x constitute simple parserwise?
On Wed, Mar 26, 2008 at 12:03 PM, Larry Wall [EMAIL PROTECTED] wrote:
On Wed, Mar 26, 2008 at 11:00:09AM -0700, Jon Lang wrote:
: all unary operators, be they prefix or postfix, should be evaluated
: before any binary operator is.
And leaving the pool of voting mathematicians out of it for
On Wed, Mar 26, 2008 at 3:18 PM, Jon Lang [EMAIL PROTECTED] wrote:
Those don't strike me as being unary operators; they strike me as
being function calls that have left out the parentheses.
At least through Perl5, 'tain't no difference between those two in Perl land.
As for binary !, you
Mark J. Reed wrote:
Jon Lang wrote:
Those don't strike me as being unary operators; they strike me as
being function calls that have left out the parentheses.
At least through Perl5, 'tain't no difference between those two in Perl land.
True enough - though the question at hand
Larry Wall wrote:
On Wed, Mar 26, 2008 at 12:56:08PM -0600, Thom Boyer wrote:
Larry Wall wrote:
... In the
limit, suppose some defines a postfix say looser than comma:
(1,2,3)say
1,2,3say
1,2,3.say
I must be missing something. Wouldn't it be easier to write
1,2,3 say
since
Thom Boyer wrote:
But the main point I was trying to make is just that I didn't see the
necessity of positing
1,2,3\say
when (if I understand correctly) you could write that as simply as
1,2,3 say
Nope. This is the same situation as the aforementioned '++' example,
in that
,
infix:*:(::T, T -- T) would become a generic list associative
non-commutative product operator. Note that a proper product is
homogeneous in ::T whereas multiplicative x is generally not.
Sorry if this is off-topic, but this is the outcome if I'm musing about
operator overloading. My driving idea
HaloO,
Doug McNutt wrote:
Don't allow it to become
= f(-$x); ## wrong!
Unless of course f does Linear, then you can factor out or in the
multiplication with -1 at will. So linearity of operators and
functions is a very interesting property for optimizers.
Regards, TSa.
--
The Angel of
into the territory of obfuscation.
Indeed mathematics is all about distilling abstract properties
from problem domains and then proving abstract theorems. That
means when applying mathematics you only have to meet the
preconditions and get all consequences for free. But
overloading a symbol that means
related to the original
- a sort of operator metonymy - but if the context is
sufficiently different, that's not a requirement. Again,
nobody's going to think you're dividing pathnames.
Strongly disagree. If context was sufficient to help the reader,
how did operator overloading get such a bad rep
On Fri, Mar 21, 2008 at 4:25 PM, Aristotle Pagaltzis [EMAIL PROTECTED] wrote:
It makes the meaning of the statement dependent on
the types of any variables, which is information that a reader
won't necessarily find in close vicinity of the statement.
[...]
if you're completely changing
* Mark J. Reed [EMAIL PROTECTED] [2008-03-21 21:35]:
On Fri, Mar 21, 2008 at 4:25 PM, Aristotle Pagaltzis [EMAIL PROTECTED]
wrote:
It makes the meaning of the statement dependent on the types
of any variables, which is information that a reader won't
necessarily find in close vicinity of
... though I disagree that the sort of overloading under
discussion (/ for separating paths) falls into the ugly things
category.
It's not ideal, but it's a fact of life. Slashes for path separators
are such a widespread custom that it would make as much sense to give
up slashes for division
On Thu, Mar 20, 2008 at 2:24 AM, David Green [EMAIL PROTECTED] wrote:
Interestingly, BASIC has gone the other direction --
at least, Visual BASIC uses + for addition and for concatenation;
I'm guessing this happened when VB got variant types that could hold
either numbers or strings.
HaloO,
Mark J. Reed wrote:
For the record, I am opposed to any restriction on operator
overloading that requires mathematical properties to hold. ANYTHING
is fair if you predeclare.
Hmm, my idea is more about defining interfaces that allow to detach
implementation of (numerical) algorithms
types is a
Path so that
you are dispatching to the intended implementation.
Yes, I was sort of assuming there'd be a simple constructor for that.
Maybe even a lexically-enablable path literal syntax. #P... anyone?
:)
Instead of overloading ~ for paths I think inventing ~/ or ~\ as
path
about the type of $x and $y an
expression $x/$y doesn't look particularly stringish to me.
BTW, operator overloading does not allow to change the precedence,
associativity and commutativity of the operator because these are
parser features.
That depends on the degree to which you can munge
kind of url-ish string that gets mapped to the
local conditions transparently. Or just use arrays, which are much
more convenent for directory tree traversals, and convert to path
at the last moment.
: Instead of overloading ~ for paths I think inventing ~/ or ~\ as
: path concatenating
On Thu, Mar 20, 2008 at 05:06:00PM +0100, TSa wrote:
BTW, do we have a unary multiplikative inversion operator?
That is 1/ as prefix or **-1 as postfix?
Well, 1/ looks like a pretty good prefix. :)
Except it's not really first class. This ain't Haskell...
As for **-1, I'd suspect that of
- inversion - that's considered a function by a mathematician.
*
At 15:01 +0100 3/20/08, TSa wrote:
BTW, operator overloading does not allow to change the precedence,
associativity and commutativity of the operator because these are
parser features.
A vector on the chalkboard can be a row or a column
On Thu, Mar 20, 2008 at 1:09 PM, Doug McNutt [EMAIL PROTECTED] wrote:
Don't even think about parsing = -$x**2; so that it returns a positive
result.
Okay, going way off on a tangent here, but I don't think the Perl
interpretation is quite as obviously correct as you think it is;
there's a
.
And that’s exactly the point. I find that regular, type-based
overloading is *very* exciting… but not in a good way. An
approach that makes operator overloading an unexciting business
therefore seems very useful to me.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
mathematics you only have to meet the
preconditions and get all consequences for free. But overloading
a symbol that means product with something that does not adhere
to the algebraic properties of products is a bad choice.
OTOH, overloading ~ with an operation that behaves like a monoid
is a bad
For the record, I am opposed to any restriction on operator
overloading that requires mathematical properties to hold. ANYTHING
is fair if you predeclare. Besides, there is nothing that inherently
associates the / symbol with division - it's only an ASCII
approximation of fraction notation. I
On Wed, Mar 19, 2008 at 12:38:48PM -0400, Mark J. Reed wrote:
: For the record, I am opposed to any restriction on operator
: overloading that requires mathematical properties to hold. ANYTHING
: is fair if you predeclare. Besides, there is nothing that inherently
: associates the / symbol
On Wed, Mar 19, 2008 at 1:01 PM, Larry Wall [EMAIL PROTECTED] wrote:
While I agree with the sentiment of not arbitrarily restricting
people from doing ugly things unless they ask for such restrictions,
Agreed... though I disagree that the sort of overloading under
discussion (/ for separating
those two messages is that it's damnably
difficult for a parser to figure out what I'm doing. Perhaps it just
isn't worth while.
If you mean that the parser understands the semantics of your code,
building a parser is indeed in the realm of AI. But for reasonable
operator overloading only two things
.)]
* Eric Wilhelm [EMAIL PROTECTED] [2008-02-24 02:05]:
# from Aristotle Pagaltzis
# on Saturday 23 February 2008 14:48:
I find the basic File::Fu interface interesting… but operator
overloading always makes me just ever so slightly queasy, and
this example is no exception.
Is that because
On 24 Feb 2008, at 15:00, Aristotle Pagaltzis wrote:
Something like
path { $app_base_dir / $conf_dir / $foo_cfg . $cfg_ext }
I've wanted this often. I've also wanted a clean way to lexically
supply a default target object. For example with HTML::Tiny you often
write
my $h =
of a certain class, or whatever).
This is excellent. I've long supported the one symbol-one meaning
idea. There are some trade-offs, though, which I'll describe. I'll
use Haskell as my object language, since it does this sort of operator
defining rather than operator overloading (only for infix
there... :)
Basically anything that could be construed as language mutation is
limited lexically in P6, and mixing in user-defined multimethods can
be construed as at least semantic mutation, and is also syntactic
mutation if you define new operators rather than merely overloading
existing ones. (We
At 17:30 + 2/24/08, Luke Palmer wrote:
On Sun, Feb 24, 2008 at 3:00 PM, Aristotle Pagaltzis [EMAIL PROTECTED] wrote:
And I read both very carefully and failed to understand most of it.
I use perl for physics and engineering mostly because I forgot most of my
FORTRAN long ago and perl works
Aristotle Pagaltzis wrote:
And this contradiction – that being able to declare sugar is
good, but the way that languages have permitted that so far leads
to insanity – is what sent me thinking along the lines that there
has to be some way to make overloading sane. And we all know
.
Something else humans do, however, is to overload symbols: e.g. /
for a filepath separator and for division. I'm not convinced that
scope-based overloading is the way to go in this particular case,
though. It is the way to go for regexes, which overload all sorts of
symbols that have other
On 2/12/06, Thomas Sandlass [EMAIL PROTECTED] wrote:
IIRC, you can always create a new method for a class, even outside of
its definition, simply by ensuring that the first parameter to be
passed in will be an object of that type:
method bark (Dog $_) { ... }
I don't think
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
Thomas Sandlass wrote:
or maybe
method Dog.bark () { ... }
Yes that works too.
Shouldn't that read Dog::bark? Why the dot?
Because I'm not 100% with the proper syntax of things. The intent was
to add a bark() method to Dog during runtime.
--
Jonathan Dataweaver Lang
On 2/8/06, Jonathan Lang [EMAIL PROTECTED] wrote:
Stevan Little wrote:
Yes, that is correct, because:
Dog.isa(Dog) # true
$spot.isa(Dog) # true
^Dog.isa(Dog) # false
In fact ^Dog isa MetaClass (or Class whatever you want to call it).
At least that is how I see/understand it.
Stevan Little wrote:
Jonathan Lang wrote:
OK. To help me get a better idea about what's going on here, what
sorts of attributes and methods would ^Dog have?
Well, a metaclass describes the behaviors and attributes of a class,
and ^Dog is an *instance* of the metaclass. So actually ^Dog
On 2/9/06, Jonathan Lang [EMAIL PROTECTED] wrote:
Stevan Little wrote:
Jonathan Lang wrote:
OK. To help me get a better idea about what's going on here, what
sorts of attributes and methods would ^Dog have?
Well, a metaclass describes the behaviors and attributes of a class,
and
Stevan Little wrote:
Jonathan Lang wrote:
OK; apparently, what I meant when I asked what methods and attributes
does ^Dog have? is what you're talking about when you speak of which
methods ^Dog will respond to. To me, an object has whatever methods
that it responds to.
I disagree, an
Stevan~
On 2/7/06, Stevan Little [EMAIL PROTECTED] wrote:
After all Foo is just a specific instance of the class Class.
Shhh... class objects don't exist ... I was never here,... I will I
count to three and when I snap my fingers you will awaken and will
have forgotten all about class
On Tue, Feb 07, 2006 at 07:32:18PM -0500, Stevan Little wrote:
: On 2/7/06, Matt Fowles [EMAIL PROTECTED] wrote:
: Stevan~
:
: I am going to assume that you intended to reply to perl 6 language,
: and thus will include your post in its entirety in my response.
:
: Yes, sorry... I missed the
Consider my Dog $spot. From the Perl6-to-English Dictionary:
Dog: a dog.
$spot: the dog that is named Spot.
^Dog: the concept of a dog.
Am I understanding things correctly?
If so, here's what I'd expect: a dog can bark, or Spot can bark; but
the concept of a dog cannot bark:
can Dog
On 2/8/06, Jonathan Lang [EMAIL PROTECTED] wrote:
Consider my Dog $spot. From the Perl6-to-English Dictionary:
Dog: a dog.
$spot: the dog that is named Spot.
^Dog: the concept of a dog.
Am I understanding things correctly?
If so, here's what I'd expect: a dog can bark, or Spot can
Stevan Little wrote:
Yes, that is correct, because:
Dog.isa(Dog) # true
$spot.isa(Dog) # true
^Dog.isa(Dog) # false
In fact ^Dog isa MetaClass (or Class whatever you want to call it).
At least that is how I see/understand it.
OK. To help me get a better idea about what's going on
On 2/6/06, Larry Wall [EMAIL PROTECTED] wrote:
So the basic answer to you question is, I think, yes. If Dog chooses
to always return true for .defined, then (in Haskell terms) it's more
like a Just type than a Maybe type. Perl 6's objects like to be Maybe
types by default, but you can
On Mon, Feb 06, 2006 at 10:41:02PM -0500, Matt Fowles wrote:
: Larry~
:
: On 2/6/06, Larry Wall [EMAIL PROTECTED] wrote:
: This is mostly motivated by linguistics rather than computer science,
: insofar as types/classes/roles in natural language are normally
: represented by generic objects
Larry~
On 2/7/06, Larry Wall [EMAIL PROTECTED] wrote:
Indeed, and the modeling point of view is that $pipe is *also* just
a representation of the Pipe. Neither Pipe nor $pipe is the thing
itself. Most computer programs are about Something Else, so computer
languages should be optimized for
Stevan~
I am going to assume that you intended to reply to perl 6 language,
and thus will include your post in its entirety in my response.
On 2/7/06, Stevan Little [EMAIL PROTECTED] wrote:
On 2/7/06, Matt Fowles [EMAIL PROTECTED] wrote:
Larry~
On 2/7/06, Larry Wall [EMAIL PROTECTED]
On 2/7/06, Matt Fowles [EMAIL PROTECTED] wrote:
Stevan~
I am going to assume that you intended to reply to perl 6 language,
and thus will include your post in its entirety in my response.
Yes, sorry... I missed the reply to all button on the gmail UI by a
few pixels I guess. Thank you for
Stevan~
On 2/7/06, Stevan Little [EMAIL PROTECTED] wrote:
Well, to be totally honest, I think only Larry truely understands
their usage, but to the best of my understanding they are intented to
serve a number of roles;
I agree with you about that, which is part of what bothers me.
(Larry,
On Sun, Feb 05, 2006 at 07:26:09PM -0800, Darren Duncan wrote:
: Part way through writing this, I had a brief chat on #perl6 with
: stevan (and apparently the meta-model is still quite in flux) and he
: said my question was related to Larry's class but undef idea, and
: that Larry should talk
At 3:02 PM +0800 2/6/06, Audrey Tang wrote:
On 2/6/06, Darren Duncan [EMAIL PROTECTED] wrote:
Speaking briefly, I would like it if Perl 6 provided a way for a
class (or role, or meta-class, etc) to declare that all variables
declared to be of that type are automatically/implicitly set to a
On 2/6/06, Larry Wall [EMAIL PROTECTED] wrote:
This is mostly motivated by linguistics rather than computer science,
insofar as types/classes/roles in natural language are normally
represented by generic objects rather than meta objects. When I
ask in English:
Can a dog bark?
that's
Larry~
On 2/6/06, Larry Wall [EMAIL PROTECTED] wrote:
This is mostly motivated by linguistics rather than computer science,
insofar as types/classes/roles in natural language are normally
represented by generic objects rather than meta objects. When I
ask in English:
Can a dog bark?
All,
Speaking briefly, I would like it if Perl 6 provided a way for a
class (or role, or meta-class, etc) to declare that all variables
declared to be of that type are automatically/implicitly set to a
particular value at declaration time, so that they are not undefined
if the programmer
On 2/6/06, Darren Duncan [EMAIL PROTECTED] wrote:
Speaking briefly, I would like it if Perl 6 provided a way for a
class (or role, or meta-class, etc) to declare that all variables
declared to be of that type are automatically/implicitly set to a
particular value at declaration time, so that
In Synopsis 13 MMD is discussed as the mechanism for overloading an
operator.
Many a times I would like to overload a method of a class.
I just played around with this:
http://svn.openfoundry.org/pugs/modules/Class-Events/lib/Class/Events.pm
Notice how the Named event variation appends
On Fri, Mar 14, 2003 at 01:45:56PM +1100, Damian Conway wrote:
: Oh, and I was wrong to originally write: Cmulti *isa ...
Sorry, you're not even wrong. :-)
: Multimethods live in their own namespace. No * required.
Alternately, we require the C* in order to accurately document
their scope.
On Fri, Mar 14, 2003 at 01:20:28PM +1100, Damian Conway wrote:
: Luke Palmer wrote:
:
: So, now that we have binding, is it possible to overload the
: assignment operator?
:
: Not really. The problem is that Cinfix:= is really an operator on
: *containers*, not on *values*. So, in order to
So, now that we have binding, is it possible to overload the
assignment operator? Does the assignment operator mean value copy
instead of reference copy?
Luke
Piers Cawley wrote:
Speaking of multis and constants, Greg McCarroll wondered on IRC if
this would work:
multi factorial (Int 0) { 1 }
multi factorial (Int $n) { $n * factorial($n-1) }
Probably not. We did discuss whether multimethods should be able to be
overloaded by value, but
Luke Palmer wrote:
So, now that we have binding, is it possible to overload the
assignment operator?
Not really. The problem is that Cinfix:= is really an operator on
*containers*, not on *values*. So, in order to overload C=, you'll still
need to define an appropriate CSTORE method on the
or, supposing we have some form of parameterized types, you could create
something more generic like:
class Val($N) {
multi *isa ($obj, Val($N) $class) { $obj ~~ $N }
}
# and then...
multi factorial (IntVal(0) $g) { 1 }
Yes, YES! Marvelous!
Not
Luke Palmer wrote:
Not that that couldn't be done with a closure anyway...
{
my Class %valClasses;
sub Val($N) returns Class {
my Class $rclass = %valClasses{$N} //= class {
multi *isa ($obj, $rclass $class) { $obj ~~ $N }
}
}
}
multi
On Wed, Mar 12, 2003 at 01:35:08PM +1100, Damian Conway wrote:
: Joe Gottman wrote:
:
:Will it be possible in perl6 to overload multis on the const-ness of a
: parameter, like C++ does? For instance,
:
:multi getX(Foo $self:) returns Int {...} #const version
:multi getX(Foo $self:
1 - 100 of 277 matches
Mail list logo
