Mutating methods
Perlists, In Perl 5, lc, lcfirst, quotemeta, uc and ucfirst don't mutate. chomp and chop do mutate. I imagine these will all be methods in Perl 6: $foo.lc $foo.quotemeta $foo.chomp I'd like a mutating version of lc, and a non-mutating version of chomp. With some nice syntax, if possible. If there isn't already such a thing in the making, I hereby suggest to re-introduce C.=, to mean more or less the same as in Perl 5, but with Perl 6's version of the C. operator. In other words: C$foo.lc would not mutate and C$foo.=lc would. $foo += 5 === $foo = $foo + 5 $foo.=lc === $foo = $foo.lc Makes sense to me. Especially for Csort it would be nice for something like this: @foo.sort # returns sorted copy versus @foo.=sort # sorts inline I think this syntax reads better than Ruby's exclamation point (foo.method!), because of the analogy with other mutating operators. Please excuse me if this or something like this has already been taken care of - I've searched for messages about it, but haven't found anything. Regards, Juerd
z ip
Kara Perlistoj, the zip operator is a useful one. I like it a lot. But I've been writing zip() all the time, even though I think an infix operator is nicer. (Not for for though, because you also have commas in the pointy sub's parameter list.) However, the broken bar is in my opinion a bad choice. As some have pointed out, because the similarity with |. Historically, 1, l, I and | have always aided in obfuscation. Adding a(nother) broken bar to it would be a mistake. One obvious reason for reaching out to unicode characters is the restricted number of non-alphanumeric characters in ASCII. But why do infix operators have to be non-alphanumeric? It has never been a problem for 'x', has it? And with Perl 6 we even get an infix xx operator. I think the ?(yen) suggestion is great, especially since it does indeed look like a zipper. Still, I would very much like an ASCII infix alternative for zip(). I propose z as the ASCII alternative for the infix zip operator (either broken bar or yen). With some imagination, it is a good candidate for representing interleaving. Besides that, zip() starts with a z so it is easy to remember even if you don't think it looks like something that zips. Regards, Juerd
Re: Dereferencing Syntax (Was: Outer product considered useful)
Larry Wall skribis 2004-03-25 12:33 (-0800): On Thu, Mar 25, 2004 at 11:35:46AM -0800, Brent 'Dax' Royal-Gordon wrote: : Larry Wall wrote: : say @bar.elems; # prints 1 : Csay? Not Cprint? It's just a println spelled Huffmanly. What happened to the principle that things that work similarly should look similarly? I dislike having another method/function/whatever to do exactly the same thing, yet a little different. That is PHP's niche. Can't we instead just have a pseudo-filehandle or perhaps a tied one and just use Cprint to print? ln.print @bar.elems; print ln : @bar.elems; Though I'm not sure why a feature like this would be needed at all, so I think this is something users should define something like this themselves if they want it: my say = print.assuming :ors \n; (Wildly guessing syntax here. I cincerely hope parens won't be needed.) I think I prefer things the way they happen to already be. print @bar.elems, \n; Also, I think Csay is a bad choice. Many people use a function called Csay for chat bots and text-to-speech. It will of course be possible to override the builtin, but for a good reason most people choose to not do that. Has this Csay already been decided? Juerd
Re: z ip
Piers Cawley skribis 2004-03-29 16:33 (+0100): You'll really confuse the deep functional programmers if you do that, for whom the term 'Y operator' means something very different Probably, but is that a good reason to not use it? Many Perl 6 things will already really confuse Perl 5 programmers; why should programmers of languages that aren't even Perl be treated differently? Juerd
lists and arrays
Hi, I'm lost. I read some Perl 6 related things and think I missed an important announcement. What is a list reference? It is as if lists and arrays are the same thing in Perl 6, but other documents use the words as they are used in Perl 5. So I guess my actual questions are: What is an array? What is a list? Regards, Juerd
Re: Compatibility with perl 5
David Cantrell skribis 2004-04-13 13:16 (+0100): Perl 6, we are promised, will try to run legacy code unchanged. How will it spot such legacy code? Doing this reliably is a hard problem, but we can make it easier. I suggest that people put: use perl5; Why change what already works? use 5; no 6; It could be a special case: not throwing a fatal exception, but instead changing the grammar to a Perl 5 compatible one. Juerd
backticks
Perl 5 has the qx// operator which does readpipe. I believe the function
for it was added later. (It doesn't handle a LIST as system does,
unfortunately.) qx// is also known as ``. Two backticks.
readpipe/qx/`` isn't used much. In all my @INC, only a handful of uses
can be found. Most are in Debian's modules.
Why should readpipe get to cheat on the huffman thing?
I think even qx// is too short for something that is almost never used
and is actively discouraged because interpolating values in shell
command lines is dangerous.
There is something that is used much more often than readpipe, and it
was recently made harder to type. Hash subscripts. %hash{'key'} works,
%hashkey does too, but they're both a lot of typing. I never liked
typing the {} anyway, and now there is even more to type. Don't get me
started on «», which doesn't even get rendered with my current terminal
settings, and is 8 key presses in total.
In Javascript, arrays are objects, objects are arrays. The . operator is
the same one as [], except you can use an expression in [].
parent.frames[1].document.forms['login'].elements['password'].value
equal:
parent.frames.1.document.forms.login.elements.password.value
I like that a lot, because it saves a lot of typing and in simple cases
actually makes reading the code easier. Template Toolkit also lets you
use hashes like this.
[% hash.key %]
However, there is an obvious clash when some bareword is both an
existing key and an existing method. I'd have to look up or try to see
what in TT [% hash.keys.5 %] does if hash.exists('keys') and it is an
array reference.
I propose to use ` as a simple hash subscriptor, as an alternative to {}
and . It would only be useable for \w+ keys or perhaps -?\w+. As
with methods, a simple atomic (term exists only in perlreftut, afaix,
but I don't know another word to describe a simple scalar variable)
scalar should be usable too.
%hash{'key'}
$hashref{'foo'}{'bar'}{'baz'}{'quux'}
%hash{$key}
$object.method.{'key'}
can then also be written as:
%hash`key
$hashref`foo`bar`baz`quux
%hash`$key
$object.method`key
With some imagination, this can also be used for arrays. That would need
to allow the key to have /^-/ and it poses a problem with hybrids like
$0. Normally []/{} decides whether it's a hash or array dereference, but
for this easy-to-write thing a /^-?\d+$/ should be doable. After all, []
and {} are still available if you need to be explicit.
$0`15 # $0[15]
$0`alpha # $0{'alpha'}
With even more imagination, but I still think it would be a good idea,
this can also be hijacked by the :foo pair constructor, to quote a
single simple bareword.
key = 'value'
:key('value')
:key`value
use Some::Module :foo :bar :baz`quux :xyzzy;
In case it was not already obvious, I'd like to stress that I'm not
proposing to use ` as something that is balanced. It's unary.
Apocalypse 2 says about the unbalanced ' in Perl 5:
And although we're adding a properties feature into Perl 6 that is
much like Ada's attribute feature, we won't make the mistake of
reintroducing a syntax that drives highlighting editors nuts. We'll
try to make different mistakes this time.
I disagree. It's not as if many editors will handle $foo{bar}
correctly out of the box. I can't even imagine a way to make that look
nice. So let's just have this autoquoting, method-ish `, please. Hashes
are used a lot in Perl and ` is in an extremely easy to type place.
It's a shame to give away that beatiful key to readpipe if you can use
it for hashes instead.
I think %hash`key makes sense. But I'd like to find out if more people
like this idea.
Juerd
Re: backticks
chromatic skribis 2004-04-14 12:07 (-0700):
I think %hash`key makes sense. But I'd like to find out if more people
like this idea.
How do you request a hash slice with backticks?
You don't. There are %foofoo bar and %foo{'foo', 'bar'} already and
hash slices aren't used much at all.
The proposed ` is very much like the . that is used for calling methods.
Except for the possible leading minus, it can probably be parsed exactly
the same (i.e. allowing :: too, as Matthijs' implementation also
does).
It is also much like the way single elements work in Perl 5, except that
you can't use an expression. (i.e. where $hash{+shift} uses the shift
operator, %hash`shift would get value of the pair that has the key
'shift' and %hash`+shift would be a syntax error -- there is already
%hash{shift} for that and this too isn't used as often as literal string
keys.
Main purposes of ` are typability and readability. Anything that allows
more complex operations would require less readable syntax if used with
the backtick. Only simple literal strings (valid identifiers, but being
able to start with a digit or minus) and simple scalar variables (the
thing perlreftut calls atomic) like $foo can be used.
Juerd
Re: backticks
chromatic skribis 2004-04-14 12:32 (-0700):
That's exactly my objection to this idea. I think it goes too far to
make simple things simpler while making complex things impossible.
Absolutely false.
This is an addition to the already existing {}, which should stay.
%foo{ something } will still be necessary if:
* the key is the result of an expression
* you want a slice
* the key is not a string
* the key is a string that isn't simple enough (i.e. contains \W in a
way that isn't supported)
I really don't want to explain why there are two hash key access
mechanisms, one that only works for single keys that match a very
simplified regular expression and one that works for one or many hash
keys with no restrictions.
There are already two. One that works with expressions and one that
works for one or many hash keys as long as they are literals.
%foo$bar doesn't quite do the same as %foo{$bar}.
Simplicity is good, yes. Huffman coding is also good. But you have to
balance them with consistency of expression, usage, and semantics.
I agree.
I don't think this proposal does the latter.
I disagree.
On the other hand, if you prod Luke Palmer, he can probably write a
macro to make this syntax work for you in under ten minutes and three
messages. In that case, it may not be a core feature, but you can have
it for very nearly free.
Or I could use something that modifies the grammar Perl uses. Almost any
syntax feature can be added outside the core. I'm not exploring the
possibility of this operator, but suggesting that it be in the core.
This operator is possible, improves readability, eases typing and does
not clash with something that already exists.
Yes, it does mean learning the meaning of one more character. I think
every programmer is able to cope with that. Even beginners.
Juerd
Re: backticks
John Williams skribis 2004-04-14 13:36 (-0600):
On Wed, 14 Apr 2004, Juerd wrote:
I propose to use ` as a simple hash subscriptor, as an alternative to {}
and . It would only be useable for \w+ keys or perhaps -?\w+.
As with methods, a simple atomic (term exists only in perlreftut,
afaix, but I don't know another word to describe a simple scalar
variable) scalar should be usable too.
%hash`$key
oops, you contradicted yourself here. only be useable for \w+ keys
Oops, part of my message wasn't read as it was intended. $key is a
simple atomic scalar and should be usable too.
Just like how $object.$method works, %hash`$key should too.
$0`15 # $0[15]
$0`alpha # $0{'alpha'}
You are repeating the errors of javascript. $0[15] != $0{15}
After all, [] and {} are still available if you need to be explicit.
Javascript's error (design) is that it has only [] and no {}.
I think I would prefer something more intuitive, like :baz=quux
That reads to me as assigning the result of quux() to a pair that has
the value 1. To avoid that it reads like an assignment, = could be
used:
:bar=quux
But ehm, then there's not much point anymore, as
bar = 'quux'
already does the same and is much easier to read.
Any [^\w\s] character could be used there unambiguously, and = has the
already existing parallel with command-line args, but ` is just an unused
character.
Command line arguments (assuming a specific kind of parsing) also
use -- instead of : and have
and ` is in an extremely easy to type place.
... on a us/english keyboard ...
On a US keyboard (qwerty/dvorak), it's in the upper left corner. Very
convenient indeed.
On German and Danish keyboards, it is the key left of backspace,
shifted. This sounds terrible, but not quite as terrible as Alt Gr plus
7 and 0 respectively.
German/Danish keyboard has:
/ ( ) = ? `-- Shift
7 8 9 0 sz '-- no modifier
{ [ ] } prc \-- Alt Gr
On Dutch keyboards (that aren't used much, but do exist), it is two keys
left of Enter. It also requires the awkward Alt Gr for { and }, but in
better positions:
- ( ) '-- Shift
7 8 9 0-- no modifier
pnd { }-- Alt Gr
H J K L plm `-- Shift
h j k l + '-- no modifier
With whatever keyboard Matthijs uses, the ` is right of the left Shift.
So that's already 6 keyboard layouts in which ` is much easier than {}.
It appears French keyboards have { as Alt Gr + 4 and } all the way over
on the right side, as Alt Gr + =. It has ` as Alt Gr + 7. But this
layout looks terrible for any typing, natural AND programming languages.
http://www.datacal.com/dce/catalog/french-layout.htm
If on your keyboard ` is in a worse place than {}, I'd like to know
where it is.
Juerd
Re: backticks
Scott Walters skribis 2004-04-14 13:12 (-0700):
Second, autovivication is impossible for the same reason. We can't tell
from parsing this lone expression whether baz should be converted to numbers
or strings automatically.
I want ` for hashes in the first place. Having it for arrays too would
be nice, but it isn't as important to me. Having seen some international
keyboard layouts, I think others may find not having to type [] very
useful.
Autovivification of elements is not a problem for pure hashes and
arrays. Autovivification of references (as in my $ref; $ref`aoeu) and
elements of hybrid arrayhashes (like $0) is also not a problem if you
use the ^-?\d+$ rule to decide. Again: if you need to be explicit, you
still can.
So I'm not sure where it is a problem. Even if deciding based on the
value isn't good and for autovivification you default to hashes, the `
would still be a welcome addition.
If you can't remember what a data structure looks like, it doesn't matter if
the code spells out the sequences of hash-array-hash each time - you're
going to spell it out wrong. People new to Perl and new to data structures
have this problem all the time - they can't keep straight what the data structure
*is*.
That, and not many hashes have \d+ keys. When they do, you can just use
{} to make sure things are interpreted the way you want them to be.
actually go one further and coopt the . operator and emulate JavaScript more
closely, but I admit the visual distinction between method calls and subscripts
might warrent the noise.
It's not just the visual distinction, but also to let the parser know.
If I understand correctly, hashes and arrays will have many methods of their
own. I don't want %hash.keys to be interpreted as
%hash{'keys'} and I do want to be able to use the easier syntax when my
hash does in fact have a key 'keys'.
Juerd
Re: backticks
Matthew Walton skribis 2004-04-14 21:23 (+0100):
%foo$bar doesn't quite do the same as %foo{$bar}.
That's one method, really - being like {' '}, and really just
carrying on the very familiar idea of different kinds of quotes. Like '
and .
The thing works as if there is an implicit {} around it: is
an alias for qw.
doesn't interpolate. Its insides are string literals separated by
whitespace.
«foo» is 13 key presses, foo is 9 key presses, {'foo'} is also
9, `foo is only 4.
(using vim's ^K and counting keys, not characters. That means shift and
ctrl DO count)
The ` idea is completely different.
Fortunately so.
Also, ditching `` quotes strikes me as a fairly dreadful idea.
Because you're used to them. You're also used to many other things that
change when you go from Perl 5 to Perl 6.
If you dislike when symbols get to mean different things, reading about
Perl 6 must be a terrible experience for you.
Yes, I could use qx// instead, but I could also use qq// instead of
.
If it were up to me, qx would also be removed from the language and only
readpipe would be left.
Ultimately, ` looks like an opening quote character, and so people will
expect it to behave like one. I think that violates the principle of
least surprise.
Least surprise is important for constructs that aren't used
continuously. Whatever is used throughout people's source code,
*defines* what people expect and is therefore after seeing it for the
first time no longer a surprise.
Some people say {} looks like a code block, and that so people will
expect it to behave like one. However, Perl 6 also uses it for hash
reference constructing, hash subscripting, alternative delimiters, rule
blocks, and perhaps even other things.
Perl 5 and PHP coders will expect . to be concatenating, - to be
for calling methods. What people expect because they are used to other
programming languages does not matter at all. The language should be
a consistent universe within itself. If THAT it is not, you are
violating the principle of least surprise.
Believe me, any non-Perl-6 coder will be surprised when seeing Perl 6 in
action. And that is a good thing.
Juerd
Re: backticks
Randal L. Schwartz skribis 2004-04-14 13:56 (-0700): Juerd == Juerd [EMAIL PROTECTED] writes: Juerd readpipe/qx/`` isn't used much. In all my @INC, only a handful of uses Juerd can be found. Most are in Debian's modules. That's because they aren't particularly interesting in modules, but in 10 line scripts, they show up quite frequently. This undermines the rest of your request. How unfortunate that you didn't notice that I made two separate requests, that both have to do with backticks. Request one: Remove `` and/or qx, because its interpolation is dangerous and solutions like it should be discouraged. Request two: Add %hash`key %hash`key can exist without `` gone. `` can be removed without ` meaning something else. It would, however, for understandability, be nicer if both requests were granted. Please, re-read my post and comment on the second request as insightfully as you did on the first. Juerd
Re: backticks
Chris skribis 2004-04-14 17:07 (-0700): Perhaps this is naive, but couldn't something like this be achieved in a manner similar to how I just implemented it in Ruby? Surely Perl will have similar capabilities to handle unknown methods. As explained in [EMAIL PROTECTED], it's not a question of whether it is possible. I know it is possible. Either by changing the grammar or perhaps by adding an operator/macro. And as explained in multiple messages already, implementing this using the . has too large drawbacks. Juerd
Re: backticks
David Storrs skribis 2004-04-14 22:39 (-0700):
Very top row, one space right of the F12 key. Extremely awkward.
(This is a US keyboard on a Dell Inspiron 5100 laptop.)
That is inconvenient.
1) ` looks like it should be a bracketing operator
I think you means circumfix/balanced operator.
2) In some fonts, ` is hard to see.
3) In some fonts, ` is hard to disambiguate from ' if you can see it.
In some fonts, the difference between () and {} is hard to see.
In some fonts, the difference between 1, l and I is hard to see.
In some fonts, the difference between 0 and O is hard to see.
In some fonts, the , is hard to see.
In some fonts, and '' look exactly the same.
Don't use those fonts when programming, period. Use a fixed width font.
No fixed width font that I have ever seen makes ` hard to see.
4) This argument has not been made strongly enough (...)
I'm not here to do anything weakly, strongly or forcefully.
5) I use `` in short utility scripts all the time, and would hate to
lose it. To anyone who says that that is dangerous and should be
discouraged--my machine, my code, my problem. (And I work for
myself, so I am the only one who will be maintaining it.)
As said in several messages in this thread before, `` does not have to
go to support %hash`key. %hash`key has already been succesfully
implemented in perl 5.8.3 and does not harm `` there at all.
Actually, what I'd like to know is when it was decided that %hash{key}
meant %hash{key()}?? Was it in one of the Apocalypses? I missed that
and would like to go back and read the reason for it, since I suspect
that, given a single-term expression in a hash subscript, it is far
more likely to be a literal than a function call. It seems that that
is really the source of the entire 'problem' that this thread
addresses.
No, it only was an extra motivation.
Juerd
Re: backticks
Aaron Sherman skribis 2004-04-14 16:40 (-0400):
From a source tree I work with (which I cannot divulge code from, but I
think statistics like this are fine):
$ find . -name \*.pl | wc -l
330
$ find . -name \*.pl -exec grep -hlE 'qx|`|`|readpipe' {} \; | wc -l
123
How many of those backticks are in documentation or string literals? In
my @INC I found a lot of attempts to get balanced single quotes in ASCII
as like `foo'.
And how often are simple hash subscripts used?
Also, how insecure and/or inefficient is this code? In #perlhelp, on
PerlMonks and in many other places, backticks are discouraged.
operators, and I see qx{} as just as good if not better, but to remove
it on the basis of the lack of use is faulty.
Removing and replacing the meanings of glyphs on the basis of use is
one of the most important changes in Perl 6.
After all, - becomes . and - gets a new meaning.
| becomes +| (or ~|, ?|) and | gets a new meaning.
Etcetera.
Lack of use as a reason for changing something is not faulty, it is
exactly what should be done.
BUT `` do not have to go because I have ` in mind for something else.
The two things can co-exist, as Matthijs pointed out with his Perl 5
patch. I think it has to go because `pwd`, `hostname`, `wget -O - $url`
should not be easier than the purer Perl equivalents and because ``'s
interpolation does more harm than good.
I would have preferred that Perl 6 used the bash/zsh-style:
$(...)
It's just one keyword and a set of quotes more: $( readpipe pwd )
Juerd
Re: backticks
Aaron Sherman skribis 2004-04-15 14:29 (-0400): On Wed, 2004-04-14 at 16:56, Juerd wrote: How many of those backticks Note, those weren't backticks, those were programs. There were 123 PROGRAMS that used backticks or equivalent syntax. I said backticks, and I meant backticks. I'm not sure why there is confusion over this. Perhaps this can disambiguate: how many of those backticks in those 123 programs. And how often are simple hash subscripts used? Very often. Many times as often as qx and friends? Security is not an issue for this code. It should be. code review? You made and assertion: backticks aren't used much. That assertion is faulty. I didn't formulate my statement carefully enough. I should have said: as much as hash subscription. Executing external code is commonplace, and probably done more often than method invocation in the wild! I want to doubt that. Or better: help change that. It's just one keyword and a set of quotes more: $( readpipe pwd ) And thus, it is not like the bash/zsh style syntax in the least. Why should Perl have to limit itself to shell-like syntax? It doesn't do that with if-constructs, foreach-loops, procedures, etcetera, etcetera, etcetera. Unless there is substantially new information in this thread, I think you have presented your case for yet another new subscripting syntax. I think I have presented two cases. The removal of `` and the introduction of %hash`key. Either can be implemented without breaking the other, though I obviously think both letting `` go and introducing the infix ` is better. Juerd
Re: backticks
Mark J. Reed skribis 2004-04-15 16:49 (-0400): If I might offer a modest counter-proposal - how about a fallback method (the equivalent of Perl5's AUTOLOAD or Ruby's method_missing, however that winds up being spelled in Perl6) that would return the value of the key equal to the requested method name? No, please not that. When there is a bareword that is both a key and a method, one of the two has to get precedence. Neither option is acceptable and both render using the . for the thing that does not get precedence useless. Option one: methods get precedence Code breaks when methods are added. Option two: keys get precedence Would have to delay everything until runtime. No, if we want a simple and lean operator for this, it must not be one that in the same context also has another function. Juerd
Re: backticks
Dave Mitchell skribis 2004-04-15 21:56 (+0100):
If hypothetically we *are* going to have a simplfied constant-index hash
access syntax, is there any reason why we can't use a single quote (')
rather than backtick ('), akin to the Perl4-ish package separator,
ie %foo'bar rather than %foo`bar?
Yes, there is one. It is a problem that the Perl4-ish package separator
causes in Perl 5 already. One that bites many coders:
Eat at $joe's
means in Perl 5:
Eat at $joe::s
would mean in Perl 6 if we used the ' for hash subscripts:
Eat at $joe{'s'}
Apostrophes are needed in text. Many languages use them to mark the
absence of some letters. I don't know of any such use of the backtick,
except by people new to computers who use them as if they are
apostrophes :)
I dislike the attempt at getting balanced quotes in ASCII that involves
` and ', but it shouldn't be a problem as that in normal use always
follows whitespace or at least interpunction.
On the grounds that personally I hate the backtick :-)
...
Juerd
Re: backticks
Austin Hastings skribis 2004-04-15 18:09 (-0400): If we're going to entertain alternatives, why not use % as the hash subscriptor? To borrow from another thread: %foo%monday%food = 10; %foo%monday%travel = 100; %foo%tuesday%food = 10; %foo%tuesday%travel = 150; There is as far as I know no technical reason to not do this. But I do dislike fat operators without whitespace. I dislike that as much as I would dislike using whitespace around a subscripting operator. This has the advantage of ensuring that the hash-marker [1] appears in every hash reference, and doubles up on the path weight of a single character, for really good Huffman. %foo is a hash. When I see %foo%bar, it feels like that should be a hash too. Besides that, $foo%bar looks funny and @[EMAIL PROTECTED] does so even more. Not to mention @[EMAIL PROTECTED] I like ` because it's a small but recognisable glyph. (And because of its location on most keyboards.) Juerd
Re: backticks
Austin Hastings skribis 2004-04-15 18:38 (-0400): $foo % bar % is 4 keys: space, shift, 5, space. Too much, IMHO. Typability and readability are both VERY important. Juerd
Re: backticks
Brent 'Dax' Royal-Gordon skribis 2004-04-15 16:56 (-0700):
1. Allow %hashfoo to be typed as %hashfoo. There would be a
conflict with numeric less-than, but we can disambiguate with
whitespace if necessary. After all, we took the same solution with
curlies.
Curlies which, as said, I also don't like typing.
On a US Dvorak or QWERTY keyboard,
{'foo'} is 9 key presses and 7 characters
foo is 9 key presses and 7 characters
foo is 7 key presses and 5 characters
`foo is 4 key presses and 4 characters
Also important when picking a character is its glyph. ` is light weight,
like the . that we use for methods. I don't want whitespace around this
operator, so the operator must not be fat, like %, @ or #.
The biggest deficiency with the two syntaxes that are already there is
that they both use a pair of characters. That is needed because for some
reason every syntax apparently needs to support every feature that Perl
has. That is: slices.
I do not use hash slices often enough to use the arcane syntax all the
time. I like bracketing delimiters for code blocks and for lists of
things. They are not something I wish to type every line.
I dislike XML and HTML because they're a lot of typing (not only because
of the redundancy in the closing tags).
Perl 6's leaving out the parens with if/foreach/while/until is a very
good step in the right direction.
Compare:
$foobarbazquux
$foo`bar`baz`quux
In fact, I encourage everyone to type the above two lines a few times.
2. Allow barewords in curlies as a special case. We're already allowing
them on the left side of = (I think), which is even more ambiguous.
Same problem, and it would mean reversing an earlier decision that in my
opinion was a sane one.
It would require some character to disambiguate again, or you have the
unquoted strings that Perl 5 has, but restricted to hash usage. Adding a
sub or method that happens to have the same name as a hash's key should
not break any code.
3. Define hash indexing with a pair to index on the key. This would
allow the syntax %hash{:foo}. (This could even be achieved by making
C~$pair eq $pair.key.)
{:foo} is 8 key presses. A too small step to be worth anything in
practice.
4. Define a bareword-quoting prefix operator (i.e. one that turns the
next \w+ into a string) and use the normal hash indexer, {}. I have
no suggestion for this operator's name, although if you wanted to rip
out the current unary backticks, it could be a candidate:
%hash{`key}.
Same as 3, but with another character.
Juerd
Re: backticks
Austin Hastings skribis 2004-04-15 19:37 (-0400): I'm sure that if Juerd or someone were to write a PublicHash class, they would cleverly reverse the access so that some collision-unlikely path would get the methods. I'm sure I have explained several times already why I think using the . operator for this purpose is a bad idea. Juerd
Re: backticks
Sean O'Rourke skribis 2004-04-15 8:55 (-0700):
[EMAIL PROTECTED] (Juerd) writes:
I think it has to go because `pwd`, `hostname`, `wget -O - $url`
should not be easier than the purer Perl equivalents and because
``'s interpolation does more harm than good.
I have to disagree with you here. The Perl way is not always the Perl
way -- the beauty of Perl is that it makes it as easy as possible to
take advantage of existing tools. Sometimes this is best done with a
foreign interface like XS, but sometimes it's adequate and easier to
simply shell out and collect the output. I don't see purity as a
good motive here; in fact, rigid purity makes languages like Java and
Smalltalk somewhere between frustrating and useless.
Yes, executing programs should still be easy. But it doesn't happen
enough to give away the beatiful backticks, in my opinion. And the
backticks encourage interpolation.
I find that there are still plenty of contexts in which `` is nice and
security is irrelevant.
This is the second time in this thread that I read about security being
unimportant. I still don't know what to say about it, though I feel like
ranting.
Of course, I'd be fine with the slightly longer qx{}...
IMHO, best would be to have only readline (which should take a
system()-like LIST!), and I think qx is acceptable. But `` is too nice
to sacrifice, and makes it too easy to not think about security.
Probably you know when you can use qx safely, but many, MANY people out
there have no clue whatsoever and use qx with interpolation *because* it
is easy.
Juerd
Re: backticks
Brent 'Dax' Royal-Gordon skribis 2004-04-16 0:25 (-0700):
Number of keystrokes isn't our only concern here. This is Perl, not
APL--we care about the size of the language and its intuitiveness too.
(Perhaps not much, but we do.)
Not the only concern, but to me, it is as important as readability.
I don't like %hash{'foo'} because it's ugly. I don't like %hashfoo
because it's ugly and adds syntax. I don't like %hash`foo because it's
ugly, adds syntax, and looks nothing like an indexing operator. (I'll
revisit this third point soon.) I think it will be easier to fix
%hash{'foo'} or %hashfoo than %hash`foo.
I have no doubt that between fixing existing things to make them nice
enough to use very, very often and just implementing %hash`foo, the
latter is by far the easiest to do.
It's also worth noting that, except for Javascript, every language I can
think of uses paired characters for indexing. Perl 5 uses {} and [];
the C-like languages I know use []; Visual Basic (ugh) uses ().
Template toolkit uses a . for methods, indexes and keys. It's great for
indexes. It's not so great for keys when there is a key that has the
same name as one of the virtual methods.
Also, other languages are irrelevant, except for inspiration.
Perl 6 mustn't be a copy of existing languages. It must be BETTER.
I thought that to make Perl a better language than all the other
languages, we were supposed to be open minded about new ideas. But
instead, many of the perl6-language subscribers keep referring to
existing non-Perl-6 languages.
I dislike XML and HTML because they're a lot of typing (not only because
of the redundancy in the closing tags).
I'd be inclined to agree with you. But we're talking about *one*
*extra* *character* here. That's two keys. It's hardly the end of the
world.
One extra character, two keys. EACH time. Still indeed not really a very
big problem. However, bracketing operators are very heavy, visually.
Unconsciously, you're matching them, counting them, seeing them.
But do note: I think %foo{EXPR} and %fooWORDS are perlfect and can stay
if %foo`key is implemented. I am not suggesting removing or changing {}
and . (Although I wouldn't mind seeing go.)
If the inside of a hash indexer consists entirely of \w characters, it
will be interpreted as the name of a hash key. If you want it to call a
subroutine instead, add a ~ stringifying operator to the beginning of
the call, or a pair of parentheses to the end of it. Simple, clear,
and doesn't shift around based on subroutine definitions. (It's not
what Perl 5 does, but that's Perl 5's fault.)
That looks to me like exactly what Perl 5 does, except you use ~ instead
of +.
It looks better to me and doesn't add any syntax.
It adds one hell of an ugly special case for the :pair syntax.
To make my position clear: WE DO NOT NEED THREE WAYS TO INDEX A HASH.
We don't even NEED two!
We don't need convenient aliasses in regexes.
We don't need threads.
We don't need lexical variables.
We don't need junctions.
We don't need any dwimmery.
But please, let's write Perl 6 instead of another Java-wannabe.
We don't NEED anything except zeroes and ones.
But all these nice features are damn nice to have!
I don't really think we need two. All we really need is one way with a
good enough syntax to meet all of our needs.
Or three syntaxes of which you can choose, depending on what you mean
and like to write.
I thought Perl minded people were used to TIMTOWTDI, but I'm proven
wrong once again.
Juerd
Re: backticks
David Wheeler skribis 2004-04-16 9:58 (-0700):
for @thingies, qw(blue yellow) xx Inf - $thingy, $class {
print qq[tr class=$classtd$thingy/td/tr\n;
}
I think that $class would be Cundef after the second record in
@thingies, unfortunately.
Even with the xx Inf? Why?
Juerd
Re: backticks
Aaron Sherman skribis 2004-04-16 9:52 (-0400):
3. You proposed (late in the conversation) that both could co-exist, and
while that's true from a compiler point of view, it also leads to:
`stuff``stuff`stuff
Huh? No. That is a syntax error.
$a`a=$a`b~`a` # Try to tell your editor how to highlight that!
Try to tell your editor how to highlight:
print $foo{ / (\d+) { $1 eq 10 or $1 ~~ /5/ and fail } / ?? $1 : };
Better hurry, because it (or something close to it) will soon be valid
syntax.
Also, try using sane spacing and then having confusing syntax.
`$a`b`c` # May or may not give an error, but shocking either way
Syntax error.
One of the things that I absolutely despise about auto-quoting is that I
keep running into the second most popular reason for code ugliness:
$x`y = 1;
$x{y} = 1;
$x`z = 2;
$x{z} = 2;
$x{a b} = 3; # Ooops, can't use ` for that one
$x{a b} = 3; # Oops, can't use unquoted string for that one.
In this case, you should probably have used {} for each of the options.
Most hashes are there mainly to keep a bunch of variables organized, and
let me show you something else:
$y = 1;
$z = 2;
${a b} = 3; # Oops? No!
There is no oops.
` is what you use when you know every key will be a \w+ one, or at least
most will be. Or what you use if one of the keys is \w+ and you do not
care about mixing syntaxes.
Now, mind you: if you WANT to add this to Perl 6, there is nothing
stopping you from writing your own syntax module for it. Go to town, and
I won't try to stop you!
Keep repeating it and it will become more true.
I know that trick too and will also repeat one message:
I'm not asking if this is possible. I know it is. I'm suggesting we put
it in the core.
For reasons to want it in the core, see Scott's summary.
I very probably will have and will use this syntax. I'm not talking
about me. I suggest this feature because I think it's good for Perl and
the people who use it.
Except for the shocking number of closed-minded people on this list.
Fortunately, they can still use {} whenever they want.
I think I have presented two cases. The removal of `` and the
introduction of %hash`key. Either can be implemented without breaking
the other, though I obviously think both letting `` go and introducing
the infix ` is better.
And others disagree. Why can't we leave it at that, and if the consensus
goes toward implementation of your idea, more the better.
Most of those who disagree so far do that they either don't understand
that `` does not have to go, or because they find the ` ugly.
Fortunately, there are also people who absolutely love the proposed
%foo`bar.
Juerd
Re: backticks
David Wheeler skribis 2004-04-16 7:56 (-0700):
And I'll bet it's something like this:
for my $i (0..$#thingies) {
my $css_class = $i % 2 ? 'blue' : 'yellow';
print tr class=$css_classtd$thingies[$i]/td/tr\n;
}
Probably.
Can't we in Perl 6 just use something like this?
for @thingies, qw(blue yellow) xx Inf - $thingy, $class {
print qq[tr class=$classtd$thingy/td/tr\n;
}
Juerd
Re: backticks
Larry Wall skribis 2004-04-16 11:50 (-0700): On Fri, Apr 16, 2004 at 07:12:44PM +0200, Juerd wrote: : Except for the shocking number of closed-minded people on this list. You seem to be one of them. From my point of view, you've had your ego plastered all over this proposal from the start, and no one can disagree with it without becoming your enemy. Please consider that some people may have thought about your proposal a long time before weighing in. Myself, I'm still thinking about it. Please don't call me closed-minded if I decide against it, however. There are many considerations to weigh, and nobody is going to give them all the same weight. I think there is a misunderstanding about when I think someone is not open-minded. shocking number was exaggeration. To clarify: only when someone disagrees based on only that it has not been done before or other languages don't do it, I think they should be more open. When you decide, it will not be based only on emotion. Personal taste will of course influence the decision, but everyone can tell that you at least considered it thoroughly, looking at more than just a few aspects. Clearly, indeed some people have thought about it for a long time before responding. But they are probably not the people I call closed-minded. However, I could be guessing badly. It could be that someone who says Perl 6 should not have a third syntax because there are already two really has thought about it. We have many ways of saying foo() if not $bar in Perl 5 and I use most of them. I like that in Perl, and hope that in Perl 6 there will still be more than one way to do it. Anyone can disagree without becoming my enemy. None of the people who have contributed to this discussion are my enemy. I am thankful for every message, because they all either tell me why the proposals are not liked, or that my original post should have been more clear. I cannot and will not argue about the 'ugliness' of the backtick. Nevertheless, I do think that this is an important issue. If most find it ugly, then implementing this in the core is probably a bad idea. Juerd
Re: backticks
Brent 'Dax' Royal-Gordon skribis 2004-04-16 13:17 (-0700):
Clever definition of the colon operator, or creation of a
bareword-quoting operator, would allow you to use barewords anywhere
you wanted to.
Defining ` to be a bareword quoting operator would be only one step away
from what I suggested initially:
1. %hash`key
2. %array`5
3. :key`value
4. say `hello;
This would make it like now, but allowing only one bareword, and
only if it is simple (identifier-ish). Oh, and much easier to read and
type :)
I like the idea of making a bareword quoting operator!
(But only 1 and 2 really matter to me. 1 more than 2.)
To get an item out of a hash, you can write %varname{key}.
You can also write %varnamekey if there aren't any spaces in
the key. Finally, if the key doesn't have any characters in it
except for letters, numbers and underscores, you can write
%varname`key.
That's not a great way to teach a langage, and for a reference manual, I
think separation into three paragraphs will make things much clearer.
Or a table, like in perlcheat :)
Basically, if ` is made a generic bareword quoter, is its plural
form. That makes it easier to explain.
I'm going to throw in one more argument at this point. It's based on a
game you all played as children: Which One Of These Doesn't Belong?
stuff(1)
@stuff[1]
%stuff{1}
%stuff«1»
%stuff`1
Hm...
print if not $foo;
if (not $foo) { print }
print unless $foo;
unless ($foo) { print }
$foo or print;
And there are many more examples in Perl. I personally like having two
ways to write exactly the same thing. If the two ways are very
different and one is because of that much easier than the other, I like
having the alternative even more.
Juerd
Re: backticks
Jonathan Scott Duff skribis 2004-04-16 15:51 (-0500):
To get an item out of a hash, you can write %varname{key}.
You can also write %varnamekey if there aren't any spaces in
the key. Finally, if the key doesn't have any characters in it
except for letters, numbers and underscores, you can write
%varname`key.
Except that you've put things in this explanation that shouldn't be
there IMHO. The %varnamekey is a special case, but not of getting a
single item from a hash, rather it's a special case of a one element
list generated from evaluating to the element. So, if you remove
that bit, it's the same as the two below just with different syntax.
I think %hashkey key key is best explained as %hash{ key key
key } with implicit curlies, not as an alternative to curlies.
This is where ` as a bareword-quoter would provide a somewhat consistent
interface, as %hash`key would then just be %hash{`key}, but without the
curlies. And :fooa and :foo`a would be :foo(a) and :foo(`a)
without the parens.
But I also like to think that // is m// with implicit m, instead of the
other way around.
Juerd
Re: backticks
John Williams skribis 2004-04-16 18:32 (-0600): You didn't answer his question, which is less complicated? Wasn't that a rhetociral question? Juerd
Re: backticks
Trey Harris skribis 2004-04-16 12:05 (-0700): I'm asking you to stop interpreting disagreement as censorship, prejudice, closed-mindedness, or whatever else. It's not. I never did interpret disagreement as anything but disagreement, and never said that I think everyone who disagrees is closed-minded. Instead of asking me to stop interpreting disagreement as close-mindedness, ask yourself to stop interpreting closed-minded as disagreeing. There is no 'between the lines' in my messages. Stop looking for it. Juerd
Re: Is Dog|undef a legal type?
Abhijit A. Mahabal skribis 2004-04-19 11:00 (-0500):
when Dog: ...
when Array: ...
Shouldn't that be:
when Dog { ... }
when Array { ... }
Or is there some .when that I have not yet heard of?
Juerd
Re: A12: default accessors and encapsulation
John Siracusa skribis 2004-04-19 14:20 (-0400):
has $.gender is rw;
(...)
This works well for a while, but then I decide to update Dog so that setting
the name also sets the gender.
$dog.name = 'Susie'; # also sets $dog.gender to 'female'
How do I write such a name() method? Do I just check the arg, set the
gender, and then return $.name as an lvalue or something?
IIRC, something like
has $.name is rw is STORE { ... };
If so, what happens if, some time down the road, the $.name attribute goes
away entirely? I can't return it as an lvalue now, can I?
Why not?
Juerd
Re: backticks (or slash, maybe)
Angel Faus skribis 2004-04-19 22:43 (+0200):
If we really need a ultra-huffman encoding for hash subscriptors, I
have always dreamt of being able to do:
%hash/key
$hashref/foo/bar/baz/quux
...
I'd hate to give up dividing slash. It's one of the few operators that I
sometimes type without whitespace. Simple because 1/10 is good enough
and 1 / 10 is very wide.
Other than that, I like it. But it isn't really doable.
%hash/{ some_func() } # dynamic key
%hash/«key1 key2» # hash slice
%hash/['key', 'key2'] # the same
I think this is not a good idea.
* «a b» and ['a', 'b'] are always substitutable, ever
Only because they are here, doesn't mean they are everywhere.
A xml library could make every node a tied hash, effectively embedding
a good portion of xpath within perl
Hmm... If only the slash weren't used by something extremely important.
for /home/angel - $file {
That would mean giving up // for regexes (i.e. making the m mandatory).
And I think having quotes for strings other than very simple ones
(anything containing a / is not a simple string imho) is good for
readability.
Juerd
Re: backticks (or slash, maybe)
Sean O'Rourke skribis 2004-04-19 15:11 (-0700): I'd hate to give up dividing slash. It's one of the few operators that I sometimes type without whitespace. Simple because 1/10 is good enough and 1 / 10 is very wide. You can have both, though. But not in a way that makes $foo/$bar divide $foo by $bar, if $foo is a hashref. That would mean giving up // for regexes (i.e. making the m mandatory). Since modifiers have to be up front, and since hash slices won't have a trailing '/', I don't think there's any ambiguity -- anything ending in a '/' is a regex, anything otherwise is a hash slice. I don't understand. Could you give some examples? Is this in the context of bare /path/to/foo, even? Juerd
Re: backticks (or slash, maybe)
Sean O'Rourke skribis 2004-04-19 15:34 (-0700):
I'm saying division is now defined such that when the numerator is
a hash(-ref), the result is the set of values associated with the
denominator. I've never tried to divide a hash or hashref by
something without it being a bug.
I understand now. But that means the meaning of the / is unknown until
runtime, which means $foo/0 can't be a compile time error.
And it doesn't quote the thing after it, which means still doing a lot
of typing.
$foo/bar should be a compile time error (Perl 6 has no barewords) if
$foo is not a hashref, but be $foo{'bar'} if it is. Waiting for runtime
is bad, I think.
/foo/ # trailing slash -- so it's a regexp (m/foo/)
/foo\/bar/ # trailing slash -- syntax error (m/foo/ bar/)
/foo/a # hash-path -- no trailing slash ($_.{'foo'}{'a'})
/foo\/bar # hash-path -- no trailing slash ($_.{'foo/bar'})
/foo\/ # hash-path -- no trailing slash ($_.{'foo/'})
Thanks. Now I'm sure I don't like the bare path idea. After a hash,
perhaps it's doable, and even if -r /etc/passwd is doable, but there
are too many allowed characters in filenames (on my system: any
character except \0 and /).
Juerd
Re: backticks
Peter Haworth skribis 2004-04-20 14:56 (+0100):
I think %hashkey key key is best explained as %hash{ key key
key } with implicit curlies, not as an alternative to curlies.
In that case, why aren't you suggesting something more in line with that?
Here's what I'd like to see instead of your suggestion:
%hashkey key key === %hash{key key key}
%hash'key'=== %hash{'key'}
%hashkey=== %hash{key}
That has
* as few keystrokes as perl5's $hash{key}
* delimiters at both ends, so you can even use non-bareword constants
* existing syntax reused in the same way as the variant
* interpolation allowed in the double quoted variant.
Hm, not bad. Doesn't do anything to arrays yet, but I like the idea.
We could maybe even treat hashes and arrays as list operators. That
would allow whitespace, and also:
@array 15
But I liked about the backtick that it's special syntax, which makes it
recognisable. Still, your idea is doable.
Juerd
Re: A12: default accessors and encapsulation
Brent 'Dax' Royal-Gordon skribis 2004-04-20 12:58 (-0700):
method buffersize()
will store {
my $sqrt=$^v.sqrt;
die $^v is not a power of two unless int($sqrt) == $sqrt;
$.buffer = \x[0] x $^v;
}
{ +$.buffer.bytes }
Could this be written as:
method buffersize {
+$.buffer.bytes
} will store {
my $sqrt = $^v.sqrt;
...
}
Or does will store BLOCK really have to go before the main block?
Juerd
Re: A12: a doubt about .meta, .dispatcher and final methods
(re-post. for some reason the alias didn't work.) Larry Wall skribis 2004-04-23 8:24 (-0700): On the third hand, maybe we should go for $obj._meta_ or some such. I don't like _foo_ names. Once you shart having things with underscores, it's only a matter of time before someone decides that _foo, foo_, _foo, __foo, ___foo, and __foo__ should all have something specific to say about what the foo is. __LINE__, __PACKAGE__, etcetera are fine with me (although I do use CLASS.pm to be able to type CLASS and get something that often eq __PACKAGE__), but I wouldn't like other uses of underscores for important things in the core language. On the sixth hand, by that argument, since .dispatcher is aiming at a Class, it should be an uppercase C. :-) Doesn't unicode have that, then? :) Juerd
Re: A12: Typed undef
Austin Hastings skribis 2004-04-23 13:33 (-0400): I should then be able to call class methods of Dog via $spot without further initialization: print defined($spot); # FALSE $rover = $spot.new; @breeds = $spot.list_breeds; But shouldn't you then just use my Class $spot = Dog then? Or maybe just my $spot := Dog? This is, as pointed out, just sugar for Dog::new and Dog::list_breeds, but it brings up the spectre of undef invocants: :: or .? I'm confused. $c-foo-bar-baz; # If foo or bar fails, what happens? - or .? Even more confused now. Juerd
Re: C style conditional statements
Aaron Sherman skribis 2004-05-12 14:04 (-0400):
Perl 5:
#!/usr/bin/perl
while() {
s/\w+/WORD/g;
print;
}
Perl 6:
#!/usr/bin/perl
while $stdin.getline - $_ {
Empty uses ARGV, not STDIN. It only uses STDIN if not @ARGV (or if
'-' is in @ARGV).
s:g/\w+/WORD/;
$stdout.print;
A2 says $*STDIN and $*STDOUT. Has this been changed?
Also, will there no longer be the concept of a selected filehandle? I'd
hate to have to specify stdin and stdout in throw away scripts.
}
I think I like this better:
for {
s:g/\w+/WORD/;
print;
}
But I think I still want to have some non-mutating version of s/// that
returns the modified string, so that you can just write something like
print s:gx/\w+/WORD/ for ;
Juerd
$foo.s/foo/bar/
Juerd skribis 2004-05-12 20:15 (+0200): But I think I still want to have some non-mutating version of s/// that returns the modified string, so that you can just write something like print s:gx/\w+/WORD/ for ; Actually, can't we just use the . for s///? You'd then use $foo.s/// to get the new string ang $foo.=s/// to mutate $foo. For bare s///, I think copying is more useful than mutating. I'm not sure, and am posting this before actually thinking about it :) Juerd
Re: C style conditional statements
Larry Wall skribis 2004-05-12 11:39 (-0700):
On Wed, May 12, 2004 at 08:15:36PM +0200, Juerd wrote:
: A2 says $*STDIN and $*STDOUT. Has this been changed?
It's $*IN and $*OUT.
I like this change!
: I'd hate to have to specify stdin and stdout in throw away scripts.
Just because there's no longer a selected filehandle doesn't mean
you have to specify stdout. It's still the default. It's just no
longer the default default. Translated Perl 5 scripts that select
the current output filehandle will need to use an explicit variable
to hold the default.
Some tools like Irssi and my own PLP tie a handle and then select it, to
intercept the output of normal print statements. But STDOUT can still be
specified explicitly if that's where you want things to go.
This makes the tools compatible with most code out there, for easy
copying and pasting. (Think of it what you want, but this is and will
stay the way beginners create their programs.)
If there is just a default, but no way of changing it, you'd have to tie
$*OUT itself. But how would one then reach the real stdout, in case it's
needed?
I hope I'm missing something :)
: for {
: s:g/\w+/WORD/;
: print;
: }
That will work fine in Perl 6. It won't even chew up all your memory
as it would in Perl 5.
The lazy readline list is one of the things that make me love Perl 6. I
didn't even think about this snippet in Perl 5 context.
Juerd
Re: C style conditional statements
Luke Palmer skribis 2004-05-12 12:46 (-0600): Well, the IO-objects are iterators, and you use $iter to iterate. It makes sense that would iterate over $*ARGV by default. $*ARGS? my $n = new IO::Socket::INET: LocalPort = 20010, Listen = 5; I'd like to be able[1] to write my $n = new IO::Socket::INET :LocalPort 20010 :Listen 5; But unfortunately, parens are not optional with :pairs. Juerd [1] Because I'd use something like that in other contexts. I expect that I will not use indirect object syntax even in Perl 6 and will in reality write: my $n = IO::Socket::INET.new LocalPort = 20010, Listen = 5;
Re: Yadda yadda yadda some more
Aaron Sherman skribis 2004-05-12 17:30 (-0400): I like C... I like it a LOT. In fact, I'm partial to the idea that it should be usable anywhere I agree. It'd make even more of my pseudo code (#perlhelp and perlmonks.org) valid syntax :). Juerd
Re: Compatibility with perl 5
Jonathan Scott Duff skribis 2004-04-26 13:02 (-0500): I know this sounds slightly irrational but I don't like using shifted characters to offset my command line switches. Also, that colon seems *way* overloaded. :-) How about = instead? Overloaded, but similar to :pairs and s:modifiers. #!/usr/bin/perl = #!/usr/bin/perl =6 Feels like something is missing. Like a LHS. I like - for command line switches. Juerd
Re: Required Named Params and go write your own grammar
Abhijit A. Mahabal skribis 2004-05-04 10:27 (-0500): As I try writing P6 programs I do find myself needing required named params, and I thought I'd like something like ++$named_req for myself as a shorthand for +$named_req is required or whatever is decided. What's wrong with just specifying them as positional ones? Don't document the feature and you'll effectively have required named parameters. Or am I missing something? the entire P6 grammar Are parts already available in Perl 6 rule syntax? Juerd
Re: RFC eq and ==
Luke Palmer skribis 2004-05-17 14:54 (-0600):
Admittedly, if you use == for everything, you can force string or
numeric comparison this way:
if +$a == +$b {...} # numeric
if ~$a == ~$b {...} # string
And $a :=: $b could be written as \$a == \$b. Oh, hm.
It does sound kind of attractive to me, because it's a bit like
lc $a eq lc $b
Juerd
Re: idiom for filling a counting hash
St?phane Payrard skribis 2004-05-18 23:14 (+0200):
I use over and over this idiom in perl5:
$a{$_}++ for @a;
This is nice and perlish but it gets easily pretty boring
when dealing with many list/arrays and counting hashes.
A3 says something about tr being able to return a histogram (a hash like
your %a), A5 says something about tr being able to match more than just
characters.
There must be some neat trick with tr that you can use for this :)
But maybe it's better to just define a histogram method for arrays. Then
you can get the unique elements by doing @array.histogram.keys. But
again, just having a method for that is probably a better idea (if only
because with the hash, the original order is lost).
Juerd
Re: idiom for filling a counting hash
John Williams skribis 2004-05-18 16:07 (-0600):
$a{$_}++ for @a;
[EMAIL PROTECTED];
That's not a bad idea, even in Perl 5:
1;0 [EMAIL PROTECTED]:~$ perl -MBenchmark=cmpthese -e'my @foo = (1..16,
1..10); cmpthese -1, { a = sub { my %foo; $foo{$_}++ for @foo; }, i
b = sub { my %foo; $_++ for @[EMAIL PROTECTED]; } }'
Rate a b
a 51121/s -- -9%
b 56220/s 10% --
Juerd
Re: idiom for filling a counting hash
Uri Guttman skribis 2004-05-19 0:08 (-0400):
J 1;0 [EMAIL PROTECTED]:~$ perl -MBenchmark=cmpthese -e'my @foo = (1..16,
J 1..10); cmpthese -1, { a = sub { my %foo; $foo{$_}++ for @foo; }, i
J b = sub { my %foo; $_++ for @[EMAIL PROTECTED]; } }'
J Rate a b
J a 51121/s -- -9%
J b 56220/s 10% --
but those are setting the empty hash to values of 1's. you can do that
with a slice or map:
Not in my perl.
perl -MData::Dumper -le'my @foo = (1..16, 1..10); my %foo; $foo{$_}++ for
@foo; print Dumper \%foo'
perl -MData::Dumper -le'my @foo = (1..16, 1..10); my %foo; $_++ for
@[EMAIL PROTECTED]; print Dumper \%foo'
Both give:
$VAR1 = {
'11' = 1,
'7' = 2,
'2' = 2,
'1' = 2,
'16' = 1,
'13' = 1,
'6' = 2,
'3' = 2,
'9' = 2,
'12' = 1,
'14' = 1,
'15' = 1,
'8' = 2,
'4' = 2,
'10' = 2,
'5' = 2
};
This is perl, v5.8.4 built for i386-linux-thread-multi
Juerd
Re: FW: Periodic Table of the Operators
Tim Bunce skribis 2004-06-08 11:30 (+0100): I can recommend PuTTY for windows. Secure, small[1], fast, featureful and free: http://www.chiark.greenend.org.uk/~sgtatham/putty/ [1] So small it easily fits on a floppy. I keep a copy on my USB memory drive. So small that even on modem lines, you can afford to download it each time you start it: http://startputty.com/ - if you trust them. Juerd
Re: cmd line like switches for functions and operators.
Michele Dondi skribis 2004-06-22 18:24 (+0200):
rename -v = 1, $orig, $new;
Any specific reason for the minus there? Perl's not a shell (yet).
rename.SWITCHES{-v} = sub {
my ($o, $n) = @_;
print renaming `$o' to `$n'\n;
}
I think just using named arguments would be better and much easier.
sub rename ($old, $new, +$verbose) {
say Renaming '$old' to '$new' if $verbose;
...;
}
rename verbose = 1, $oldthingy, $newthingy;
rename $oldthingy, $newthingy, :verbose; # alternative, more
# switch-like pair constructor
Juerd
Re: cmd line like switches for functions and operators.
Luke Palmer skribis 2004-06-22 16:32 (-0600):
*rename.wrap - $orig, $new, *%opt {
say Renaming '$orig' to '$new' if %opt{'verbose' | 'v'};
call;
}
Would it be possible to just add a named argument, without repeating any
part of the existing signature? Like:
*foo.wrap sub (*foo.signature, +$new_thingy) {
# or whatever syntax
...
call;
}
Or is the original signature not usable, and does one need to consult
the manual/source and copy it?
Juerd
Re: definitions of truth
Scott Bronson skribis 2004-06-24 10:44 (-0700): However, it seems that because Perl is finally getting a typing system, this hack can be fixed in Perl itself! No programmer intervention needed. Undef and '' can be false for strings, undef and 0 can be false for integers, undef, 0, and 0.0 can be false for floats, etc. I think this makes sense: string: undef, number: undef, 0 (implies 0.0) other: convert to number and then decide. Anything that can't naturally be converted to a number (i.e. would be invalid syntax if unquoted) is true. /me wanted to write this in Perl 6, but couldn't think of a good way to represent true and false when returning from is_true :) Perhaps having real true and false values (where true cannot be false and false cannot be true) would make a lot of things much easier. I, for one, would like return true; (where true is undef-ish: a keyword that always returns the same value). Juerd
Re: definitions of truth
Larry Wall skribis 2004-06-24 11:29 (-0700): This is Perl 6. Everything is an object, or at least pretends to be one. Everything has a .boolean method that returns 0 or 1. All conditionals call the .boolean method, at least in the abstract. (The optimizer is free to optimize the method call away for known types within known conditionals, of course. It had better, or evaluating the truth of .boolean will end up calling .boolean again... :-) I didn't know about the (to-be) existence of .boolean. It makes things fun and easy, though. However, is the name boolean final? I would prefer true, perhaps with a corresponding false. That is, assuming that there will be $foo.defined and $foo.empty. Hm. I wonder where (and if) I read about .empty. Can't find it. not when the data becomes false. Plus we'll have the // operator.) I'll be wanting a length-or. Perl 6 will make coding it easy enough to not need it in the core. But the operator needs a symbol. I'm assuming infix: will work. But will there be a way to ask Perl if syntax can be used without introducing possible ambiguity? A circumfix ++ operator won't work for several reasons. What will Perl do if you try defining one? Please don't say that picking a random sequence of at least 5 different unicode dingbats will be the best way to be sure :) Juerd
Re: definitions of truth
Larry Wall skribis 2004-06-24 12:24 (-0700):
Well, the type/property name doesn't have to be boolean--it could
be truth, instead.
I understand that 'true' and 'false' can't be used.
However, truth is in the same category as definedness, and
$foo.definedness looks awful :)
Perhaps for conversion to a certain type, simply the type name can be
used as a method. Then $foo.int and $foo.bool make the same kind of
sense. (Or $foo.Int and $foo.Bool, but then int $foo would be strange
(I assume int $foo returns a fully functional scalar integer))
[length-or]
What do you mean by length? [bytes, graphemes, etc]
Good question. Probably byte length. If there is one byte, that has to
represent at least one of the other length-units, right?
Not having 'length' will be hard to get used to. Perhaps I'll try to
make it easier (and thus harder in the longer term) for myself by
defining something that does .isa('Str') ? .chars : .isa('str') ? .bytes
: .isa('Hash') ? .keys : .isa('Array') ? .elements : 1.
Synopsis 6 describes 'str' as 'native string'. Is my assumption that
such a string is one that doesn't have multi-byte characters correct?
Juerd
Re: definitions of truth
Austin Hastings skribis 2004-06-24 14:29 (-0700): $foo as boolean This is Perl 6. Everything is an object, or at least pretends to be one. Everything has a .boolean method that returns 0 or 1. If I understand the current design correctly, having both .boolean and casting via as would mean that $foo.boolean and $foo as Bool and $foo as Bit mean the same in boolean context, but the first literally is 1 or 0, the second is true or false and the third is 1 or 0 again. But all this only by default, because every one of these three can be overriden. And actually, I don't think I understand it correctly. It's been a while since I had a feeling of understanding Perl 6 :) Is this complexity really needed? Juerd
Re: definitions of truth
Austin Hastings skribis 2004-06-24 15:54 (-0700): I'd say yeah, it is. 0-but-true is pretty nice to have. (Finally the system calls can return something other than -1.) That we already have. 0 but true. (perldoc -f fcntl) It's 1 but false that's really special :) Juerd
Re: more than one modifier
Please configure your email client correctly. (I'm surprised that the message was accepted, even) [EMAIL PROTECTED] skribis 2004-06-25 13:38 (-): I have a wish for Perl6. I think it would be nice to have the possibility for more than one modifier after a simple statement. Has been discussed more than once already. Please read the older messages first. http://www.mail-archive.com/[EMAIL PROTECTED]/msg27900.html print $a+$b if $a if $b for 1..3; The double if doesn't make a lot of sense. What's wrong with and? print $a + $b if $a and $b for 1..3; Or, with just one statement modifier, as if is just a fancy and (or vice versa): $a and $b and print $a + $b for 1..3; Juerd
Re: more than one modifier
Stéphane Payrard skribis 2004-06-25 16:15 (-0400):
It is unpossible to stack loop modifiers without adding
conventions denoting the iterators.
Is it really? I've always thought this would be useful enough:
say .{foo} for @$_ for @foo;
Although that can probably just be written as:
say .{foo} for @@foo; # Looks strange. Is this correct?
Juerd
Re: The .bytes/.codepoints/.graphemes methods
Dave Whipp skribis 2004-06-28 9:55 (-0700): substr($string, 2 bytes, 4 bytes) = $substitute; substr($string, 2, 4 :bytes) substr($string, 2 but graphemes, 4 but bytes); I think but even makes sense, if substr defaults to something. Juerd
Re: undo()?
Mark A. Biggar skribis 2004-06-29 9:07 (-0700): Besides we already have MTOWTDI with local() and hypotheticals. I thought temp replaced local. If not, how do they differ? (is temp for lexicals, local for globals (and why would that make sense?)) Juerd
Re: The .bytes/.codepoints/.graphemes methods
Matt Diephouse skribis 2004-06-30 20:51 (-0400): my $string = Hello, World!; say $string[0..4]; # prints Hello\n $string[7...] = Larry!; say $string; # prints Hello, Larry!\n And that array is one of bytes? graphemes? In general, I like the idea. In [EMAIL PROTECTED], almost the same was suggested, but implemented differently: a string's .bytes method in list context (but isn't it array context, technically?) would dwym. As would the other parts-of-string methods. Perhaps without method, the string in array/list context can default to the default set by a lexical pragma. Which, I hope, has a default itself. (I like default defaults...) Juerd
Re: if not C, then what?
Scott Bronson skribis 2004-07-01 12:42 (-0700): But C; requires a surrounding do block, as you noted. Then invent a horizontal ; operator that does not :) pray_to $_ then sacrifice $virgin for @evil_gods pray_to $_ ., then sacrifice $virgin for @evil_gods; Juerd
Re: if not C, then what?
Scott Bronson skribis 2004-07-01 13:31 (-0700): Then invent a horizontal ; operator that does not :) pray_to $_ then sacrifice $virgin for @evil_gods pray_to $_ ., then sacrifice $virgin for @evil_gods; Sure. But what is .,? Cthen could work alone, couldn't it? It is a horizontal ;. See: ., If you turn your head 90 degrees counter clockwise, you see the horizontal semicolon and even a smiley face :) Juerd
Re: if not C, then what?
Scott Bronson skribis 2004-07-01 14:11 (-0700): On Thu, 2004-07-01 at 13:35, Juerd wrote: pray_to $_ ., then sacrifice $virgin for @evil_gods; I meant it without then, but apparently forgot to remove it. pray to $_ ., sacrifice $virgin for @evil_gods; Ha! I love it. Good source code should look happy. I'm glad you like it :) Juerd
Re: if not C, then what?
Jonadab the Unsightly One skribis 2004-07-03 13:33 (-0400):
e.g., is this legal?
sub infix:before ( $before, $after ){ ... }
I should HOPE it would be legal to define infix:before.
There already are infix:x and infix:xx. If Perl 6 will let us define our
own operators just like built in ones, infix:before should also be
possible.
And infix:¥ (for those like me who have a simple terminal that doesn't
know how to display this, or are suffering from my lack of config-fu to
get headers and encodings synched: this is Yen, created using ^KYe in
vim. I see a dashed rectangle.) will in my programs probably only be
used through infix:Y or infix:z, which I will define myself if
necessary. (zip() is not infix and thus not an *equivalent*
alternative.)
Juerd
Re: scalar subscripting
Gautam Gopalakrishnan skribis 2004-07-08 21:12 (+1000): about string subscripting. Since $a[0] cannot be mistaken for array subscripting anymore, could this now be used to peep into scalars? Looks easier than using $a[0] is $a.[0]. That means that if there is a @$a, it still is array subscripting. Accessing strings as if they are arrays was discussed recently. Please read the archives. (groups.google.com is my favourite interface) Juerd
Re: if not C, then what?
Michele Dondi skribis 2004-07-09 11:39 (+0200): - then as a method of print makes sense then as a method of everything How does then as a method make sense? A method has to be somehow related to the object. Don't use methods for syntactic sugar, Perl 6 has plenty of ways to add sugar without abusing things that normally mean something else. Juerd
Re: enhanced open-funktion
Luke Palmer skribis 2004-07-13 7:24 (-0600): But in Perl 6, you don't have to specify things like that through the mode string: you can specify them through named parameters: my $fh = open $filename :excl; I was hoping we could finally get rid of mode characters, and especially combined mode and filename in one argument. Ever since I read about the new :pairs, I thought that would imply :rw instead of . Juerd
Re: Cartesian products? [Especially wrt iterations]
Luke Palmer skribis 2004-07-13 10:28 (-0600):
for outer(1..3, 4..6) - $x, $y {
say $x,$y;
}
1,4
1,5
1,6
2,4
2,5
2,6
3,4
3,5
3,6
So outer is somewhat like {} in shell globs?
perl -le'print for glob {1,2,3},{4,5,6}'
Juerd
Re: enhanced open-funktion
Larry Wall skribis 2004-07-13 14:04 (-0700):
The combined form is definitely problematic in various ways, and we haven't
really redesigned open yet, since we haven't got to A29 yet. :-)
Well, open being much like IO::All::io would really make me happy.
That is:
my $fh = open 'foo.txt';
$fh.print 'hello!';
Should be possible, as well as:
my $fh = open 'foo.txt';
print $fh.readline;
Modifiers could be used to force something into a separate mode. rw and
ro are used elsewhere in Perl 6 already, but obviously r without w would
also be handy.
my $fh = open 'foo.txt', :ro;
$fh.print 'hello!'; # Not possible
Of course, those who want the mode first can use
my $fh = open :ro, 'foo.txt';
Which isn't too different from
open my $fh, '', 'foo.txt';
Or perhaps, for open an exception should be made, and r should be used
instead of ro.
my $fh = open $filename :excl;
my $fh = append $filename :excl;
my $fh = creat $filename :excl;
...er, I mean,
my $fh = create $filename :excl;
That I would very much dislike. Let's not introduce keywords when the
same thing can be done by modifiers, unless something is used EXTREMELY
often (my mind has now accepted say, but only because print ...\n is
extremely common).
Of course, append and create might just be shorthand for a normal open
with a :create or :append arguments, I suppose.
I hope those keywords can be introduced with a pragma. use
shorthands;. That pragma then does need a single letter command line
switch, because it would be very useful for one-liners.
@lines = open $infile;
print (append $outfile): @lines;
Or equivalently:
open $infile ==
print (append $outfile):
I'd prefer
(open $outfile :append).print slurp $infile;
Or, for the shorthand junkies :)
(append $outfile).print slurp $infile;
But that might be a little too concise for good error messages.
Assuming $infile ne $outfile and that the default error message (which
perhaps is only there if enabled with a Fatal.pm-like pragma) includes
the filename (it should, imo), two things being on one line shouldn't be
a problem.
And they might lead people to write things like
while open $file {...}
I've never seen
while (IO::File-new($file)-readline) { ... }
either.
Of course, while-open is a good candidate for a warning.
I don't think this problem needs a solution. I hope or-cache will
still be an often used idiom in Perl 6:
while my $fh //= open $file { ... }
Although I'm not sure what exactly my would mean here.
But :rw is more or less orthogonal to and in UnixThink.
There's one thing feel I must say about and : They're not different
enough, visually. This works well on the command line and for
delimiters, but
open '', $foo;
open '', $foo;
is much harder to read than
open 'r', $foo;
open 'w', $foo;
For the same reason, I prefer unified diff format to the / format that
my copy uses by default.
The fact that you want to both read and write a file says nothing
about whether you initially want to use, clobber, or append to an
existing file.
It's okay to have defaults, I think.
r use
w clobber
a append
rw use
This can without too much trouble be solved with :append and :clobber.
Juerd
Re: enhanced open-funktion
H.Merijn Brand skribis 2004-07-15 11:57 (+0200):
1. They do not ambiguate with files named 'r', or 'w'
Not a problem, assuming that these are named arguments as in:
open :r, $file;
open :w, $file;
open :rw, $file;
open :r :w, $file; # Hmm...
2. They don't have to be translated (in german that would be 'l' and 's')
zeg hallo, wereld;
mijn $dbh = DBI-verbind(...);
mijn $sth = $dbh-bereid_voor($zoekopdracht);
$sth-voer_uit(@waardes);
$sth-bind_kolommen(\my ($foo, $bar));
zolang ($sth-apporteer) { # :)
toonf %10s %d, $foo, $bar;
volgende als $bar gd 15;
}
No, translations don't work in programming.
3. They play nice with possible extensions 'open :utf8, $file;
But
open :w('utf8'), $file;
it would even make using different layers for in and output easy:
open :r('iso-8859-15') :w('utf8'), $file;
although you shouldn't want that :)
Juerd
Re: enhanced open-funktion
Brent 'Dax' Royal-Gordon skribis 2004-07-15 13:04 (-0700): $in=open :r |/usr/bin/foo; $out=open :w |/usr/bin/foo; $both=open :rw |/usr/bin/foo; No, thank you. Please let us not repeat the mistake of putting mode and filename/path in one argument. [EMAIL PROTECTED]:~/tmp/example$ ls -R * |: usr |/usr: bin |/usr/bin: foo Juerd
push @bar, .splice;
If an array element knows that it is an array element, this can be
useful:
for @foo { push @bar, .splice if EXPR }
Juerd
Re: push @bar, .splice;
Dave Mitchell skribis 2004-07-17 18:24 (+0100):
On Sat, Jul 17, 2004 at 06:53:28PM +0200, Juerd wrote:
If an array element knows that it is an array element, this can be
useful:
for @foo { push @bar, .splice if EXPR }
What happens if the element is an element of more than one array?
Good point. It can perhaps know which array that it belongs to is
currently used with foreach :) Which would automatically bring us to the
question: what if it belongs to two arrays, that are both being iterated
over? I have no idea.
Juerd
:)
Do we have a :) operator yet? Juerd
Re: This week's summary
The Perl 6 Summarizer skribis 2004-07-20 14:46 (+0100):
Another subthread discussed interpolation in strings. Larry's changed
his mind so that $file.ext is now interpreted as $object.method. You
need to do ${file}.ext or $( $file ).ext. Or maybe $«file».ext
by analogy with %foo«bar». James Mastros pointed out that . is
rather ambiguous in a literal string; sometimes a full stop is just a
full stop.
My preference is $file\.ext. Clear, light and ascii.
Juerd
Re: String interpolation
Larry Wall skribis 2004-07-21 10:24 (-0700):
Interpolates
NoYes
-----
@foo @foo[1]
%bar %bar{a}
$foo.bar $foo.bar()
Oh, please don't do that.
Whatever interpolation thing is invented, make it SIMPLE. Allowing
@foo[1], but not @foo is not simple.
In fact, with {}, is anything more than $foo and {} needed? Is $foo
needed, even (I'd like to have it, because I dislike brackets
everywhere)?
Juerd
Re: String interpolation
Matt Diephouse skribis 2004-07-20 20:06 (-0400): This is close to the new form() syntax as well, which could be considered a plus. I for one won't complain about adding the good things from Ruby back in to Perl. Ehm, no, that means that if you want to interpolate something into the format string, the rest of that string becomes bizarrely unreadable. Juerd
Re: Precedence table update
Larry Wall skribis 2004-08-18 15:37 (-0700): It the moment the zipper has moved to be the same precedence as comma, because it really wants to be looser than ranges but tighter than listops. Plus it's sort of like a »,« if you squint. I'm eagerly awaiting my first opportunity to use the »¥« operator in anger... Which makes me wonder: is there another core-only set of operators that renders as ???, or can we safely assume that ??? is Y (I still don't see why infix:Y would be wrong, and want it badly, because prefix zip() doesn't quite feel the same)? Let's see... ?foo bar baz?# qw %foo?bar?# qw @foo ?+? @bar# hyper @foo ? @bar # zip I guess it's not as bad as I initially thought. Even when rendered badly, I think in most cases it will still be recognisable. (Hm, can the real ? be made intelligent enough to dwim? Then I can even *copy and paste* the new operators in this terminal and have it dwym.) Juerd
Re: Return with no expression
Matt Diephouse skribis 2004-08-19 9:35 (-0400):
But I came across this code at work this week:
use CGI qw(:standard);
my $foo = Bar-new(
name = Baz,
value = param('baz'),
something = 'else'
);
Ouch. You have foo-bar-baz code *at work*? :)
See the problem?
Yes, you forgot scalar. param() is *documented* to behave differently in
list context. It's not an unfortunate side-effect, but the official,
documented API.
In fact, this was anticipated and the doesn't-exist case is explicitly
documented as:
If the parameter does not exist at all, then param() will return
undef in a scalar context, and the empty list in a list context.
I can't imagine how much trouble this would have caused me if I didn't
know about the Creturn; special case.
There is no need to know about the special case, because you can read
exactly how it works in the documentation.
The bare return is there only to avoid a warning. param's behaviour
wouldn't be different with only the second return statement:
return wantarray ? @{$self-{$name}} : $self-{$name}-[0];
my $string = join , = @array;
my $string = join , == @array;
It's a 180, but it'll workforme.
Juerd
- as - with automatic is rw
I like that arguments will be readonly by default. But when I look at my
current code, I see that I would be typing is rw quite a lot, which in
my opinion is too long for a thing that occurs very often.
Every such situation in my code is a foreach loop. A thing that in Perl
6 will mostly be used with the pointy sub declaration syntax.
If I'm not mistaken, - is still available. It communicates
bidirectional and that is more or less the same as read/write access.
I'm proposing
for zip(@foos, @bars, @xyzzies) - $foo, $bar, $xyzzy { ... }
for %quux.kv - $key, $value { ... }
to mean
for zip(@foos, @bars, @xyzzies) - $foo is rw, $bar is rw, $xyzzy is rw { ... }
for %quux.kv - $key is rw, $value is rw { ... }
Comments, anyone?
Juerd
Re: A thought for later -- POD tables
$_ $xType of Match ImpliedMatching Code == = == Any Code$ scalar sub truth match if $x($_) How about making paragraphs that have a line like the divider one above special? By simply parsing the = lines, it's easy to make it a table for formatters that understand tables, and you have full control over how things look in plain text. It would mean being a little more careful with the lines, as they should indicate column width, and not just end at the end of the column header. Podchecker can of course be made to warn if there is non-whitespace in a column that had an = in the divider (now: column specification) line. $_ $xType of Match ImpliedMatching Code - == = == + == === == Any Code$ scalar sub truth match if $x($_) An HTML formatter could generate code like: table tr thtt$_/tt/th thtt$x/tt/th thttType of Match Implied/tt/th thttMatching Code/tt/th /tr tr tdttAny/tt/td tdttCodelt;$gt;/tt/td tdttscalar sub truth/tt/td tdttmatch if $x($_)/tt/td /tr !-- ... -- /table I haven't thought of a solution for non-verbatim cells yet. I'm not convinced that they are needed. Juerd
Re: - as - with automatic is rw
Larry Wall skribis 2004-08-20 13:31 (-0700): Unfortunately I'm not sure it passes the Are there already too many ways to declare a sub? test... I'm not seeing it as another way. Technically, of course it is different, but by the user, - and - will probably be seen as one thing, with one of them being the other's specialized form. It's really sick Sick would be if - were introduced to make the variable write-only ;) W R @foos - $foo @foos - $foo @foos - $foo It would be consistent, though... Juerd
Re: Instantiation
Aaron Sherman skribis 2004-08-23 12:53 (-0400): use Some::Module::That::Defines::A::Class; our Some::Module::That::Defines::A::Class $foo := new; and I keep thinking that that's too redundant (...) So, I was wondering about a synonym, like: uses Some::Module::That::Defines::A::Class $foo; Maybe, but I'd like something like this better: #!/usr/bin/perl6 use Module::AutoLoader :except(rx/^ Baz\:\: /); my Foo::Bar$bar .= new; my Quux::Xyzzy $xyzzy .= new; my Baz::Blah $blah .= new; # error, because there is no Baz::Blah::new Perhaps something must be added to tell it *when* to load modules: at runtime or during compilation. It shouldn't be hard to implement this module yourself, should it not go into the standard distribution. Juerd
Re: Progressively Overhauling Documentation
David Green skribis 2004-08-23 11:30 (-0600):
One of the selling features (or one of the features that is always sold)
of POD is that you can mix it with your code. Except nobody does, at
least I can't recall that last time I saw a module that did that, and I
don't think I've ever really done that myself. The POD usually sits in
a lump at the end of the file.
I'll consider inline documentation when POD can be inlined. But as long
as =command paragraphs need to start in the first column, I'm not
interested in this feature.
Having a nice, compact way to declare sub signatures is good. Being
able to document those signatures, not just nearby, but
*simultaneously*, would be great.
IMHO, with Perl 6's verbose signatures, it'd really help if POD could
copy the signature literally. This is one small thing I do like about
PHP documentation.
I also think POD should be overhauled completely. I've been thinking
about proposing something like:
sub foo (
Foo::Bar$bar,
Quux::Xyzzy $xyzzy,
+$verbose,
+$foo
) description {
Calculates the foo-intersection of $bar and $xyzzy, optionally
blah blah blah...
} returns Array | undef {
# real code here
}
which would get rendered as:
foo (Foo::Bar $bar, Quux::Xyzzy $xyzzy, +$verbose, +$foo)
returns Array | undef;
Calculate the foo-intersection of $bar and $xyzzy, optionally
blah blah blah...
Having {} instead of would also please me. Especially if we can get
{b:foo} instead of Bfoo.
But I haven't really given this much thought. That's why I haven't
proposed it yet. But since POD is a hot topic now anyway, let's see what
everyone thinks about this.
Juerd
Re: Progressively Overhauling Documentation
Rod Adams skribis 2004-08-23 13:16 (-0500):
sub foo :doc(take an Foo::Bar, and foo it over.) (
Anything involving a string is not good for documentation, because in
documenation it must be *easy* to add code examples. Besides that, ()
would make me want to put it all on one line, and that may be a little
*too* concise for documentation.
class Dog {
sub bite (
Int $strength is validated { 0 $_ = 9 } # Do we have
# something like this
# yet?
) description {
foo bar baz, demonstrated here:
=verbatim {
...
}
In any case, {b:CAVE CANEM}. # Translated: beware of the dog.
# And yes, that's a comment in POD, and should not be rendered.
} {
.mouth.open;
.head.extend;
.mouth.close $strength;
}
}
Juerd
Re: Progressively Overhauling Documentation
Thalhammer, Jeffrey BGI SF skribis 2004-08-23 12:03 (-0700): unsubscribe It doesn't work that way. If I'm not mistaken, unsubscribing is done by sending mail to [EMAIL PROTECTED]. Also, you might want to consider using a sane e-mail program and some training in quoting :) Juerd
Re: A question about attribute functions
Larry Wall skribis 2004-09-01 8:02 (-0700): : $x.transform.(); That might not work either. This will, though: ($x.transform)(); This is surprising. Can you please explain why .() won't work? I have methods return subs quite often, and like that I can just attach -() to it to make them work for me. I dislike parens. If $object.method.() will really not work, is there a way to call it without adding parens? Adding parens for someone who doesn't plan an entire line of code before typing it, means going back (for me, this is the most important reason for using statement modifiers; it's not just linguistically pleasing). Juerd
Re: Synopsis 9 draft 1
Larry Wall skribis 2004-09-03 17:08 (-0700): The element with index -1. Arrays with explicit ranges don't use the minus notation to count from the end. We probably need to come up with some other notation for the beginning and end indexes. @array.abs[0]; @array.abs[-1]; .abs would be an alternative interface for the array, where 0 is always the first element. The real index is then ( $abs_index = 0 ?? @array.first :: @array.last + 1 ) + $abs_index Juerd
Re: parameter contexts (was: Synopsis 9 draft 1)
John Williams skribis 2004-09-03 23:06 (-0600): (A and Z) I think I'd prefer alpha and omega. Why not use Cyrillic or Korean or the secret code alphabet we used in school? I don't like using letters for array indexes, but if they're used, please keep it ascii :) Juerd
Re: What Requires Core Support (app packaging)
John Williams skribis 2004-09-07 11:37 (-0600): and postfix:'th? It's 80s and postfix:th! Probably to help separate the term from the postfix operator. @array[ $foo'th ]; Maybe what I'm saying now is a really bad idea, because it doesn't make sense, but can't we just have an adverb that changes an integer into an ordinal? 4 :th $foo :th Obviously, the : should be optional for literal integers: 4th 3th Juerd
Re: more ordinal discussion
Jonathan Lang skribis 2004-09-07 14:12 (-0700):
Again, with a bit of magic where the dot is optional when the object in
question is an integer literal: 4th =:= 4.th - and probably with special
synonyms for th when the literal is any of (1 or -1, 2 or -2, 3 or -3) -
Number::st, Number::nd, and Number::rd, respectively. Mind you, these
wouldn't _really_ be methods, since they would only be valid when used
within the arguments of a list's postcircumfix:[] operator.
Why would they be invalid outside? Ordinals as real possible values make
sense to me.
Say, you have an array @foo, that starts counting at 5, and @bar that
starts counting at 10. Both have 5 elements. Wouldn't this be handy?
for 1 .. 5 {
... @foo[.th] ... @bar[.th] ...
}
# or maybe even:
for 1st .. 5th {
... @foo[$_] ... @bar[$_] ...
}
$nth = 1st;
say @foo.resolve $nth; # 5 # could be useful
# In normal situations, one would of course use:
# for @foo Y @bar - $foo, $bar { ... }
# but that is besides the point.
So we've come up with two mutually exclusive schemes for ordinal indices,
depending on which of 0th or -1st refers to the last element of a list.
There's a third option where the last element isn't given an ordinal at
all; but I doubt that anyone would prefer this, even as a second choice.
I used to think I wanted 0th to be the 0th (one before the first),
because 1nd + $foo could logically only mean (1 + $foo)th. However, if
th is a method of Number, you can just use literally (0 + $foo).th, and
there is no need for a 0th in this anymore.
Still, though -1st seems more logically to me, especially since +1st
isn't 0-based either.
if we want to look at the next existing element, we can say (1 +
1).th; if we want to look at the element whose index is one higher
than the first index, we can say 1.st + 1.
I read this three times, but don't get it. Can you please explain what
the difference is between the element after the 1st and the element
whoso index is one higher than the 1st's?
Juerd
Re: more ordinal discussion
Michael Homer skribis 2004-09-08 15:54 (+1200): I think (correct me) what he's getting at here is a sparse array 1=a, 3=b, 4=c where 2nd is 'b' (the second item) but 1st+1 is undefined (there is no index 2). I don't know how well that scheme works from a comprehension point of view though, it seems a little confusing. Oh my, sparse arrays. Isn't that what we have hashes for? Juerd
Re: But is it intuitive?
Aaron Sherman skribis 2004-09-14 14:02 (-0400):
qr{(fo*) ({$1 ne 'foo'})}
What is the second set of parens for? Will the following suffice?
rx/ (fo*) { $1 ne 'foo' } /
And it is because of the lack of anchors that this won't work as
expected?
rx/ !before foo fo* /
Juerd
Re: Still about subroutines...
Jonathan Scott Duff skribis 2004-09-16 13:44 (-0500): Speaking of which ... why is it that $?foo and ?foo became $foo and foo respectively? perlcheat is one page. I hope that when Perl 6 is around, I can summarize all uses of and on one page. The second page will be for the rest of the syntax :) Juerd
