Re: Perl 6's for() signature
> Anyone but me feel the need for non-greedy slurpy arrays? similar to
> non-greedy RE matches?
> Then we could do:
>
> sub for ([EMAIL PROTECTED], &block) {...}
>
> Proposed behavior of *?@ : All Arguement to Parameter mapping left of it
> are processed Left to Right. Once seen, the mapping starts over right to
> left. Everything remaining is slurpable.
With obvious restrictions on "no other slurpy/semi-slurpy arrays" in the
param list, b/c that would make things go insane, IMHO. Although, I guess
with typing, you could do splits on the typed params between, and assuming
there was no ambiguity ...
Ow, my head hurts now :o
--attriel
Re: Apocalypses and Exegesis...
> Apocalypses and Exegesis are not an 'official' specification for Perl6, > I mean, they are subject to change. Is there any idea when will we have > a freeze on the syntax and features for perl6? Since the A/E gig is where the design team is getting a handle on what it is they want to be doing and how (and then trying to explain it to the rest of us using small words :), I think they won't freeze anything until they're much further along on the series OTOH, I think they aren't planning to make sweeping changes to whats there already and most of it can be considered 'slushy', which may not be as good as frozen, but it's closer :o That's my take on it, of course; I could be entirely wrong, too --attriel
Re: AW: AW: AW: nag Exegesis 2
> (1)
>
> my size(4), human DNA ($alpha, $beta, $gamma, $delta ) = ( 'atgc',
> 'ctga', 'aatt', 'ccaa' );
>
> is so perfect, vs
>
> (2)
>
> my DNA ($alpha, $beta, $gamma, $delta) is human, size(4) = ( 'atgc',
> 'ctga', 'aatt', 'ccaa' );
If I were concerned about this, I would either do it the way Damian
suggests
my DNA ($alpha, $beta, $gamma, $delta) is human size(4)
= ('atgc', 'ctga', 'aatt', 'ccaa');
Or I would just make it two lines:
my DNA ($alpha, $beta, $gamma, $delta) is human size(4);
($alpha, $beta, $gamma, $delta) = ('atgc', 'ctga', 'aatt', 'ccaa');
And then expect the compiler to do precisely the same thing. The
benefit I find in the second case is that I can now move it somewhere
else and have separate declarations and initializations.
the example in (1) looks like it's beind declared as a "size(4)" , with
"human" and "DNA" being somehow modifiers on "size(4)" (admittedly, if
it were the stated style, people would be expected to understand it, but
it would still be counterintuitive, IMO)
--attriel
Re: 'my int( 1..31 ) $var' ?
>> print "date" if $var.isa(int); >> print "date" if isa $var: int; >> print "date" if $var ~~ int; >> >> Those should all work. IMO the first reads the best. That will also >> work for Cs, as C is a subclass of C (I think). > > These only determine if $var is of type int or Int. However: > > my $var = 0; > # or my $var = "0"; > # or my int $var = 0; > # or my num $var = 0; > > # all 4 cases should print "is integer" > print "is integer" if int $var == $var; > > This should work as a more generic method to test Integer *value*, > rather than type, which IMHO is more useful (and more commonly wanted). Well, in general I think it would be good to have some mechanism for determining the type of the data rather than the type of a representation of the contained value. If I have "0", it's possible I might at some point (this having been user input perhaps) have some reason to care whether it was an integer or a string. I know I hate the fact that, in almost every lang I use, adding the strings "014" and "231" requires me to do ' "" + string1 + "" + string2 ' since if I 'string1 + string2' I get integer addition and end up with a single number 245, or '"" + string1 + string2' becomes the string "245". I've come to accept it, and I realize that 'var-typed(string1) + var-typed(string2)' takes more characters, looks uglier, and is generally more annoying in all ways for that problem, but I imagine there might exist cases where the information is useful ... I suppose it could be stored at input time as a ... variable property (?) that the program sets, but once it's read, I'm not sure the information exists in any meeans to produce the information FOR the property, so it would have to be set in the input functions themselves ... Admittedly, the value-type is goin to be more interesting in a large majority of the cases, so it probably SHOULD continue being the default low-effort result ... I had a point. I think I made it in there. --attriel
Re: 'my int( 1..31 ) $var' ?
>> If I have "0", it's possible I might at some point (this having been >> user input perhaps) have some reason to care whether it was an integer >> or a string. > > How would the user distinguish when providing the input? The Perl 5 having slept now, the same thought occurs to me ... I think I wasthinking of the user typing "0" to show that they're putting it in in string context ... but then the variable would hold ""0"" ... which seems like it'd solve the problem itself, at that point, since a user defined entity can now /\"\d+\"/ to find out if it's built that way even if it does collapse back to a number >> I know I hate the fact that, in almost every lang I use, adding the >> strings "014" and "231" requires me to do ' "" + string1 + "" + >> string2 ' > > Fortunately Perl isn't one of those languages. In general you need for I should learn not to read/respond when i'm tired :o I was thinking of all the Java & JS I've been doing the last couple weeks. Perl I'd just do "$a$b" and be done with it. >> ... I imagine there might exist cases where the information is useful >> ... > > I'm struggling to think of any -- if you come up with some please could > you mail them so I can understand your viewpoint better. Needing to > know about this kind of thing strikes me as most unPerlish. Yeah, since the user would have to in some way dicatate that it was a string value (typing "0" or such), the code will actually receive enough information to build that if the programmer wants it. And I have ZERO idea what I was thinking of as a "useful case" ... But since it is user-garnerable information, and no cases are springing to mind, I retract my earlier comments and say that it might be interesting in some case, but in the same case it is feasible to simply allow the programmer to generate it rather than killing ops generating it automatically ... --attriel (I'll quit posting just before I go to bed now :o)
Re: L2R/R2L syntax (was Re: Everything is an object.)
> Can I suggest that an alternative solution might be the following:
>
> Suppose Perl 6 had two new very low precedence operators: ~> and <~
> (a.k.a. "bind rightwards" and "bind leftwards")
>
> @out = @a ~> grep {...} ~> map {...} ~> sort;
>
> @out = sort <~ map {...} <~ grep {...} <~ @a;
>
> That way, everything is still a method call, the ultra-low precedence of
> <~ and ~> eliminate the need for parens, and (best of all) the
> expressions actually *look* like processing sequences.
(a) OOh, shiny!
(b) Can <~ and ~> be used at the same time?
I'm not entirely sure of what functions take two array params
meaningfully, but could we do:
@a ~> grep (...) ~> sort ~> for <~ map (...) <~ @b {
(for content goes here)
}
With the understanding that
(1) EWWW, that is horribly ugly, but it was the first thing I could come
up with that meaningfully takes two list args
(2) Anyone who ACTUALLY does this with a for be shot on sight?
It would be more meaningful in another function that takes two lists and
does something useful, but without a body block ... More of a
@a ~> grep (...) ~> apply <~ sort <~ @b ;
So that the grep'd elements of @a are applied, 1:1, to the sorted @b ... ala
apply (grep (..., @a), sort(@b));
(again, more useful for a longer chain)
--attriel
RE: L2R/R2L syntax (was Re: Everything is an object.)
>>(b) Can <~ and ~> be used at the same time? >> >>I'm not entirely sure of what functions take two array params >>meaningfully, but could we do: > > Damian's proposal didn't say anything about array params. If I > understood him correctly, then this should print "FOO" on standard out: DOH! All the examples were using @'s, and somehow that translated to "this is an array opthingy" :o > $foo ~> print <~ STDERR; That makes a fair amount of sense (and certainly more than any of my array-based flawed examples :) Thanks for clearing up my fogginess :o --attriel
RE: L2R/R2L syntax (was Re: Everything is an object.)
Note 1) This is the second time I'm typing this Note 2) Ctrl-Shift-Capslock apparently closes all current instances of mozilla ... that was weird > I'm not even sure how that would parse, though that: > @keep <~ grep /good/ <~ @list ~> grep /bad!/ ~> @throw; > would go like: > ( @keep <~ grep /good/ <~ @list ) ~> grep /bad!/ ~> @throw; > > which is probably not what i wanted... I would, from the descriptions, imagine that: @keep <~ grep /good/ <~ @list ~> grep /bad!/ ~> @throw; Would parse as: @keep <~ grep /good/ <~ @list; @list ~> grep /bad!/ ~> @throw; Due to that being what is almost always going to be intended, I think. Also, since we'd want $a <~ 2 + 4; to be $a = 6;, I would imagine that <~ and ~> would need low priorities. Further, since <~ stars at the end of the list and works its way left, it would need a lower priority than ~> which starts at the beginning and works its way right. So if it did have a parenthetical variation, I would imagine it would be @keep <~ grep /good/ <~ (@list ~> grep /bad!/ ~> @throw); Which is, still, probably not what you wanted. OTOH, I'm still new at posting here, and I may not be following all the bits that came before :o --attriel
Re: Variable Types Vs Value Types
> my Set of Apple $a; > my Basket of Fruit $b; > > and a generic assignment: > > $c = $a; > $c = $b; > > Now we can fill in your list (which is somewhat expanded): > AssignmentOK?Because... ======== my Basket $c = $a no $c's type: Basket (of Object) X ^ | | $a's type: Set of Apple my Basket of Apple $c = $aok $c's type: Basket of Apple ^ ^ | | $a's type: Basket of Apple Now, just to be sure I didn't miss a step: That second entry is wrong, sin't it? it should be OK? no b/c: C's Type : Basket of Apple X^ || A's Type : Set of Apple yes? (I'm trying to make sure I didn't miss a majikal mystery conversion step that seems contradictory but somehow exists anyway :o) --attriel
Re: L2R/R2L syntax (was Re: Everything is an object.)
>> I'm just suggesting the same for the ~ character:
>>
>> ~~ smart-match
>> ~concatenate
>> ~| stringy bitwise OR
>> ~> append args
>> <~ invocate
>
> This is where I get lost. I see 4 different concepts being overloaded
> onto '~'.
>
> In the first it indicates 'match' just as it always has for =~ and !~.
> In the second, it is being used for concatentation - nothing to do with
> matching. In the third it is being used to cast stringwisely - nothing
> to do with matching or concatenation. In the fourth and fifth it is
> being used to re-order arguments - nothing to do with matching,
> concatenation (well, possibly concatenation of argument lists) or
> stringwise casting.
Well, I always used =~ // for strings, and (from what I gather) ~~ is the
uber =~ in that it can figure out types and meaningfully guess what
"matches" means, so I see the first 3 as "string toys", just as the -- -
and -= were all "subtraction"
I'll give you that ~> and <~ don't do stringy things, though :) But I
think they'd be read, once it's more than theories in email messages ;o,
as single ops (like the ->) rather than "squiggly and arrow" it'd be
"squigglyarrow" ... I think the major concern would, to me, be that ~> and
-> are kinda close, visually, and I imagine nearly indistinguishable in
some fonts :/
> I would like to see '~' kept for matching and just matching. It is well
> known in this role and is analogous to the "roughly equals" operator in
> the Real World (extended ASCII character 247 - just don't ask me to type
> it).
Now you've given them ideas :) we're all gonna be typing ≈ (OK, so,
all I can get is that it's unicode 2248; still haven't figured out how to
ACTUALLY type it :o Alt-247() seems to be the wrong character though and
I don' see it anywhere on my HTML ascii chart :/
> I also think '_' should be used for concatenation because it's in
> keeping with the existing use of 123_456.
That actually reads like _ is a null character "This is not the character
you are looking for. There is no character, there is only zool" kinda
thing ... I know it's concat, but it reads more like a "visual separation
character that is COMPLETELY ignored by the parser, except insofar as to
explicitly ignore it"
> As a prefix character to indicate stringwise (numberwise, bitwise, etc)
> casting, can we not use a single character prefix, e.g. 's' for string,
> 'n' for number, 'b' for bitwise, 'v' for 'vector', and so on?
>
>$a s| $b;# stringwise
>$a b| $b;# bitwise
>$a n| $b;# numberwise
>@a v| @b;# vector
>@a vsn| @b; # vector stringwise bitwise
I think this was brought up during the operators thread (I admit, I only
skimmed it ... I had 6 or 7 versions in my inbox when I got to it :/) and
the "against"s pointed out that it would mandate whitespace separation
(although, some of the coders I know could live with some mandatory style
guidelines, ugh) ...
>> I mean, compare:
>> @a ~> grep {...} ~> map {...} ~> sort ~> @a;
>> with:
>> @a |> grep {...} |> map {...} |> sort |> @a;
>>
>> I don't know about *your* font, but in mine the ~> and <~ versions are
>> at least twice as readable as the |> and <| ones.
>
> In my font, or perhaps more importantly, to my eye, the |> and |< are
> more readable. But regardless, I think it's more important to make the
To me, for some reason, |> reads as a forward gate "Do not continue unless
the previous item was true; if it was, feed the result here" ... <|
doesn't read like much, and |< looks like some 1337 h4xx0r trying to be
cool, honestly :o It just looks broken! As an op, I would expect it to
translate to "OR Less Than" and I can't come up with how to use that "$a
== 7 |< 200" I guess :o
And would the consistency rules require them to be:
~> ~< ? so that the ops look similar? (If so, I'm gonna vote that ~<
looks like a fish and is just weird :)
--attriel
Re: L2R/R2L syntax (was Re: Everything is an object.)
> print sort { ... } <~ mymethod(42) <~ @b;
>
> call sort on what comezouta calling mymethod(42) on what comezouta @b.
> I think. Indirect objects are still somewhat confusing. :)
>
> If I'm reading the info right on <~, then we want to make it clear
> that you _don't_ put it between print and stuff you want to print, or
> in other words that "this ain't cout".
If I read the conversations right, I think that line is trying to do:
print (to stream mymethod(@b,42)) sort { ... }
I think to make it work like you wanted, you need ()'s
print (sort { ... } <~ mymethod(42) <~ @b); so that the <~ is directly
associated with the sort; otherwise sort is a param to the print, and
we're comezouta'ing the "where do i print sort"
and sort takes the "how do i sort" first and the "What do i sort"
second, yes? which makes me now wonder about all the sort { ... } <~
examples, and my understanding of the whole "where do <~ and ~> stick
things?" thing ...
OK, looking back, <~ binds to the "indirect object" ... and Damian's
examples use map { ... } and grep { ... } with <~'s, so I guess the
indirect object would work the same for sort { ... }, but now I'm not real
sure on what the indirect object IS in all these calls ...
Could someone explain how to know what's the indirect object? (who knew
the "sentence diagramming" would be USEFUL!!)
--attriel
Re: Arrays: Default Values
So ... with the discussion of "what if i really wanted to put an undef in there b/c it's not just that i haven't defined it but rather that it really isn't defined. I KNOW it's not defined, and i'm now explicitly saying it's undefined as opposed to before when i was implicitly suggesting that i didn't know what it was and used a default 'unknown'" discussion ... What we really need is: @a[2] = undef but undef; or, possibly (more tongue-in-cheek-y) @a[2] = undef but seriously; so the ... property? would say "you have a default, maybe, but i don't care. this is REALLY undef" is that possible? aside from it being disturbing to write "undef but undef" :o --attriel (the first suggestion is serious, but the syntax is flawed; the second suggestion has better syntax but is tongue-in-cheek suggested ... )
Re: Arrays: Default Values
> Solution 1: If you attempt to SET a cell to it's 'empty value', it
> will be set to it's default:
>
> my int @a is default(5); #
> @a[5] = 0;# actually sets it to it's 'empty value',
>
> 5
> @a[5] = undef;# autocnv to 0, + warning, still sets to
> 5
>
> my Int @a is default(5); # NOTE difference in type!
> @a[5] = 0;# THIS really does set it to 0
> @a[5] = undef;# and this sets it to 5
>
> So you can't set something to its type's own empty value, because it
> will, by definition, thereafter return it's "overloaded" empty value,
> .
> -
>
> In spite of the perhaps surprising nature of solution 1, I think it is
> probably the more correct solution, if you really insist on putting a
> default value on a primitive-typed array. As it points out, you can
> still get both behaviors, simply by choosing int vs. Int, str vs. Str,
> etc.
OK, it sounds reasonable to me, for those cases where the 'empty value' is
undef ...
but if I have an array of #s ...
I have the list of people I invited to my wedding.
I default the # of people attending to 2 (inviting couples or "& Friend") ...
Joe responds, he's coming alone (ok, so i set him to a 1)
Karen is bringing her kids (so 4)
Fred can't come. That's a 0. Which is a 2. But he's not coming, so the
2 is really a 0, but I can't say 0, b/c 0 is "empty" and becomes "default"
2 ...
Likewise for strings. I default it to explicitly say "UNKNOWN" so I know
what's not known, but now when I find out it doesn't exist ("What's John
Doe's middle name?") I can't say that. The answer then is "UNKNOWN" so
"John Doe" became "John UNKNOWN Doe" due to a flawed (IMO) functional
limitation ...
This is also why i (somewhat facetiously) suggested "undef but really",
although it doesn't help in this case b/c I'm wanting to set it to 0, and
saying "attendees[23] = 0 but really" looks wrong ... so maybe the "but
really" would be for setting to default ('empty value') if you had need
and used it in assignment (but undef @attendees[23] would, i think, still
make it 'empty val' b/c i'm not assigning a value to it, i'm unassigning
the value I've given it, which is a distinction that I think may be
relevant ...)
--attriel
Re: newline as statement terminator
>> I don't mean to be abrupt here, especially seeing as how this list has
>> been so patient with some of my ideas but... PLEASE NO. The rules you
>> suggest for keeping track of when a semicolon is required sound more
>> confusing than the simple rule of "end of statement, put semicolon".
>
> As Luke Palmer said, in perl6, semicolon is a statement separator not a
> statement terminator. So there is no such simple rule in Perl but you
> are free to imposit it on yourself. Perl allows it but it does not
> requires it.
Er. What is the difference between a "statement seperator" and a
"statement terminator" for the majority case?
Seperator means I can leave off the last one in a {} b/c there's no
following statement ... But is there any other place I can "optionalize"
the ; by calling it a seperator vs a terminator?
I like having ;'s at the end of my bits, b/c then I know where a line
ends. When someone's pasting me bad (and I mean BAD) perl5 code, I like
having those ;'s there to tell me what ended where, since (The case i'm
thinking of offhand) was doing a print qq|| that printed out a BUNCH of
things and then ended with an if .. that ; was important b/c I kept
thinking hte if was part of the next line (it was on a seperate line,
making it even more fun)
Yes, this would make that program entirely not work, but I'm sure the new
version wouldn't be much prettier since there'd be no ;s at all
>> I like to break up my long statements in all sorts of arbitrary
>> places, and adding the worries of when a newline might be significant
>> puts a knot in my stomach just thinking about it (literally).
>
> I agree that be obliged to check the next line to see if the newline is
> or is not a statement terminator is not the nicest thing.
lookahead parsing is tolerable in a compiler, but in an interpreted/jit
environment, I'd HATE for my code to change meaning b/c i forgot a \n ...
esp if it's in generated code ... e
> On the other hand, if the programmer is correctly indenting the program
> it should stand out that the next line is part of the courant statement.
>
>
> print "---" # must read the next line to
> # figure out if new line is statement terminator or
>if $condition";
>
>
> Here indentation is a mere clue but has no syntactic meaning.
So, is the indentation required as a parser-hint (ewww, I hated mandatory
indents in fortran, and I can't see any good reason to bring them back;
stylistically I still think they're mandated, but not dictated by the
language) or is it just there to help people ?
And why is there a "; there? i presume the " is a typo, but since this
whole discussion is getting rid of the ;, I cna't see why it's there ...
Summary: ;'s good, indentation necessary but not parser-graphically
dicatated :o
--attriel
(parsergraphically?)
