Re: Backwards compatibility and release 1.0
Moritz Lenz writes: > On 10/13/2015 10:52 AM, Richard Hainsworth wrote: > > > Following on the :D not :D thread, something odd stuck out. > > > > On 10/13/2015 03:17 PM, Moritz Lenz wrote: > > > > > > We have 390+ modules, and hand-waving away all trouble of > > > maintaining them seems a bit lofty. > > > > Surely, the idea of keeping the release number below 1.0 is to warn > > early adopter developers that code is subject to change and thus in > > need of maintenance? > > ... a large percentage of the module updates are done by group of > maybe five to a dozen volunteers. ... 5 people updating 70% of 390 > modules. Modules they are usually not all that familiar with, and > usually don't have direct access. So they need to go through the pull > request dance, waiting for reaction from the maintainer. In short, it > sucks. Thanks for the explanation, Moritz. That does make sense. I'm still a _little_ uneasy because that sounds a bit like the explanation of why Makefiles have to use tab characters: I just did something simple with the pattern newline-tab. It worked, it stayed. And then a few weeks later I had a user population of about a dozen, most of them friends, and I didn't want to screw up my embedded base. The rest, sadly, is history. — Stuart Feldman http://stackoverflow.com/a/1765566/1366011 Though the important difference is that invisible whitespace characters that some editors don't even let you type are particularly beginner-hostile, whereas allowing undef arguments where they don't make sense (and hence where callers don't generally try supplying undef) is something that many Perl 5 programs have been doing for years with no widespread harm. Cheers Smylers -- http://twitter.com/Smylers2
Re: The invocation operators .* and .+
Aristotle Pagaltzis writes: Just because you can’t think of the use of a feature doesn’t mean there isn’t one. No, though it possibly means the docs could do with a clearer example which demonstrates its use in a situation where it makes sense to use it. Smylers -- http://twitter.com/Smylers2
Re: Perl 6 in CS (Was: [perl6/specs] 89cc32: Spec Bag.kxxv)
Damian Conway writes: I have no confidence yet, however, that Perl 6 will be widely taken up as a CS teaching language. ... the decision on a teaching language usually reflects either the personal biases of the individual teacher, or those of the curriculum committee, or else mirrors the market demand of the local community. How else do we explain the awful languages that are so often taught in our universities. :-( A university I'm familiar with taught introductory programming in the 90s using Pascal, chosen for its pedagogical merits, then taught OO using C++. But students, and potential students, were put off by the idea of learning Pascal, seen as an irrelevant language. So in the late 90s they switched to teaching C++ as a first language. Shortly afterwards they found would-be applicants on open days were querying why they were teaching C++ when rival universities offered Java, seen as what they needed to learn for getting jobs. So a few years later, they switched to Java. In other words, the language chosen for teaching introductory programming was determined by the views and misconceptions of 16-year-olds! However, the staff teaching that module didn't feel that Java was a good choice as an introductory language, so they asked the higher-ups to be able to put some Python in there too, as an example of a different programming language. This was agreed, so long as the course was still marketed as teaching Java, and just happened to include some Python along the way. (This was over 10 years ago, when Python wasn't as widespread or recognized as it is now.) I think that over time the amount of Python increased. So maybe the situation isn't completely without hope. Smylers -- Why drug companies shouldn't be allowed to hide research results that they don't like: http://gu.com/p/3zat8 — UK gov wasted millions on Tamiflu Sign the AllTrials petition: http://www.alltrials.net/
Re: [perl6/specs] d9d8b3: refactor case mappings (again)
Larry Wall writes: On Tue, Jul 24, 2012 at 09:42:10PM +0100, Smylers wrote: : Under what circumstances is tcuc useful? I'm currently suffering : from a lack of imagination as to when somebody would ever want that : rather than just uc. A bare uc will do the wrong thing for the first letter of a word in those languages that distinguish tc from uc. Titlecase is distinguished from other uppercase forms that are used after the inital letter, and so doesn't care whether the next character is uppercase or lowercase. It's simply wrongish to use uc on the first character in such a language. Thanks. Smylers -- http://twitter.com/Smylers2
Re: [perl6/specs] d9d8b3: refactor case mappings (again)
GitHub writes: https://github.com/perl6/specs/commit/d9d8b35825f7abf07a9314fd90b0b5563253bd15 Author: Larry Wall la...@wall.org There is no more titlecase function. Instead there is a suite of mapping functions appropriate to apply on a word-by-word basis (tc, tclc, and tcuc), Under what circumstances is tcuc useful? I'm currently suffering from a lack of imagination as to when somebody would ever want that rather than just uc. Cheers Smylers -- http://twitter.com/Smylers2
Re: Underscores v Hyphens (Was: [perl6/specs] a7cfe0: [S32] backtraces overhaul)
Moritz Lenz writes: Am 23.08.2011 10:46, schrieb Damian Conway: ... why hidden_from_backtrace instead of hidden-from-backtrace? ... low-level things are spelled with underscores, while we reserve the minus character for user-space code. So the idea is that if Perl 6 has an identifier zapeth_clunk itself that leaves zapeth-clunk free to be used by developers to mean something else? Is that something we want to enable? Code with identifiers that differ only in word separators sounds like it would be most confusing to maintain. Are there specific circumstances in which it would be useful? Patrick R. Michaud writes: On Tue, Aug 23, 2011 at 05:36:27PM +0200, Damian Conway wrote: I'd like there to be a more consistent approach than that +1 to consistency. Could we have underscores and hyphens mean the same thing? That is, Perl 6 always interprets illo-figut and illo_figut as being the same identifier (both for its own identifiers and those minted in programs), with programmers able to use either separator on a whim? That would seem to be the most human-friendly approach. Smylers -- http://twitter.com/Smylers2
Re: Suggested magic for a .. b
Jon Lang writes: Approaching this with the notion firmly in mind that infix:.. is supposed to be used for matching ranges while infix:... should be used to generate series: With series, we want C $LHS ... $RHS to generate a list of items starting with $LHS and ending with $RHS. If $RHS $LHS, we want it to increment one step at a time; if $RHS $LHS, we want it to decrement one step at a time. Do we? I'm used to generating lists and iterating over them (in Perl 5) with things like like: for (1 .. $max) where the intention is that if $max is zero, the loop doesn't execute at all. Having the equivalent Perl 6 list generation operator, C..., start counting backwards could be confusing. Especially if Perl 6 also has a range operator, C.., which would Do The Right Thing for me in this situation, and where the Perl 6 operator that Does The Right Thing is spelt the same as the Perl 5 operator that I'm used to; that muddles the distinction you make above about matching ranges versus generating lists. Smylers -- http://twitter.com/Smylers2
Re: r31050 -[S03] refine hyper dwimminess to be more like APL, with modular semantics
pugs-comm...@feather.perl6.nl writes: Author: lwall Log: [S03] refine hyper dwimminess to be more like APL, with modular semantics +(1,2,3) »+» 1 # 2,4,4,6 rhs dwims to (1 xx *).batch(3) I'd've expected the output to be 2,3,4; is the 2,4,4,6 copy pasta or am I missing something? Cheers Smylers -- http://twitter.com/Smylers2
Re: r29778 - in docs/Perl6/Spec: . S32-setting-library
pugs-comm...@feather.perl6.nl writes: Author: lwall New Revision: 29778 Modified: docs/Perl6/Spec/S03-operators.pod === +As a list infix operator, C... takes a left on both its left and +right and evaluates them as lazily as possible to produce the desired +series of values. The lists are evaluated as flat lists. Takes a left -- is this the satnav operator? Smylers -- Connecting walls made up by me now on the BBC -- this week's 'Only Connect', the fiendish TV quiz/puzzle show: http://www.bbc.co.uk/programmes/b00qvkrm
Re: r29778 - in docs/Perl6/Spec: . S32-setting-library
pugs-comm...@feather.perl6.nl writes: Author: lwall New Revision: 29778 Modified: docs/Perl6/Spec/S03-operators.pod === +Any means of specifying a function will do, as long as you arrange +return it as a list value rather than calling it: I think arrange return needs a to in the middle. Smylers -- Watch fiendish TV quiz 'Only Connect' (some questions by me) Mondays at 20:30 on BBC4, or iPlayer: http://www.bbc.co.uk/programmes/b00lskhg
Re: r29768 - docs/Perl6/Spec
pugs-comm...@feather.perl6.nl writes: Author: lwall +++ docs/Perl6/Spec/S02-bits.pod 2010-02-17 19:15:34 UTC (rev 29768) +rhyme((1,2),3,:miceblind) # rhyme has 2 arguments Should that say 3 arguments? (If not, please can somebody clarify what the 2 arguments are.) Thanks. Smylers -- Watch fiendish TV quiz 'Only Connect' (some questions by me) Mondays at 20:30 on BBC4, or iPlayer: http://www.bbc.co.uk/programmes/b00lskhg
Re: S26 - The Next Generation
Damian Conway writes: It's Sunday evening and, as promised, here's the new draft of S26. Wow, thanks for that -- it's most impressive and I'm already excited about what it will allow and how it permits improved documentation. * Hence it must always parsed using full Perl 6 grammar: perl6 -doc Having a multi-character option preceded by a single hyphen doesn't play well with bundling of single-character options (such as perl -wle in Perl 5): * The above looks like a bundled version of -d -o -c. That some of those don't exist doesn't affect that impression: it isn't reasonable to expect a user to know all options before she uses any of them, so if she's seen some single-letter options but doesn't know about -doc then she will misinterpret -doc. * In order for -doc to work, 'long' options have to trump 'bundled' options with the same spelling. If a version of Perl 6 introduces all of the -d, -o, and -c options then -cdo, -cod, -ocd, and so on will all be synonyms but -doc will be completely different. Putting arbitrary restrictions on bundling order that aren't related to the options themselves is an irritating cognitive load: if you're adding the -c option to a program that already has -do it matters where you put the c. * If long options with single hyphens are permitted in general then a future version of Perl 6 may add new ones. That means that _no_ single-character option bundling is safe to use from a forwards compatibility viewpoint, because any sequence may become a long option -- and hence radically change semantics -- in future. Using double-hyphens for all long options disambiguates them from bundled short options, and is familiar to many users from other software which follows that convention. Indeed others (including S19) already seem to believe that two hyphens are needed: jerry gay writes: this is why it's spelled 'perl6 --doc' Smylers
Re: S26 - The Next Generation
Jon Lang writes: FWIW, the current proposal for aliasing blocks of ambient text is functional; it just feels a bit kludgey, Why? To me it seems the opposite: what could be more natural for delimiting a block of code than braces? and I'm a bit bothered by the fact that you can't alias any ambient text other than a code block. Can't is a bit strong: it's more that if you want to quote an arbitrary portion of code then you need to add some braces around it. But those braces are unlikely to harm the program. The exception is if you want to quote an 'unbalanced' portion of code, for example the start of a loop but not the entire loop. Do you consider that to be likely? how about saying that an ambient code alias is normally terminated by the next blank line or Pod directive (as per =for) Braces are more robust than blank lines; if aliasing a brace-delimited block I may unthinkingly edit it to have a blank line in the middle of it, on the basis that the blank line isn't significant to perl. (Whereas if I edit the braces then I've changed the program as well as its docs.) An alternative would be to have blank-line termination for an alias which _doesn't_ start with a brace (that is, doesn't have an opening brace on the following non-blank line). However that would likely confuse somebody who happens to add a brace to the line following the alias directive (perhaps inside a quoted string, or changing the brackets on a hash look-up, or in a regex) and unwittingly changes the alias from several lines to just a few characters in the middle of that line. Terminating at a Pod directive sounds plausible, unless anybody can think of a good reason to be quoting Pod as part of code? Let's see what others think. OK. I like the braces. I suggest initially only providing for braces, but with the possibility of later adding options to indicate other termination points if in practice there turn out to be many situations where the braces don't work well. Smylers
Re: given vs for
Dave Whipp writes:
Mark J. Reed wrote:
So eseentially,
given (@foo)
means the same as Perl5
for ([EMAIL PROTECTED])
Just wondering: should given @foo {...} alias to $_, or @_?
I'd expect it to alias to C$_, on the grounds that everything always
aliases to C$_.
What's the argument for it being C@_?
Smylers
Re: Decrement of Numbers in Strings (Was: [svn:perl6-synopsis] r14460 - doc/trunk/design/syn)
On September 13th [EMAIL PROTECTED] committed: Modified: doc/trunk/design/syn/S03.pod == +Perl 6 also supports CStr decrement with similar semantics, simply by +running the cycles the other direction. However, leftmost characters +are never removed, and the decrement fails when you reach a string like +aaa or 000. + +Increment and decrement on non-Str types are defined in terms of the +C.succ and C.pred methods on the type of object in the CScalar +container. Apologies for the delay in responding to this; however the above is still in S03. The algorithm for increment and decrement on strings sounds really good, however I'm concerned that dealing with all that has made the common case of integer decrement a little less intuitive where the integer happens to be stored in a string, for example in this case: perl -wle '$a = 10; $b = shift; $a--; $b--; print $a $b' 10 Perl 5 prints 9 9, but Perl 6 will print 9 09. If a 'number' is read in from a file, standard input, a webpage, a command-line argument, and possibly even a database then it's likely to be a string to start with. I realize there are ways to get round this, for example by declaring the variable as numeric. But not having to worry about declaring variable types is quite Perlish. And the above subtlety is something I wouldn't like to have to explain to a beginner (The program works fine when I hardcode 10 into it, but not when I provide 10 as input!); treating 10 and 10 differently with the same operator seems a little PHPish. About C+ S03 says: +Microeditorial: As with most of these operators, any coercion or type +mismatch is actually handled by multiple dispatch. The intent is that +all such variants preserve the notion of numeric addition to produce a +numeric result, presumably stored in suitably large numeric type to +hold the result. Do not overload the C+ operator for other purposes, +such as concatenation. (And please do not overload the bitshift +operators to do I/O.) In general we feel it is much better for you +to make up a different operator than overload an existing operator for +off topic uses. I'm wondering if something similar should apply to C--; that string and numeric decrement are different, so should have different operators. Smylers
Re: [svn:perl6-synopsis] r14479 - doc/trunk/design/syn
[EMAIL PROTECTED] writes: Modified: doc/trunk/design/syn/S09.pod Log: Clarification of autovivification semantics in terms of protoobjects -my $obj = [EMAIL PROTECTED]; # $obj is a Capture object - see S02 +my $cap = [EMAIL PROTECTED]; # $obj is a Capture object - see S02 Does the variable name in the comment need changing too? Smylers
Re: perl 6 grammar
cdumont writes:
there are some changes in the grammar which benefits aren't that
obvious :
Hi there. For some of these the benefit is indirect: it isn't that it
makes the feature in question easier to use; instead it enables _other_
features.
1- $str1 ~ $str2
I do not really understand the new concatenation style when most of
the time it's '+' or '.'
It isn't great, but I'm sure we can live with it. It frees up dot for
other things. Anyway, because of interpolation Perl doesn't use
concatenation as much as many other langauges (and even less so in Perl
6 with method calls being interpolatable and braces for conveniently
interpolating any code at all).
It also has the advantage that tilde is consistently used in several
places in Perl 6 to indicate strings.
2- $life = (!$monster) ?? 'safe' !! 'dead';
I don't see how putting 2 questions marks and 2 exclamations marks
make things shorter and easier to understand.
Clearly it doesn't -- but then I don't think anybody is claiming that
that's the reason for the change!
Shortness isn't always a virtue; by using doubled characters they stand
out more, which makes it easier to spot when this operator is being used
-- something that's more important with this operator than most, since
it is split between two positions.
And it frees up some symbols for use in other operators.
3- given $operator {
when '' {}
}
The given ... when doesn't seem to bring that much from switch ...
case given ...
Surely it brings all of it? Plus much more as well. Much of the power
is in the smart-matching, which enables many different sorts of
comparisions, each naturally matching the appropriate thing. A big
advantage given has over C's switch construct is not having to include
break in the usual case (and get mysterious-yet-silent bugs if you
accidentally forget it).
And hashes require '=' but it could be nice to switch to ':'
Indeed it could be. But, unfortunately, the colon seemed to be top of
many people's most-wanted lists, with many different (and mutex)
suggestions for what it should do. (Remember, only a couple of
paragraphs ago you were wanting to keep it for the ? ... : operator!)
Possibly somebody could design a language in which the colon is the only
symbol used ...
because then :(or perhaps we can use whatever separator we want?)
{
elems : {
deleting : {
ids : [1,2,3],
names : ['concatenation','ternary operator','switch']
},
replace : {
with : ['.','?:','switch...case']
}
};
And I know this may not sound that much but it could be sent to
javascript or actionscript or any ecmascript based languages.
The key bit of the above is your parentical comment about using whatever
separator you want -- which is exactly what Perl 6 provides the
flexibility to do. In Perl 6 it will be possible to do:
use Grammar::JSON;
and then within that file you can have the above syntax for complex
data-structures.
Or at least, it will if somebody writes the Grammar::JSON module -- but
the whole point of Perl 6's pluggable grammars is that it specifically
supports people who want to do this sort of thing: it recognizes that
not everybody is going to agree on the ideal syntax, so instead it
merely provides a 'default' syntax (which Larry judges to be the best
all-round) then provides a way of changing anything about it.
Hope that helps.
Smylers
Re: perl 6 grammar
cdumont writes: Smylers wrote: cdumont writes: The given ... when doesn't seem to bring that much from switch ... case given ... Surely it brings all of it? Plus much more as well. Much of the power is in the smart-matching, which enables many different sorts of comparisions, each naturally matching the appropriate thing. A big advantage given has over C's switch construct is not having to include break in the usual case (and get mysterious-yet-silent bugs if you accidentally forget it). I understand that given ... when is even more powerful than a simple switch case but why just don't say it this way : this is a switch case dopped with hyper process Maybe the documentation will say it that way! and keep the old switch ... case keywords. But keeping the old ones would require having them already -- which Perl doesn't. What would be the point in simultaneously introducing a flexible syntax which meets all switching needs and a less-powerful syntax (which is completely different, thereby making it more work than necessary if you outgrow its requirements and need to change to using the more flexible alternative; and which is error-prone)? I don't know why, this given... when sounds so 'English' without really being that English. I'm afraid you've lost me -- are you saying that given does sound English or that it doesn't? And why is it relevant either way? And hashes require '= ' but it could be nice to switch to ':' Indeed it could be. But, unfortunately, the colon seemed to be top of many people's most-wanted lists, with many different (and mutex) suggestions for what it should do. (Remember, only a couple of paragraphs ago you were wanting to keep it for the ? ... : operator!) Possibly somebody could design a language in which the colon is the only symbol used ... I don't really think using the column in a ternary means that you cannot use it else where. We started off with that, and it was changed specifically because it was causing a problem; I can't remember exactly what, but it's in this list's archives somewhere. Remember that whatever expression you want to use the colon for is going to be valid between the ? and : parts of the ? ... : operator, and so you need to avoid the colon being confused for the : which marks the end of this part of the ? ... : operator. Also remember that we want Perl 6 to be able to complain about syntax errors -- that is, we want that when somebody makes a typo, there's a good chance of perl complaining about the source being invalid, rather than it being valid Perl 6 (but which silently does something else). As for the functions, i didn't see that much for hashes and arrays which was a big disappointment. What were you hoping for? Many things which were functions in Perl 5 are now also available as methods in Perl 6. If you post here with what you're disappointed to be missing, it may be that somebody can reply pointing out where the equivalent functionality is! Smylers
Re: Standards bearers (was Re: xml and perl 6)
Peter Scott writes: I do feel strongly that we need some sort of solution to this so that Perl 6 is not merely an outstanding framework that leaves all domain-specific extensions to the end user. OK. Can we find a way to make and maintain some recommendations in a way that people can find them easily from P6 itself ... Maybe what we need is an editorial team. Build it, and they will come! This isn't something which needs to influence language design -- in the sense that it doesn't need to be sorted before the design can be final and Perl 6 released. It isn't really anything that needs to be agreed by central diktat (remember that search.cpan.org isn't in any way official -- it's 'just' a Cpan mirror which happens to have a web interface that many people find convenient). Nor is it something that needs to be got right the first time, or we need to be confident will last as long as Perl 6. (For example, ActivePerl has been the _de facto_ standard Windows Perl distribution for some time; it's possible that Strawberry Perl in time will take over that, but if so it'll just be because it gets momentum behind it and the community as a whole chooses it, not because somebody named it as such.) Smylers
Re: xml and perl 6
James Fuller writes: my claim is that XML is significantly common place, Yes, but the question isn't whether it's common place _now_ -- but whether it still will be in a couple of decades time. We know from experience that adding some modules to Perl 5 a decade ago is now a maintenance burden, for modules that aren't now common place. We don't want to repeat that mistake. to the core, you would have to be better at making predictions than those who added modules to Perl 5. _Are_ you better at such predictions? What evidence have you got for that? the only evidence I have is anecdotal. OK then. But why do you _think_ you are better at making predictions? When XHTML1 launched did you correctly predict that XHTML2 would turn into an ignored project that no web-browser vendors are interested in implementing, and that instead they would be implementing HTML5, a language based on HTML4 that encourages authors not to bother with XML? no, I didn't predict this ... but this is not really a valid analogy, It wasn't supposed to be an analogy; it was supposed to be events which seem to directly contradict your prediction. I am not predicting XML usage In a previous message you said: I can only see more XML for all of us. That looks entirely like a prediction to me. . I am sure there is a silent majority of perl users who interact with XML on a regular basis Many of us aren't. Or aren't sure there will be in 2 decades. but yes I agree it is impossible for me to prove ;) Quite. It isn't that I'm predicting XML _won't_ be around in 2 decades; it's that none of us can be sure that it will be. So it's being left out. That doesn't mean that there won't be an XML parser in commonly encountered Perl distributions. Look at what Adam Kennedy is currently doing with Strawberry Perl, as an example. my point is if we should have some bits in the core which I see as being an advantage over other languages; Ah, well that's where you've seriously misunderstood the situation, I'm afraid. The deal here is that we have bits in the core which _Larry_ sees as being advantageous over other languages! (And the rest of us tag along because we like the decisions he makes.) Smylers
Re: xml and perl 6
James Fuller writes: by making some fundamental xml processing available by the core, u do promote a common and systematic approach to working with XML in all perl modules. Why is that a good thing? What makes you so sure that nobody will come up with a better way of working with XML In Perl 5 would it've been good to add XML::Parser to the core as soon as it was written, and ecouraged everybody to standardize on using that rather than coming up with others? Smylers
Re: [svn:perl6-synopsis] r14449 - doc/trunk/design/syn
[EMAIL PROTECTED] writes: -A leading C[ or C+ indicates an enumerated character class. Ranges +A leading C[ indicates an enumerated character class. Ranges in enumerated character classes are indicated with C.. rather than C-. / [a..z_]* / - / +[a..z_]* / - / +[ a..z _ ]* / - / + [ a .. z _ ] * / Whitespace is ignored within square brackets and after the initial C+. Did you mean to remove and after the initial C+ as well? + / [ a..z _ ]* / + Simon
Re: Web Module (Was: Perl6 new features)
Juerd Waalboer writes: 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. Fair enough. Obviously it would be great if that happened, and by the time the code part of Perl 6 is releasable we have all those other things. But if we get to the state where core Perl 6 is ready to unleash on the world as a stable release, but it's still the case that: * The OO documentation, while readable and complete, if given a little more structure would be better for computer parsing. * We haven't finalized the Web module. * There isn't a fully working Perl 6 implementation of 'Duke Nukem Forever' in the examples/ subdirectory. ... then I don't think it would be worth holding up Perl 6.0.0.'s release to wait for any of those things to happen. Smylers
Re: Quirky comments
Larry Wall writes: I have a problem with both extremes, and I want to solve it with a dose of postmodern apathy. It may seem a bit insane, but I think that in print qq:to/END/ =for whatever END I would prefer that the =for is considered Pod by any standard Pod parser, but is *not* considered Pod by the Perl 6 parser. And I think that's just fine. I like it! Is that a decision yet, or were you just thinking out loud? Smylers
Re: [svn:perl6-synopsis] r14421 - doc/trunk/design/syn
Mark Overmeer writes:
* Smylers ([EMAIL PROTECTED]) [070616 09:09]:
You're concerned that an aspect of Perl 6 might have too much
freedom? Isn't Perl all about giving users freedom to choose their
own way of doing something?
Why treat documentation as a second-class citizen all the time?
I'm not suggesting we do; it's precisely _because_ Perl provides so much
freedom in things like coding style that I think it would be bizarre to
be so restrictive in the documenation format. Documentation should be a
first-class citizen, and therefore have as much freedom as coding.
Why have a standard syntax for regexes, and not for docs?
We have a standard _syntax_ for docs; what you are additionally
proposing are standard _semantics_, which is something regeps (and other
areas of Perl) don't enforce -- they just provide the tools for
programmers to use them as they wish.
Aren't you glad that at last we get a standard for OO programming and
named parameters?
Yes. But I'm also glad that these have both carefully been done in ways
which don't enforce them, leaving programmers free to do things in other
ways.
The boundary between freedom and anacharchy is faint.
Indeed. And I'd much rather we err on the side of anarchy. Many times
have I been frustrated by the limits of some software or programming
language. Far better to allow somebody enough freedom to create a poor
piece of software (since that's going to be possible anyway) than to go
too far in t'other direction and inadvertently prevent somebody in the
future from doing something really clever that none of us have yet
thought of.
Yes. But in reality many people will follow what others do, or look
to follow best practices. With Perl 5 you have complete freedom as
to the names of C=head1 sections in the Pod for modules, yet in
browsing Cpan it's clear that there are conventions and many people
use the same headings. So not mandating a convention isn't much of
a problem.
Well, the you are talking about the top three headers, the most.
Not true; there are several more which are shared between Cpan
distributions (by different authors).
And those have a good example in standard UNIX manual-pages. So:
there is a definitions for them, which most people have seen.
I am sceptical of your claim that most Cpan authors have seen any
official definitions of sections in Unix manual pages.
Do you really think that people can now, before Perl 6 has gained
anything approaching the usage we expect, make policy for how things
should be documented, such that that policy will be the best
possible way of documenting everything written in Perl 6, for ever?
Or even a good way?
There is no need to think that a documentation syntax develops
differently than a programming language.
I agree. And programming languages develop in hard-to-predict ways,
which is why Larry is putting lots of flexibility for things to be
redefined into Perl 6, so it can grow and adapt in line with future
developments. It would be good if Pod can keep up.
So when Perl is developing, POD can develop in parallel.
Exactly!
That strikes me as incredibly shortsighted, verging on arrogance by
whoever comes up with the rules, and doomed to failure.
Sorry? Not only you insult me,
Apologies, that wasn't supposed to be an insult. Note that it isn't
that I'm objecting to your rules (nor any particular rules), nor
doubting your abilities to come up with good rules; you'd be one of the
best people for coming up with some standards. I just don't believe
that _anybody_ can come up with rules that won't be bettered at some
point in the future.
but you also ignore all these other languages which do have a nice and
standard way of documenting. Insignificant languages, like Java,
which we tend to ignore.
I've encountered Javadoc, and I really dislike it[*0]. The fact that a
standard exists does not make it a good one.
Smylers
[*0] Consider a function Cvalid_postcode. I'd document it along
the lines of:
valid_postcode
Returns whether the specified postcode is valid, for example:
if (valid_postcode $postcode) {
Javadoc-style systems seem to insist on documentation like:
valid_postcode
Description: Returns whether the specified postcode is valid.
Parameters:
$postcode: (string) The postcode to test for validity
Returns: (boolean) Whether $postcode is valid
Exceptions: none
Side Effects: none
Lots of structure and consistency, but in practical terms no
additional information compared to my informal doc -- and the
verbosity and repetition actually make it harder to spot the
information you want.
Re: Web Module (Was: Perl6 new features)
Moritz Lenz writes: You could help by contributing some suggestions to what the new Web module should be able to do, and how so. Web is hopefully CGI done right, and still in its early planning stage. Web module? This is the first I've heard of it. Where is it being planned, if not on this list? Also, why are we hoping that it will be done right? Given the history of things like this it strikes me as unlikely that now is the particular moment where we suddenly manage to create a perfect library, and as such this would be hoping against the light of available evidence! It seems entirely possible that during Perl 6's life somebody, possibly somebody who at the moment hasn't even heard of Perl 6, will create a better web module. It would be good if at that point it becomes straightforward for it to get acceptance and people to adopt it. Smylers
Re: = at Start of Line ([svn:perl6-synopsis] r14421 - doc/trunk/design/syn)
brian d foy writes: In article [EMAIL PROTECTED], Smylers [EMAIL PROTECTED] wrote: brian d foy writes: In article [EMAIL PROTECTED], Damian Conway [EMAIL PROTECTED] wrote: No. It's Pod. *Any* line that begins with '=begin' always starts a Pod block. Always. As you know, one of the biggest complaints about Perl is that you have to have a lot of special rules knowledge to figure some things out. Indeed. What's much nicer is to be able to state that a given rule always applies. Well, now explain literal strings :) Fortunately Larry has found a way in which literal strings will still work as you (and your students) expect. The rules for Pod5 always applied too, so I don't see what we've gained here as far as the simplicity of rules Well the new is simpler. Putting aside this particular situation, the argument comes down to where does the water balloon pooch out? We haven't lost any complexity, it's just in different places. Maybe some places need less complexity and some places could stand a little more. I agree with that. I also think that this particular change is worth the risk of a learner putting an assignment at the start of a line, especially given: * With the exception for literal strings, this now pretty much only applies to assignment. * Because the C= has to be followed immediately by the Pod directive, any C=s with space after them or assigning a quoted string will be immune; only those assigning the return values of functions will be affected. That's slim. Even allowing for Sod's Law I would happily lead a beginners' Perl course and chance not mentioning this exception Smylers
Re: Referring to source code within Perldoc: the new A code
Damian Conway writes: Here's the first draft (documented in Pod 6, of course ;-). Feedback and suggestions are most welcome. Note that C=alias is a fundamental Perldoc directive, like C=begin or C=for; it is Inot an instance of an Labbreviated block|#Abbreviated blocks. Hence there is no paragraph or delimited form of the C=encoding directive (just as there is no paragraph or delimited form of C=begin). I was with you right up until the mention of C=encoding; what's that got to do with anything? Smylers
Re: Web Module (Was: Perl6 new features)
Darren Duncan writes: At 6:37 PM +0100 6/21/07, Smylers wrote: Web module? This is the first I've heard of it. Where is it being planned, if not on this list? It was being discussed on the perl6-users list, last year. Thanks. Smylers
Re: Referring to source code within Perldoc: the new A code
Damian Conway writes: Here's the first draft (documented in Pod 6, of course ;-). =head3 Ambient aliases The CA formatting code specifies an Balias to an ambient antecedent. Please can you explain the reasoning for choosing antecedent, rather than successor? I'm not disagreeing with your choice, merely that it doesn't seem obvious to me that one is going to work better than t'other, so I'm open to being persuaded. In Perl 5 I generally intermingle Pod, such that when reading the source the description of a function or method comes before the code (so that by the time you've reached the code you already know what it's supposed to be doing) -- but I'm not adamant about continuing with this style. Smylers
Re: Referring to source code within Perldoc: the new A code
Juerd Waalboer writes: 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. That doesn't follow. If we are to ever have consistent, semantic, structured OO documentation throughout CPAN (and numerous in house projects), we must start with Perl itself, 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. 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. There isn't really anything to be gained by pre-empting this and picking something initially. Documentation, unlike code, doesn't have to be backwards compatible: if Perl 6.0.1 changes the API of a standard function that will break existing code; but if Perl 6.0.1 has documentation with a different structure from Perl 6.0.0, that won't break anything. Also it's much easier for people to get the benefit of documentation improvements than of code improvements. If Perl 6.0.1 introduces a new feature then I need to upgrade from Perl 6.0.0 on all my computers to be able to use it; but if Perl 6.0.1 has improved documentation then I can read, browse, and search that documentation on its website without needing to upgrade any of my computers. Smylers
Re: Referring to source code within Perldoc: the new A code
Juerd Waalboer writes: Smylers skribis 2007-06-21 21:33 (+0100): 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. There's no reason why it has to be. There are no barriers to anybody unofficially adding extra semantic information to the documentation and making it available on a website. Smylers
Re: Web Module (Was: Perl6 new features)
Moritz Lenz writes: Smylers wrote: Moritz Lenz writes: Web is hopefully CGI done right ... why are we hoping that it will be done right? Because we hope we learned from the past. There are several other modules that fullfill most of CGI's tasks, some of them do most of it better. Reimplementing one of them would already make Web a better CGI ;-) Indeed -- making a better CGI is a great idea. But the fact that such innovations came along later supports my point. I suspect that some of these got less mindshare than they otherwise would have done (or were seen as inferior to CGI) because: * The CGI module was core. * By being called simply CGI, the CGI module gets some kind of superiority over all the other modules which have to be CGI::Something. Has Larry yet decreed whether Web will be bundled with Perl 6? Given the history of things like this it strikes me as unlikely that now is the particular moment where we suddenly manage to create a perfect library, and as such this would be hoping against the light of available evidence! You're right, but we should ship things as best as we can, so we try ;-) 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'. It seems entirely possible that during Perl 6's life somebody, possibly somebody who at the moment hasn't even heard of Perl 6, will create a better web module. It would be good if at that point it becomes straightforward for it to get acceptance and people to adopt it. Right, but that's no reason not to try hard on your own. It isn't. But it is a reason to anticipate the existence of future developments, and try to be careful not to do anything which makes life harder for them. Smylers
Re: = at Start of Line ([svn:perl6-synopsis] r14421 - doc/trunk/design/syn)
brian d foy writes: In article [EMAIL PROTECTED], Damian Conway [EMAIL PROTECTED] wrote: No. It's Pod. *Any* line that begins with '=begin' always starts a Pod block. Always. As you know, one of the biggest complaints about Perl is that you have to have a lot of special rules knowledge to figure some things out. Indeed. What's much nicer is to be able to state that a given rule always applies. Like Damian has just done here. Saying that C= at the start of a line always means Pod is much simpler than having a list of exceptions of places where it doesn't. Also, doesn't this then limit Pod to Perl 6 (which I thought was not the goal)? I reckon the complete opposite. I doubt other languages will want to deal with this situation. With these new Pod rules it's possible to entirely remove Pod from a file without knowing _anything_ about the host language. (It could straightforwardly be done as an editor macro, for example.) That permits Pod to be used to document just about anything; all you need to allow it is a filter that strips off all Pod before you do anything else with the file. If Pod were to take notice of the host language's context throughout the file then this would not be possible: every language which wished to have Pod support would require its own Pod parser embedded within the languge parser. _That_ is orders of magnitude more complex than the simplicity of filtering off all Pod first, and strikes me as something other languages are much less likely to be bothered to do. Smylers
Re: [svn:perl6-synopsis] r14421 - doc/trunk/design/syn
Mark Overmeer writes: * Damian Conway ([EMAIL PROTECTED]) [070615 00:17]: * Pod 6 is both a structural and a semantic scheme; you can specify both the structure of a document, and the meaning of its various components Yes, and that is one of the things which worries me most *You can*. It's full freedom, You're concerned that an aspect of Perl 6 might have too much freedom? Isn't Perl all about giving users freedom to choose their own way of doing something? like XML, and without a convention everyone may think-up there own way of documenting the same kinds of code elements. Yes. But in reality many people will follow what others do, or look to follow best practices. With Perl 5 you have complete freedom as to the names of C=head1 sections in the Pod for modules, yet in browsing Cpan it's clear that there are conventions and many people use the same headings. So not mandating a convention isn't much of a problem. Moreover, I reckon that not mandating a convention is essential. Look at what's being done with Perl 5 at the moment (not specifically Pod, just in the Perl 5 community in general) and the best practices that have sprung up in recent years (and are still evolving). People are, of their own accord, following conventions that nobody had even thought of at the time Perl 5 was released; even at the time Perl 5.6, say, was released. In this structure, the responsibility of how things get interpreted is not for the programmer, so consistent over all modules. We can make search.cpan.org and manual-pages with a consistent structure. Do you really think that people can now, before Perl 6 has gained anything approaching the usage we expect, make policy for how things should be documented, such that that policy will be the best possible way of documenting everything written in Perl 6, for ever? Or even a good way? That strikes me as incredibly shortsighted, verging on arrogance by whoever comes up with the rules, and doomed to failure. Rather than trying to map out the future in detail (which is tricky), the best we can do is come up with things that are sufficiently flexible that they're capable of being used in ways we haven't yet thought of. Then when somebody, years from now, has a good idea, it will be possible for that to be implemented (and followed by others), rather than tying us to some convention set at an arbitrary point in the past. * To summarize the summary: - Use Perl for what Perl is good for (specification) - Use Pod for what Pod is good for (commentary) - Use expressions where expressions are good for (calculation) - Use regexes where regexes are good for (matching) ... i.e. it is not a valid argument: expressions and regexes are integrated. Yes, but on the other side of the argument coconuts and fax machines are not integrated. I'm reasonably confident that for every pair of things which you list as being integrated I can come up with a pair which aren't; I doubt that will really assist the argument one way or t'other. the issue is to have sufficiently integrety in code and markup to be able to create documentation-generating tools which produce enough quality. Damian's spec permits this. And at the same time give the programmer the mimimal burden on writing documentation, to increase the chance that it is present and good. You should 'Perl 6 Documentation Best Practices', with guidelines for how to use Pod. I'm sure many people would appreciate just being able to follow a template rather than having to make decisions over the small details of what to do. That way we have a convention for those that want it, but also don't tie ourselves into anything. If a particular convention gains widespread approval then peer pressure should encourage its use (in the same way that strict and warnings are currently optional in Perl 5, but in the absence of a good reason it's expected that they be used). Smylers
Re: [svn:perl6-synopsis] r14418 - doc/trunk/design/syn
[EMAIL PROTECTED] writes:
Log:
Line-initial #{ is no longer a line-end comment, but starts a block
comment, guaranteed to catch at compile time the accidental use
of #{...} foo();. (Old behavior would silently not execute
foo().)
Oooh, those block comments look nifty -- and are inspired way of
avoiding surprising people just putting hashes at the beginning of all
their lines of code.
Smylers
Re: [svn:perl6-synopsis] r14407 - doc/trunk/design/syn
Larry Wall writes: ... I'm not too worried about the counterintuitiveness of it, by and large. It's much like that little embarrassing problem in physics that a GUT is neither as grand nor as unified as a TOE. :) Hmm, maybe we should just rename Object to something more generic. Nah, the current name is good: it has the convenient mnemonic of being the name that people object to ... Smylers
Re: Should a dirhandle be a filehandle-like iterator?
John Macdonald writes: open(:file), open(:dir), open(:url), ... could be the non-dwimmy versions. If you don't specify an explicit non-dwimmy base variant, the dwim magic makes a (preferrably appropriate) choice. That'll make it easy for people porting PHP scripts to Perl 6 -- in particular for those wanting to port the security hole where a CGI parameter is used to form part of a filename opened by a script but a malicious user can supply a URL instead and cause the program to do things very different from what it intended. What are the situations in which a programmer really needs to open something but doesn't know wether that thing is a file, a directory, or a URL? I'm still unpersuaded this is sensible default behaviour. Smylers [Apologies for the delay on this; I first tried to send it on April 15th, and only just spotted it failed to get through.]
Re: List Archives Link Broken
Browder, Tom writes: Where can I see this list's archived mail? The link on http://www.mail-archive.com/perl6-language@perl.org/ is broken from here. Google Groups works for me: http://groups.google.com/group/perl.perl6.language/topics (Though I've some memory of previously establishing the link is one-way, and that posting using the Google Groups interface doesn't result in your mail reaching the list elsewhere.) Smylers
Re: Should a dirhandle be a filehandle-like iterator?
Jonathan Lang writes: Also: why distinguish between open and opendir? If the string is the name of a file, 'open' means open the file; if it is the name of a directory, 'open' means open the directory. Many programs open a file from a name specified by the user. Even if Copenfile existed, many programmers would surely continue to use Copen for this. Users being able to trick such programs into opening a directory rather than a file could be unpleasant. Smylers
Re: [svn:perl6-synopsis] r14339 - doc/trunk/design/syn
[EMAIL PROTECTED] writes: Separated clobbering == == from pushy == and == +Feeding into the C* whatever term sets the source for the next sink. +To append multiple sources to the next sink, double the angle: + +0..* == *; +'a'..* == *; +pidigits() == *; Can you append to something that isn't there? Would it matter if the first feed also had a double pointy bracket on it? Smylers
Re: [svn:perl6-synopsis] r14317 - doc/trunk/design/syn
Larry Wall writes: On Thu, Mar 08, 2007 at 09:05:32AM +, Smylers wrote: : So I fear that people will do the same thing in Perl 6. Which, : initially, will appear to work. But then, some months later, : somebody upgrades the installed version of a module (or the program : gets deployed on another computer, which happens to have a more : recent version installed), and suddenly the program will break. Nope, check your assumptions, you've got a big one that just ain't so. Perl 6 is specced to keep all the old versions of modules around in the library Yeah, that's why I added or the program gets deployed on another computer, which happens to have a more recent version. (unless the new version claims to emulate the old version). So an upgrade doesn't generally break fixed dependencies. Aha! So even if I specify that I want, say, version 1.3, if only version 1.6 is installed but the module's author claims never to've broken backwards compatibility then it will run anyway? That's good. : * In many (most?) cases the breakage will be arbitrary, in that the : module would've worked fine had it been allowed to run rather than : being stopped by the version-checker. It is allowed to run anyway, Sorry, I don't quite understand that. What does happen if a program requests a version of a module that : * It's a change from what was good practice in Perl 5. s/good/common/; I'd say that common practice in Perl 5 is merely to use a module and not specify a version number at all! Specifying a minimum version number is an improvement -- obviously not ideal, but it is as much as can be done straightforwardly with Perl 5. And I think it'very likely people in the habit of doing this in Perl 5 will, at least initially, specify a single version number in Perl 6 Cuse lines. Those who believe the stagnation of Perl 5 is caused by Perl 6 should go back and reread the 361 RFCs ... Snip Sorry if my post came across as some kind of attack on Perl 6 as a whole -- it certainly wasn't supposed to be!! I'm very much in favour of the way Perl 6 is going and the many improvements it brings. (And I'm not sure what stagnation has to do with this thread, but for what it's worth I think quite the opposite: Perl 6 has been the inspiration for several good things people are already doing with Perl 5.) Cheers. Smylers
Re: [svn:perl6-synopsis] r14317 - doc/trunk/design/syn
[EMAIL PROTECTED] writes: Saying C1.2.1 specifies an Iexact match on the version number, not a minimum match. To match more than one version, put a range operator in parens: +use Dog:ver(1.2.1..*); That[*0] strikes me as a common trap for the unwary. In Perl 5 if you rely on a feature (or bugfix) from a particular version of a module you can specify that version and the code will continue to work with future versions -- which is a reasonably pragmatic approach, effectively saying until proven otherwise I'll presume that any future releases of this module won't break this functionality. So I fear that people will do the same thing in Perl 6. Which, initially, will appear to work. But then, some months later, somebody upgrades the installed version of a module (or the program gets deployed on another computer, which happens to have a more recent version installed), and suddenly the program will break. In summary, I feel uneasy about the combination of: * In many (most?) cases the breakage will be arbitrary, in that the module would've worked fine had it been allowed to run rather than being stopped by the version-checker. * It's a change from what was good practice in Perl 5. * The bug _cannot_ hurt straight away, only at some point in the future (and often by actions of somebody who isn't the programmer). Any of those separately is liveable with, but together it's a bit much! [*0] And I recognize from the lack of leading + symbols on the text it isn't a recent change; my apologies for not spotting it earlier. Smylers
Re: [svn:perl6-synopsis] r14317 - doc/trunk/design/syn
Andreas J. Koenig writes:
$spot:Inconsistent:(parens)
On Wed, 7 Mar 2007 20:38:17 -0800 (PST), [EMAIL PROTECTED] said:
+class Dog:ver1.2.1:authcpan:JRANDOM;
+class Dog:ver1.2.1:authhttp://www.some.com/~jrandom;
+class Dog:ver1.2.1:authmailto:[EMAIL PROTECTED];
+class Dog:1.2.1 cpan:JRANDOM
+class Pooch:nameDog:ver1.2.1:authcpan:JRANDOM
+class Pooch:Dog 1.2.1 cpan:JRANDOM
So far you're using angle brackets
That's a string.
+use Dog:ver(Any):auth(Any);
From here you start mixing angle brackets and parens.
That is not literally the author called Any releasing the version
Any, but saying that Any values are permitted.
+use Dog:1.2.1;
Literal version number.
+use Dog:ver1.2.1:auth(Any);
Even in one line.
Literal version number, but any author.
+use Dog:ver(1.2.1..1.2.3);
+use Dog:ver(1.2.1..^1.3);
+use Dog:ver(1.2.1..*);
+use Dog:ver(1.2.1 | 1.3.4):auth(/:i jrandom/);
+use Dog:ver(Any):auth({ .substr(0,5) eq 'cpan:'})
+use Perl:ver(v6..*):auth(Any);
Seems accidentally to me.
Those are all ranges or code that specifies which values are permitted,
rather than literal values.
Smylers
Re: request new Mapping|Hash operators
On February 27th Darren Duncan writes: At 4:45 PM + 2/27/07, Nicholas Clark wrote: 4. rename(): rename is a Perl 5 builtin. I see this situation as being similar to Dog.bark() vs Tree.bark(); The difference is that those are methods. Having different objects which have identically named methods is very different from having a built-in function which performs multiple, but very different, tasks based on its arguments. One common usage scenario, of relational-join in particular, is doing operations on tabular data, where you want to know something that involves matching up columns in several tables. Snip excellent example I've seen lots of programs that do things like that. But by a long way it's far more common to have the data tables in a database and use SQL for the joining than for the data to be elsewhere, such that SQL can't be used and it has to be read into Perl data structures for doing the joining. DBI is a module, not a core part of the Perl language. I think it would be odd for Perl 6 to have core support for these operations when most users would use DBI instead. For people doing data processing that requires this functionality I don't see why loading a module would be too much of a burden. In conclusion, I consider functionality like relational-join to provide considerable conciseness to very common data processing operations Are there Cpan modules in existence for doing this kind of thing in Perl 5? Smylers
Re: for ... else
Andy Armstrong writes:
On 3 Mar 2007, at 00:39, Thomas Wittek wrote:
I'd like the For::Else behaviour more. Especially as I remember
numerous times writing an if clause to check if a list is empty
before processing it.
That's crazy. If the list is empty foreach still does the right thing
- there's no benefit in guarding a foreach with a conditional.
The purpose of the Cif test is not to guard the loop but to attach an
Celse clause to (hence the above mention of CFor::Else), so that
some code can be run only in the case where the list is empty.
I have many times wanted this: either list the results or display a
message saying that there aren't any results; process each invoice, or
throw an error complaining there aren't any invoices.
Oooh, or, now there's an idea. In Perl 6 the return value of Cfor
is the list of values that successfully completed an iteration. In the
case of their not being any items in the list to start with that will be
an empty list, which is false. So I think this will work:
for @invoice
{
.process;
} or fail 'No invoices to process';
I don't remember many cases where I wrote something like this:
my $found;
foreach my $item (@items) {
if ($item = 'foobar') {
$found = 1;
last;
}
}
unless ($found) {
..
}
I'd say that or a close variation of it was a pretty common idiom.
I've many times wanted a better way of doing that too. Basically you
want an Celse to attach to the Cif but only be activated if none of
the. Larry's suggestion of using Cfirst for this looks good.
Smylers
Re: for ... else
Steve Lukas writes:
On the other hand, there is no important reason for it because C
for @rray - $el {}
if ! @rray {}
should work. It's short and easy to understand.
But it involves repeating C@rray -- which for more complex expressions
(results from function calls, delving deep into very nested data
structures, whatever) could be tedious. Repetition is certainly poor
style and makes the code more prone to errors being introduced.
Also, it relies on the contents of C@rray not being cleared inside the
loop.
Smylers
Re: request new Mapping|Hash operators
Darren Duncan writes: I believe that ... some common relational operations would be a lot easier to express if Perl 6 had a few more operators that make them concise. I am prepared to believe that. But what I'm unclear on is when I'd want to perform a common relational operation. Please could you give an example of something which is useful -- that is useful as a means to some other end, not merely useful to somebody who has an interest in relational theory -- but which is currently awkward, and then give the same example again showing how much better it is with your proposed functions? I also want to emphasize that I see this functionality being generally useful, and that it shouldn't just be shunted off to a third-party module. Why is being in a module being shunted off? You could put everything in the main namespace but that way PHP, ahem I mean madness, lies. Nicholas already pointed out that in Perl 5 Crename exists, as an operation on files. That shows the problem with using generic function names for quite specific operations without there being any surrounding context. Many people rarely use Crename, because they happen to be using Perl for things other than dealing the filesystem, but the existence of that function clobbers a useful name. Rather than fighting over it it strikes me as much more sensible to have a module for filesystem operations and another for relational operations, then users can import the functions that they actually use. Note that being in a module doesn't (necessarily) mean 'not distributed with core Perl'. 1. join() aka natural_join(): Remember that Perl already has a Cjoin function, for joining strings. Smylers
Re: Bit shifts on low-level types
Geoffrey Broadwell writes: How are the bitwise shifts defined on low level types? In particular, for right shift, does high bit extension or zero fill occur? Does the answer depend on whether the low level type is signed or not? On the flip side, it seems more useful if we have both operators available ... Deal with anything as low-level as bits seems to be very rare in Perl 5 programming. Introducing more operators to the core language, especially terse punctuationy ones, for something rarely used strikes me as a way of making the documentation fatter and raising the barrier to entry for little benefit. Perhaps having both + and ? operators? Since coerce to boolean and then right shift is meaningless, ... It's useless, rather than meaningless; you've neatly defined what the meaning of that (useless) operator would be. That is, at the moment there are consistent rules for being able to correctly guess the meaning of an operator based on knowledge of other operators. Your suggestion would break that; just because some combination of symbols doesn't currently have a use doesn't mean that it makes sense to appropriate them for something else. this seems ripe to DWIM. But DWIM is the meaning you previously defined, surely? (For me, DWIM here means + does high bit extension, ? does zero fill.) Why? You think that somebody not knowing about this operator would correctly infer its existence from other operators? Even if somebody guessed that both operators exist it looks pretty arbitrary which is which. For this esoteric sort of stuff can't we have named operators (short names if you like, perhaps taken from assembly language), in a module that can be loaded by those who need them? Smylers
Re: What criteria mark the closure of perl6 specification
Richard Hainsworth writes: When does the specification of perl6 come to an end? At a guess: when it's implemented. Many of the recent changes have been made by Larry in response to his trying to write the grammer, and encountering problems. Perhaps there could be a perl6.0 specification, with further changes (syntactic sugar, new operators, renaming operators, etc) being assigned/incorporated into a perl6.1 specification, etc. There would be no point in freezing a specification that isn't implementable. If we had labelled the spec as it was a year ago as Perl 6.0 and all subsequent changes as being part of Perl 6.1 that wouldn't've made any practical difference: it would be Perl 6.1 that everybody was trying to implement! Or to put it another way, feel free to assign the label Perl 5.93714 to a snapshot of the current spec, the state that it is in right now. Then we can all agree that Perl 5.93714 will never change. But I doubt it will help. While perl6 remains unstable in its specification (or is perceived to be that way) and is looking (from outside a select group?) like a unending road, wont this act as a deterrent to those who want to help hack it into existence, usefulness and stability? If it's any comfort the road doesn't look anywhere near as unending as it used to be! Many recent changes have been consolidatory, or relatively minor syntax tweaks -- not deep changes to the core of the language. Larry writing the grammar is a tangiable task which should have a natural end, hopefully getting us to a relatively stable point where the spec is at least consistent and implementable. There are still some 'hey wouldn't it be great if ...' threads on this list, proposing brand new features, but nowhere near as many as there used to be. And at least some of us are trying to discourage such things, hoping to deflect them away from taking Larry's time away from getting finished synthesizing what we already have -- especially in the case of things which could easily be provided by a module. Smylers
Re: What criteria mark the closure of perl6 specification
Jonathan Lang writes: Smylers wrote: Richard Hainsworth writes: When does the specification of perl6 come to an end? At a guess: when it's implemented. Many of the recent changes have been made by Larry in response to his trying to write the grammar, and encountering problems. With all due respect: Once the grammar is written, what's left to do in terms of finalizing the Perl 6.0 specification? Yeah, that's why I said implemented then immediately referred to writing the grammar, purposefully fudging exactly what level of being implemented is needed! Surely we don't need to wait for the Perl 6 implementors to finish their work before declaring 6.0 to be fully specified (and getting on with the business of working on 6.1 features)? Maybe. The tricky bit is being sure that there isn't an awkward spot in there somewhere which nobody notices until encountering it when trying to run programs. It could be foolish to be in a position where Perl 6 hasn't yet been released but problem with it can't be addressed because the spec has already been frozen. Smylers
Re: [svn:perl6-synopsis] r13588 - doc/trunk/design/syn
[EMAIL PROTECTED] writes:
Clarification of coercion declarations and semantics.
+++ doc/trunk/design/syn/S13.pod Fri Feb 16 17:59:34 2007
+method postcircumfix:( ) (|$capture) {...}
+method postcircumfix:[ ] (|$capture) {...}
+method postcircumfix:{ } (|$capture) {...}
+Those are a bit unwieldy, so you may also use these short forms:
+
+method .( |$capture ) {...}
+method @.[ *@@slices ] {...}
+method %.{ *@@slices } {...}
Did you mean for whats inside the brackets to differ between the long
and short forms for arrays and hashes?
Smylers
Re: my $temperature is ro
Steve Lukas writes: (1) The best readable form is probably: readonly $temperature; # lexical scope (2) But this fits better in perl6 conventions: my $temperature is ro; # lexical scope I think form (2) should be possible for variables. As Larry's pointed out, it pretty much already is. And form (1) Creadonly $temperature; should become syntactical sugar for Cmy $temperature is ro; Why? What does hiding the fact that is a lexical variable declared with Cmy get us? Isn't your form 2 sufficient? (3) For those who work a lot with readonly semantics, this could be best: readonly $-temperature; # lexical scope, twigil prevents all attempts! I don't fully understand. In what way are you proposing: readonly $-temperature = value(); would differ from: readonly $temperature = value(); ? Are you envisaging that both forms would be permitted, such that a program could have some read-only variables with minus signs and some without them? Would the form with the minus sign require the minus sign every time the variable is referred to (that is, it is part of its name)? If so, do you really think that C$-temperature looks 'more' read-only than C$TEMPERATURE does? Would you also be able to declare a separate (presumably read-write) variable, C$temperature in the same scope as C$-temperature? Smylers
Re: Negative array subscripts
Jonathan Scott Duff writes:
On 2/6/07, Smylers [EMAIL PROTECTED] wrote:
Blair Sutton writes:
David Green wrote:
In some ways, I like not having a [0] index at all: programmers
may be used to counting from zero, but normal humans start with
first, second, third, ... third last, second last,...
My feelings are Perl 6 should stick to 0 being the index of the
first element of a list. Otherwise we might alienate programmers
from P5 and nearly every other language. Couldn't the first array
index be adjusted by adding a user defined Parrot grammar
definition that applies the transformation +1 inside [] operators
instead; maybe this could be accessible via a Perl use pragma.
Hmmm, a pragma's a bit heavyweight for this; how about being able to
set this with a special global variable -- that sure sounds handy
...
I can't quite tell how serious you are :-)
I was being completely serious in my attempt to remind folk of C$[ in
Perl 5, how much it is despised, and that it is a mistake that Perl 6
won't be repeating.
... I can see the need for a pragma to help out the Pascal or Fortran
programmers start all of their arrays at something other than 0.
Those sort of crutches in programming languages (let's help folk who
know some other language -- meaning they end up programming in some
hybrid of the two languages) often turn out to be a mistake. Think of
Pascal programmers #define-ing begin and end as { and } in C, or
WordBasic being 'localized' into French, or Cuse English in Perl 5.
Part of this is cos they are mostly unnecessary: there are so many
fundamental and much deeper differences between Pascal and Perl that any
Pascal programmer who's managed to learn about and cope with all the
weird and wonderful things that Perl offers isn't going to struggle with
the relatively superficial difference in array subscripts.
And I can see the need for a modifier so that an individual array can
start at an index other that 0.
Isn't that something shaped arrays can already do?
Smylers
Re: [svn:perl6-synopsis] r13582 - doc/trunk/design/syn
[EMAIL PROTECTED] writes:
+++ doc/trunk/design/syn/S06.pod Mon Feb 12 00:10:05 2007
+ Version: 69
... this does [work]:
+my @data = 1,2,3;
+my @tmp = eager @data;
+@data == grep { $_ % 2 } == @tmp;
+
+Conjecture: these are probably impossible:
+
+@data == grep { $_ % 2 } == eager @data;
Surely that's the form that folks will actually want?
With no supporting data at all I'm going to claim it's reasonably common
to want to filter an array without any need to keep the original around;
having the Perl 6 idiom for that involve a temporary array seems rather
ugly, exactly the sort of awkwardness that Perl 6 is eliminating
elsewhere.
Smylers
Re: Negative array subscripts
Blair Sutton writes: David Green wrote: In some ways, I like not having a [0] index at all: programmers may be used to counting from zero, but normal humans start with first, second, third, ... third last, second last,... My feelings are Perl 6 should stick to 0 being the index of the first element of a list. Otherwise we might alienate programmers from P5 and nearly every other language. Couldn't the first array index be adjusted by adding a user defined Parrot grammar definition that applies the transformation +1 inside [] operators instead; maybe this could be accessible via a Perl use pragma. Hmmm, a pragma's a bit heavyweight for this; how about being able to set this with a special global variable -- that sure sounds handy ... Smylers
Re: [svn:perl6-synopsis] r13564 - doc/trunk/design/syn
[EMAIL PROTECTED] writes:
+++ doc/trunk/design/syn/S03.pod Fri Feb 2 01:07:36 2007
if $filename ~~ :e { say exists }
+if $filename.:e { say exists }
+Both of these forms actually translate to
+
+if $filename.TEST(:e) { say exists }
Hey, that looks good.
I've got a slight concern over the name CTEST though. The Perl QA
folk already seem to have enough trouble coming up with enough
permutations of test, tests, Test, TEST, and so on for labelling
tests, test frameworks, and things that relate to testing. Which this
isn't.
(But I have't got a suggestion for a better name.)
Smylers
Re: Remember: Outlaw to declare a lexical twice in the same scope
Carl Mäsak writes: my $foo; # ...later in the same scope... my $foo; # illegal Perl5, legal Perl6 That isn't illegal in Perl 5. It yields the warning: my variable $foo masks earlier declaration in same scope but it does work. Smylers
Re: Numeric Semantics
TSa writes: Larry Wall wrote: The default / operator is not going to do integer division. [..] And % should stick to standard floor semantics, I expect. Since the latin1 charset contains the division character ÷ we could use that to mean floor based integer division and % the floor based modulus. Then we could make the div and mod pair mean the Euclidean definition. Do you think most Perl programmers appreciate the difference, or are likely to need both sorts frequently? I'd much prefer for introductory Perl books not to have to explain what Euclidean means. Everything else could be loadable from a module. I still reckon a single type of division is sufficient in core, with everything else in modules. Smylers
Re: Numeric Semantics
TSa writes: Smylers wrote: I'd much prefer for introductory Perl books not to have to explain what Euclidean means. Yeah, it will not dive into the exact reasons why the floor definition was chosen, either. Sure, if we _only_ have floor (or indeed if we _only_ have one of the others). But as soon as we have two different sorts of div, it's necessary to explain the difference between them. Smylers
Re: Numeric Semantics
Darren Duncan writes: For round-trip consistency, a generic non-formatted num-to-char-string operation should include a .0 as appropriate if it is converting from a Num, whereas when converting from an Int it would not. So this (in Perl 5): % perl -wle 'print 100 / 2' 50 you would want in Perl 6 to print 50.0 instead? Obviously it would be possible to get 50 by explicitly converting the result to an integer: % perl6 -e 'say (100 / 2).int' But of course always using Cint means you lose any fractional parts from divisions that don't yield integers: % perl -wle 'print 99 / 2' 49.5 How would you get the current Perl 5 behaviour of displaying fractional parts if they exist and not if they don't? Smylers
Re: Numeric Semantics
Larry Wall writes: The default / operator is not going to do integer division. Yay! This is not negotiable; Double-yay! Whether a Num that happens to be an integer prints out with .0 is a separate issue. My bias is that a Num pretend to be an integer when it can. Triple-yay! Smylers
Re: Numeric Semantics
TSa writes: Looks like we need a host of division function pairs: fdiv fmodflooring division ediv emodeuclidean division rdiv rmodrounding division tdiv tmodtruncating division cdiv cmodceiling division That depends on exactly what you mean by we and need. I think it would be terrible to that many div and mod functions as a core part of the Perl language. Most people would rarely use any of them, and merely having them there at all slightly raises the barrier of entry to Perl, making the documentation just a little bit fatter. By all means have them available as modules. Presumably people who need this stuff in Perl 5 have already created Cpan modules providing them, and the same will happen in Perl 6. Smylers
Re: [svn:perl6-synopsis] r13495 - doc/trunk/design/syn
[EMAIL PROTECTED] writes: New Revision: 13495 doc/trunk/design/syn/S12.pod +In addition to Cnext METHOD, the special functions Ccallsame, +Ccallwith, Cnextsame, and Cnextwith dispatch to the next +candidate, possibly with a new argument list, and if the next +variant is used, without returning: + +callsame; # call with the original arguments (return here) +callwith(); # call with no arguments (return here) +callwith(1,2,3);# call with a new set of arguments (return here) +nextsame; # redispatch with the original arguments (no return) +nextwith(); # redispatch with no arguments (no return) +nextwith(1,2,3);# redispatch with a new set of arguments (no return) So Cnext sometimes has the meaning of jumping to the next iteration of the current loop (as in Perl 5), and sometimes means to invoke a different method in place of the current one; nextsame and nextwith are related to the latter meaning. Won't that be confusing? Or hard to teach? The 'loop' use of Cnext is likely to be encountered by learning programmers far earlier than 'method' use, leaving the latter as something to trip them up when they finally meet it. Smylers
Re: supertyping
TSa writes:
Larry Wall wrote:
role Num is also does Complex {
method im {...}
}
Is that the actual syntax?
Larry's words that you snipped introducing that code fragment were:
We might *possibly* get away with reopening roles like we can reopen a
class:
It seems unlikely that the syntax is final if the feature is only being
mooted as might be possible (and the rest of Larry's message wasn't
exactly enthusiastic about the idea).
Smylers
Re: supertyping
Jonathan Lang writes: For the record, I think that superdoes should be spelled done_by. I think it's unlikely that Larry will incorporate any keywords that contain underscores -- certainly not without at least searching for a single word that sums up the concept in question. Smylers
Re: [svn:perl6-synopsis] r13487 - doc/trunk/design/syn
[EMAIL PROTECTED] writes:
Log:
More entries in smartmatch table.
+++ doc/trunk/design/syn/S03.pod Wed Nov 29 09:20:50 2006
+HashHash hash keys identical match if $_.keys === $x.keys
+HashSet members identicalmatch if $_.keys === $x
+Set Set members identicalmatch if $_ === $x
+Hashany(Hash) hash key intersectionmatch if exists
$_{any(Hash.keys)}
Should that last one have a C$x in the code somewhere?
Smylers
Re: Set-returning .keys
Ruud H.G. van Tol writes: Darren Duncan schreef: TSa: set operations ... make them Bag operations to start with. I agree with ... making Set the main type and making Bag an extension built upon that, as complex is built upon num, etc. I don't think that will work out. Modification of a Set is more complex than modification of a Bag, so in that sense the Bag is the main type. Is this still the Perl 6 _Language_ group? The one where we consider what Perl 6 will do, and leave the implementation details to others? Smylers
Re: beg for Bag
TSa writes: I want to propose the addition of a Bag type Different from the CBag that's already mentioned in Synopsis 3? Smylers
Re: generic ordinal-relevant operators
TSa writes: ... one question remains that might actually make Duncan's proposal pointless. Didn't Larry actually accept Darren's proposal and add the Cbefore and Cafter operators? Are the comparison operators available for overloading just like any other operator Yes. This feature is used often enough in Perl 5 classes, and I'm almost certain there are no plans to remove it from Perl 6. Smylers
Re: generic ordinal-relevant operators
TSa writes: Darren Duncan wrote: For the record, my preference is to have the generics be the shortest, [==,!==,=,,,=,=], and use [+,~] prefixes for Num or Str casting versions. And lengthen the bit-shift operators to use thin-tailed arrowheads as you suggested. I like this proposal for its orthogonality. Bzzzt, wrong language! But Perl isn't an orthogonal language, it's a diagonal language. http://www.oreilly.com/catalog/pperl2/excerpt/ch01.html For what it's worth, I don't like the proposal because I was already having trouble getting my head round the number of different operators for asking is this thing at least vaguely like this other thing. Please can proposals for new operators (not just operators, for that matter) be supported by examples along with the form: Look at this awkward code (which could plausibly occur in the wild), and look how less awkward the code is when rewritten using my proposed operator. And it allows to introduce some more binary boolean functions: Woo, _more_ binary boolean functions -- what a boon! ? inhibition? reverse inhibition ?= implication ?= reverse implication (dual of the above) ?== equivalence (dual of xor) The low precedence versions might be spelled inh, rinh, imp and rimp. Hmm, and eqv ;) Personally I choose to use a language such as Perl in preference to, say, 6502 Assembly Language, to avoid operators being non-intuitive sequences of three letters. BTW, could we define that the arithmetic shift ops do just that, whereas the string ones do logical shift? And in addition that for the bit inversion +^$a == -1 - $a holds? Note that -1 == +^0. Does that assume a two's complement system? Is that a safe assumption to make about everywhere Perl 6 will run? (Is it even a safe assumption to make about Perl 5?) Note further that in infinite precision the arithmetic shift left maintains the sign ... Do we expect Perl 6 to be running on infinite-precision systems? Smylers
Re: named sub-expressions, n-ary functions, things and stuff
Darren Duncan writes:
1. I'm not sure if it is possible yet, but like Haskell et al ..., it
should be possible to write a Perl 6 routine or program in a pure
functional notation or paradigm, such that the entire routine body is
a single expression, but that has named reusable sub-expressions.
I realize it isn't pure functional, but in Perl a Cdo block permits
arbitrary code to be treated as a single expression. Or to put it
another way round, you can use temporary variables inside the expression
that don't 'leak out' of it.
For example, in pseudo-code:
routine foo ($bar) {
return
with
$bar * 17 - $baz,
$baz - 3 - $quux,
$baz / $quux;
}
This is instead of either of:
routine foo ($bar) {
return ($bar * 17) / ($bar * 17 - 3);
}
That's obviously bad cos of the repetition.
routine foo ($bar) {
my $baz = $bar * 17;
my $quux = $baz - 3;
return $baz / $quux;
}
But what does a functional form have over that? Or over the Cdo
version:
my $whatever
= do { my $baz = $bar * 17; my $quux = $baz - 3; $baz / $quux };
Sure there are variables. But in terms of how your brain thinks about
it is it any different from the functional version -- labels being
associated with intermediate parts of the calculation?
Smylers
Re: Programming languages and copyright?
Markus Laire writes: Does anyone know if programming languages are protected by copyright or not? Code can be copyrighted; ideas can't be. When creating a new program, you are not allowed to pick-and-choose what you want from other programs sources as that would be a copyright violation. Sources is the key word there. You are allowed to take inspiration from what other programs _do_ -- indeed most programs out there seem to be imitations of or rivals to others. But when creating a new programming language, it seems that everyone is picking-and-choosing what they want from other programming languages. Yes, but not from the source of their implementation. (At least, not from the source of any which don't have a licence explicitly permitting doing so.) Smylers
Re: set operations for roles
TSa writes: Ruud H.G. van Tol wrote: TSa schreef: A(|)B produces a subtype of A and B, and that A()B produces a supertype Are you sure? Very sure ;) In which case that provides a handy example supporting Larry's suggestion that this is confusing, with some people expecting it to work exactly opposite to how it does. It doesn't really matter which way is right -- merely having some people on each side, all naturally deriving what makes sense to them -- shows that implementing this would cause much confusion. Smylers
Re: Synposis 26 - Documentation [alpha draft]
On October 7th Damian Conway wrote: Before Christmas, as promised! [DRAFT] Synopsis 26 - Documentation Thank you for that, Damian! Apologies for taking a while to respond, but I wanted to leave reading the document until I had a sufficient chunk of time to do it justice. And I was very impressed. One quibble: To include named Unicode or XML entities, use the CE code. If the contents are not a number, they are interpreted as an upper-case Unicode character name, or as a lower-case XML entity. For example: Perl 6 makes considerable use of Elaquo and Eraquo. I think the only standard XML entities are Clt;, Cgt;, and Camp;. Particular XML languages can define further entities which use that syntax, but they aren't included by default. However, the examples you give are HTML entities, defined in the HTML 4 spec: http://www.w3.org/TR/REC-html40/sgml/entities.html Smylers
Re: Don't tell me what I can't do!
Trey Harris writes:
In a message dated Wed, 4 Oct 2006, Smylers writes:
Trey Harris writes: T
I remember not so many years ago when there were a lot of modules
floating around that required you to do no strict of various
flavors in order to use them.
Really? How?
I wrote imprecisely. Not to use them in the sense of Cuse Package,
but use in the sense of make use of them as described in the perldoc's
synopsis
No, your words were fine -- you successfully conveyed that meaning but
was still puzzled by it.
--usually by dint of requiring undeclared package variables,
barewords,
How can a module require undelcared package variables? Surely a module
simply requires package variables, then it's up to you whether you
declare them or not?
or symbolic refs.
I hadn't thought of that. Have you got an example of that? I'm still a
little surprised to hear there were a lot of modules floating around
doing this sort of thing.
Alias is one example, there were others.
I've never used Alias, but from looking at its synposis I'd've thought
that judicious use of Cour would permit code using the module to run
with Cuse strict.
(For example, a package that had string constants defined as
subroutines like Csub ERRCODE() { ERRCODE } would behave
differently than one that assumed barewords would work, but both might
use identical examples of Cmoose ERRCODE in their perldocs.)
Gotcha. So a user of the latter module could put the error codes in
quotes to keep with Cuse strict, it's just that the module docs didn't
make this clear? That sounds more like a documentation glitch than a
module which requires you to use Cno strict.
I still run across modules that need no warnings. (I won't name
names, because some of their authors post to this list ;)
Again, I can't see how. If you use Cuse warnings in your program then
it is lexically scoped and only affects your code, not that of other
files you load in.
Again, I meant in code use,
Sure.
not in just loading--uninitialized value warnings being the main
culprit there.
But any variable that I define I can initialize to prevent that warning
being emitted by my code. And since Cuse warnings is lexical, it
doesn't matter what the module's code does, that won't emit warnings
just because I've enabled them in my code that uses the module.
Smylers
Re: S5: substitutions
Jonathan Lang writes:
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() } }
That special case is nasty if you don't know about it -- you
inadvertently execute as code something which you just expected to be a
string. Not a good trap to have in the language.
Smylers
Re: S5: substitutions
Jonathan Lang writes:
Smylers wrote:
Jonathan Lang writes:
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() } }
That special case is nasty if you don't know about it -- you
inadvertently execute as code something which you just expected to
be a string. Not a good trap to have in the language.
If you expected it to be a string, why did you use curly braces?
Because it isn't possible to learn of all Perl (5 or 6) in one go. And
in general you learn rules before exceptions to rules.
In general in Perl the replacement part of a substitution is a string,
one that takes interpolation like double-quoted strings do.
In general in Perl if the default delimiter for something is
inconvenient you can pick a different delimiter -- this includes
patterns, and also strings. And if you pick any sort of brackets for
your delimiters then they match -- which is handy, cos it means that
they can still be used even if the string inside contains some of those
brackets.
So it's quite possible for somebody to have picked up all the above, and
have got used to using Cqq[long string] or Cqq{long string} when he
wishes to quote long strings. The form with braces has the advantage
that they are relatively uncommon in text (and HTML, and SQL, and many
other typically encountered long strings).
At which point if he wants to do substitution with slashes in at least
one of the pattern or the replacement text (perhaps it's a URL or a
filename) then he's likely to pick some other arbitrary characters for
doing the quoting. And braces seem as likely to be picked as anything
else. Unless he specifically knows about an exception there's no reason
not to pick them.
I refer simply to Perl above. The above situation could just as
easily arise (or already have arisen) in Perl 5 -- in which case the
programmer's expectations would've been met and the code interpreted
fine. Your proposal would make that no longer the case in Perl 6.
And, apart from people learning Perl fresh, there's also a large number
of existing Perl 5 programmers who also won't be expecting this
exception.
Yes, Perl 6 isn't supposed to be compatible with Perl 5, and obviously a
Perl 5 coder is going to have to learn lots of new things anyway. But
usually they are significantly different, or the old way of doing things
will be a syntax error. This is a situation where the old syntax
continues to work but does something quite different.
That's unfortunate, but probably liveable with in general. But in this
particular case the particular behaviour involves _executing as Perl
code something which the programmer never intended to be code in the
first place_. That's crazily dangerous.
It's like having a Perl 5 to Perl 6 translator that randomly sticks
eval statements in front of some of your double-quoted strings.
While I'm completely on board with the idea that _pattern_ delimiters
shouldn't affect the _pattern's_ semantics, the second half of the
search-and-replace syntax isn't a pattern. Conceptually, it's either
a string or an expression that returns a string.
Sure. Or rather, it's a string (but braces inside strings can be used
to embed expressions in them).
To be consistent your proposal should also suggest that these become
equivalent:
* { function() }
* qq[ {function() }]
* qq{ function() }
* eval function()
and, naturally, that these no longer are:
* string
* qq[string]
* qq{string}
And if braces are special as delimiters for Cqq consistency would say
they should be for Cq as well -- effectively just another way of
spelling Ceval, but one that doesn't stand out so much.
Smylers
Re: Don't tell me what I can't do!
Trey Harris writes: In a message dated Wed, 4 Oct 2006, chromatic writes: The assumption I remember from the design meetings was always No library designer has the knowledge or the right to tell me how fast or strict my program has to run. Whatever BD you do in the privacy of your own modules is fine, but if it leaks out past encapsulation boundaries, expect that somewhere you might offend community standards. Yes, but by the same token, no library designer should force you to be *less* strict than you wish to. Sure. I remember not so many years ago when there were a lot of modules floating around that required you to do no strict of various flavors in order to use them. Really? How? I still run across modules that need no warnings. (I won't name names, because some of their authors post to this list ;) Again, I can't see how. If you use Cuse warnings in your program then it is lexically scoped and only affects your code, not that of other files you load in. C-w does affect all files, but that's one of the reasons why Cuse warnings is an improvement over C-w, because it lets the author of each bit of code have control over it. Smylers
Re: Don't tell me what I can't do!
jerry gay writes: On 10/2/06, Jonathan Lang [EMAIL PROTECTED] wrote: I'm not used to programming styles where a programmer intentionally and explicitly forbids the use of otherwise perfectly legal code. Is there really a market for this sort of thing? use strict; That's different: it's _you_ that's forbidding things that are otherwise legal in your code; you can choose whether to do it or not. Jonathan's examples were all of _somebody else_ forbidding you from doing otherwise-legal things; you have this imposed on you without choice. Smylers
Re: Capture sigil
Larry Wall writes: Conjecture: We need a corresponding sigil to request captureness. As Bikeshed: What should that sigil be? What's * doing these days? Smylers
Re: renaming grep to where
Darren Duncan writes: At 6:26 AM +0200 9/19/06, Damian Conway wrote: ... *if* we're going to change it from grep, we ought to change it to filter. I agree. So filter is now my preference for a new name, and if grep is kept, then that can be an alias for it; No: no aliases. Perl does not have a tradition of these, and overall aliases tend to add to confusion -- with the result that everybody ends up having to learn both (or all) names anyway. And I'm pretty sure Larry has previously spoken out against aliases. MySQL's SQL dialect has a few synonyms. On numerous occasions I've seen SQL that I didn't think I understood only to discover I knew a different name for the same thing, or _vice versa_. use English provides lots of aliases in Perl 5, but note how rarely they are used in practice. Even if somebody chose to use English in all her code she would still have to learn the punctuation variable names to read others' code, get help from fora, and so on. And I can honestly say that when reading Damian's 'Perl Best Practices' when I saw a reference to C$EVAL_ERROR I first of all stopped to see where it had been declared before realizing it was just another name for the variable I use every day as C$@. filter should be the canonical name for most documentation, though. That's one of the problems with aliases: if the docs generally use Cfilter then when a reader encounters code using Cgrep for the first time he will be more puzzled than if either name had been used consistently through out. And you can be sure that most existing Perl 5 coders who are used to Cgrep would continue to use that name in Perl 6, regardless of what the docs say. I do not think renaming Cgrep to Cfilter is a terrible idea, but if it's being done then it should be done properly, not half-heartedly with an alias. Smylers
Re: renaming grep to where
Damian Conway writes: I don't object in principle to renaming grep to something more self explanatory (except for the further loss of backwards compatability and historical Unix reference...though that didn't stop us with switch vs given ;-) But while Cswitch had precedence in computer science in general it didn't have this in Perl; your Switch module is not used much in Perl 5, and Perl 6's Cgiven is a substantial improvement over the Cswitch statement in most languages. Whereas Cgrep is a well-known and well-used Perl 5 function, and this functionality is not being changed in Perl 6 (other than being available as a method as well as a function). The standard--and self-explanatory--CS term for this operation has always been filter, which is also currently used by Python, Scheme, Haskell, and numerous other languages, so *if* we're going to change it from grep, we ought to change it to filter. Yes, but Cgrep is a just one type of filter: it's specifically a filter on elements in a list. By deploying the generic word filter for this specific use we'd be clobbering its use for any other sorts of filters -- on lines, source code, coffee, whatever. I have no statistics but I'd guess that Cfilter is a reasonably common sub or method name in Perl 5 code found in the wild -- much more so than Csay or Cgiven -- and that it's currently being used to filter many things other than lists. The above are not conclusive reasons why we shouldn't rename Cgrep to Cfilter (I'm not that bothered either way myself), but just some points to bear in mind and reasons to be cautious. Smylers
Re: renaming grep to where
Randal L. Schwartz writes: Smylers == Smylers [EMAIL PROTECTED] writes: Smylers No: no aliases. Perl does not have a tradition of these, except for/foreach. :) I don't reckon one instance is enough to be labelled a tradition! (Um ... actually I forgot about that one. But if I had considered it I still wouldn't've considered it to be a tradition. Honest.) Smylers
Re: [svn:perl6-synopsis] r11504 - doc/trunk/design/syn
[EMAIL PROTECTED] writes:
New Revision: 11504
doc/trunk/design/syn/S02.pod
+C ('foo','bar') . Since parentheses are generally reserved just for
+precedence grouping, they merely autointepolate in list context. Therefore
Typo: autointepolate.
Smylers
Re: ===, =:=, ~~, eq and == revisited (blame ajs!) -- Explained
David Green writes: On 8/13/06, Smylers wrote: Please could the proponets of the various behaviours being discussed here share a few more concrete examples ... OK, Thanks for that. In summary, if I've understood you correctly, it's that: =:= two aliases to the same actual variable === one variable contains a copy of the other's actual contents eqv both contain contents which represent the same thing but may have come from different sources And that being true at one level implies being true for the above levels. Yes? === Example: Suppose I have some employee objects, and I employ two John Smiths. They have the same name, work in the same department, and by stunning coincidence everything my class knows about them just happens to be the same. Except that they wouldn't. Because each one would have a separate payroll number, or some artificial thing invented just for the sake of being different. So this example doesn't sound plausible to me. But they're still different objects (the payroll system definitely needs to produce two cheques, although since they earn the same salary, it doesn't matter which one of them gets which cheque); so $john1 !=== $john2, and I can tell them apart. And why on earth would you be making such a comparison? If you have a list of employees who need cheques then you just iterate through them and process them in turn; you wouldn't be comparing an arbitrary pair of them. So I now understand what this operator does. But I'm still struggling to fathom where I would ever have a use for it. Smylers
Re: ===, =:=, ~~, eq and == revisited (blame ajs!) -- Explained
On July 14th Yuval Kogman wrote: On Fri, Jul 14, 2006 at 11:42:24 +0100, Smylers wrote: I'm afraid I still don't get it. Or rather, while I can manage to read an explanation of what one of these operators does and see how it applies to the variables in the examples next to it, I am struggling to retain a feeling of _why_ I would want to use any of these operators in real-life Perl 6 code. To compare deep structures ;-) Already in Perl 5 having 2 different equality operators is something that learners often stumble over. But only for low level types. To see if two objects are the same, or two hashes, you need to use Data::Compare, or to overload either == or eq, neither of which is a perfect fit. I have to catch my flight, so I'll explain more later. Hi there. Ann's (excellent, very useful, and much appreciated) summary reminded me that this was still pending. Did you catch your flight? For the benefit of anybody else who's struggling to remember a thread from a month ago this was my original request. Please could the proponets of the various behaviours being discussed here share a few more concrete examples which start by explaning a scenario in which there is a desire to do something, preferably one that Perl 5 coders can identify with, and then show how one of these new operators would meet that desire (and that without that operator it would be hard or clumsy to achieve the same thing)? Cheers. Smylers
Re: [svn:perl6-synopsis] r10350 - doc/trunk/design/syn
[EMAIL PROTECTED] writes: s/loop/repeat/ for test-after loops Yay! That makes things very clear, with different things looking nicely different. Smylers
Re: S04 - forbidden coding-style
Markus Laire writes:
S04 seems to say that a style like this can't be used by
perl6-programmers:
loop
{
...
}
while $x;
I like this style, as it lines up both the keywords and the curlies.
As of yesterday you can get very close to this by putting a space-eating
backslash after the closing brace:
loop
{
...
}\
while $x;
That still has the keywords and the braces aligned.
Smylers
Re: [svn:perl6-synopsis] r10299 - doc/trunk/design/syn
[EMAIL PROTECTED] writes: New Revision: 10299 Modified: doc/trunk/design/syn/S03.pod == +If the next item after the list operator is either an infix operator +or a term, a syntax error. If the sentence has no verb, a grammatical error. Smylers
Re: ===, =:=, ~~, eq and == revisited (blame ajs!) -- Explained
Yuval Kogman writes: So, Larry assisted by Audrey explained the purpose of === vs eqv vs =:=. I'm afraid I still don't get it. Or rather, while I can manage to read an explanation of what one of these operators does and see how it applies to the variables in the examples next to it, I am struggling to retain a feeling of _why_ I would want to use any of these operators in real-life Perl 6 code. Please could the proponets of the various behaviours being discussed here share a few more concrete examples which start by explaning a scenario in which there is a desire to do something, preferably one that Perl 5 coders can identify with, and then show how one of these new operators would meet that desire (and that without that operator it would be hard or clumsy to achieve the same thing)? Already in Perl 5 having 2 different equality operators is something that learners often stumble over. If we're going to have 5 of the things in Perl 6 then there needs to be a very clear way of explaining how to determine which one to use (or at least an explanation that 3 of the operators are very esoteric and beginners don't need to worry about them). Smylers
Re: ===, =:=, ~~, eq and == revisited (blame ajs!) -- Explained
Yuval Kogman writes: On Fri, Jul 14, 2006 at 11:42:24 +0100, Smylers wrote: Or rather, while I can manage to read an explanation of what one of these operators does and see how it applies to the variables in the examples next to it, I am struggling to retain a feeling of _why_ I would want to use any of these operators in real-life Perl 6 code. To compare deep structures ;-) Thank you. That helps. My initial instinct was that this meant the new operators can all be dismissed as ignorable by learners, as they won't be using nested data structures anyway. But actually deep doesn't have to be very deep in order for such a comparison op to have use: merely wanting to see if the contents of 2 arrays are the same doesn't involve any nesting and is a concept that is well within the grasp of a beginner. so I'll explain more later. Great. I appreciate your help, and I'm looking forward to your explanation of the different behaviours in this thread. Smylers
Re: [svn:perl6-synopsis] r10077 - doc/trunk/design/syn
[EMAIL PROTECTED] commits: New Revision: 10077 Modified: doc/trunk/design/syn/S02.pod == -foo.bar # foo().bar -- postfix prevents args +foo.bar # foo().bar -- illegal postfix, must use foo().bar foo .bar # foo($_.bar) -- no postfix starts with whitespace I don't think it makes much sense to start the comments with an alternate form for the expressions now denoted as illegal -- here's some other syntax which this used to be the same as but it no longer is probably only confuses the casual reader. Smylers
Re: Perl5 - Perl 6 Translations Design Document
Sage La Torra writes:
interpolative context ment the perl 5 side, where the double quotes
should cause interpolation.
Yes, but not for entire hashes; the percent character isn't special in
Perl 5 double-quoted strings, as Aaron said:
On 6/6/06, Aaron Crane [EMAIL PROTECTED] wrote:
Sage La Torra writes:
http://infohost.nmt.edu/~slatorra/conversionstageone.txt
You say this:
-Hash in interprative context: %hash - %hash{} (also @{[...]} -
{...})
Hashes don't interpolate in Perl 5, so that's not an issue
And Sage, please (in general) don't top-post on this mailing list; it
makes it much harder for people who wish to follow up on what was said
earlier in the thread to provide context for exactly what they're
commenting on.
Smylers
Re: Provisional Foo [Was: [svn:perl6-synopsis] r9176 - doc/trunk/design/syn]
Larry Wall writes:
Yes, the false value is False now, just as the true value is not True.
It's not? I thought somebody had just said that it was?
The reason for changing them is to avoid confusion with the built-in
true() function,
Makes sense.
So arguably, we could have a rule or policy that 0-ary functions are
generally uppercase, not just the constant ones. Instead of time,
we'd have Time.
Does that actually gain us anything?
Then the 0-or-1-ary functions could be rand(42) vs Rand, and the Rand
form would never look for an argument.
Personally I think that'd be more confusing. It isn't particularly
intuitive, and it makes switching from one form to another more awkward
cos you don't just have to change the params after the function name but
also the case of the letter at the start.
And what about functions with names starting with an underscore?
Defining a
sub baz ($x?) {...}
would also define
sub Baz () {...}
Could also say that, unlike a provisional foo, a provisional Foo
would be considered 0-ary rather than list op.
Who would benefit from this? To me it just seems like more complexity,
and encouraging hard-to-spot typos as we have things which differ only
in case. Surely if somebody has a function call Cbaz which they
explicitly want to mark as being 0-ary then writing it as C(baz) or
Cbaz() is already a sufficiently convenient way of doing this, and is
intuitive to the casual reader.
I think the effort in learning this special case outweighs any benefit
it brings.
Smylers
Re: [svn:perl6-synopsis] r9197 - doc/trunk/design/syn
Allison Randal writes: [EMAIL PROTECTED] wrote: Log: Changed :words/:w to :sigspace/:s and invented ss/// and ms// (or maybe mm//). I keep expecting 'sigspace' to have something to do signatures. So do I. How about :litspace for 'literal space'? Except they aren't exactly literal, because they only indicate where _some_ space has to be, not that it has to be exactly that sort of space. What about :gappy, to indicate that there have to be gaps in the source text at the points where there are gaps in the pattern? Smylers
Re: Scans
Larry Wall writes: On Mon, May 08, 2006 at 05:30:23PM +0300, Gaal Yahas wrote: : 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. I'm obviously insufficiently imaginative. Please can you give a few examples of these things being very useful? Maybe that's just what reduce operators do in list context. Instinctively I'm resistant to that, cos I can think of situations where I'd invoke reduce operators (or where I already do the Perl 5 equivalent) wanting a reduction and where the code just happens to be in list context: in a Csay call, or in the block of a Cmap. Having to remember to use C~ or C+ to avoid inadvertently getting something complicated I don't understand sounds like the kind of thing that would trip me up. But this could just be because I don't (yet) grok scans. Smylers
Re: Scans
Markus Laire writes: On 5/9/06, Smylers [EMAIL PROTECTED] wrote: But this could just be because I don't (yet) grok scans. Here's a simple example: [+] 1,2,3,4,5 would return scalar 1+2+3+4+5 as a reduction and list (0, 1, 1+2, 1+2+3, 1+2+3+4, 1+2+3+4+5) as a scan. That doesn't help. I can understand the mechanics of _what_ scans do. What I'm struggling with is _why_ they are billed as being very useful. So I have the list generated by the scan. And? What do I do with it? I can't think of any situation in my life where I've been wanting such a list. Smylers
Re: Scans
Gaal Yahas writes:
On Tue, May 09, 2006 at 11:23:48AM +0100, Smylers wrote:
So I have the list generated by the scan. And? What do I do with
it? I can't think of any situation in my life where I've been
wanting such a list.
Scans are useful when the intermediate results are interesting, as
well as when you want to cut off a stream once some threshold
condition is met.
OK, we're getting closer, but that still sounds quite abstract to me.
item [+] 1 .. 10; # 10th triangular number
list [+] 1 .. 10; # 10 first triangular number
first { $_ 42 } [+] 1 ..* # first triangular number over 42
Same question, but one level further on: why would I want the first 10
triangular numbers, or the first triangular number over 42?
Sorry to keep going on like this, but I'm still struggling to see what
this gets us. Is wanting to do something like that sufficiently common
in real-life situations?
I've seen other people ask similar questions about features such as
juctions and hyperoperators (and folk were able to come up with suitable
examples), but in those cases there was also response that these are
features which beginners can choose to ignore.
I'd have no particular objection to scans being in Perl 6 if those of us
without sufficient imagination were able to just ignore them, and act
like they don't exist. But if things that look like reductions
sometimes turn out to be scans then I have to know about them (even if
just to avoid them) anyway.
And I have no problem in thinking of lots of situations where I'd find
reductions handy. It slightly unnerves me that I suspect some of those
would happen to be in list context -- not because I wanted a list, but
because things like Cmap blocks and Csay arguments are always lists.
Are scans sufficiently useful that they are worth making reductions more
awkward, and have a higher barrier to entry (since you now have to learn
about both reductions and scans at the same time in order to be able to
use only one of them).
If you have a series whose sum yields closer and closer approximations
of some value, you can use a scan to efficiently cut off once some
epsilon is reached.
OK, I can see why mathematicians and engineers would want to do that.
But that's a specialist field; couldn't this functionality be provided
in a module? I'm unconvinced that core Perl needs features for closely
approximating mathematicians any more than it needs, say, CGI parameter
parsing or DBI -- they're all niches that some people use lots and
others won't touch at all.
Smylers
Re: Scans
Mark A. Biggar writes: Austin Hastings wrote: Gaal Yahas wrote: list [==] 0, 0, 1, 2, 2; # bool::false? # (bool::true, bool::true, bool::false, bool::false, bool::false) (And I'm with Smylers on this one: show me a useful example, please.) Well the above example does tell you where the leading prefix of equal values stops, assuming the second answer. But you still have to iterate through the list of Cbools to get that index -- so you may as well have just iterated through the input list and examined the values till you found one that differed. Combined with reduce it gives some interesting results: [+] list [?] @bits == index of first zero in bit vector Yer what? Are you seriously suggesting that as a sane way of finding the first element of C@bits that contains a zero? That doesn't even short-cut (since the addition reduction can't know that once it starts adding on zeros all the remaining values are also going to be zeros). There are other APLish operators that could be very useful in combination with reduce and scan: The fact that there are more operators that go with these only adds to my suspicion that this field of stuff is appropriate for a module, not the core language. the bit vector form of grep (maybe called filter); filter (1 0 0 1 0 1 1) (1 2 3 4 5 6 7 8) == (1 4 6 7) Please don't! The name 'filter' is far too useful to impose a meaning as specific as this on it. Smylers
