On Fri, Jun 12, 2009 at 11:23 PM, Matthew
> Although some things may be able to be implemented far more
> efficiently if they know that they're being called with infix:<.=> and
> not with infix:<.>.
Last I checked, Perl 6 had some types that are mutating and others
that aren't (e.g., List and Array, I think). An additional benefit of
setting up the "primitive methods" as non-mutating is that you
increase the amount of functionality shared by the two: if all
mutating methods are syntactic sugar for non-mutating counterparts,
then non-mutating types will be able to do everything that their
mutating brethren can do (except mutate, of course). E.g., a List can
push, unshift, splice, etc; an Array can append, perpend, impend, etc.
And if you want to do purely functional programming, you can do so by
restricting yourself to the use of non-mutating types and staying away
from those methods that have side effects (which should [i]also[/i] be
easily identifiable). Indeed, this same notion of ensuring that pure
functional versions of mutating methods exist should also apply to
methods with side effects: as much as possible, if a method is
designed to perform a calculation and to produce a side effect, there
should also be an equivalent method that merely performs the
calculation. Even better would be to segregate the methods that
produce side effects from the methods that perform calculations.
Am I making sense?
Jonathan "Dataweaver" Lang