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 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: Nomenclature Question - BEGIN etc.
Brandon S. Allbery KF8NH skribis 2008-04-10 19:41 (-0400):
> On the other hand, that may be the answer right there: "when-blocks".
No, this is a when block:
when /foo/ { ... }
:)
--
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: Concerns about "{...code...}"
Michael G Schwern skribis 2007-12-21 19:21 (-0800): > Normally I'd go on the side of the reader and say yes, when writing code you > should be picky about what quotes you use. But in this case I find that, on > the writing side, I find it a common annoyance when I chuck a variable into a > string and then only realize afterwards that it's not interpolating. On the > reading side, I find visually scanning for $ in strings easy and I guess I > assume everyone else does, too. Just to add nothing to the discussion: I find double quotes without interpolation annoying, but only when I'm reading code without syntax highlighting. Whenever I read code with syntax highlighting that makes the interpolated variables stand out, it's no issue at all. I tend to write "" first, and then change them to '' when getting close to releasing the code. Unpaid non-opensource code usually stays at ""... My excuse is growing up with BASIC. -- 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: Factoring Arguments
Ryan Richter skribis 2007-12-21 11:52 (-0500):
> On Fri, Dec 21, 2007 at 08:41:54AM -0800, Jonathan Lang wrote:
> > and so on, you might do something like:
> > with &qq :(c => false) {
> I think this can be done with normal currying, something like
> temp &circumfix:<" "> := "e:.assuming(:!c);
Hm, would the following work?
given "e:.assuming(:!c) -> &circumfix:<" "> {
...
}
--
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: perl 6 grammar
Jonathan Lang skribis 2007-12-06 16:36 (-0800): > > I know it used to be that way back near the Dawn of Time, but methods > > don't automatically topicalize anymore unless you explicitly name > > one of the parameters '$_': > Huh. I guess I need to review current standards for method > declaration; last I'd checked, the invocant did not need to be > explicitly named. It does if you want to access it by a name other than a lone sigil. -- 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 ));
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
?? '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: Web Module (Was: Perl6 new features)
Smylers skribis 2007-06-21 23:23 (+0100): > Of course. But there's a big difference between the attitude of 'let's > do the best we can right now' and 'this is our one chance to do this > right'. I think that for some things, mainly for setting community standards (Web, POD, ...), this is our one chance to get it right, for the next two decades. This said, I don't think Web should be core. It should be the *first* web toolkit for Perl 6, though. -- 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: Referring to source code within Perldoc: the new A<> code
Damian Conway skribis 2007-06-21 11:45 (+1000): > A dedicated OO documentation tool could certainly do a better job in that > case, I heartily agree. I'm looking forward to using one. This dedicated OO documentation must be core, because Perl itself is heavily OO. If we are to ever have consistent, semantic, structured OO documentation throughout CPAN (and numerous in house projects), we must start with Perl itself, and there isn't the option of having this tool be third party. -- 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: .perl, nested arrays, parens and a bug with .perl after hyperop
Steffen Schwigon skribis 2007-05-21 1:28 (+0200): > 1. Should assigning an arrayref to an array dereference? No, an array in list context only flattens when it has the @ sigil, or when it is explicitly flattened with the [] postcircumfix operator, or the | prefix operator. >Which Synopses describes this? S03 > 2. Shouldn't .perl generally use parens for outputting arrays (at >least on the most outer level)? No, because parens are just for grouping and controlling precedence. They are not constructors. Note that in this assignment, my @foo = @bar; @bar is in list context. The syntax is ARRAY = LIST; and not ARRAY = ARRAY. Assigning an array to an array seems kind of useless to me. Binding probably makes a bit more sense: my @foo := @bar; That's ARRAY := ARRAY there, so the following should dwym: my @foo := [ 1, 2, 3 ]; However, this does not work with pugs, so I don't know if I am wrong, or pugs is wrong. -- 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: 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.probably; "period" -- 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: 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: 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]>
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 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 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 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]>
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 C 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
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: 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: [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/>.
