HaloO,
Juerd wrote:
wolverian skribis 2005-09-24 13:45 (+0300):
Why not define .chars like this:
Context Return value
item amount of units
list units themselves
I still have my objections to this outside-in flow of type
information.
Originally I thought that .elems and .chars were symmetric and both
should behave the same semantically
I still think this. They certainly LOOK symmetric.
But with respect to what are .elems and .chars symmetric?
Do you mean they are just two five elems err chars long names
for the identical concept? Otherwise elems could be perhaps
renamed 'smelems' and even my poor eyes could see the symmetry
---sorry, couldn't resist!
But .elems isn't needed. At all. [EMAIL PROTECTED] already is the number of
elements, list @foo already is a list of elements.
So is [EMAIL PROTECTED] I can easily interpret .elems as the postfix equivalent
to prefix *. Well and list as just the four character name of the
concept in prefix context.
Thus I see, with =::= denoting meta|semantic level identity:
(* @foo) =::= (list @foo) =::= (@foo .elems) =::= (@foo .list)
which leaves postfix .elems somewhat redundant. But perhaps it is
just the slot accessor that happens to be implemented in the
particular array class that @foo refers to. But I have proposed
that this be written (@foo :elems) or (elems => @foo) or (@foo .<elems>).
And of course there also is the total slice (@foo .[]) notation.
BTW, I have use parens and whitespace here to explicitly give
precedence, nothing else.
Given explicit type info about elems beeing a postfix operator, even
(@foo elems) is viable. The dot form is just the auto-postfixing of a
prefix op to me---a postfix cast of the operator, so to say. Note that
e.g. the increment operator ++ is not invariant in this transformation!
And there is no guarranty that you can factor out its application as
in:
(++$x - $x++) =::= ( (++ - ++) $x ) =::= ( $x .(++ - ++) )
where the latter two terms are hardly valid syntax. But I wanted
to be terse. But again, junctions seem to pull exactly this stunt =:)
Now, if we're going
to have .elems anyway, then let it be symmetric with .chars.
The 'symmetric' there meaning 'semantic identity' or giving cardinality?
The
difference with @foo without .elems would then be non-Num item context:
item @foo returns [EMAIL PROTECTED], but item @foo.elems returns [EMAIL
PROTECTED]
I have no problems to understand
(item @foo) =::= (\ @foo) =::= (@foo .item) =::= ([EMAIL PROTECTED])
where the last term uses the itimizing circumfix [], and that
(num @foo) =::= (+ @foo) =::= (elems @foo) =::= (@foo .elems)
but I don't follow how you manage to mix these concepts and
come up with 'non-Num item context'. Where is such a beast born
syntactically, and how does it propagate?
BTW, does everybody expect more than one prefix numerifyer beeing
redundant or is there an idea of (+ (+ @foo)) beeing modelled
after (bar (bar @foo)) where prefix bar is called twice, first with
the array @foo, then with a non-negative integer value from which no
way leads back to @foo? Note that I would write the redundancy as
((+ +) @foo) which means that + returns itself un-invoked or some
such. Sorry, if this is too much LISPish thinking and Perl 6 is not
LISP without parens and some sigils thrown in---but what then?
... Perl 6, of course. But that definition is unfortunately
self referencial!
Still, I'd
prefer not having .elems at all, as it adds nothing but confusion,
regardless of which of the two semantic sets is chosen.
To me it adds flexibility or unspecificity on the semantic level,
which can be construed as confusion! The only thing I dislike is that
it increases the burden of someone who wants to deliver the identical
meanings under all possibly choosable names. An example of what I mean
can be seen in the 'generic equality' problem.
--
$TSa.greeting := "HaloO"; # mind the echo!
