Re: .chars, .bytes, etc.
HaloO, Juerd wrote: wolverian skribis 2005-09-24 13:45 (+0300): Why not define .chars like this: Context Return value itemamount of units listunits 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!
Re: .chars, .bytes, etc.
Hi, please configure your e-mail client to use (greater-than, space) for quoting, if possible. It currently uses (greater-than). TSa skribis 2005-09-26 13:43 (+0200): Why not define .chars like this: Context Return value itemamount of units listunits themselves I still have my objections to this outside-in flow of type information. Can you explain please what outside-in means to you? 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? They are both plural, and the word used is used to describe a fundamental building piece of the greater whole: an array has elements, a string has characters. It has nothing to do with both elems and chars being 5 letters. 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] ... but I don't follow how you manage to mix these concepts and come up with 'non-Num item context'. non-Num item context is item context that isn't specifically numeric. Bare @foo in non-Num context returns a reference, @foo.elems in non-Num context returns the number of elements. In Num context, both return the number of elements. BTW, does everybody expect more than one prefix numerifyer beeing redundant or is there an idea of (+ (+ @foo)) beeing modelled It's providing context to something that was already providing context. A bit redundant indeed. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: .chars, .bytes, etc.
HaloO, Juerd wrote: Can you explain please what outside-in means to you? TSa wrote: BTW, does everybody expect more than one prefix numerifyer beeing redundant or is there an idea of (+ (+ @foo)) beeing modelled Juerd answered: It's providing context to something that was already providing context. A bit redundant indeed. This is exactly what I mean with outside-in. The outer + puts the inner + into numeric context and that puts the innermost array in numeric context. My view is that an array of course knows how many elements it represents. This is sort of required by the specification of 'a Perl6 Array'. The prefix + operator is one possibility to retrieve this information *out of* the array! So is .elems, .size are whatever name is choosen. Let's assume this number is 42. At what point in a syntactic sequence outward from the array does this 42 loose its relation to the array @foo? Compare that to the case where two prefix ops are wrapped around this number-of-elements retrieval operation in (op1 (op2 (+ @foo))). Or in the extreme case beeing parametric with respect to all three operations (op1 (op2 (op3 @foo))). Where is the context generated and is it propagating inwards, outwards or both? To me the bottom of the language specification is reached when you hit a sigiled term or a literal. In the above case this is @foo in (op3 @foo), which results in op3 becoming a prefix op that has to be capable of handling an array, *without* retrieving any further meta information. From there I think the type information of the as of the expression itself unknown return type must be handled by the op2 and so on until the whole expression is typed as the return type of op1. If nothing else is known, all these type checks or dispatches are deferred until the actual call and result in an exception if they don't hold. Sorry if my joke attempt of elems and chars both having a 5 chars name symmetry didn't work. What I want to say is that the other thing that the language spec has to nail down is the name under which certain, central concepts are known and how to provide them for non-standard classes, modules, types or whatever. One means of providing them is MMD. Messing with the grammar in my eyes is possible but shouldn't be the canonical, lightweight approach how you add numerification to your class. The same applies to stringification and with greater difficulty to equality. This greater difficulty for equality stems from the fact that the concept is generic with respect to *both* participants while numerification has a defined result type. Unfortunately the concepts in both cases are not so well defined either. A string could e.g. numerify to its length or by parsing its content. I mean +'12' should be twelve not two. OTOH, +'two' == 2 is not too far fetched. This obviously is prefix + for numerification. Interestingly, prefix - does *not* have this redundancy or do you expect the numerical context it imposes inwards combined with flipping the sign makes (- (- @foo)) = 0? Or is the sign flipping honoured with each step inwards but numeric context travels unhindered once it is established? -- $TSa.greeting := HaloO; # mind the echo!
.chars, .bytes, etc.
Hi all, After some thinking it occured to me that the current way of defining .chars, .bytes and .elems (and whatever else there are) doesn't make any sense to me. In pugs at least they currently return the amount of units in question - in any context! Why not define .chars like this: Context Return value itemamount of units listunits themselves Juerd proposed this list originally, which matches my thinking. Originally I thought that .elems and .chars were symmetric and both should behave the same semantically, but now I think that's false - if there should be an .elems method, leave it at returning an Int at all times. @foo.elems returning the elements in @foo makes no sense. -- wolverian signature.asc Description: Digital signature
Re: .chars, .bytes, etc.
wolverian skribis 2005-09-24 13:45 (+0300): Why not define .chars like this: Context Return value itemamount of units listunits themselves Agreed, of course. 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 .elems isn't needed. At all. [EMAIL PROTECTED] already is the number of elements, list @foo already is a list of elements. Now, if we're going to have .elems anyway, then let it be symmetric with .chars. 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] 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. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
