Re: Containers vs Objects.
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 as opposed to name based subtyping with roles, classes and signatures or contraint based subtyping with where clauses. Quite interesting that Perl 6 does all three of them where other languages are content with one :) -- TSa (Thomas SandlaÃ)
Re: Containers vs Objects.
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 persistent belief : >(and fond hope) that theory and practice don't always have to pull in : >opposite directions. : : Well, quoting Einstein: "Nothing is more practical than a sound theory!" : : :)) Well, sure, but it's psychologically interesting that you personally find an appeal to authority more practical in this situation. :-) Besides, we all understand that Einstein is being disengenuous here in reducing the correlation between sound theory and practice to a single dimension. But human existence is multidimensional, and it is obvious from casual inspection of human history that having a sound theory is only moderately correlated with adaptiveness. Sure, sound theory will occasionally save you from earning a Darwin award, but the correlation breaks down anywhere a low-overhead heuristic is more efficient than a high-maintenance theory. The human psyche is a mishmash of rules of thumb, and Einstein's thumb is only two of them. Anyway, human languages have little to do with sound theory. At best you might try to develop a theory of sound, which we call linguistics. My assertion that we can do better with computer languages is a persistent belief and fond hope, but you'll note I don't actually claim to be either rational or right. Except when it's convenient. :-) Larry
Re: Containers vs Objects.
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 pull in opposite directions. Well, quoting Einstein: "Nothing is more practical than a sound theory!" :)) -- TSa (Thomas SandlaÃ)
Re: Containers vs Objects.
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 them more as part of the type declaration. So that
:
: my Int $var;
:
: could also be written in the extreme as
:
: my var is Scalar of Int;
:
: Unless the parser needs the sigil for actually finding the name
: that is declared?
They are considered part of the name, though that could be hidden
by the syntax (as can the rest of the type system, as you point out).
: In any case I would like all sigils to be optional as it is the
: case for & and :: already. Of course they *are* needed to disambiguate
: when needed. After all---as Larry and others use to say---the "type
: system is optional" and "everything is fair if you predeclare".
Yes, I think I'm already on record as saying I expect one of the first
Perl 6 variants to be a "use sigilless". We're certainly throwing a
large sop into the sigilless camp with "{foo}" closure interpolation.
On the other hand, I think the majority of English speakers find the
sigils psychologically useful, and will continue to use them. And
we do use them for a lot of disambiguation in the grammar, which a
sigilless variant would have to solve rather differently, with various
psycholinguistic complications.
But if I'd been born in a different hemisphere, I'd probably rather write
é += æç;
than
$é += $æç;
: The above lifts the question up to the type system which in my eyes
: needs some more clarifications. In that sense it's actually not optional
: at all, but *defines* the behaviour of the whole Perl6 language. It's
: only optional on the sytactic level, or better gives very flexible defaults.
You've hit the nail on the head. The Perl 6 ideal is to allow the
user to choose which color of rose-tinted glasses they'd like to view
harsh reality with, while allowing interoperability at a deep level
with people who have chosen differently colored rose-tinted classes.
On the other hand, I recognize that no amount of rose-colored glasses
will ever allow
method æ ($æ) {...}
to interoperate with Indo-Europeans.
: Reading about A. J. H. Simons's "Theory of Classification" has made
: me a true admirer of the design of Perl6 as it is right now.
: (See http://www.dcs.shef.ac.uk/~ajhs/classify/index.html). I would
: really like to hear how this works out on Perl6! Perhaps we could
: interesst some students or researcher of theoretical computer science
: to write a paper or so?
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 pull in
opposite directions.
Larry
Re: Containers vs Objects.
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
Re: Containers vs Objects.
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 Or something like that. I've noticed in my recent programming which has been heavily algorithmic that sets are ubiquitous. % would still mean hash by default, but hash would mean a "set of pairs". Up to a point all three sigiled types &, @ and % can be interpreted as sets: & maps the argument(s) to the return value --- and can have side effects @ maps the integer index/slice to the return value % maps the key(s)/slice to the return value Each of these comes with a corresponding postcicumfix dereferencer. & with .() @ with .[] % with .<> and .ÂÂ Is that too abstract? Maybe now is the time to figure out what they *do* mean. I see them more as part of the type declaration. So that my Int $var; could also be written in the extreme as my var is Scalar of Int; Unless the parser needs the sigil for actually finding the name that is declared? In any case I would like all sigils to be optional as it is the case for & and :: already. Of course they *are* needed to disambiguate when needed. After all---as Larry and others use to say---the "type system is optional" and "everything is fair if you predeclare". The above lifts the question up to the type system which in my eyes needs some more clarifications. In that sense it's actually not optional at all, but *defines* the behaviour of the whole Perl6 language. It's only optional on the sytactic level, or better gives very flexible defaults. Reading about A. J. H. Simons's "Theory of Classification" has made me a true admirer of the design of Perl6 as it is right now. (See http://www.dcs.shef.ac.uk/~ajhs/classify/index.html). I would really like to hear how this works out on Perl6! Perhaps we could interesst some students or researcher of theoretical computer science to write a paper or so? Regards, -- TSa (Thomas SandlaÃ)
Re: Containers vs Objects.
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 better to just introduce some routines to facilitate
that.
> As for Perl Speakers, I would argue that a high percentage of the time
> someone says C< for @list {...} >, they really don't care for which
> order the elements are executed in, just that they are.
Hmmm. I wonder about that "high percentage" qualifier there; for
the code I write I'd estimate that it's as least as frequent that with
C< for @list { ... } > the order of the elements is extremely
important to me. And it's nice that I can use the same structure
(@list) for both ordered and unordered lists.
Pm
Re: Containers vs Objects.
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
threading you can always force it with
$junkout = -> $x { random_expression }.($junkin)
or
$junkout = do given $junkin -> $x { random_expression }
or some such (assuming the $x parameter is taken to be non-junctive).
Larry
Re: Containers vs Objects.
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
quite commonly in their speak, and often refer to them as lists (e.g.
Shopping Lists). In fact, when expressing any list, we go out of our way
to explicitly give them an order or ranking. Not to mention people do
think in terms of sets. Back to the shopping list, you have the set of
things on your list (#list), and the set of things in your cart (#cart),
as well as the things in the store (#store).
What can you cross off your list? #list x #cart
What's left to buy? #list - #cart
What's not available? #list - #store
What did you buy that wasn't asked for? #cart - #list
Add to this the not infrequent use of the phrase "You listed ___ twice."
in response to hearing a list, thus implying something more set-ish
about it than an array gets. Or the frequency with which one gives six
or more responses to the question "What are your top 5 ?"
I have little ability to translate hashes into English, beyond "How many
cans of ___ are in the cupboard?"
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
As for Perl Speakers, I would argue that a high percentage of the time
someone says C< for @list {...} >, they really don't care for which
order the elements are executed in, just that they are. Creating a hash
where all the values are 1, just to get the set like features of the
keys, is a fairly common Perl idiom.
As Computer Science Speakers, Sets are a very fundamental data
structure. Okay, not as fundamental as Arrays. But easily more so than
Hashes.
Programmers tend not to speak in terms of Sets very often, because their
languages don't support them.
Junctions, on the other hand, almost never come up in English, except as
a Set. Where do you see sentences which have a word which means two
other words _at_once_, and the listener is supposed to understand all of
the meanings? Double entendres come close, but there are two main
drawbacks: 1) only a limited set of words can be used in this case, and
each of them has a very limited number of values it can possess. Not any
noun taking on the value of any two or more other nouns at once. 2) it
is almost never in question that only one meaning was meant, and the
other meaning was merely a cover, to prevent a faux-pas.
-- Rod Adams
Re: Containers vs Objects.
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? For example, given $x = -1 | 10; $ref.meth1($x).meth2($x) are the meth1 and meth2 calls considered to be "equi-precedential", I'm not sure that's the right question. I think the question is: what are the relative precedences of "argument list to method call" and "method call on result". And I think it's pretty clear that arg list wins there. So: $ref.meth1($x).meth2($x) -> any($ref.meth1(-1).meth2($x), $ref.meth1(10).meth2($x) ) -> any( any( $ref.meth1(-1).meth2(-1), $ref.meth1(-1).meth2(10) ), any( $ref.meth1(10).meth2(-1), $ref.meth1(10).meth2(10) ), ) Or to put it another way: method call isn't n-ary. And what of ... $ref.meth1($x) + $x are the $x still "tied" to each other even though they're being used at different levels of precedence? I.e., do I get any( $ref.meth1(-1) + -1, $ref.meth1(10) + 10) or any( any( $ref.meth1(-1) + -1, $ref.meth1(-1) + 10 ), any( $ref.meth1(10) + -1, $ref.meth1(10) + 10 ) ) Definitely the latter. As Einstein avowed: "no spooky action at a distance!" ;-) Damian
Re: Containers vs Objects.
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. > > That's certainly true. But I think the real problem there is in mistakenly > treating Perl 6 comparators as binary ops (with n-ary sugar), rather than > as genuine n-ary ops. > > That is, a junction must autothread early, and over the entire operation > (or at least, over the entire equi-precedential part of the operation) in > which it's used. 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? For example, given $x = -1 | 10; $ref.meth1($x).meth2($x) are the meth1 and meth2 calls considered to be "equi-precedential", with a result of ... any( $ref.meth1(-1).meth2(-1), $ref.meth1(10).meth2(10) )? And what of ... $ref.meth1($x) + $x are the $x still "tied" to each other even though they're being used at different levels of precedence? I.e., do I get any( $ref.meth1(-1) + -1, $ref.meth1(10) + 10) or any( any( $ref.meth1(-1) + -1, $ref.meth1(-1) + 10 ), any( $ref.meth1(10) + -1, $ref.meth1(10) + 10 ) ) ? Pm
Re: Containers vs Objects.
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 that the always refer to the same abstract value. : : That's certainly true. But I think the real problem there is in mistakenly : treating Perl 6 comparators as binary ops (with n-ary sugar), rather than : as genuine n-ary ops. Yes, that's what I was trying to say, but my tongue got entangled with my thoughts... Larry
Re: Containers vs Objects.
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 problem there is in mistakenly treating Perl 6 comparators as binary ops (with n-ary sugar), rather than as genuine n-ary ops. That is, a junction must autothread early, and over the entire operation (or at least, over the entire equi-precedential part of the operation) in which it's used. So if: $x = -1 | 11; then: 10 < $x < 0 --> any(10 < -1 < 0, 10 < 11 < 0) --> any(10 < -1 && -1 < 0, 10 < 11 && 11 < 0) --> any(false, false) The mistake is in thinking that the n-ary comparison should be expanded before the junction autothreads. Damian
Re: Containers vs Objects.
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.
: >
: >
: Rephrasing my question:
:
: What characteristics would _any_ new structure or class have to have to
: merit becoming a first class container with it's own sigil, rather than
: being just another class?
It would have to be very much basic to the way we classify nouns in
our heads. So I think that sort of thing should be added about as
often as a natural language adds a new case or number marker, which
is not very.
To be sure, English is not a great example of clarity here. English
junctions cause a great deal of confusion on the subject of singular
and plural verbs:
If any of you are coming to the store...
If any of you is coming to the store...
: Or is Perl close enough to "pure" object-oriented these days, where only
: grandfathered classes make the cut?
Well, the reason we grandfather the grandfathers is that we wouldn't
be here without them. There's a precedence to things such that
descendents don't happen without ancestors. The very fact that
something is historical means that it has generally had more influence
than anything derived from it. By that argument, Perl programmers
have spent a great deal more time thinking about plural values as
arrays than as junctions or sets or objects. That's not the only
way to think--and I've certainly realized that in studying Japanese,
wherein there is no grammatical singular/plural distinction--but
it's how a lot of English speakers think, and a lot of existing Perl
programmers too. 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. The problem is that as soon as you start throwing
junctionals around, you're now talking about abstract set definitions
with all sorts of interesting entanglements inside.
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.
: As a separate question, is there a relatively easy way to create a
: user-defined class with it's own sigil? (w/o having to modify half the
: parse rules).
Certainly, just say
macro term:<¢> ($name) is parsed(m:p//) {...}
or some such. (Making it interpolate would be a little more work.)
Larry
Re: Containers vs Objects.
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 history.
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?
They have syntactical semantics:
sub foo ([EMAIL PROTECTED]) {
say @_.elems;
}
my @a = (1,2,3,4,5);
my $a = @a;
foo(@a); # 5
foo($a); # 1
Hashes do too, particularly in rules.
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
Or something like that. I've noticed in my recent programming which has
been heavily algorithmic that sets are ubiquitous. % would still mean
hash by default, but hash would mean a "set of pairs".
Correspondingly, @ would mean array by default, but you could certainly
put a linked list in there.
The biggest problem (perhaps) with these abstractions is that
subscripting--their most common operation--is not well-defined.
Presumably most of these containers would define reasonable
subscripters, but if you ask for an array in your parameter list, you
may not even be able to subscript it.
So I don't think these are quite right. Also, rules refer to the
"value" of a hash for a partcular key, and that's not well-defined for
sets either.
Maybe now is the time to figure out what they *do* mean.
Luke
Re: Containers vs Objects.
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 have to have to merit becoming a first class container with it's own sigil, rather than being just another class? Or is Perl close enough to "pure" object-oriented these days, where only grandfathered classes make the cut? As a separate question, is there a relatively easy way to create a user-defined class with it's own sigil? (w/o having to modify half the parse rules). -- Rod Adams
Re: Containers vs Objects.
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 argument there. Which is why I was interested effectively the argument that "Junctions/Sets are Objects, and don't need their own container/sigil" was considered so compelling. -- Rod Adams
Re: Containers vs Objects.
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 > for needing their own container and sigil, whereas Junctions/Sets do not. Perl isn't a "pure" object-oriented language. -- c
Containers vs Objects.
In my recent unsuccessful attempt to convert junctions into sets with their own container, perhaps the strongest argument against could be paraphrased as follows: Everything about junctions or sets can be represented fully as an object, and objects are nicely stored in scalars, because it's simply one instance of a given class, in this case C. My question comes down to: so what makes Arrays and Hashes so special? As many pure-OO languages demonstrate, both can be fully represented as an object, and objects belong in Scalars. 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), I do know that they certainly predate P5's objects and references. Therefore, there was no other way to create an array or hash. That is no longer the case. In P6, we've even gone so far as to say that you can access an element in an array ref with C<$ref[1]>. I'm fairly sure you can call all the methods of the Array class on the $ref, letting you do C<$ref.pop> and all the other fun things we do with arrays. Similar things hold for hashes. 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. -- Rod Adams
