feather.perl6.nl decommissioned
Hi all, Just a short message to let you know that the server(s) known as feather will be shut down, permanently, 2015-03-31. All data will be deleted, so if there's anything in your home dir that you still want to have, get it now. If you have any DNS records pointing to any of these addresses, please remove them, because the IP addresses may be repurposed: - 193.200.132.135 - 193.200.132.142 - 193.200.132.146 - 2a02:2308:10::f:1 - 2a02:2308:10::f:2 - 2a02:2308:10::f:3 - 2a02:2308:10::f:* - 2a02:2308:10::f:*:* Feather has been online since 2005. There's a new server, run by Moritz Lenz. If you want access to the new server, read about signing up at http://perlgeek.de/blog-en/perl-6/2014-community-server-live.html I'm sending this to perl6-language, because that's where the original feather announcement was posted. -- Met vriendelijke groet, // Kind regards, // Korajn salutojn, Juerd Waalboer ju...@tnx.nl TNX
Re: What is the self pragma?
Larry Wall skribis 2008-04-12 9:26 (-0700): Now that people have gotten used to self.foo and $.foo, it may be that the demand for the pragma has fallen off a bit... :) I hope it has. Perl 6 would be less confusing without this pragma. -- Met vriendelijke groet, Kind regards, Korajn salutojn, Juerd Waalboer: Perl hacker [EMAIL PROTECTED] http://juerd.nl/sig Convolution: ICT solutions and consultancy [EMAIL PROTECTED]
Re: Nomenclature Question - BEGIN etc.
My suggestion: consequential blocks -- Met vriendelijke groet, Kind regards, Korajn salutojn, Juerd Waalboer: Perl hacker [EMAIL PROTECTED] http://juerd.nl/sig Convolution: ICT solutions and consultancy [EMAIL PROTECTED]
Re: [svn:perl6-synopsis] r14489 - doc/trunk/design/syn
[EMAIL PROTECTED] skribis 2008-01-10 16:14 (-0800): +(Note that C.bytes is not guaranteed to be well-defined when the encoding +is unknown. (This message is a mess; in my defense, it's 5:30 AM here. I just had to respond, because I have the feeling Perl 6's unicode model is going exactly the wrong way if I interpret this diff correctly.) What if the encoding is known, but by accessing the .bytes level one breaks the consistency? Rather than a scheme where unicode text strings have an encoding property, I think a scheme where unicode text strings are just unicode text strings is better: the *binary* strings can have an encoding property. So: * A Str is a sequence of codepoints, and provides grapheme/glyphs if requested. It does not have bytes, and the internal encoding does not show except through introspection. The internal encoding can theoretically change at Perl's will. * A Buf is a sequence of bytes, not codepoints or characters of any kind. * A Buf with a defined .encoding: - does Str, with transparent decoding (with validity checking) - also, transparent encoding my Str $foo = H€łłø wöŕłđ; my Buf $bar; $bar.encoding = utf-8; # or however a decoding is declared $bar = $foo; # gets utf-8 encoded $bar.bytes; # [ H, \xE2, \x82, \xAC, ... ] $bar.codes; # [ H, €, ł, ... ] $foo.codes eqv $bar.codes # true $foo.bytes; # Huh? What? Makes no sense - fail All byte-oriented mechanisms can have an encoding defined somehow: filehandles, environment variables, Bufs, system call wrappers. I think that would work much easier than giving Strs encoding properties. When writing to a file, or a Buf, you're probably using a lot of Strs, and it would make no sense to have them all encode differently. Likewise, when reading from IO, a Buf, or anything byte-oriented, the encoding will have to be known to decode it. I fail to see how giving a Str any .bytes or .encoding might make sense: these belong to byte strings, not text strings. Making it easy to work with the internal byte buffer will take away means of optimization, ease of changing our mind about the best implementation encoding, and either security or performance (Either you check the consistency every time you do something and everything is slow, or you don't, and everything is potentially insecure when passed on to other code.) Of course, the current internal encoding and byte buffer should be accessible somehow, and maybe even writable for the brave of heart, but IMO certainly not with the way too encouraging .bytes thing - I'm tempted to call for .HOW.internal. I think that a Buf with a defined encoding should check whether the data is valid when reading, but a Str can skip this: Perl itself put the data there, and trusts its own routines for much better performance. Please, don't give Strs any byte semantics, but do give Bufs support for transparent en-/decoding, and perhaps even unicode semantics. -- Met vriendelijke groet, Kind regards, Korajn salutojn, Juerd Waalboer: Perl hacker [EMAIL PROTECTED] http://juerd.nl/sig Convolution: ICT solutions and consultancy [EMAIL PROTECTED]
Re: xml and perl 6
Danny Brian skribis 2007-11-29 10:57 (-0700): Perhaps a pro XML-er can weigh in. Unlike many others on this list, I use XML for almost everything. I think the point is what you're saying here above, Jim. The benefits you describe of a native XML data type boil down to a) encouraging a common approach to processing, and b) not having to import modules. And it does, but it doesn't have to be native. It can be just standard, including de facto standard. Yes, XML is essential for many programmers. Yes, having a standard XML data type can certainly improve things for many people. But why on earth would it need to be bundled with Perl? All you need to make something the de facto standard, is to be good and the first, or better than all existing options. DBI is Perl 5's primary database API. Very few people ever consider using anything else. I think as many people use DBI as use XML in some way. It is NOT bundled with Perl, and has never been. Yet it is extremely popular. Do the same with XML, please. If anyone else reading this, feels like building this data type, with the code to back it, by all means please start today. But putting it in the core only helps in the forcing-down-one's-throat area. It doesn't improve maintenance, flexibility, or usability one bit. Encouraging a common approach is not an easy or necessarily smart thing in the XML space. Still, though, XML is very probably flexible enough (with its roles) that a single XML data type can still be a good idea. Something representing an XML element with its children is incredibly useful when standardised. And if it doesn't do what you want, just add a role that makes it do that. A native XML type would only serve to antiquate Perl 6 long before it's time (!), and is therefore a ... nonstarter. Amen. -- Met vriendelijke groet, Kind regards, Korajn salutojn, Juerd Waalboer: Perl hacker [EMAIL PROTECTED] http://juerd.nl/sig Convolution: ICT solutions and consultancy [EMAIL PROTECTED]
Re: Ternary endweight alternative?
raiph skribis 2007-06-29 1:10 (-0700):
system('cls' !! 'clear' ?? ($?OS eq any MSWin32 mingw));
I read this as: given 'cls', use 'clear' if not, and ($?OS eq ...) if
so. Which doesn't make sense, because 'cls' is always true.
Note that I ofter write ternaries on three lines:
condition
?? if_so
!! if_not
And that's probably why I read your example as
condition
!! if_not
?? is_so
Instead of
if_not !!
if_so ??
condition
(I have no idea how this could be indented in a useful way.)
And this ambiguity is, IMO, more than enough reason to disallow this. As
for the end weight problem, try formatting the thing in three lines like
I do. That quickly makes it readable again:
system $?OS eq any MSWin32 mingw
?? 'cls'
!! 'clear';
This puts system, cls and clear all on the left side.
--
korajn salutojn,
juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig
convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: Web Module (Was: Perl6 new features)
Hakim Cassimally skribis 2007-06-25 9:57 (+0200): Releasing a language without a useful, easily installable library bundle could quite reasonably be construed as a stupid business practice. A useful, easily installable library bundle does not have to be in the core distribution. Debian already has its own split between perl and perl-modules. This is a great scheme that allows Debian to use Perl in the base system, without requiring the loads of unused modules that usually come with it. If you need those modules, though, you can easily install them. It would be great if Perl had this by default, because it would make it easier for vendors to choose to use Perl in their base system. It would also make Perl a more attractive choice for embedded systems. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: Referring to source code within Perldoc: the new A code
Smylers skribis 2007-06-21 21:33 (+0100): That doesn't follow. It's an opinion. I disagree. perldoc.perl.org was started by JJ, gained popularity, and then got awarded the official blessing of the onion. Over the years there have many several sites with Perl documenation. That's not a way of documenting things, it's just an interface to existing documentation. It provides no semantic search featurewhatsoever, and can't, because Perl's documentation wasn't built like that. The documentation for CGI is very different from the documentation for IO::Socket::INET, although both are (can be) OO. That's okay if you read the things like a book, but structured documentation with structured interfaces allow readers to more easily use the documentation for reference. Let the same thing happen with Perl 6: allow innovation, and if you, or Markov, or anybody creates a particularly fine site then people will admire it, use it ... and then perhaps it can be made official. Sure, but it's a huge chicken-egg problem that doesn't have to exist. There isn't really anything to be gained by pre-empting this and picking something initially. I disagree very strongly. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: POD - Code entanglement
Thomas Wittek skribis 2007-06-14 17:18 (+0200):
So maybe directives like method, sub, attribute, class etc. might be a
better choice regarding semantics.
Yes, a better choice indeed. But I would still not be happy with it,
because there would still be a lot of code duplication.
method foo (:$bar = 5) { ... }
I don't want to have to mention *again* that the thing is a method,
and that it is called foo, that it has a named argument identified
as $bar, which defaults to 5.
This is why I (long time ago) suggested is documented. Like Mark, I do
not really care about the actual syntax much:
method foo is documented(Foos its argument interactively)
(
:$bar = 5 is documented(Object to be fooed),
# I'm not sure about the precedence of is.
) {
...
}
The backtick is rather cute and saves a lot of typing. It's like a
comment (#), but ends up as *external* documentation. That's nice.
Semantics are very useful in documentation, why throw them away?
Why not have both? With normal POD as suggested by Damian, you could
still generate it from something else. A few macros could help ignore
the inline documentation.
--
korajn salutojn,
juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig
convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: Generalizing ?? !!
Zev Benjamin skribis 2007-06-11 0:57 (-0400): ?? and !! could always return some kind of result object that boolizes to true or false. Can we *please* keep simple things simple? -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: PERL arrays
[EMAIL PROTECTED] skribis 2007-06-05 14:36 (-0700): how do i declare loop through and print a 4 dim array in PERL Please note that Perl 6 is still not an acronym. It's not PERL, but Perl. Datastructures are documented in Synopsis 9, at http://dev.perl.org/perl6/doc/design/syn/S09.html I couldn't find how to loop over multidimensionally shaped arrays; maybe you can and maybe someone can show an example. ...Are you sure you were asking about Perl 6? -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: propose renaming Hash to Dict
Dictionaries are usually alphabetically ordered. Hashes are not. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: Is Perl 6 too late?
Thomas Wittek skribis 2007-05-14 0:42 (+0200): excessive use of special characters (/\W/). This seems to be I don't like regexes. Ignoring for now that Perl 6 regexes will be more verbose and thus easier to read for someone without much prior exposure to them, what would you suggest as an alternative to regex matching? One of the common alternatives is to iterate over a list of characters, possibly using an index. Would you say that a screen page full of such code is easier to read and maintain than a single regex on a single line? Many languages have regexes, even the cleanest among them. And they're all as messy as Perl's. They're often more verbose on the outside, which can result in something like foo.match(/foo/) instead of foo =~ /foo/, but the /foo/ part is most important here. If you don't recognise what that is, it doesn't matter if .match or =~ was used. Many languages have regexes, but Perl was probably the first to apply them heavily in normal programming. And nowadays, they're so ubiquitous that it's hard to find a language without Perl-ish or Perl compatible regexes. Why do you think this is? I think it's kind of funny that indeed exactly the most cryptic part of Perl's syntax is copied to so just about every modern programming language, while at the same time Perl is constantly criticized for using special characters so much. No, special characters aren't a problem. They are the fundament of a very powerful and expressive syntax. Just don't try to understand a screen full of them all at once -- realise that in another language, the first three lines would sometimes already fill the same screen, and adjust your reading speed. On the other hand, the overall structure of a program is often more obvious, exactly because so much more fits in one screenful. In Perl it is often not needed to refactor something to many tiny subroutines with verbose identifiers, just for legibility. One thing stays true, though: Perl is very hard to read for someone who doesn't know Perl well enough. But that's practically true for almost language, be it Python or Japanese. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Sigils by example (was: Re: Is Perl 6 too late?)
Thomas Wittek skribis 2007-05-14 22:20 (+0200): But I think that the name of an identifier (noun/verb, single/plural, the meaning of the word) already gives enough context to understand what type it is. So is user_id a variable or a type? How about substring or document? Is new a function, or a variable? How about old? Is is_valid a function that determines whether something is valid, or a variable holding the result of this test? When you have update(delete_random), where both update and delete_random are functions, does this pass the function delete_random to update, or does it first delete something, and then pass the resulting value to update? Don't forget that one of the important decisions in Perl was that we don't always like to use parentheses, because that clutters code (and you don't want that!!). Given HTML Element, is HTML the type and Element the variable of that type, or is Element the type, and HTML the variable (for example, to hold the html element object)? Is pid a variable you used yourself, for example as the return value from fork, or does pid give you the pid of your current process? And if the latter, is that by calling the pid function, or because pid is a variable? Doesn't count input look wrong to you? It should, because count is a hash! By the way, what would input be? And how on earth would you write object.foo(), where foo is a variable holding a reference to a method, not the name of the method, if you had no sigils? ... ... ... ... ... | So is user_id a variable or a type? How about substring or | document? The Perl Way: $user_id is a variable, $substring is a variable, $document is a variable. user_id is not a variable, substring is not a variable, document is not a variable. | Is new a function, or a variable? How about old? The Perl Way: $new is a variable, $old is a variable. new is not a variable, old is not a variable. | Is is_valid a function that determines whether something is valid, or | a variable holding the result of this test? The Perl Way: $is_valid is a variable. is_valid is not a variable. | When you have update(delete_random), where both update and | delete_random are functions, does this pass the function delete_random | to update, or does it first delete something, and then pass the | resulting value to update? The Perl 6 Way: update(delete_random) passes the function delete_random to update. update(delete_random) calls the function delete_random, and passes whatever it returned to update. | Given HTML Element, is HTML the type and Element the variable of that | type, or is Element the type, and HTML the variable (for example, to | hold the html element object)? The Perl 6 Way: HTML $Element is a variable of the type HTML. $HTML Element is a syntax error caught early by the compiler. (And that's really great if your native language makes you think the other way around than the programming language wants you to.) | Is pid a variable you used yourself, for example as the return value | from fork, or does pid give you the pid of your current process? | And if the latter, is that by calling the pid function, or because | pid is a variable? The Perl Way: $pid is a variable that you set yourself. pid is not a variable. $*PID is a variable, that represents the pid of your current process. | Doesn't count input look wrong to you? It should, because count is a | hash! By the way, what would input be? The Perl Way: %count $input (or %count input) looks wrong, error caught even before compile time, programmer time and energy conserved. | And how on earth would you write object.foo(), where foo is a variable | holding a reference to a method, not the name of the method, if you had | no sigils? The Perl Way: $object.foo() calls the method called foo. $object.$foo() calls the method that is in the variable $foo. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: Is Perl 6 too late?
Thomas Wittek skribis 2007-05-14 22:31 (+0200): $.but! (*adding$ %*characters _+that^# $might) @#not_ !#be() !necessary_ *#$doesn't! *(make) [EMAIL PROTECTED] =_easier Those characters are meaningless. The many symbols in Perl 6 have very distinct meanings, which makes them very powerful tools! Oh, I thought Perl was a programming language. My fault. Apples and oranges. There is a reason that C programmers don't throw away their source code after compiling it. While in some companies, writing software is indeed a unidirectional process, most companies that wish to survive have to maintain what they wrote, and then you also have to read it. Programming languages and spoken languages are both read by human beings, so they should still be easily parsed by these creatures. Most modern scripting languages don't need the semicolons. I think there's no plausible reason for them. They typically have a line continuation character instead of a semicolon, though. However, like the previous sentence, and this one too, actually, sometimes there is a line break in between. Again, written language can be a nice example, because if we had line \ continuation characters in here, it would suddenly look a lot \ different. Did you, while reading this, pause, just before different? -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: Sigils by example
Thomas Wittek skribis 2007-05-15 0:48 (+0200): The Perl Way: $object.foo() calls the method called foo. $object.$foo() calls the method that is in the variable $foo. My way: someref = somemethod object.someref() Of course you could argue that you don't know in advance, if object has a method with that name, so you cannot manually avoid the conflict. Indeed. Now you have to know your object very well, and avoid all of its method names for variable names. For example, an HTTP::Request object has a .headers method. If Your Way were in effect, I could no longer safely use the name headers for my own variables, and then still call the headers method on the object. Perl allows both avoiding clashes and not-avoiding clashes. Your way only strictly requires the former programming style. And since my preferred style is different, I'm glad you're not designing Perl 6. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: Sigils by example (was: Re: Is Perl 6 too late?)
Jonathan Lang skribis 2007-05-14 14:52 (-0700):
Good examples. Now could you provide some to explain to me why it's
important to distinguish between '$', '@', '%', and ''?
It's useful code self documentation, but not very important, in my
opinion.
If you have sigils, it makes sense to have different sigils for
different things, because that allows very nice shorthands (remember how
this thread was originally more or less about avoiding clutter?) like:
sub foo (@bar, $baz) { ... }
And of course, different behaviour in list context:
my @quux = (@foo, @bar); # These arrays foo and bar flatten
my @quux = ($foo, $bar); # These arrays foo and bar do not
That's a subtle yet very useful distinction.
But this is just very handy, not important.
--
korajn salutojn,
juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig
convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: Is Perl 6 too late?
Thomas Wittek skribis 2007-05-15 1:03 (+0200): On the other hand, the overall structure of a program is often more obvious, exactly because so much more fits in one screenful. My suggestions won't have an impact on the expressiveness of Perl. Not so. Consider /@foo/, which is an alternation of all the elements of @foo. That's not just interpolation, it's something very smart, and even without seeing the context that this regex is in, I know how to read this. I don't have to scroll back up to find out that foo was once assigned an array. So in many cases you might have even less characters on your screen. Less characters isn't always better. Often it's worse, sometimes it's better. It appears to me a hell of a job to find out when it's what, and I think Larry figured it out quite well. Of course some special character sequences would be replaced by word character sequences, but that won't fill your screen by a magnitude. Of course. Every symbol can be substituted for a word comma but that doesn apostrophe t automatically make code easier to read period I think a language needs a good balance between symbols and letters comma and for a programming language comma I think alternating between the two is close to a perfect balance comma whereas in human languages once, every $few (words) is.probablybetter; period -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: Sigils by example
Thomas Wittek skribis 2007-05-15 1:52 (+0200): Would it be a good idea to call methods on objects, that never thought of this methods? Absolutely! Roles can be used for that too. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: What should file test operators return?
Damian Conway skribis 2007-04-13 20:01 (+1000): Maybe there also needs to be a boolean conversion for printf (perhaps %t for true?): I often use [ ] and [X] to represent true and false in text output. They resemble checkboxes. I don't think printf needs a boolean output template, but it would be nice if it were configurable. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: [svn:perl6-synopsis] r14357 - doc/trunk/design/syn
[EMAIL PROTECTED] skribis 2007-03-28 13:17 (-0700): +block) early using the Cbreak verb. More precidely, it leaves the precisely? -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED] Ik vertrouw stemcomputers niet. Zie http://www.wijvertrouwenstemcomputersniet.nl/.
Re: lexical subs
Just a short note: please, if this is implemented, make sure that either Perl 6 conforms to Perl 5 behaviour, or the other way around. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED] Ik vertrouw stemcomputers niet. Zie http://www.wijvertrouwenstemcomputersniet.nl/.
Re: lexical subs
Juerd Waalboer skribis 2007-03-09 21:27 (+0100): Just a short note: please, if this is implemented, make sure that either Perl 6 conforms to Perl 5 behaviour, or the other way around. Wanted to CC this list, but by accident replaced the To instead. Now CC'ing p5p. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED] Ik vertrouw stemcomputers niet. Zie http://www.wijvertrouwenstemcomputersniet.nl/.
Re: [S09] Whatever indices and shaped arrays
Jonathan Lang skribis 2007-03-06 13:35 (-0800): Could someone advise me on how to create patches? Single file: diff -u oldfile newfile Entire tree: diff -Nur oldtree/ newtree/ See also diff(1), and note that when diffing trees, you want to distclean them first :) -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED] Ik vertrouw stemcomputers niet. Zie http://www.wijvertrouwenstemcomputersniet.nl/.
Re: for ... else
Thomas Wittek skribis 2007-03-03 23:17 (+0100):
Larry Wall:
: if ($item = 'foobar') {
== of course ;)
Or how about eq? :)
--
korajn salutojn,
juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig
convolution: ict solutions and consultancy [EMAIL PROTECTED]
Ik vertrouw stemcomputers niet.
Zie http://www.wijvertrouwenstemcomputersniet.nl/.
Re: Closures, compile time, pad protos
Yuval Kogman skribis 2006-11-22 16:01 (+0200):
my $x ::= 3;
sub foo { say ++$x };
Why would you be allowed to ++ this $x? It's bound to an rvalue!
--
korajn salutojn,
juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig
convolution: ict solutions and consultancy [EMAIL PROTECTED]
Ik vertrouw stemcomputers niet.
Zie http://www.wijvertrouwenstemcomputersniet.nl/.
Re: Interrogative statements
Jonathan Lang skribis 2006-10-19 18:27 (-0700):
Let's say that I want
$expression?;
to mean the same thing as the statement
$_ = $expression;
That is, any statement that ends with a '?;' instead of a ';'
evaluates in scalar context instead of void context and stores the
result as the topic '$_'. (I was going to suggest '?' intead of '?;',
but a quick review of the specs pointed out that this would be
ambiguous wrt the ? prefix operator.)
Prefix and postfix live in different places, so you can just use a
normal postfix operator:
sub postfix:? ($lhs) {
$CALLER::_ = $lhs;
}
42?;
say($_); # prints 42!
# This code is not futuristic. It already works with Pugs.
But you wanted a statement thingy. That would require that you modify
the Perl 6 grammar. Yes, you can do that with Perl 6.
--
korajn salutojn,
juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig
convolution: ict solutions and consultancy [EMAIL PROTECTED]
Ik vertrouw stemcomputers niet.
Zie http://www.wijvertrouwenstemcomputersniet.nl/.
Re: [svn:perl6-synopsis] r12875 - doc/trunk/design/syn
[EMAIL PROTECTED] skribis 2006-10-09 0:22 (-0700):
P5's s[pat][repl] syntax is dead, now use s[pat] = repl
Why keep the s?
substr works perfectly as both rvalue and lvalue, and I think m[], also
known as //, can do the same. No need to do things based on delimiter
(bracket versus non-bracket), then.
+ s[pattern] = doit()
m[pattern] = doit();
/pattern/ = doit();
+ $str.subst(/pat/, replacement);
+ $str.subst(/pat/, {replacement});
+ $str.=subst(/pat/, replacement);
+ $str.=subst(/pat/, {replacement});
Hmmm... I have no answer for the non-mutating version, but:
$str.match(/pat/) = replacement;
$str.m(/pat) = replacement;
+This is not a normal assigment, since the right side is evaluated each
+time the substitution matches
Can't this be generalized somehow? Return an lvalue proxy, like substr
does, and make thunking the default for certain LHS types.
I don't like special syntax that looks like normal syntax.
--
korajn salutojn,
juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig
convolution: ict solutions and consultancy [EMAIL PROTECTED]
Ik vertrouw stemcomputers niet.
Zie http://www.wijvertrouwenstemcomputersniet.nl/.
Bytes make no sense on text strings
I don't understand why having :bytes for things like s/// would be a good thing. A Str doesn't have bytes, just like how a Buf doesn't have characters. To get bytes out of a Str, you need an encoding. There will be an internal encoding, but exposing it in this way is probably just asking for a lot of trouble: inconsistent (invalid) data that internals rely on, and the inability to switch the internal encoding later. Or, for example, to keep things 8bit encoded as an optimization until something demands more than that. As I understand it, a Str is a unicode string, not a UTF-8 string. I propose that using :bytes on a text string throws an exception. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED] Ik vertrouw stemcomputers niet. Zie http://www.wijvertrouwenstemcomputersniet.nl/.
Recursing? hypers
S03 says that hypers recurse into subarrays. That's a nice and useful feature, but that not-recursing is even more useful. Especially given that many objects will probably does Array, you want to be explicit about recursion. S03 doesn't give a way to avoid recursion. I suggested on #perl6 that standard hypers do not recurse, and a new operator: double hypers. These are the same, but they do recurse. From my point of view, hypers should operate on lists, not arrays. Recursive hypers would work on arrays because arrays are single element lists. Audrey agreed. It would probably be useful to allow combinations of recursive and non-recursive hypers. »+«# do not dive into arrays »»+«« # do dive into arrays, on both sides »+«« # dive into arrays only on the RHS »»+« # same, but LHS 42, 15 »+ 1 # 43, 16 ( 42, 15 ) »+ 1 # 43, 16 [ 42, 15 ] »+ 1 # 2 [ 42, 15 ] »»+ 1 # [ 43, 16 ] The ASCII variant is a bit big, but that's okay huffmanwise, IMO. Recursion can be a pretty big operation anyway. Being explicit about that is good. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED] Ik vertrouw stemcomputers niet. Zie http://www.wijvertrouwenstemcomputersniet.nl/.
Re: Comments in qw// or qqw//
demerphq skribis 2006-10-08 16:01 (+0200): If its not obvious why this would be nice: qw() is often used as a list constructor for things like options or hash elements, and it would be convenient to have a way to selectively comment out certain elements. In perl 5 you have to CP out the offending part and then stick it in a comment later on. Or hand hack a custom qw//, which for quick fixes, and stuff like that is a bit annoying. I think that this feature fits perfectly in qqw// or «», which is already dubbed shell-like. Every shell that I know lets you comment things. If # is special, you need a way to escape or quote it. qqw already provides this. I also believe that qqw is much more likely to be used for constructing hashes than qw, exactly because of the quoting feature. Shells require comments to be separated from other characters with whitespace. I think this is a good feature to steal. my %foo = « foo bar baz# And quux xyzzy# comments blah 42#15# go red #FF# here :) »; works like my %foo = ( foo = bar baz, # And quux = xyzzy,# comments blah = 42#15,# go red = #FF, # here ); but with much less punctuation and finger strain. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED] Ik vertrouw stemcomputers niet. Zie http://www.wijvertrouwenstemcomputersniet.nl/.
Re: S5: substitutions
Jonathan Lang skribis 2006-10-07 15:07 (-0700):
Translating this to perl 6, I'm hoping that perl6 is smart enough to let me
say:
s(pattern) { doit() }
Instead of
s(pattern) { { doit() } }
I would personally hope that Perl isn't that clever, but treats all
bracketing delimiters the same there. Partly for future-proofness,
partly for least surprise.
--
korajn salutojn,
juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig
convolution: ict solutions and consultancy [EMAIL PROTECTED]
Ik vertrouw stemcomputers niet.
Zie http://www.wijvertrouwenstemcomputersniet.nl/.
Re: Nested statement modifiers.
Damian Conway skribis 2006-10-03 16:40 (-0700):
Which can also be written as:
do { do { say 1 if 1 } if 1 } if 1;
Sorry, no it can't. From S4
(http://dev.perl.org/perl6/doc/design/syn/S04.html#The_repeat_statement):
Unlike in Perl 5, applying a statement modifier to a do block is
specifically disallowed
Oh. For some reason, I thought this exception was for loops only.
--
korajn salutojn,
juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig
convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: Nested statement modifiers.
Aaron Sherman skribis 2006-10-03 13:46 (-0400):
In Perl 6, that's simplified to:
{{say 1 if 1}.() if 1}.() if 1;
Which can also be written as:
do { do { say 1 if 1 } if 1 } if 1;
Which if crammed together the way you wrote it, turns into:
do {do {say 1 if 1} if 1} if 1;
Or perhaps you like this even better:
do{do{say 1 if 1}if 1}if 1;
I find that hard to guess. I personally think the statement is confusing
anyhow, with or without whitespace. Besides, stacked if-statements
really don't make any sense. We've already got and for that! :)
say 1 if 1 and 1 and 1;
Oh, and 1 is always true. So you could just write:
say 1;
Which seems like a great improvement.
It may be more useful to discuss this issue using less contrived
examples. :)
--
korajn salutojn,
juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig
convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: Dumb list-flattening question.
Mark J. Reed skribis 2006-09-21 9:53 (-0400): If I have two arrays @a and @b and I wish to create a two-element list out of them - a la Perl5 ([EMAIL PROTECTED], [EMAIL PROTECTED]) - what's the correct way to do that in Perl6? If it's still ([EMAIL PROTECTED], [EMAIL PROTECTED]), then what do we call what the \ is doing there, now that references are supposed to be a behind-the-scenes automagical thing? They're captures. I personally wouldn't mind unary $, to supplement unary @ and %. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: renaming grep to where
Jonathan Lang skribis 2006-09-19 16:39 (-0700):
Anyway, it's not clear to me that grep always has an exact opposite.
I don't see why it ever wouldn't: you test each item in the list, and
the item either passes or fails. 'select' would filter out the items
that fail the test, while 'reject' would filter out the ones that pass
it.
There's a neat trick for this: .grep:{ not ... }
HTH :)
--
korajn salutojn,
juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig
convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: -X file test operators
Aaron Sherman skribis 2006-09-15 15:28 (-0400):
I didn't see this going back, sorry if I missed someone sending the mail.
Sorry. I promised to do it, but have so far lacked tuits and more or
less forgot all about it. Thanks for bringing it up!
There was a discussion on IRC on Sept 9th about the -X filetest
operators between at least audreyt, Juerd, myself and markstos. The
problem with these operators was that they conflicted in some cases with
the parsing of unary -, such as:
foo(-?? * 2 * $r);
or just:
sub x($n) { $n*2 }
foo(-x $number);
The problem was that -e was made a prefix operator. To make it work as a
method (i.e. for easy $_ operations), this implied that unknown postfix
ops would be mapped to prefix ones.
e.g.
-e $foo
$foo.-e
I think it's a bad idea to do this for all operators, because then we
take away future compatibility. If there's any area in which we still
have room to expand, it's postfix ops, and as they're nice and
methodish, we shouldn't grab the entire ASCIIbet already.
So, we discussed making -e a real method, which would imply that
identifiers can begin with -. That's nice, except that it forces
whitespace for prefix -, and that gets really annoying with things like
-Int. We also discussed -e for a while in the -2.71828183 sense, which
some believed should also be possible.
1. All file tests have long names as methods which P6 prefers:
$file.file_exists;
$file.is_directory;
$file.file_bytes;
2. That these methods be provided on Str, any IO that knows how to find
its filesystem represenation, File* where applicable.
And we discussed my bad feeling about polluting either the main or the
Str namespace with numerous file methods. I proposed .file, which
returns an unopened filehandle. This object can easily buffer stat info,
and could stringify to the filename (or, in case of STDOUT or a socket,
some other descriptive text) later, for easy verbose output.
e.g.
$filename.file.exists;
$filename.file.size; # perhaps bytes.
and
my $fh = $filename.file;
$fh.open or fail;
while ($fh.readline) { ... }
in addition to the existing
my $fh = open $filename or fail;
while (...) { ... }
I acknowledge that files can be anonymous, but they usually did have a
name when opening. Stringification to something useful is a good idea,
and it doesn't always have to match the current actual filename. We
could prepend \0 to special names like those for STD* and sockets. This
generally doesn't do anything special to terminals or web pages, but
does make string matching fail, as well as opening them as files, as no
system that I know of allows \0 in a filename.
Someone said it should probably be $filename.as(File) or something, but
I didn't like that because that takes away all the nice
bracketlessness and typability. Fortunately, Audrey mentioned that the
current trend is towards $filename.File anyway, for casting.
I think the concensus was that we don't really need -e and alikes to be
available by default, but we all wanted them for short scripts and
oneliners. A cheat mode pragma could easily solve this problem. I had
already been pondering the idea, in my head called use cheats;. It
would also provide useful short aliases like mv rm ls. Someone
mentioned that these functions, and -e alikes, are all shell-like
syntax, and pointed us to Perl 5's Shell.pm. It could also re-introduce
$$, in a kind of no English sense. Something like that would be great,
but a bit more thought out in a Perl 6 context. People agreed that such
a module or pragma should be enabled by default when the command line -e
was given (note: that's not file test -e.).
Our final conclusion was that we should probably parse postfixes like:
^\w+$
Try method call first, if it doesn't exist, try function call.
other
Always interpret as postfix operator. Because this could begin with
\w+, it takes precedence over pure ^\w+$.
and that we have four things we could do with -e:
1. Get rid of it entirely. Normal methods and/or use Shell fill the gap.
2. Install it as a prefix op, not as a postfix op. To get to $_, write
-e $_ explicitly.
3. Install these as prefix ops, and as postfix ops, but not as a general
rule for all prefix ops.
4. Rename the dash to underscore, use normal methods, and get used to _e
instead of -e.
I don't like 3 because it's duplication and special casing.
I don't like 4 because it would pollute namespace.
I like 1 because it encourages better programming, and because I really
like the idea of $name.file.exists.
I like 2 because I almost never default -e to $_ anyway, and -e $_ or
-e($_) isn't that bad.
My favourite is 1, followed by 2.
--
korajn salutojn,
juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig
convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: -X file test operators
Larry Wall skribis 2006-09-15 14:03 (-0700): To which I already responded with 5: To write any prefix op as postfix, you should put it in quotes, which gives us .'-e' and .'@' and the like. (And also giving us a general way of isolating the method name from the .* variants, not to mention generating method names by interpolation without needing a temp variable.) First impressions: Ugly, hard to type, not a solution for -e, weird syntax. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: -X file test operators
Jonathan Scott Duff skribis 2006-09-15 16:50 (-0500): To which I already responded with 5: To write any prefix op as postfix, you should put it in quotes, which gives us .'-e' and .'@' and the like. (And also giving us a general way of isolating the method name from the .* variants, not to mention generating method names by interpolation without needing a temp variable.) Ugly, hard to type, not a solution for -e, weird syntax. How is it not a solution for -e ? I thought it a perfectly good response to the problem. And, in fact, it solves a more general problem than just the -X ops. It's a solution for some of the -e problems, not all. It doesn't fix that unary minus needs whitespace to be used with certain identifiers for functions. Also, it doesn't fix the shorthand syntax for testing -e on $_ at all, because .'-e' is no better than -e($_). Well, okay, 1 character, but it costs a lot of grokability. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: Outlaw to declare a lexical twice in the same scope
Steve Lukas skribis 2006-09-11 4:35 (-0700): If you declare a lexical twice in the same scope, it is the same lexical I would argue for: If you declare a lexical twice in the same scope, it is an error! I agree. The reason that I love my $foo is that it always gives me a new variable. I can safely use this anywhere in the code, without any need to read all the existing code. This is, for me, one of the most important aspects of having lexicals in the language: I can add (debugging or otherwise temporary) code to any existing project without getting to know the structure of the project's code. Perl 5 warns that a second declaration masks the first. This is fine: it tells me about the stupid mistake I made and lets me fix it. A compile error would be fine too. In fact, even better because then my probably broken code isn't executed then. Just ignoring the declaration is bad, just like implicit declaration. If we do this, we get only typo checking, and none of the other nice protection that lexical declaration gives us. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: Naming the method form of s///
Audrey Tang skribis 2006-09-01 19:10 (+0800): Because of the awkward syntax that goes with a method: two parens, four delimiters, comma[s]?. .s(/bar/, baz); # 20 keypresses on a US keyboard Minor nit, but: .s: /bar/,'baz'; # 17 keypresses... And since it's something used a lot in expressions, you wouldn't use the parenless form of the method call much. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Naming the method form of s///
Luke Palmer skribis 2006-08-31 15:48 (-0600): I don't think using a method (even if called s) is good huffman coding. My expectation is that copying substitution will be used much - perhaps even more than mutating substitution! And so a method called s is poor huffman coding... why? (I do agree with your frequency conjecture) Because of the awkward syntax that goes with a method: two parens, four delimiters, comma[s]?. .s(/bar/, baz); # 20 keypresses on a US keyboard While a postfix operator, with the same .s feel, could allow .s/bar/baz/; # 12 keypresses on a US keyboard And since it's something used a lot in expressions, you wouldn't use the parenless form of the method call much. We need a quotelike construct for this form of s/// for exactly the same reason we need it for m// and the other s///. Our language deviates too much from being Perl if we had only method forms. $foo.match(/foo/); $foo.subst(/foo/, bar); $foo.=subst(/foo/, bar); That just isn't Perlish, at all. My suggestion for a s/// postfix op mainly stems from this argument, but I really also believe that ~~ and s/// is a farfetched combination. Perl 5's =~ was a binding operator, and s/// fit right in. But Perl 6's ~~ is a matching operator, and in my opinion should remain pure, and so: not mutate. I'm even a bit inclined to suggest that .m// should return matches, while ~~m// should return a bool. But ignore that for now :) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Naming the method form of s///
Michael Snoyman skribis 2006-08-31 15:13 (-0700): :g That said, I think to a certain extend it *is* a modifier on the match. It's saying match bar globally, and then subst says everything that the regex matched should be replaced by baz. I think that's a pretty intuitive way of handling the problem. It is indeed a modifier on the *match*, or the *substitution*. Just not on the *regex*. What you pass to a .subst method is a regex, not a match. The difference is that matches and substitutions are actions, while a regex is an object, i.e. data. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Naming the method form of s///
Jonathan Lang skribis 2006-08-31 15:35 (-0700): IIRC, :g is an adverb, and adverbs are merely syntactic sugar for named parameters. So perhaps the signature for the substitution method should include a slurpy hash of modifiers... In which case you'd end up parsing the keys, because we have stuff like :2nd and :3th. And if we're parsing anyway, you might as well pass in a string. Indeed, :g would only be syntactic sugar. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: but semantics (was Re: Naming the method form of s///)
Trey Harris skribis 2006-09-01 0:17 (-0700):
I think these semantics are Almost Right, but yet Entirely Wrong. The
problem is that Cbut reads to me as a *mutating* operator. That is, I
would expect the above code snippet to give me a C$z.y of 17, but leave
C$p.y as 0. Surely this is what one would expect from analogy of
In the terminology that I have been using, that would not be a mutating
operator, but a copying operator, exactly because the operand $p remains
untouched.
mutating:
sub foo ($foo is rw) { $foo = sqrt($foo) }
foo($bar);
$baz ~~ s/foo/bar/;
copying:
sub foo ($foo is copy) { $foo = sqrt($foo) }
foo($bar);
$baz.subst(/foo/, bar);
But yet Cbut with a closure doesn't copy, given the translation above,
or even allow modification, since Cgiven doesn't either. $_ (in the
above case, $p) is set to point to the same object, and so $p.y and $z.y
are both modified (or rather, they both refer to the same object, which is
modified during assignment).
In other words, I would actually expect
$x but { ... }
to translate to
do given $x - $_ is clone { ...; $_ }
Agreed that this would be much more useful.
where Cis clone is a conjectural way of calling .clone if the argument
is an object type but reduces to Cis copy if the argument is a value
type.
Oh, I like is clone with these semantics. Though everything is an
object, so you'd need a different explanation...
I do not think that Cbut should mutate its LHS, regardless what its RHS
is.
Agreed, and that's why $foo but s/// would be a reasonable replacement
for what's currently still $foo.subst(//, ''). subst doesn't mutate.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Contextual::Return (was Re: could 'given' blocks have a return value?)
Damian Conway skribis 2006-08-31 9:08 (+1000): return want.rw ?? $lvalue :: want.count == 2 ?? (7,11) :: want.item ?? 42 :: want.list ?? 1..10 ::die Bad context; s:g/::/!!/ # :) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Naming the method form of s///
Mark J. Reed skribis 2006-08-31 9:45 (-0400): According to S05, the string method equivalent of the s/// operator is named subst. (Just going by the spec here; the method doesn't exist yet in Pugs). I anticipate typos galore from the near-collision of names between subst and substr; perhaps replace would be a better name, even though it breaks the mnemonic association with s///? Another issue is how we're going to pass arguments to this method. s/// has very special syntax, that I don't think we can easily replicate. I personally still prefer $foo.s/// and $foo.=s///, because I don't think substitution belongs in a smart match op. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Naming the method form of s///
Mark J. Reed skribis 2006-08-31 10:29 (-0400): Another issue is how we're going to pass arguments to this method. s/// has very special syntax, that I don't think we can easily replicate. S05 says it's $str.subst(regex, string-or-block); presumably the flags would go on the regex? Ah, block. Still, though, How would you specify :g? It doesn't make a lot of sense on rx// -- just like you can't use it with qr// in Perl 5. I personally still prefer $foo.s/// and $foo.=s/// I don't really like the combination of quotelike and method call syntaxes. I would happily take s as a replacement for the method name, but I don't think it can happily coexist with the operator. I was thinking of a postfix op (not normal postcircumfix, but quoting). Postfix ops happen to be called with the dot too, but aren't necessarily the same as methods. because I don't think substitution belongs in a smart match op. Well, that's the reason for the method version in perl6. Which, AFAICT, returns the new string instead of the Match object, which is as it should be. The only thing I don't like is the name. :) No, the method just returns the new string. The inline substitution is still done with ~~ (although you can probably use .=subst too, but really I don't like that syntax at all.) I don't think using a method (even if called s) is good huffman coding. My expectation is that copying substitution will be used much - perhaps even more than mutating substitution! $foo.subst(/foo/, bar) $foo.s(/foo/, bar) $foo.s/foo/bar/ Hm. I don't know how but works exactly, but in the realm of syntactic sugar, this is appealing: $foo but s/foo/bar/ (Note that while but is long, it's extremely easy to type.) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: clarifying the spec for 'ref'
Richard Hainsworth skribis 2006-08-28 10:33 (+0400): --- | Class A| | -- | || Class B | | | -- | -- Your mail program is wrapping this in a way that renders it unusable. Please make sure you use a monospaced font, and do not exceed the wrapping limit (typically 72 characters). - -| Class D | | Class A | || | |---|-| || |-| | --|- | | ---|-|-|- | | | | Class B | | --| |Class C | I'm curious what this was supposed to look like. :) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: clarifying the spec for 'ref'
Luke Palmer skribis 2006-08-24 23:57 (-0600): Let's say our arrays are simple, for argument's sake: With a constant array, you can: * get its length * get the value of an element at an index With an array, you can: * get its length * get the value of an element at an index * set the value of an element at an index You define in terms of functionality, but don't provide an explanation for the chosen point of view. One could say that constant arrays protect against modifications, which normal arrays don't. Hence, constant arrays do *more*. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: clarifying the spec for 'ref'
Trey Harris skribis 2006-08-25 11:33 (-0700): Ok... same thing from a DBC perspective. Subclasses can add functionality (by AND'ing postconditions), or remove constraints (by OR'ing preconditions), but they can't traditionally remove functionality or add constraints. I just want to read about how that works. The keyword is traditionally. We're used to a dynamic language that bends the rules all the time, including runtime. Why would Perl stick to academic limitations, while optimizing for the most common use is the standard? my Array::Const @foo; @foo ~~ Array; # False?! Please, no. Though in practice I expect is ro to be used, not a subtype or subset. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: clarifying the spec for 'ref'
Trey Harris skribis 2006-08-25 13:26 (-0700): Explain to me how nontraditional DBC might work in an internally consistent way. Otherwise, this is hand-waving. :-) Perl *is* hand-waving.
Re: Pair of lists = list of pairs?
Mark J. Reed skribis 2006-08-23 17:43 (-0400): But is there an easy way in Perl6 to do it all in one go? Should this work? my %h = @k [=] @v; Hyper is not [], but . And = works perfectly in Pugs, and does exactly what you describe. [] is for reduction, and is prefix: [+] 1,2,3 Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: underscores in the core lib
Eric skribis 2006-08-10 10:22 (-0600): I think .valid is an excellent argument for underscores all by itself. I think it's an argument for reconsidering the name of that method. valueid is only 2 characters more. I'm personally against non-prefix underscores in any core identifier. I agree that valid to mean value ID is a bad idea, though. It's extremely ambiguous. I don't have any other arguments for _, but it would be interesting to hear the reasoning agianst it. Forbidden underscore encourages the designers to think much harder about the best name, because it automatically rules out things like valid if you stick to sanity. It may be so that value ID itself is a bad name. Also, having_underscores leads_to longer_names, in my experience. Longer names are great for my own code, but I want core stuff to be consise and short. On 8/6/06, Ashley Winters [EMAIL PROTECTED] wrote: On 8/6/06, Yuval Kogman [EMAIL PROTECTED] wrote: Please do not answer above the quote. Regards, Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: DOC: glossary
I haven't actually read your message, just the Subject, because I was just going to bed. Be sure to check out http://pugs.kwiki.org/?Perl6Nomenclature Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Synchronized / Thread syntax in Perl 6
James Mastros skribis 2006-05-31 12:03 (+0100): I don't like the name synchronized -- it implies that multiple things are happening at the same time, as in synchronized swiming, which is exactly the opposite of what should be implied. Serialized would be a nice name, except it implies serializing to a serial format, like disk. Locked is the best name I can think of, and it frankly isn't that good -- it's so vauge as to be able to mean almost anything. is exclusive Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Perl 6 Wiki -- 2 more possibilities, further discussion.
Please, for proper threading, don't reply to multiple messages at once. Conrad Schneiker skribis 2006-05-25 1:46 (-0700): Juerd wrote: Feather, the semi-public, semi-private, Perl 6 development server, is available to host a Perl 6 wiki. The hostname www.perl6.nl is deliberately kept available for something like that. Does that mean you are willing to be the one to set up a Perl 6 Wiki and administer it? (Preferably using perl5 wiki software, so that the Perl 6 Wiki could be available as soon as possible?) If so, how much more encouragement do you need to proceed? Willing, certainly. Lacking tuits, that too. I could set up wiki software in a few minutes, but then, so could anyone else. Personally, I think this shouldn't be rushed: there are lots of wikis, and typically they're incompatible in terms of syntax and storage. Also, I'd really love a Perl 6 wiki written in Perl 6 itself. Revision control can be outsourced to svn, leaving practically only a small bit of HTTP and wikitext parsing. However, this is still too much work for me to handle at this moment. The concept of feather is that I provide hardware, and system administration, and that others can then use that. Feather is very actively used, and it'd be nonsense to assume that everything on it is, or should be, done by me. I actively avoid getting involved too much, because I know that I won't be able to handle things as they expand. Feather was donated exactly because I wanted to do something for Perl 6 volunteers, without needing to spend much time, because I don't have that much time to spend on computing, because of personal circumstances. As a competing suggestion, how about... http://pugs.kwiki.org/?perl6 Very interesting. But did you look at it? :-) I found this on the home page link target: I know, and have contributed to, the Pugs wiki. If I may note: I don't like kwiki syntax, and much prefer a mediawiki-like syntax. I'd thought of that, but there's always the background issue of moderation and control. (We definitely want the Perl 6 Wikipedia page to link to our Perl 6 Wiki, of course.) I don't think Wikipedia is (at present) a suitable forum for semi-controversial topics. Language advocacy / competitive marketing is a highly contentious and emotional religious issue for many people, and we certainly want perl6 people to feel free to indulge in (reasonably civil) unbridled advocacy of all things perl6. Agreed. Feather has the powerful future marketing advantage that it can also be used to develop and then host a showcase Perl 6 implementation of the Perl 6 Wiki. However, I think that we should initially *begin* with a solid and proven Perl 5 wiki implementation that we can use *immediately*. If we could do this, then this would be my first preference. Beginning with a Perl 5 wiki, with lots of features, and migrating to a Perl 6 wiki later, means you have to support all of the 5-wiki's features for compatibility. That may not be a great plan, as a huge stack of functional requirements makes creative programming less interesting, and it may then never happen. If nobody is able to spend a day on a simple Perl 6 wiki today, why would they be able to spend *several* days on a backwards compatible wiki later? Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: (Existing) Perl 6 Wiki: (http://perl.net.au/wiki/Perl_6).
Conrad Schneiker skribis 2006-05-23 0:42 (-0700): Perl 6 Wiki: (http://perl.net.au/wiki/Perl_6). That's a nice page, and Mediawiki is a nice wiki. But I'd really prefer a wiki written in Perl 6, because it's about time we started to show off. Serving important information with PHP is possible, but there will be people who will interpret that meta-info. Besides that, the page is kind of slow... But that could be temporary. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: A rule by any other name...
Damian Conway skribis 2006-05-10 18:07 (+1000):
More than that, the current 'rule' and 'regex' can both be used inside
and outside a grammar. If we were to take the 'sub'/'method' pattern, then
'rule' should never be allowed outside a grammar,
I entirely agree.
I don't. While disallowing named methods and rules may be a wise idea
(I'm not sure they are), the anonymous forms are probably very useful to
have around.
my $method = method { ... };
$object.$method(...);
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Scans
Gaal Yahas skribis 2006-05-08 17:30 (+0300):
We have a very nifty reduce metaoperator. Scans are a counterpart of
reduce that are very useful -- they are the (preferably lazy) list of
consecutive accumulated reductions up to the final result. But I can't
think of a convenient way of expressing scans in Perl 6.
To make sure I understand what you mean, not as a proposed
implementation:
my @input = (...);
my @scan = map { [op] @input[0..$_] } [EMAIL PROTECTED];
Is this what you mean?
Hm, could that be written as:
my @scan = [op] @input[ 0 .. ([EMAIL PROTECTED]) ]
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Scans
Gaal Yahas skribis 2006-05-08 17:58 (+0300): (Is there special sugar to make @input be the last index when used in a range, or did you mean ..^ ?) I meant @input.last, or probably @input.indices (or .keys?) instead of the entire range, and @input.first instead of the first 0. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: [S05] /ee
Dr.Ruud skribis 2006-05-05 15:25 (+0200):
s/pattern/{ eval doit() }/
s/eval/try/ ?
No, string eval stays eval. Only block eval is renamed to try.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Linking Synopses to corresponding pod-files?
Markus Laire skribis 2006-05-04 14:55 (+0300): When reading Synopses, I sometimes notice some mistakes or typos, which I'd like to submit a patch for, but it's not easy to do so as I don't know where to get the source. Have you tried s/html/pod/? :) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Perl 6 Perl 6 Wiki Wiki (RFC: Community education page)
Not entirely related, but: it would be great if someone wrote usable wiki software (with revision control support) in Perl 6, and could maintain it so that it keeps up with Pugs. Because of the current state of Pugs, it will have to be written in a very simple way. Especially if it looks great on the outside, this will do Perl 6 much good. I've been meaning to do this myself, but I'm past the point where I give up waiting for sufficient sufficiently round tuits. Of course, feather can host it :) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: A shorter long dot
Damian Conway skribis 2006-04-30 9:49 (+1000): This would make the enormous semantic difference between: foo. :bar() and: foo :bar() And how is that very different from the enormous semantic difference between: foo. .bar() and: foo .bar() that already exists? I understand your point, and tend to agree with it, but it counts for both .: AND . .. PS: While I can understand the appeal to laziness, I'm not at all convinced by the argument: And it's a lot of work (many, many keystrokes!) to go back and change something. In vim, the exact number of keystrokes to realign the long dots of N lines is 7+N. If you plan it, sure. But without planning, you easily get to 12 and more. It's not just about the number of keystrokes, though. Having to go back itself is awkward. We need to be careful not to require the language to solve problems that are better solved with tools. I think we should be careful, and are careful, to support lots of tools. Many programmers prefer simple editors. Many programmers who use advanced editors, like to keep them at the default settings. And whenever you have to create a macro to do something that's common in a certain programming language, that programming language was badly designed. Let's not let Perl 6 be such a language. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: A shorter long dot
Audrey Tang skribis 2006-04-30 17:31 (+0800): Austin Hastings wrote: Or, to put it another way: what hard problem is it that you guys are actively avoiding, that you've spent a week talking about making substantial changes to the language in order to facilitate lining up method names? Sorry, I disagree strongly. Lining things up is an important aspect to how people use Perl. Consider my suggestion retracted, and sorry for the disturbance in the force. :) I still want to talk about it. Good arguments (about trailing dot being hard to spot, and about underscores) are made, and I think healthy discussion can lead to a much better solution than the current long dot. People who think it wastes their time, by now know what this thread is about, and can choose to ignore it. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: A shorter long dot
chromatic skribis 2006-04-30 2:06 (-0700): I'm still wondering what's awful about: $antler.bar; $xyzzy.bar; $blah.bar; $foo.bar; That's what I will do when current long dot stays, but I prefer to keep things left-aligned to the indentation level. These cascades look messy. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: A shorter long dot
Yuval Kogman skribis 2006-04-30 2:58 (+0300): We need to be careful not to require the language to solve problems that are better solved with tools. On that point I agree, but I think it was a question of aesthetics... Juerd? Yes, it was about both aesthetics and the extra work involved. But mostly aesthetics and a bad feeling. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: A shorter long dot
Jonathan Lang skribis 2006-04-29 19:08 (-0700): Is there a reason that we've been insisting that a long dot should use whitespace as filling? I don't know. foo.___.bar Would still have the problem of clashing with .. when there's no _ in between. foo.___:bar Would suffice for my needs. Not sure if people are willing to give up their underscore-only method names, though. Perhaps whitespace can be allowed in numbers too: 5 000 000; 5_000_000; Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: A shorter long dot
John Siracusa skribis 2006-04-30 8:15 (-0400): foo.___:bar Would suffice for my needs. Not sure if people are willing to give up their underscore-only method names, though. No one's going to use either of these because they're ugly. I am not going to use either of these because I think they're ugly. I don't think it's ugly. It's not any less tidy. $xyzzy.foo() $xyzzy.foo() $fooz.:foo() $fooz.:foo() $foo._:foo() $foo. :foo() $da.__:foo() $fa. :foo() My variable names aren't so long that I'm likely to have foo.___:bar, and $foo.__:bar is clean. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: A shorter long dot
Gaal Yahas skribis 2006-04-30 16:05 (+0300): But it doesn't work across lines: $and_a_long_one_I_still_want_to_align. :foo() Explain to me why it wouldn't work, please. I don't get it. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
A shorter long dot
16:50 audreyt Juerd: write to p6l and explain the .. conflict,
The current long dot consists of a dot, then whitespace, and then
another dot. The whitespace is mandatory, which makes the construct at
least three characters long. Tripling the length of an operator, just to
make it alignable, is quite a lot.
Illustration:
$xyzzy.foo();
$fooz. .foo(); # doesn't line up, so we have to change the
# *previous* line!
$foo. .foo(); # this lines up again.
So we use:
$xyzzy. .foo();
$fooz. .foo();
$foo. .foo();
which is ugly and feels bad. It feels bad, because we're adding much
more whitespace (two character positions in total) than we had to
bridge. And it's a lot of work (many, many keystrokes!) to go back and
change something.
However, the whitespace in between cannot simply be made optional, as
then it would clash with the range operator. As ranges are even more
important than a sane long dot solution, the long dot had to change.
Larry indicated that changing the long dot would have to involve
changing the first character. The only feasible solution in the tiny
glyphs section was the backtick. I refrain from explaining why that
will widely be considered a bad idea.
Audrey cleverly suggested that changing the second character would also
work, and that has many more glyphs available. So she came up with
and propose .: as a solution,
That's right, dot-colon. There are more glyphs available, but none of
them is nice like this. The basis is in regexes, where a colon means you
commit to have parsed the left side of the colon. That's how the colon
already reads in the indirect object notation, and the colon in
$foo.map:{...} can already be read.
So the actual solution is to make the method call operator not ., but
.:. Of course, a lone . still works and is the recommended style for
all simple method calls that don't have to be lined up. You can also
explain it as . still being the base operator, where .: is a special
form. Whatever you like best :)
and . : as an extension,
Of course, it wouldn't be a solution to the long dot problem if it
didn't allow an arbitrary amount of whitespace in between.
So, obviously, it does allow lots of whitespace in between. And, of
course, comments. If you really hate your future maintainer, you could
even put some POD in between.
$xyzzy.foo();
$fooz.:foo();
$foo. :foo();
Or, if you prefer:
$xyzzy.:foo();
$fooz. :foo();
$foo. :foo();
Or, if you actually LIKE the extra whitespace that the current long dot
mandates:
$xyzzy. :foo();
$fooz. :foo();
$foo. :foo();
and . + as an generalization,
Of course, this works nicely with the operators it was inspired by, that
were also inspired by regex postfix operators: .*, .+ and .?. They
can also contain whitespace in our proposal.
The dot-colon fixes another problem too. You couldn't line them up
anymore:
$foo.?bar();
$foo.baz(); # makes the ? look like part of the method name
So, now you can:
$foo.?bar();
$foo.:baz();
And an illustration with whitespace in between:
$xyzzy.:foo();
$fooz. ?foo();
$fo. *foo();
and coexistence/removal of . . as a consideration
If we have dot-colon, we could keep the old long dot too. That would
work well with my preference for ... as the first part of the old long
dot, as three dots stand out much better at the end of a line:
$foo...
.bar();
Though that isn't really dependent on the old long dot. It can live
separately. In fact, postfix ... could be a generic eat whitespace
and pretend it wasn't there operator:
$foo...
.bar()...
.baz();
$foo...
.:bar(); # with normal old long dot, would be :bar(), looking like
# a pair, not a method call.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Fw: ([EMAIL PROTECTED]) Re: A shorter long dot
I get a message like this for every message that I send to this list.
Trying to contact [EMAIL PROTECTED] did not result in response or change.
Any ideas?
- Forwarded message from sbc sbc [EMAIL PROTECTED] -
From: sbc sbc [EMAIL PROTECTED]
Date: Sat, 29 Apr 2006 08:31:24 -0700 (PDT)
To: [EMAIL PROTECTED]
Subject: Re: A shorter long dot
Testing with sbc30k
[EMAIL PROTECTED] wrote:
16:50 audreyt Juerd: write to p6l and explain the .. conflict,
The current long dot consists of a dot, then whitespace, and then
another dot. The whitespace is mandatory, which makes the construct at
least three characters long. Tripling the length of an operator, just to
make it alignable, is quite a lot.
Illustration:
$xyzzy.foo();
$fooz. .foo(); # doesn't line up, so we have to change the
# *previous* line!
$foo. .foo(); # this lines up again.
So we use:
$xyzzy. .foo();
$fooz. .foo();
$foo. .foo();
which is ugly and feels bad. It feels bad, because we're adding much
more whitespace (two character positions in total) than we had to
bridge. And it's a lot of work (many, many keystrokes!) to go back and
change something.
However, the whitespace in between cannot simply be made optional, as
then it would clash with the range operator. As ranges are even more
important than a sane long dot solution, the long dot had to change.
Larry indicated that changing the long dot would have to involve
changing the first character. The only feasible solution in the tiny
glyphs section was the backtick. I refrain from explaining why that
will widely be considered a bad idea.
Audrey cleverly suggested that changing the second character would also
work, and that has many more glyphs available. So she came up with
and propose .: as a solution,
That's right, dot-colon. There are more glyphs available, but none of
them is nice like this. The basis is in regexes, where a colon means you
commit to have parsed the left side of the colon. That's how the colon
already reads in the indirect object notation, and the colon in
$foo.map:{...} can already be read.
So the actual solution is to make the method call operator not ., but
.:. Of course, a lone . still works and is the recommended style for
all simple method calls that don't have to be lined up. You can also
explain it as . still being the base operator, where .: is a special
form. Whatever you like best :)
and . : as an extension,
Of course, it wouldn't be a solution to the long dot problem if it
didn't allow an arbitrary amount of whitespace in between.
So, obviously, it does allow lots of whitespace in between. And, of
course, comments. If you really hate your future maintainer, you could
even put some POD in between.
$xyzzy.foo();
$fooz.:foo();
$foo. :foo();
Or, if you prefer:
$xyzzy.:foo();
$fooz. :foo();
$foo. :foo();
Or, if you actually LIKE the extra whitespace that the current long dot
mandates:
$xyzzy. :foo();
$fooz. :foo();
$foo. :foo();
and . + as an generalization,
Of course, this works nicely with the operators it was inspired by, that
were also inspired by regex postfix operators: .*, .+ and .?. They
can also contain whitespace in our proposal.
The dot-colon fixes another problem too. You couldn't line them up
anymore:
$foo.?bar();
- End forwarded message -
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: S5 - Question about repetition qualifier
Jonathan Scott Duff skribis 2006-04-25 23:35 (-0500):
I get your point though. There's no easy way to say match 1, 7, 12, or
19 with this particular syntax.
How often does that come up in practice though? I don't think I've
ever wanted something like that.
Quite often. A silly example:
$hex_wep_key ~~ /^ hexdigit**{10|26} $/
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: =$fh vs *$fh
Larry Wall skribis 2006-04-22 19:40 (-0700): Hmm, I almost never write scalar FH because I very rarely want to input a single line in list context. But leaving that aside... I've used it a lot. I do tend to use it less often as I move away from line based text documents for storage. [101 lines] I wish I had time to read it all. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: [svn:perl6-synopsis] r8573 - doc/trunk/design/syn
Damian Conway skribis 2006-04-06 20:41 (+1000): Please reconsider. We can't. The problem is that: foo .bar has to mean: foo($_.bar) So the only way to allow whitespace in dot operations is to put it after the dot. Given the consequences of this constraint, I think that perhaps (probably!) sticking to foo .bar having to mean foo $_.bar is a bad idea. Parens could effectively break the method name parsing. I don't like typing parens, but I still like typing parens much better than breaking a few of the most important principles in my syntax style. And in this case, I think it breaks almost everyone's syntax style, not just that of a few. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: [svn:perl6-synopsis] r8573 - doc/trunk/design/syn
Larry Wall skribis 2006-04-06 9:01 (-0700): Okay, we could revert it, and .foo would remain term/operator sensitive, and retroactively eat preceding whitespace when an operator is expected. Or change the definition so that something that looks like a method call IS a method call, and that you have to put something else in between (like parens) to avoid it. So .bar; # $_.bar foo.bar;# foo.bar foo .bar; # foo.bar foo().bar; # foo.bar foo(.bar); # foo($_.bar) foo ~.bar; # foo(~$_.bar) foo *.bar; # foo(*.bar) That makes the parsing entirely predictible. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Perl 6 design wiki?
Mark Overmeer skribis 2006-03-05 10:44 (+0100): I know about the naming scheme, but I am not really looking forward to the two new perl books Perl DBI-(Any)-cpan:TIMB and Perl DBI-(Any)-mailto:[EMAIL PROTECTED] I think that's a very good argument for managing namespace centrally (but not necessarily against using this scheme). I would really like to maintain a certain hierarchical name-space structure on CPAN, where we strive for unique names, although can work around accidental collissions. In principle I agree, but to be honest, hierarchical names make less and less sense by the day, as techniques are combined, and new many new things overlap much. Often it is hard to choose between top level namespaces, or to choose which part of your module name you put first. And once you settle on a name, it's even quite likely that although it describes the way you intended the module to be used, it doesn't cover all the bases. See DBIx::XHTML_Table and Apache::Session, that have nothing to do with DBI and Apache, respectively. More and more, I like cute names that don't really describe the module. We have abstracts for the latter. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Instance attributes collision
Luke Palmer skribis 2006-02-13 9:36 (+): That's a compile time error. Both has declarations generate a method a, so it is a method conflict. Doesn't normally double declaration end in the later masking/overriding the earlier declaration, with a warning, but not an error? I'd expect has $.a; has @.a; To result in both $.a and @.a, but only one method .a, which is an accessor for @.a Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Instance attributes collision
Luke Palmer skribis 2006-02-13 9:46 (+):
class Baz {
does Foo;
does Bar; # does this count as double declaration?
}
I'd put composition and inheritance in a slightly different category
than accessor *generators*.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: The definition of 'say'
Larry Wall skribis 2006-02-08 8:38 (-0800): It would be nice to have other data points I associate say with to-human communication, and there, I don't generally have records. Without records, no ORS. However, while I think that say should not be print.assuming(:ors(\n)), it shouldn't be print + \n either. Instead, I think the format should be configurable, defaulting to suffixing \n, but configurable to have another suffix, and possibly a prefix even. For example, I may very well like a * %s\n-like output, or when dealing with HTML, %sbr. Of course, I could just override say. But I think making it configurable and documenting the difference between say and print as a difference in final recipient (human versus computer) may make more sense. In any case, say being print + \n as the default is IMO a better plan than having it default to any ORS, even if that ORS happens to be \n. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Conversion oneliner t-shirt
Because of the favourable response to the prototype I wore during the post-euroscon Amsterdam.pm meeting, and because Cafepress finally has black shirts, it is now available for everyone who wants one. http://www.cafepress.com/perl6 Please note that although I'm spamming this, there's no profit in there for me, or anyone except Cafepress. (I did add $ 0.01 because I think .99 values are incredibly silly.) Please donate to TPF separately :) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: ff and fff [Was: till (the flipflop operator, formerly ..)]
Patrick R. Michaud skribis 2006-01-25 13:47 (-0600): On Wed, Jan 25, 2006 at 11:37:42AM -0800, Larry Wall wrote: I've changed the flipflop operator/macro to ff, short for flipflop. This has several benefits. ... ...another of which is that we can use ff and fff to mean loud and really loud in our perl poetr^H^H^H^H^Hmusic. :-) We need pp and ppp for balance. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: ff and fff [Was: till (the flipflop operator, formerly ..)]
Jonathan Scott Duff skribis 2006-01-25 14:49 (-0600): 1) Will ff (and fff) require whitespace around them? I hope it will be exactly like x and xx. They need whitespace around them if otherwise it'd be part of an identifier. 2) Do we get a more punctuationish unicode equivalent? I fear someone will suggest the ff ligature. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
[OT] Re: Parrot and PGE will save the day (was Re: as if [Was: Selective reuse of storage in bless.] )
Rob Kinyon skribis 2006-01-20 23:12 (-0500):
$ perl -le '$h{1} = Perl; print values h'
Perl
$ perl -le 'push a, Perl; print @a'
Perl
Now, that's an unadvertised feature! I think I need to revisit some golfs ...
Not worth the effort, because length('[EMAIL PROTECTED]') == length('push a').
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Perl 6 OO and bless
Rob Kinyon skribis 2006-01-18 20:57 (-0500):
Well, for one thing, you can't write OO code in P5.
Nonsense. OO isn't a set of features, and OO isn't syntax.
Granted, syntax can really help to understand OO, and a set of features
is nice, because it avoids having to re-invent wheels.
But OO is just that: object orientation. It is a way of programming, and
that can very well be done without any syntax or features for that in
place.
C's filedescriptors are objects/invocants, and so are PHP's MySQL
resources.
Perl 5 has syntax for OO, and even a few useful features. Even though
these are not needed at all to write OO code, it certainly does help
people to stick to OO design.
And if more features are needed, CPAN has them.
Object orientation is still object orientation if you write it
differently: $bar-{foo}-(), if that's how you decide to write a method
call on $bar, is still OO.
Classes, like OO syntax, are not necessary for OO.
You can write code that behaves like you're in OO-land and that talks
with an OO accent (so long as you don't look behind the curtain), but
it's not OO.
Your definition of OO is far too specific for a 2-letter acronym.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Perl 6 OO and bless
Rob Kinyon skribis 2006-01-19 9:15 (-0500): OOP is all about black-box abstraction. This is probably the fundament of our disagreement. OO is about objects, which CAN BE but DO NOT HAVE TO BE black-box/opaque. It is customary, and good style, to treat objects as black boxes, but their actual implementation can differ, given proper abstraction. To that end, three items have been identified as being mostly necessary to achieve that: I'd say these are extremely useful and highly desired, but theoretically optional. P5 excels at #1, does #2 ok, and fails completely at #3. Now, one can argue whether the programmer should make the decision as to whether strong encapsulation is desirable, but the point is that you cannot create encapsulation in Perl that someone else cannot violate. Neither can you in any language that lets you poke into its internals. However, that means that the internals define a property of the language, which I think is reversed logic. it seems silly (to me) to cripple P6 out of a misguided effort to maintain backwards compatibility with P5. It's as useful as Inline::Java. That means different things to different people. To me, it means I can re-use code more easily. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Perl 6's bless is (seriously) broken
Stevan Little skribis 2006-01-19 15:45 (-0500):
class Foo {
method new ($class: %params) {
$class.bless(%params);
Wouldn't that be %params.bless($class), or more directly,
%params.blessed = $class?
This *won't* work the same in Perl 6 though. This is because,
what is blessed is not a literal hash, but an instance of ^Hash.
The mistake here is that Foo doesn't does Hash, I think.
Sure, in Perl 5, you could have different kinds of references as
instances of the same class. But I don't recall ever having encountered
that.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Perl 6's bless is (seriously) broken
Rob Kinyon skribis 2006-01-19 16:10 (-0500): There are no references in Perl6. When you said that one can't use OO in Perl 5, I had something to say because it's a recurring subject. I have to admit, though, that I've never seen this statement, or anything implying it. It's entirely new to me. Is your Perl the same as that of other people on this list? :) In fact, the only think you have in Perl6 is objects, so why do we need to take something that isn't an object (which doesn't exist) Could you live with @foo being an array, and @foo in scalar context returning a reference to that array? And with arrays being interfaces to underlying Arrays, which are objects, which makes arrays non-objects that can be used *as* objects? Perl still has non-object types. They may represent objects internally, but they work differently from what we've historically been calling objects. Especially in assignment, the differences are huge, because an object is considered a reference, while real scalars, arrays and hashes evaluate to (a list of) their values, or a useful representation (like the number of elements) when used in non-OO fashion. bless was a brilliant idea for Perl5. It's wrong for Perl6. I think it's needed to be able to convert Perl 5 code semi-automatically. But you have probably thought about this more than I, so I'll ask you: what's the alternative? Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Perl 6's bless is (seriously) broken
Juerd skribis 2006-01-19 22:18 (+0100): Could you live with @foo being an array, and @foo in scalar context returning a reference to that array? And with arrays being interfaces to underlying Arrays, which are objects, which makes arrays non-objects that can be used *as* objects? This turns everything is an object into everything can be used with OO syntax, which I think is more true. Alternatively and simultaneously, everything represents an object. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Perl 6's bless is (seriously) broken
Stevan Little skribis 2006-01-19 16:59 (-0500):
But we cannot automagically inject a role into a class, for a number
of reasons.
1) thats just plain evil
But then, so is bless, so the two can play along.
2) what if the role conflicts with other roles being does-ed by Foo?
Debugging hell there.
Very good point.
3) What if Foo wants to have a .keys, .value, .exists, etc? Do they
shadow the Hash version? What if Foo.keys is implemented using
Hash.keys? Many issues abound here.
Even better point.
Sure, in Perl 5, you could have different kinds of references as
instances of the same class. But I don't recall ever having
encountered
that.
bless([] = 'Foo');
bless({} = 'Foo');
bless(\*Foo = 'Foo');
bless(\(my $var) = 'Foo');
Okay, now I did encounter it...
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Perl 6's bless is (seriously) broken
Stevan Little skribis 2006-01-19 17:06 (-0500): This turns everything is an object into everything can be used with OO syntax, which I think is more true Alternatively and simultaneously, everything represents an object. Well, if everything is NOT an object, then the synopsis need to reflect this. I was more thinking along the lines of NOT everything is an object, but some things are. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Perl 6's bless is (seriously) broken
Rob Kinyon skribis 2006-01-19 20:54 (-0500): There are no references in Perl6. Is your Perl the same as that of other people on this list? :) There are no references in Perl6 in the way Perl5 conceives of references. There are references in Perl 6. Do note that @foo evaluates to a reference to itself in scalar context, which isn't some magical auto-referencing thing. Likewise, a reference to an array is dereferenced when used as an array. This is automatic, but still not quite magical. References, their terminology, and their semantics still very much exist. I'd say learn Ruby to know what OO is, but I happen to know you already know a nearly-pure OO language - Javascript. Somehow that makes me think you don't happen to know that I already know Ruby too. :) Every single 'thing' in JS is an object - you can hang methods off of a string literal or a number. Most objects in JS aren't references. They are what one would call a reference if the language were Perl. I'm very strictly limiting my jargon to Perl's, unless explicitly stated otherwise. For example, PHP's references are not references, but more like pointers and/or symbolic references, depending on which you choose to call references in PHP. Note, by the way, that JS has primitive strings, and Strings, only the latter being objects. Fortunately for us, though, a string is automatically promoted to a String when the string is USED AS an object. bless was a brilliant idea for Perl5. It's wrong for Perl6. I think it's needed to be able to convert Perl 5 code semi-automatically. But you have probably thought about this more than I, so I'll ask you: what's the alternative? Well, there's two scenarios - you either run your P5 code using Ponie or you attempt to use Larry's Wondrous Machine of Translation. How would the latter work, if there's no bless? But, if you must use the WMoT, then I suspect the following will happen: 1) The WMoT notices your use of bless and marks that package as a class and that method as a constructor. 2) It creates a Perl6 class for your use, noting the accesses into the Perl5 reference that you used and calling those attributes. 3) It then creates your BUILD() method, putting all the non-bless components of your new() into it. Doesn't solve the problems as mentioned in this thread, like overlapping methods. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Perl 6 OO and bless
Rob Kinyon skribis 2006-01-19 22:50 (-0500): There's already a mechanism in the P6 OO system for specifying the internal representation of the instance. Now there's the actual problem in its baremost form: indeed the *P6* OO system has that, but the *P5* OO system (excuse me for calling it that) did not. The two are wildly incompatible, but we do want both. Well, perhaps you do not, but many of us here do. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: split on empty string
Jonathan Lang skribis 2006-01-18 7:26 (-0800): Mark Reed wrote: Perl6 .split(/whatever/) is equivalent to split(/whatever/,) in Perl5. I'm hoping that the perl 5 syntax will still be valid in perl 6. Don't worry, it is. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Table of Perl 6 Types
Larry Wall skribis 2006-01-12 12:40 (-0800): Well, it could be a lazy list that you only ever pop, I suppose. In any event, it doesn't work syntactically because ... is where a term is expected, so it's a yada-yada-yada with an unexpected term following it. Why avoid having both ... and ...$foo? MMD, longest-match, ugly hacks, there's a bag full of tricks that could be used, so I gathered there must be a philosophical reason not to have this. I just can't think of any that would weigh more than having ...$foo around. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: binding arguments
Ingo Blechschmidt skribis 2005-12-25 17:37 (+0100): I disagree about binding only being a language thing: I fail to see how your example code illustrates your disagreement. return 42 if (my $short := $long_parameter_name) == $specialcase; That's terribly horrible style! push @foo, (my $head := pop @grtz); A bit better style, but I'd still recommend against it. (Unless of course, you consider this to be obfuscation.) Not obfuscation, but horrible style. You're doing something in an expression that has no effect on what happens in the expression itself. ($bar = $foo) =~ s/// is useful because you need a copy, and the inline copying is a clear indication of $bar's function: to be $foo in its state after s///. The same thing with := instead of = would be horrible, because $bar and $foo would be the same thing, during and after the expression, and the aliasing itself had nothing to do with the substitution. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: binding arguments
Ingo Blechschmidt skribis 2006-01-05 18:32 (+0100):
Juerd wrote:
Ingo Blechschmidt skribis 2005-12-25 17:37 (+0100):
I disagree about binding only being a language thing:
I fail to see how your example code illustrates your disagreement.
return 42
if (my $short := $long_parameter_name) == $specialcase;
I inferred that you think/thought that binding should/can't be used in
expressions
No, that's not what I meant.
A language thing means it's mostly relevant for the way you write
something as a result of the feature. In case of binding, the most used
application is aliasing: getting a second way to address the same
variable -- probably because the alias is less typing.
push @foo, (my $head := pop @grtz);
A bit better style, but I'd still recommend against it.
Consider:
my @sites = abc.org def.org ghi.org ;
loop {
push @sites, (my $site := shift @sites);
check_for_updates($sites);
sleep ...;
}
my $site := shift @sites;
push @sites, $site;
check_for_updates($sites);
Although in Perl 6 I'd be much tempted to do:
given shift @sites {
push @sites, $_;
check_for_updates($_);
}
Because $_ is visually easy to recognise, making it immediately obvious
that it's the same thing in both lines.
(This is also my main argument against any style that ALWAYS provides an
explicit loop variable: $_ is easy to spot, and thus is more than just
easy to type.)
Consider a perhaps more usual example:
while(...) {
process($tasks[$i++]);
if(...) { $i-- } # redo the last task
if(...) { $i = 0 } # redo all tasks
if(...) { $i++ } # skip next task
}
As ugly. In fact, using an index is the ugliest part of your example.
Still, separately, $i++ in the process() instruction is bad style IMO.
Incrementing $i is important for program flow, and should be its own
statement, directly following indentation.
Also, if you remove process() here, the entire program is broken,
because there was an important but easy to overlook subexpression was in
it.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Deep copy
Luke Palmer skribis 2005-12-23 16:16 (+):
However, I think that would be ignoring the amazing prevelance of the
shallow copy idioms in perl 5:
[ @array ]
{ %hash }
It's a great idiom. Not much typing, easy on the eyes and easy to
understand.
There's little, if any, reason to use a .clone method instead.
We could consider .clone to be the natural extension of this (and have
the above forms be its definition for Array and Hash).
I think both shallow and deep should be possible, with an infinite
amount of options in between. One hashref may be meant as a nested hash,
while the other is meant as a reference to a conceptually separate hash.
The first should be copied, the second not. How on earth we're going to
let Perl know what we want is, in my opinion, much more interesting than
what the default behaviour will be.
Consider
my %foo = (
a = 41,
b = 15,
c = {
bar = 1,
baz = 1,
quux = 0,
},
d = \%bar,
);
I'd want something that clones this, somewhere between shallow and deep.
.c should be deep, but .d shallow. Perhaps this can be determined
using some attribute, that for a referenced hash defaults to the
opposite of what it defaults to for a literal anonymous hash.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: real ranges
TSa skribis 2005-12-23 17:33 (+0100): lt strictly inside -+ gt strictly outside --+ | eq == exactly on boundary --+ | | | | | negation ne != not on boundary --+ | | le = inside or on boundary --+ | ge = outside or on boundary ---+ Comments? If you like to overload operators with very different meanings, by all means go ahead, but please don't do it for something I use all the time, like ranges. We already have $range ~~ $inside and $range !~ $outside, and boundary checking isn't exactly interesting, but could probably be done with any($range.min, $range.max) == $boundary. I'd assume $foo $range to compare $foo to the number of elements in the range, OR $foo $range to mean $foo $range.min, and $foo $range to mean $foo $range.max, and would be surprised if they meant anything else. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
