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: 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: 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?)
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,
def.
-
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: 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: 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: Variable Types Vs Value Types
HUGE chungs of stuff cut 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 #8776; (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 againsts 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.)
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: 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 CInts, as CInt is a subclass of Cint (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
