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<Junction>.

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

They were.

Perl isn't a "pure" object-oriented language.

-- c

At 01:04 PM 2/15/2005 -0800, chromatic wrote:

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

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 (*@_) {
        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

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

:
: >>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/<Perl::name>/) {...}

or some such.  (Making it interpolate would be a little more work.)

Larry

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

:
: >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

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

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.

Definitely the latter. As Einstein avowed: "no spooky action at a distance!"

;-)

Damian

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

: 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

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.

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

HaloO All,

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?

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ß)

Thomas Sandlaß skribis 2005-02-16 18:35 (+0100):

% 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

: 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

HaloO Larry,

Well, quoting Einstein: "Nothing is more practical than a sound theory!"

:))
--
TSa (Thomas Sandlaß)

: HaloO Larry,
:
: >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

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ß)