--- Stevan Little [EMAIL PROTECTED] wrote:
On 5/23/06, Sam Vilain [EMAIL PROTECTED] wrote:
People can diverge completely with completely incompatible
metaclasses that don't .do those roles, the only side effect
of which being that people who write code for the standard
Perl 6 metamodel
Larry Wall wrote:
'Course, I left out everything about prototype objects there...
The name Foo also (in context) represents an uninitialized object of
the class in question. Any object, initialized or not, can get at
its type handlers by saying
Foo.meta
$foo.meta
and, in fact, the
On Fri, May 19, 2006 at 05:05:02PM -0700, Larry Wall wrote:
So what's in a name? One could say that .meta is functioning more like a
name sigil than like a method, and the Real Name of the metaobject is
Foo::^Bar or some such, if it needs a name.
Method, I like. Stealth sigil, I don't like.
On Thu, May 18, 2006 at 03:17:36PM -0700, Chip Salzenberg wrote:
: What's the relationship in perl6 between namespaces and classes?
Hmm, well, that's hard to put one's finger on, but to the first
approximation namespaces are for declarational names, while classes
can really only name things
'Course, I left out everything about prototype objects there...
The name Foo also (in context) represents an uninitialized object of
the class in question. Any object, initialized or not, can get at
its type handlers by saying
Foo.meta
$foo.meta
and, in fact, the Foo.^bar syntax is
On Fri, May 19, 2006 at 12:35:11PM -0700, Larry Wall wrote:
If this isn't answering what you were asking, please ask s'more,
and I'll try to reply when I'm not busy having a grandbaby.
adCONGRATULATIONSvance :-)
Packages, modules, classes, roles, subsets, enums, etc. all pretend they
are
On Fri, May 19, 2006 at 12:53:29PM -0700, Larry Wall wrote:
and, in fact, the Foo.^bar syntax is just short for Foo.meta.bar.
So, you anticipated my half-question.
The type of metaobject Foo.meta might be called Class if that's what the
metaobject protocol decides it should be, but Perl the
On Fri, May 19, 2006 at 02:51:55PM -0700, Chip Salzenberg wrote:
On Fri, May 19, 2006 at 12:53:29PM -0700, Larry Wall wrote:
The type of metaobject Foo.meta might be called Class if that's what the
metaobject protocol decides it should be, but Perl the Language doesn't
care. If so, then
On Fri, May 19, 2006 at 03:25:43PM -0700, Chip Salzenberg wrote:
: Based on what I'm seeing, the Perl 6 type object is the thing that claims
: the primary name associated with a class. Foo::Bar is the type object.
: The metaobject seems to be anonymous. And the package seems to be fairly
:
Larry Wall wrote:
On the other hand, - makes a pretty pathetic fish operator. So for
the sake of argument, let's keep it = for the moment. But ignoring the
tail leads us to the head end of the fish. What do we do about $ARGS?
We could say this:
=$fh : *$fh :: = : *
Now if you
Larry Wall skribis 2006-04-22 19:40 (-0700):
Hmm, I almost never write scalar FH because I very rarely want to
input a single line in list context. But leaving that aside...
I've used it a lot.
I do tend to use it less often as I move away from line based text
documents for storage.
[101
On Thu, Nov 17, 2005 at 04:05:30AM +0100, Daniel Brockman wrote:
That is, hyphen and underscore are synonymous in identifiers,
but an initial hyphen is not taken to be part of the identifier.
Why not make this feature generic and define equivalence classes for
equivalent characters in an
DB == Daniel Brockman [EMAIL PROTECTED] writes:
DB You may be right about this. I would be happy if the
DB standard distribution came with a package that enabled the
DB hyphenated identifiers syntax in the lexical block:
DBuse hyphenated_identifiers;
DB Hopefully the name of
Uri Guttman [EMAIL PROTECTED] writes:
this idea would need to be worked out in much greater detail. there are
many different identifiers in perl. would all of them be subject to this
change? how would a global work if some other module refered to it using
underscores but your module used
No sane person would put their braces in different places in
different parts of their code, so why don't we just say,
from now on, you must use brace style X?
Have you never seen code that's been worked on by several people with
differing tastes in brace positioning and no coding standard? Have
On Wed, 16 Nov 2005, Daniel Brockman wrote:
No offense to whoever made that suggestion, but I think there are far
more people out there with a developed taste for hyphenated
identifiers than there are people with a thing for using backticks as
subscript operators.
Do you see the difference?
Jan,
No offense either, but if you are suggesting that
@a[$i-1] + @a[$i+1]
should be interpreted as
@a[$i_1] + @a[$i+1]
then I think it is pretty obvious why this is a really bad idea.
That's a very good example. I think I'm going to have to
change my mind and agree that it
On Thu, Nov 17, 2005 at 10:56:27AM +0100, Daniel Brockman wrote:
: That problem is not specific to this feature. For any package
: that changes the syntax, you can ask what about eval?
:
: So... what *about* eval? :-)
Always parses with the parser in effect at that point, the same one you'd
get
I like hyphens. They're easier to type and help
prevent_me_from_Doing_This and generating errors because of case
sensitivity.
On the other hand, consistency of appearance may be a problem for some
people. I often associate code with the way it looks on screen, not
necessarily with what it does or
Sebastian,
I like hyphens. They're easier to type and help
prevent_me_from_Doing_This and generating errors because
of case sensitivity.
On the other hand, consistency of appearance may be a
problem for some people. I often associate code with the
way it looks on screen, not necessarily
On Thu, 2005-11-17 at 05:31 +0100, Daniel Brockman wrote:
This is a very valid concern, but the problem will not arise
unless people start mixing these two styles --- something
which is very obviously not a good idea.
That doesn't mean that people will avoid it, by accident or on purpose.
Daniel Brockman [EMAIL PROTECTED] wrote:
So what is my suggestion? Obviously disallowing underscores
and instead allowing hyphens would just replace one problem
with an even worse problem (not only would there still be
people who don't like hyphens, but it would alienate a large
portion of
Thank you for your considerate reply, Brent.
I see a few syntactic problems with this idea: the subtraction and
negation operators you already mentioned,
Did I miss any problems related to those?
but also the fact that dashes are already used in package names to
indicate version and author
On Thu, 2005-11-17 at 07:27 +0100, Daniel Brockman wrote:
Yet you have the choice of where to put your braces, even
though the braces don't lend themselves to different tasks
depending on whether you put them on a new line or not.
You *don't* have the choice to use different types of braces,
chromatic [EMAIL PROTECTED] writes:
Yet you have the choice of where to put your braces, even
though the braces don't lend themselves to different tasks
depending on whether you put them on a new line or not.
You *don't* have the choice to use different types of
braces, though -- at least
On 10/26/05, Larry Wall [EMAIL PROTECTED] wrote:
On Wed, Oct 26, 2005 at 07:35:05PM -0700, chromatic wrote:
: On Wed, 2005-10-26 at 21:58 -0400, Rob Kinyon wrote:
:
: Plus, the argument is a straw man. Instead of:
:
: class Some::Class is also {
: }
:
: you would do:
:
:
On Thu, Oct 27, 2005 at 05:37:13AM -0400, Rob Kinyon wrote:
: Will I be able to do something like:
:
: package Foo;
Hmm, you just started in Perl 5 mode.
: $*VERSION = 1.3.2;
Perl 5 would get confused here, so I'm presuming Perl 6. But Perl 6
isn't likely to let you override the global
On 10/27/05, Larry Wall [EMAIL PROTECTED] wrote:
On Thu, Oct 27, 2005 at 05:37:13AM -0400, Rob Kinyon wrote:
: Will I be able to do something like:
:
: package Foo;
Hmm, you just started in Perl 5 mode.
: $*VERSION = 1.3.2;
Perl 5 would get confused here, so I'm presuming Perl 6. But
On Tue, 25 Oct 2005, Larry Wall wrote:
But we're trying to design the OO features (indeed, all of Perl 6)
such that you can usefully cargo cult those aspects that are of
immediate interest without being forced to learn the whole thing.
It's not the number one design goal, but it's right up
On Wed, Oct 26, 2005 at 09:36:48AM +0200, Michele Dondi wrote:
: On Tue, 25 Oct 2005, Larry Wall wrote:
:
: But we're trying to design the OO features (indeed, all of Perl 6)
: such that you can usefully cargo cult those aspects that are of
: immediate interest without being forced to learn the
--- Larry Wall wrote:
On Tue, Oct 25, 2005 at 05:24:52PM +0200, Michele Dondi wrote:
: But maybe that's just me. Whatever, I guess that the {casual,average}
: programmer may be scared by its richness and complexity.
But we're trying to design the OO features (indeed, all of Perl 6)
such
On Wed, 2005-10-26 at 20:29 -0400, Rob Kinyon wrote:
I would prefer to use roles as they're closed by default, leaving
class to be my powertool, if I need the power.
I don't understand this desire; can you explain your reasoning?
(NB: closed here, as I use it, still *does not* correspond to
On 10/26/05, chromatic [EMAIL PROTECTED] wrote:
On Wed, 2005-10-26 at 20:29 -0400, Rob Kinyon wrote:
I would prefer to use roles as they're closed by default, leaving
class to be my powertool, if I need the power.
I don't understand this desire; can you explain your reasoning?
If a role
On 10/26/05, Rob Kinyon [EMAIL PROTECTED] wrote:
On 10/26/05, chromatic [EMAIL PROTECTED] wrote:
On Wed, 2005-10-26 at 20:29 -0400, Rob Kinyon wrote:
I would prefer to use roles as they're closed by default, leaving
class to be my powertool, if I need the power.
I don't understand
On Wed, Oct 26, 2005 at 08:48:12PM -0400, Rob Kinyon wrote:
: If a role is an immutable class, that means that its internals cannot
: be changed. Hence, the compiler can trust that it will be the same at
: the end as at the beginning. Which means it's optimized. Which means
: my objects run faster
On Wed, 2005-10-26 at 19:22 -0600, Luke Palmer wrote:
But we find that many programmers make decisions that trade
readability and extensibility for an extra 1% of speed, even when they
are writing a command-line frontend to MPlayer[1]. If those people
are module writers, then we have a bunch
On 10/26/05, Luke Palmer [EMAIL PROTECTED] wrote:
[snip]
Okay, an open class means you can add methods to it, right? So, let's
say you have this class:
class Foo {
method foo() {...}
method bar() {...}
}
And this code:
my Foo $x = Foo.new;
$x.foo();
On Wed, 2005-10-26 at 21:58 -0400, Rob Kinyon wrote:
Plus, the argument is a straw man. Instead of:
class Some::Class is also {
}
you would do:
class My::Version {
does Some::Class;
}
Problem solved.
Don't forget the fun of modifying all existing uses of
On Wed, Oct 26, 2005 at 07:35:05PM -0700, chromatic wrote:
: On Wed, 2005-10-26 at 21:58 -0400, Rob Kinyon wrote:
:
: Plus, the argument is a straw man. Instead of:
:
: class Some::Class is also {
: }
:
: you would do:
:
: class My::Version {
: does Some::Class;
:
On 10/26/05, Rob Kinyon [EMAIL PROTECTED] wrote:
What about:
class Foo is also {
method foo() { ... }
}
Where the second foo() is no longer what the first foo() did.
Just overwrite the vtable.
Furthermore, let's say you have:
class Bar isa Foo {
method
On Oct 25, 2005, at 6:31 AM, Michele Dondi wrote:
On Fri, 14 Oct 2005, Stevan Little wrote:
I think Perl 6's OO system has the potential to be to OO
programming what Perl 5, etc was to text processing. This, I
believe, is in large part due to
Sorry for replying so late. Thought it seems
On Tue, 25 Oct 2005, Stevan Little wrote:
Well, the point is that it is interesting to note that text processing
is an _application area_, whereas OO programming is a programming
language paradigm.
Allow me to clarify.
Perl 5 (and below) are known by outsiders (non-perl users) as being a
On Wed, Sep 21, 2005 at 13:53:20 +0200, TSa wrote:
HaloO Yuval,
you wrote:
On Mon, Aug 29, 2005 at 14:07:51 +0200, TSa wrote:
role Object does Compare[Object, =:=]
role Numdoes Compare[Num, ==]
role Strdoes Compare[Str, eq]
What is the implication of from the perspective of
HaloO,
Yuval Kogman wrote:
No, the role installs homogenious targets into the generic
binary-MMD comparator which I think is called eqv.
Err, why? We already have that with regular MMD semantics.
role Num {
multi *infix:eqv ($x:, Num $y) { $x == $y }
}
What you mean is double
HaloO Yuval,
you wrote:
On Mon, Aug 29, 2005 at 14:07:51 +0200, TSa wrote:
role Object does Compare[Object, =:=]
role Numdoes Compare[Num, ==]
role Strdoes Compare[Str, eq]
What is the implication of from the perspective of the person using
Object, Num and Str?
Do they have
HaloO,
Damian Conway wrote:
Just a meta-point...one thing we really do need to be careful of is not
ending up with 17 different equality operators (like certain languages
I shall refrain from naming). So far we're contemplating:
=:=
~~
==
eq
eqv
equals
Do we really
On Wed, Aug 24, 2005 at 16:57:30 +1000, Damian Conway wrote:
This is what the operators mean to me:
=:=
The right side and the left are the same thing, in the sense that:
$x =:= $y; # if this is true
$x.mutating_method; # and one side is changed
$x =:= $y; #
On Mon, Aug 29, 2005 at 14:07:51 +0200, TSa wrote:
HaloO,
Damian Conway wrote:
Just a meta-point...one thing we really do need to be careful of is not
ending up with 17 different equality operators (like certain languages I
shall refrain from naming). So far we're
contemplating:
Larry wrote:
Or we could have a different operator that coerces like == and eq, only
via .snap:
if [1,2,3] equals [1,2,3] { say true } else { say false }
(Actual name negotiable, of course). The advantage of the latter approach
is that you can say
@foo equals @bar
and the
On Tue, Aug 23, 2005 at 16:32:37 -0700, Larry Wall wrote:
Hmm, well, I don't think op is valid syntax, but you did say
semantics, so I can't criticize that part. :-)
What is , btw?
Is it
circumfix:{'',''} (Code op -- Code); # takes some code, returns
a listop
or
Hi,
Yuval Kogman wrote:
I think this is more consistent, and just as useful:
10 == 10; # dispatches to num
10 == 10; # dispatched to Num, by means of coercion (== has some
affinity to it for backwards compatibility) 10 == 10; # dispatches
to Str, due to better match 10.0 == 10; # unlike
On Tue, Aug 23, 2005 at 18:15:07 +0200, Ingo Blechschmidt wrote:
sorry, I've some problems with this proposal:
== has always meant numeric equality in Perl and I'd like it to stay
that way.
For simple values like numbers and strings == is numberic, because
it's affinity to it.
snip
10 ==
On Tue, Aug 23, 2005 at 06:19:33PM +0300, Yuval Kogman wrote:
: 10 == 10; # dispatches to Str, due to better match
Nope, that will continue to coerce to numeric comparison. The design
team did in fact consider pure equivalence MMD dispatch of == in
the last meeting, but rejected it in
On Tue, Aug 23, 2005 at 10:28:01 -0700, Larry Wall wrote:
On Tue, Aug 23, 2005 at 06:19:33PM +0300, Yuval Kogman wrote:
: 10 == 10; # dispatches to Str, due to better match
Nope, that will continue to coerce to numeric comparison. The design
team did in fact consider pure equivalence
On Wed, Aug 24, 2005 at 12:43:46AM +0300, Yuval Kogman wrote:
: On Tue, Aug 23, 2005 at 10:28:01 -0700, Larry Wall wrote:
: On Tue, Aug 23, 2005 at 06:19:33PM +0300, Yuval Kogman wrote:
: : 10 == 10; # dispatches to Str, due to better match
:
: Nope, that will continue to coerce to numeric
Chip Salzenberg wrote:
This:
multi sub is_equal(Integer $a, Integer where { $_ == $a } $b: ) { 1 }
hurts. At least as I've been given to understand it[*], is impossible
to implement, because the second parameter's type can't be precalculated
in order to prepare for MMD dispatching.
On Tue, Jun 14, 2005 at 03:43:42PM +0200, TSa (Thomas Sandlaß) wrote:
Chip Salzenberg wrote:
This:
multi sub is_equal(Integer $a, Integer where { $_ == $a } $b: ) { 1 }
hurts. At least as I've been given to understand it[*], is impossible
to implement, because the second parameter's type
Chip Salzenberg wrote:
Link link.
http://www.cs.washington.edu/research/projects/cecil/www/Papers/gud.html
In case it matters, we're trying to support the Perl 6 semantics of
both ($a:$b:) and ($a,$b:). The former looks like something that
could be implemented with something called
On Tue, Jun 14, 2005 at 04:25:17PM +0200, Chip Salzenberg wrote:
: On Tue, Jun 14, 2005 at 03:43:42PM +0200, TSa (Thomas Sandlaß) wrote:
: The syntax might just be:
:
: is_equal:(Integer $a, Integer where { $_ == $a } :)
:
:
: It's a new type object every time, so every time you run that
On Sun, 2005-05-15 at 19:18 +0200, Juerd wrote:
Now:
Declaration ExplicitImplicit $_ $?SELF
has $.var | $obj.var \ .var \ ./var \
has $:var | $obj.:var \ .:var \ ./:var \
Consistent:
has $.var \ $obj.var \
Aaron Sherman skribis 2005-05-16 5:54 (-0400):
On Sun, 2005-05-15 at 19:18 +0200, Juerd wrote:
Now:
Declaration ExplicitImplicit $_ $?SELF
has $.var | $obj.var \ .var \ ./var \
has $:var | $obj.:var \ .:var \ ./:var \
On Mon, 2005-05-16 at 12:23 +0200, Juerd wrote:
Aaron Sherman skribis 2005-05-16 5:54 (-0400):
I'm not sure I see that you changed anything
[...]
Okay, let's try it differently, then:
[...something that looks like braille...]
And now, you've s/[\$\w]+//g; what point are you making, Juerd?
Now:
Declaration ExplicitImplicit $_ $?SELF
has $.var | $obj.var \ .var \ ./var \
has $:var | $obj.:var \ .:var \ ./:var \
Consistent:
has $.var \ $obj.var \ .var \ ./var \
has $.:var \
On 5/14/05, Damian Conway [EMAIL PROTECTED] wrote:
Larry wrote:
I don't think we can allow this situation to stand. Either we have
to make != and !~ and ne transform themselves via not raising, or
we have to disallow negative comparisons on junctions entirely.
Opinions?
Making
On 5/15/05, Luke Palmer [EMAIL PROTECTED] wrote:
multi sub infix:!= (Any|Junction $a, Any|Junction $b) {
!($a == $b);
}
Then it Just Works.
Also, that's the right way to provide a working != for any object
which defines ==. We all want that, right?
Ashley Winters
Luke wrote:
Hmm. I'll just [mention] that if != is implemented like this:
multi sub infix:!= (Any|Junction $a, Any|Junction $b) {
!($a == $b);
}
Then it Just Works.
I'd be fine with the dwimmy version if that is the underlying rule, since then
the behaviour isn't a special case,
On Mon, May 16, 2005 at 10:37:13AM +1000, Damian Conway wrote:
: Luke wrote:
:
: Hmm. I'll just [mention] that if != is implemented like this:
:
: multi sub infix:!= (Any|Junction $a, Any|Junction $b) {
: !($a == $b);
: }
:
: Then it Just Works.
:
: I'd be fine with the dwimmy
On Sat, May 14, 2005 at 09:31:29AM -0700, Larry Wall wrote:
I don't think we can allow this situation to stand. Either we have
to make != and !~ and ne transform themselves via not raising, or
we have to disallow negative comparisons on junctions entirely.
I'm of the opinion that disallowing
Larry Wall wrote:
We have a bit of a problem with negative operators applied to junctions,
as illustrated recently on PerlMonks. To wit, when a native English
speaker writes
if $a != 1 | 2 | 3 {...}
they really mean one of:
if not $a == 1 | 2 | 3 {...}
if $a == none(1, 2, 3) {...}
or,
Larry wrote:
I don't think we can allow this situation to stand. Either we have
to make != and !~ and ne transform themselves via not raising, or
we have to disallow negative comparisons on junctions entirely.
Opinions?
Making them DWIM here would be a mistake, since the dwimmery would disappear
I¹m only an amateur linguist, but from a linguistic point of view, there are
several related terms in this space.
The term ³subject² has many meanings in English, including ³topic². But
from a grammatical and linguistic standpoint, there are only two meanings of
³subject², and ³topic² is a
Luke Palmer wrote:
And in fact, one of the big questions that's always in the back of my
mind (that I'm not searching for an answer to, but I'm always observing
for one) is: what do @ and % mean these days?
Another idea: they define the subsystem of the type system that uses
structural subtyping
Jonathan Lang [EMAIL PROTECTED] wrote:
There are a couple of problems: first, a hash's keys are limited to
strings; a set ought to be able to handle a wider range of data types.
Last time I checked, there was going to be a way to declare a
different data type for the key (which could easily be
On Mon, Feb 21, 2005 at 10:32:15PM -0800, Jonathan Lang wrote:
: ...then you've got the notion of Fuzzy Logic Sets, where the key would be
: the prospective element and the value would be the degree of membership.
: For fuzzy sets, hashes seem to be a better fit than junctions, which have
: no
On Mon, 21 Feb 2005, Jonathan Lang wrote:
There are a couple of problems: first, a hash's keys are limited to
strings; a set ought to be able to handle a wider range of data types.
Well, if I had learnt something about Perl6 it is that it is no longer
necessarily so.
Michele
--
It's also
On Tue, 22 Feb 2005, Larry Wall wrote:
On Mon, Feb 21, 2005 at 10:32:15PM -0800, Jonathan Lang wrote:
: ...then you've got the notion of Fuzzy Logic Sets, where the key would be
[snip]
But using values for degree of membership is an interesting idea.
On the other hand, if we ever have numeric
Michele Dondi wrote:
OTOH all these discussions seem to imply that there is some demand (by
me, for one!) for a set-like builtin data-type as well as for the
already existing hashes and junctions and of course for
interoperability between any two of them, e.g. in terms of automatic
On Sun, 13 Feb 2005, Jonathan Lang wrote:
If we want Sets in Perl, we should have proper Sets.
I'll agree, depending on what you mean by proper. I'd be interested in
having some means to perform set operations in perl6: unions,
intersections, differences, membership checks, and subset/superset
On Mon, Feb 21, 2005 at 03:07:34PM +0100, Michele Dondi wrote:
: On Sun, 13 Feb 2005, Jonathan Lang wrote:
:
:If we want Sets in Perl, we should have proper Sets.
:
: I'll agree, depending on what you mean by proper. I'd be interested in
: having some means to perform set operations in
On Thu, Feb 17, 2005 at 08:58:21AM +0100, Thomas Sandlaß wrote:
: HaloO Larry,
:
: you wrote:
: That would be cool. I'd like to see our community build up a pool of
: theoreticians who are not allergic to the practicalities of building a
: language for ordinary people to think in. It is my
On Wed, Feb 16, 2005 at 12:14:10AM -0600, Rod Adams wrote:
So in terms of frequency of use in the English Language, I'd rank things
in the following order:
1) Scalars
2) Sets
3) Arrays
4) Hashes
Perhaps. However, it's fairly easy to use an Array or Hash to represent
a Set, so perhaps it's
HaloO All,
Luke Palmer wrote:
But what are some nice, abstract concepts that these could represent.
One that I've been thinking of is:
* @something is necessarily ordered: there is a well-defined first element
* %something is necessarily a set: adding something twice is always
redundant
Thomas Sandlaß skribis 2005-02-16 18:35 (+0100):
% with . and .«»
% with .{}
. and . imply {}
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
On Wed, Feb 16, 2005 at 06:35:38PM +0100, Thomas Sandla wrote:
: Each of these comes with a corresponding postcicumfix dereferencer.
: with .()
: @ with .[]
: % with . and .
% with .{} (plus . and . as syntactic sugar)
: Maybe now is the time to figure out what they *do* mean.
:
: I see
HaloO Larry,
you wrote:
That would be cool. I'd like to see our community build up a pool of
theoreticians who are not allergic to the practicalities of building a
language for ordinary people to think in. It is my persistent belief
(and fond hope) that theory and practice don't always have to
On Tue, 2005-02-15 at 14:26 -0600, Rod Adams wrote:
The obvious statement I expect to here is Perl's always had Arrays
and Hashes. While I'm not sure if they were there for Perl 1.0 (I
started w/ Perl 4.xx)
They were.
So I'm interested in hearing what pushes Arrays and Hashes over the edge
At 01:04 PM 2/15/2005 -0800, chromatic wrote:
On Tue, 2005-02-15 at 14:26 -0600, Rod Adams wrote:
So I'm interested in hearing what pushes Arrays and Hashes over the edge
for needing their own container and sigil, whereas Junctions/Sets do not.
Perl isn't a pure object-oriented language.
No
chromatic wrote:
So I'm interested in hearing what pushes Arrays and Hashes over the edge
for needing their own container and sigil, whereas Junctions/Sets do not.
Perl isn't a pure object-oriented language.
Rephrasing my question:
What characteristics would _any_ new structure or class
Rod Adams writes:
So I'm interested in hearing what pushes Arrays and Hashes over the
edge for needing their own container and sigil, whereas Junctions/Sets
do not.
Nothing. In fact, arrays and hashes aren't atomic or fundamental in any
respect, and the main thing that keeps them there is
On Tue, Feb 15, 2005 at 04:20:28PM -0600, Rod Adams wrote:
: chromatic wrote:
:
: So I'm interested in hearing what pushes Arrays and Hashes over the edge
: for needing their own container and sigil, whereas Junctions/Sets do not.
:
:
:
: Perl isn't a pure object-oriented language.
:
:
Larry wrote:
That's the basic problem with
0 $x 10
after all--the problem with rewriting that as
0 $x and $x 10
is that it should only work as long as the two values of $x remain
entangled so that the always refer to the same abstract value.
That's certainly true. But I think the real
On Wed, Feb 16, 2005 at 01:13:53PM +1100, Damian Conway wrote:
: Larry wrote:
:
: That's the basic problem with
:
: 0 $x 10
:
: after all--the problem with rewriting that as
:
: 0 $x and $x 10
:
: is that it should only work as long as the two values of $x remain
: entangled so
On Wed, Feb 16, 2005 at 01:13:53PM +1100, Damian Conway wrote:
Larry wrote:
0 $x 10
after all--the problem with rewriting that as
0 $x and $x 10
is that it should only work as long as the two values of $x remain
entangled so that the always refer to the same abstract value.
Larry Wall wrote:
But as far as English is concerned, sets are just
objects that have a singular outside and a (potentially) plural inside,
much like almost any other object. At least, that's how concrete
sets work.
Hmm. I would argue that most of the time, when English Speakers use sets
On Tue, Feb 15, 2005 at 10:01:52PM -0600, Patrick R. Michaud wrote:
: Uh oh, I hadn't caught that particular nuance. Is it indeed over the
: entire equi-precedential part of the operation, or just over the
: chained operators?
Just the chained operators, I think. For more general expression
Jonathan Lang wrote:
Maybe set should be an operator akin to any, all, one, and none,
at least in terms of and |. That is, if junctions are special cases
of sets, why not allow for the creation of generic sets in much the same
way? Then you could have:
# $A and $B are sets,
union($A, $B)
Rod Adams wrote:
Now that I've gotten some feedback from my original message (on list and
off), and have had some time to think about it some more, I've come to
some conclusions:
Junctions are Sets. (if not, they would make more sense if they
were.)
As pointed out elsewhere, Junctions
On Fri, 3 Dec 2004, Brent 'Dax' Royal-Gordon wrote:
Larry Wall [EMAIL PROTECTED] wrote:
So optimizing to a state variable won't necessarily help your loop
overhead, but it could help your subroutine overhead, at least in Perl
5, if Perl 5 had state variables. Best you can do in Perl 5 is an
our
On Sat, 4 Dec 2004 22:03:19 -0800, Larry Wall [EMAIL PROTECTED] wrote:
On Sun, Dec 05, 2004 at 02:15:51AM +0300, Alexey Trofimenko wrote:
: oh! that it. I've found example which could make it clear to me
:
: sub test {
: return sub {
: for 1..3 {
:state $var = 1;
:print
On Fri, Dec 03, 2004 at 11:36:02PM -0800, Brent 'Dax' Royal-Gordon wrote:
: Larry Wall [EMAIL PROTECTED] wrote:
: So optimizing to a state variable won't necessarily help your loop
: overhead, but it could help your subroutine overhead, at least in Perl
: 5, if Perl 5 had state variables. Best
101 - 200 of 332 matches
Mail list logo
