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 > > 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 > === > +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: 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: 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,:mice) # 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
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: 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: 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 C 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- types are defined in terms of the
> +C<.succ> and C<.pred> methods on the type of object in the C
> +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: Pair notation for number radix
brian d foy writes: > In article <[EMAIL PROTECTED]>, Larry Wall > <[EMAIL PROTECTED]> wrote: > > > On Tue, Dec 04, 2007 at 08:28:48AM -0800, brian d foy wrote: > > > > : In article <[EMAIL PROTECTED]>, Larry Wall > > : <[EMAIL PROTECTED]> wrote: > > : > > : > : Later in the "Literals" section of S02, there's a chart of the > > : > : corresponding forms for fat arrow, pair, and paren notation. It has > > : > : > > : > :a => 'foo' :a :a() > > > > You're confusing various levels here when you say "same thing". > > They're the same in some ways and different in others. > > Well, I think the documentation is confusing it. If these notations > are not the same thing, should there be a table that shows the > correspondence of these forms? Those three _are_ all the same thing, in that they all generate pairs. The colon can _also_ be used for forming adverbs (similarly to how the slash can be used for both regexes and division, in different places), but that doesn't effect the equivalence of the above. 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: 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: 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: 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: > On Nov 28, 2007 8:46 PM, chromatic <[EMAIL PROTECTED]> wrote: > > > On Wednesday 28 November 2007 10:59:30 James Fuller wrote: > > > > > I do not nec. agree with 'a particular grammer is not' part of the > > > core ... if that grammar is so common to every problem (like regex > > > is) then why not include it? > > > > The criterion for including a module in the core is "Is this > > necessary to get and install other modules?" not "Why not include > > this module?" > > feels like we are externalizing what I would call build artifacts of a > language e.g. a distro of Perl 6 should be easy to adopt and easy > to use immediately chromatic said "the core"; you said "a distro of Perl 6". They are not the same thing. > . I would like to see some basic level of XML support in this > distro. I'm sure you would. Personally I would like to see all the modules I often use in the distro. It's very rare for me to use XML, but there are lots of other things I do use often. How about we make the core the union of the modules you want and those that I want? Or should we let anybody else in this game too. > I understand that there can be different distros customized to certain > problem domains, but as explained I see XML as common to all those > problem domains. Currently you use XML all over the place. I can believe that. But for your argument to make sense you'd need to show that: * XML is widespread. * XML will continue to be widespread for the life of Perl 6. * Whatever XML module we design now will be the best XML module for people to use throughout the desing of Perl 6, without a better one coming along. Perl 5 has lots of modules in its core. Some of them, with hindsight, might not be the best possible choices: * Text::Soundex -- how much is that used? * CGI -- is that really the best CGI-parsing or HTML-generating module still? (That so many others have been written suggests not.) So, to make a claim for any 'domain-specific' functionality to be added 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? 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? If you didn't predict that, how does it fit in with your claim that you "can only see more XML for all of us"? 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: documentation standards (was "[svn:perl6-synopsis] r14421 - doc/trunk/design/syn")
David Green writes: > Well, clutter like "Blah: none" seems to me to be more the fault of > the doc-formatter for not hiding lines like that. It's more the repetition in the lines you snipped that I really object to: given the function's name, the name(s) of its parameter(s), and the short description of what it does, it's obvious what the parameter(s) are for and what it returns; repeating that information doesn't help anybody. (It may help computers, though.) Smylers
Re: Web Module (Was: Perl6 new features)
Darren Duncan writes: > At 11:23 PM +0100 6/21/07, Smylers wrote: > > > Has Larry yet decreed whether Web will be bundled with Perl 6? > > I believe that what Larry has said is that there are no official core > modules, ... So ... not something to worry about now. Thanks for that, Darren. Smylers
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: 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: 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: 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
Damian Conway writes: > Here's the first draft (documented in Pod 6, of course ;-). > > =head3 Ambient aliases > > The C> formatting code specifies an B 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: 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: [svn:perl6-synopsis] r14421 - doc/trunk/design/syn
Chaddaï Fouché writes: > I'm quite surprised by this debate... To me it seems a clear rule that > state that "if a line begin with "=" then it starts a POD section" is > way easier to understand than "a line beginning by = will start a POD > section except if it is in a Perl statement, or in a :to section, or > in a string literal, etc...". It is. But that isn't the argument being made against it. The point is that even knowing that simple rule is more complicated than not having to know any rule at all. Even knowing that there _is_ a rule requires knowing that Pod exists, which shouldn't be a prerequisite for starting your first Perl program; you can't learn everything at once, in parallel. > The "Learning Perl 6" argument seems equally contrived to me since > anyway you don't need POD to understand programming in Perl Or rather, you didn't need that with Perl 5. > and I never actually learned POD until I wanted to do a real module > and document my little console utilities in Perl. Sure. But the 'Learning Perl' argument is this one, which you mentioned later in your message > The other "problem" is that if somehow a braindead guy (where would he > get the idea from, I never saw such a style) put his "=" in first > column expecting a assignment he won't get it... Seriously ? Yes. Personally I think that, on balance, the simplicity of the "what is Pod?" rule is more of a gain than this awkwardness is a loss. But it is a completely valid argument. Remember that also until Larry's recent proposal, this affected string constants too -- and somebody might have anything in a multi-line string. > Are you really allowing for such weirdness in introductory material to > a Language course ? The problem is that when teaching programming (I also used to be a Perl 5 trainer) you have to one part of the course first. And whatever that is, it really should be usable without relying on material that hasn't yet been covered. This means that when teaching the very basics of Perl a trainer has to do one of: * State the exception that C<=> is special in the first column of the source file -- thereby increasing the complexity of what users need to grasp in one 'chunk' when first covering variables, and distracting them from the core issue and sparking their curiosity with mention of this documentation language. * Not mention it, and hope that nobody formats a line in a way which will be interpreted as Pod -- thereby causing much frustration in the rare cases where this does happen, making the learner in question irritated (with either the trainer for not mentioning it, or the language for having this exception). Neither of those are ideal. > You don't need to understand POD to read a program where POD is used : > it's usually quite clear from the content where it is POD and where it > is doc and each section that don't look like Perl is usually POD. Yes. But not if you've created unintentional Pod. Smylers [Apologies for the lag in this. I wrote 95% of the above 2 days ago -- before brian's similar message -- then got distracted and have only just completed it. But I thought it worth mailing anyway, to point that even though I've argued on the opposite side from brian on this, I completely acknowledge he has a valid point.]
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 I an instance of an > L. 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: = 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: 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: [svn:perl6-synopsis] r14421 - doc/trunk/design/syn
Mark Overmeer writes: > * Jonathan Scott Duff ([EMAIL PROTECTED]) [070616 20:15]: > > > You mention OOP. For Perl 5 we have a standard, if very general, > > syntax and "open" semantics that have allowed people to implement > > OOP in a variety of ways. This was all well and good for a while > > until we realized that there should be some more reasonable defaults > > (in both syntax and semantics) for common operations in OOP. > > OOP in Perl5 has a mechanism, but not a standard in the use of those > features. Full OO languages all choose a direction, but there are > serious culture differences. Perl uses them all. There are many ways > how to instantiate an object, which is lot of fun as programmer but a > hassle for "the average" programmer. Within one program, you may very > well need to use different instantiation techniques... Of course, > this could have been forseen (perl is not the first language which > implements OO), and some advice on the convention to use could have > avoided wild collection of approaches we see now. But if this had been "forseen" and restrictions put in place, then we wouldn't have had the recent advances in things like inside-out objects and MOP. The flexibility and people doing different things allowed for experimentation, and where those experiments were successful new ideas gained community mindshare very quickly. > This is also why "Perl Best Practices" is a good book [shameless plug] Indeed. But it doesn't need to be part of the Perl core. > although I would have welcomed it 11 years earlier. But it extols many practices which weren't thought of 11 years previously! Hence the need for flexibility, so as to allow time to invent them ... > > I think it's the same thing with POD6. It's "open" enough that many > > documentation systems can be built from it (man pages, books, > > magazines, wikis, etc.) For some of those documentation systems > > we'll have nice conventions and other conventions will grow as > > needed. If we find that convention isn't enough in specific areas, > > ... > > Without any doubt, there are thousands of documentation systems > around. At least ten percent of them are considered "the best ever > made" by its developer or developer community. Just by simple math, > the chance that the system developed really is the best is less than > one percent. Quite so -- which is why in my previous mail I thought it was shortsighted to think we can create something now which we won't later want to change. > IMO, any argument that POD6 is good because it can be used to write > books or express complex mathematical expressions is really frightning > me. POD (as in the version with Perl 5) wasnt designed for writing books or whatever, yet people liked it enough they took it in directions that nobody first expected. There's a good chance of that happening with Pod 6, even if it isn't an aim. > Every single complication added to the doc syntax will make it not to > understand for a large percentage of the primar target community, as > every teacher can tell you from experience. You could say the same thing about Perl 6 (or even earlier versions), yet we cope, partly by ensuring that you don't need to learn all of it in order to be able to use it. (In the case of Pod one of the things that helps is its large overlap with plain text.) > When I create a program, it starts with a goal. To reach that goal, I > have to write some code, some docs, some tests. For me, it is all > part of the program. I do not see one to be of more importance than > the other: all three are first-class sitizens in my program. Testing is another area which has had immense progress since the release of Perl 5. Look at where Test::More, Test::Class, TAP::Parser and so on are now; we certainly wouldn't want to be restricted to a standard of best practices in testing from the early 1990s. 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 C. 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: Quirky comments
Jonathan Lang writes: > The only other thing that I'll continue to lobby for is that the line > starting with a block comment's termination tag should _not_ be > considered part of the comment, save for the termination tag itself. > Programmers are likely to be surprised when text that follows a > closing bracket is treated as being included within it. They would be, if they spotted that it's a closing bracket. The trouble with the current specification is that it draws attention to this 'exception'! Whereas in practice I suspect most people will find it natural, because in the process of 'commenting out' a large block of code they won't even spot that they've got a mixture of single-line and block comments. Certainly on first reading Larry's recent changes in this area my initial thoughts were: * Oh, he's removed the exception from matched-bracket comments which will allow for commenting-out lots of lines by putting hashes at the beginning of them. That'll surprise people when they try to do that and it doesn't work. I should object! * Hmmm, now there's this third type of comment as well. What on earth is that for? Until it twigged. If I hadn't read the spec then everything would just have worked naturally! Smylers
Re: = at Start of Line ([svn:perl6-synopsis] r14421 - doc/trunk/design/syn)
Mark Overmeer writes: > * Smylers ([EMAIL PROTECTED]) [070616 08:44]: > > > With these new Pod rules it's possible to entirely remove Pod from a > > file without knowing _anything_ about the host language. 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. > > And then the main point: if you write documentation which is not > related to Perl6 coding itself, do we really need to create just > another text processor? There are already so many sofisticated > text processors available! Sure, but some people like Pod. Lots of things other than Perl 5 have been documented with POD, so lets continue to make this kind of thing easier. > And why do you want easy to remove docs? I didn't mean remove them for human (non-)consumption, but filtering them out from, say, a shell script so that what remains is a syntactically valid script which can be run in the shell. > Other languages already have their own documentation system. Why do > you expect them to use POD6? Most people won't. But that's no reason to make it hard. 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: > * 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: = 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] 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 C existed, many programmers would surely continue to use C 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
Larry Wall writes: > On Mon, Mar 12, 2007 at 10:20:12PM +0000, Smylers wrote: > > : [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? > > Doesn't matter, Excellent; that's what I was hoping. > ... just thought it was a clearer example this way. Oh, it is! But using pushy feeds for all of the lines makes it easier to change the order of the lines (similar to putting a trailing comma after the final list item in a one-item-per-line list), and I was just checking that it's permitted. 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 +0000, 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 C lines. > Those who believe the stagnation of Perl 5 is caused by Perl 6 should > go back and reread the 361 RFCs ... 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
Andreas J. Koenig writes:
> $spot::(parens)
>
> >>>>> On Wed, 7 Mar 2007 20:38:17 -0800 (PST), [EMAIL PROTECTED] said:
>
> > +class Dog:ver<1.2.1>:auth;
> > +class Dog:ver<1.2.1>:auth<http://www.some.com/~jrandom>;
> > +class Dog:ver<1.2.1>:auth<mailto:[EMAIL PROTECTED]>;
> > +class Dog:<1.2.1 cpan:JRANDOM>
>
> > +class Pooch:name:ver<1.2.1>:auth
> > +class Pooch:
>
> 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:ver<1.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: [svn:perl6-synopsis] r14317 - doc/trunk/design/syn
[EMAIL PROTECTED] writes: > Saying C<1.2.1> specifies an I 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: 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. > 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
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: 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 C test is not to guard the loop but to attach an
C clause to (hence the above mention of C), 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 C
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 C to attach to the C but only be activated if none of
the. Larry's suggestion of using C for this looks good.
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: 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 C 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 C, 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 C function, for joining strings. 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: 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: [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) C should become syntactical sugar > for C Why? What does hiding the fact that is a lexical variable declared with C 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 C 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 C 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: > 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
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
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
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 C 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
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 C, the special functions C, > +C, C, and C 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 C 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 C 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: beg for Bag
TSa writes: > I want to propose the addition of a Bag type Different from the C that's already mentioned in Synopsis 3? 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: 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 C and C 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: 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 C 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 C
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: 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: 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: 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: "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 C, > 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 C would permit code using the module to run with C. > (For example, a package that had string constants defined as > subroutines like C would behave > differently than one that assumed barewords would work, but both might > use identical examples of C in their perldocs.) Gotcha. So a user of the latter module could put the error codes in quotes to keep with C, 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 C. > > > 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 C 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 C 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: 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 C> 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 E and E. I think the only standard XML entities are C<<>, C<>>, and C<&>. 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: 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 C or C 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 C consistency would say
they should be for C as well -- effectively just another way of
spelling C, but one that doesn't stand out so much.
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: "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 B&D 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 C 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 C 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"
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: 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 C 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 C is a substantial improvement over the C statement in most languages. Whereas C 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 C 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 C is a reasonably common sub or method name in Perl 5 code found in the wild -- much more so than C or C -- 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 C to C (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"
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 C then when a reader encounters code using C 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 C would continue to use that name in Perl 6, regardless of what the docs say. I do not think renaming C to C is a terrible idea, but if it's being done then it should be done properly, not half-heartedly with an alias. 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
David Green writes: > I guess my problem is that [1,2] *feels* like it should === [1,2]. > You can explain that there's this mutable object stuff going on, and I > can follow that (sort of...), but it seems like an implementation > detail leaking out. The currently defined behaviour seems intuitive to me, from a starting point of Perl 5. The difference between: my $new = [EMAIL PROTECTED]; and: my $new = [EMAIL PROTECTED]; is that the second one is a copy; square brackets always create a new anonymous array rather than merely refering to an existing one, and that's the same thing that's happening here. Think of square brackets as meaning something like Array->new and each one is obviously distinct. > And I feel this way because [1,2] looks like it should be platonically > unique. I'd say that C< (1, 2) > looks like that. But C< [1, 2] > looks like it's its own thing that won't be equal to another one. 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
