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/>.
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/>.
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 C&P 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 => "#FF0000", # 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/>.
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: 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
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: -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
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 . 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: 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: 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 C 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 C with a closure doesn't copy, given the translation above,
> or even allow modification, since C 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 C is a conjectural way of calling .clone if the argument
> is an object type but reduces to C 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 C 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: 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: 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///
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///
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: 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: 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: 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'
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: 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'
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: 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-24 8:09 (-0700): > My guess is that that's a pretty much location-independent problem, unless > (for examples), (1) you get perl.org to host a Perl 6 users wiki, (2) you > get perl.org and allied sites to put a prominent link to it on their main > Perl 6 pages, and so on. 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. 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: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: 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: [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
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: 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
Re: A shorter long dot
Larry Wall skribis 2006-04-30 9:58 (-0700): > On Sat, Apr 29, 2006 at 05:15:08PM +0200, Juerd wrote: > : 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. > "Only feasible"? I think you guys give up too easily. ... in the "tiny glyphs" section. We could go with larger glyphs, like \, of course -- it just hadn't been considered yet. > Actually, there is a postfix \(...), but that wouldn't interfere with > a \. construct. There's prefix \, though: It creates a big difference between $foo \.bar and $foo\ .bar # currently the same thing But I don't think that's a problem. > $foo\ > .foo(); I've never liked continuation characters, but I could live with this limited application. 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
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
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
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
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
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
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
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
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
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 ~~ /^ **{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 " 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
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: [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
[EMAIL PROTECTED] skribis 2006-04-05 22:30 (-0700): > Whitespace is not allowed before the parens, but there is a corresponding > -C<.()> operator, which allows you to insert optional whitespace before the > dot: > +C<.()> operator, which allows you to insert optional whitespace after the > dot: > -&foo.($arg1, $arg2); > +&foo. ($arg1, $arg2); If done consistently, this destroys the sane multiline markup: $foo .bar(...) .baz(...) .quux(...) And I'd really hate to be forced to use this instead: $foo. bar(...). baz(...). quux(...) because then you lose visual indication that bar, baz, and quux are methods (rather than functions), and the . and the end of a line is visually lost and probably easily forgotten. Plus, I don't like continuation characters at all. Please reconsider. 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: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: 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: 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, "%s".
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 ..)]
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
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
[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
perl6-language@perl.org
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: 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'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
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
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
