quotemeta
I vote for axing Cquotemeta in favor of Cq:meta// and Cq:m//. -- Rod Adams
New S29 draft up
I just posted a fresh copy of S29 to: http://www.rodadams.net/Perl/S29.pod http://www.rodadams.net/Perl/S29.html New: All defined functions have been restructured into packages. Perl6::Arrays, Perl6::Lists, and Perl6::Hashes are (mostly) written. Some Math::Basic and Math::Trig functions added. :'s have been added into signatures where they belong. various other clean ups. Comments welcome. -- Rod Adams
Re: [Pugs] short-circuit operators
On Tue, Mar 15, 2005 at 11:04:31PM -0800, Larry Wall wrote: On Wed, Mar 16, 2005 at 01:30:10PM +0800, Autrijus Tang wrote: : I wonder if there is a way to expose this trait to the user, : though... A quick grep did not find anything. Anyone got ideas? For the most part we'll delay evaluation with explicit curlies. In general I don't think we should be encouraging people to write a lot of delayed evaluation macros that aren't explicitly marked as thunks with curlies. In fact, we're going the other direction with grep and map's first argument, and not allowing the bare form of thunk that Perl 5 allows. Every time you allow bare thunks, you disallow passing a reference to a thunk instead. Okay, so strictness hinters like is delayed is okay as a parameter trait, but with a warning that they should not be carelessly used? Also, how does that philosophy fit with the bare thunking in array slices, as listed in A05? @3d_slice = @array[ !($_ % 2) ; 0..9:3; ?test($_) ]; Thanks, /Autrijus/ pgpHKGiLj6thr.pgp Description: PGP signature
Re: quotemeta
On Wed 16 Mar, Rod Adams wrote: I vote for axing Cquotemeta in favor of Cq:meta// and Cq:m//. Given A05 states that bare scalars match literally, quotemeta is (almost?) obsolete. It can certainly be downgraded. Richard -- Personal [EMAIL PROTECTED]http://www.waveney.org Telecoms [EMAIL PROTECTED] http://www.WaveneyConsulting.com Web services [EMAIL PROTECTED]http://www.wavwebs.com Independent Telecomms Specialist, ATM expert, Web Analyst Services
Different ways for MinGW
In his Wiki
(http://wiki.kn.vutbr.cz/mj/index.cgi?Build%20Parrot%20with%20MinGW),
Michal Juroz lists 3 ways for building Parrot :
1) Build Parrot with MinGW, MSYS and MSYS-DTK
2) Build Parrot with MinGW and ActiveState Perl
3) Build Parrot with MinGW-Perl (Build Perl with MinGW first)
There is a fondamental difference between the first and the two others.
MinGW is only the GNU toolsets (gcc, gdb, make) for MSWin32,
but MSYS is an emulation box with shell and standard Unix command.
MSYS-DTK contains a Perl 5.6.1 distribution that gives
$ perl -e print $^O
msys
MSYS is like cygwin, but lightweight.
Someone wants work on MSYS, and someone wants work without MSYS.
With only MinGW, the way 3 is the safest and easier but longest (need build
Perl).
The built Perl allows to grab correct configuration.
The way 2 is the best for the future because ActiveState Perl is the most
popular distribution on MSWin32.
But today, this way is hazardous, because the configuration is complicated
(a lot of option) and incomplete.
See Márton Papp thread.
Most of options grabed in ActiveState Perl are wrong, so there must be
patched by config/init/hints/mswin32.pl
But after comparing lib/Parrot/Config.pm (or config_lib.pasm) produced by
these 2 ways, I could propose a patch of mswin32.pl
With it, the way 2 configuration is only :
perl Configure.pl --cc=gcc --ICU_stuff
I obtain the same result with way 2 and 3 :
building OK, except dynclasses, and install is incomplete ( .exe, .dll are
not copied).
Failed TestStat Wstat Total Fail Failed List of Failed
---
t/dynclass/pybuiltin.t5 1280 65 83.33% 1-2 4-6
t/dynclass/pyclass.t 6 1536 66 100.00% 1-6
t/dynclass/pycomplex.t1 256 11 100.00% 1
t/dynclass/pyfunc.t 4 1024 44 100.00% 1-4
t/dynclass/pyint.t 25 640025 25 100.00% 1-25
t/pmc/nci.t 55 1408056 55 98.21% 1-55
t/pmc/sys.t 1 256 11 100.00% 1
5 tests and 69 subtests skipped.
Failed 7/135 test scripts, 94.81% okay. 97/2204 subtests failed, 95.60% okay.
For the way 1, I am disagree with the Michal's proposition of merging
mswin32.pl and cygwin.pl.
The factorization of this kind of code is not a good idea at this early
stage of development.
A contrario, I propose the creation of a new file msys.pl that handles the
way 1 (MSYS is a platform like cygwin).
I creat a first version of this file.
With it, the configuration is only :
perl Configure.pl --ICU_stuff
I obtain : building OK, except dynclasses, and install is incomplete (
.exe, .dll are not copied).
Failed TestStatus Wstat Total Fail Failed List of Failed
imcc/t/imcpasm/opt1.t 1 256491 2.04% 48
imcc/t/syn/file.t 1 256121 8.33% 11
t/dynclass/pybuiltin.t 5 1280 65 83.33% 1-2, 4-6
t/dynclass/pyclass.t 6 1536 66 100.00% 1-6
t/dynclass/pycomplex.t 1 256 11 100.00% 1
t/dynclass/pyfunc.t4 1024 44 100.00% 1-4
t/dynclass/pyint.t25 640025 25 100.00% 1-25
t/pmc/nci.t 55 1408056 55 98.21% 1-55
t/pmc/object-meths.t 271 3.70% 19
t/pmc/objects.t 592 3.39% 53, 57
t/pmc/sys.t1 256 11 100.00% 1
5 tests and 68 subtests skipped.
Failed 11/135 test scripts, 91.85% okay. 102/2204 subtests failed, 95.37% okay.
Francois Perrad.
--- mswin32.pl.oirg 2005-02-21 11:56:08.0 +0100
+++ mswin32.pl 2005-03-15 23:46:16.0 +0100
@@ -1,3 +1,6 @@
+# Copyright: 2005 The Perl Foundation. All Rights Reserved.
+# $Id: mswin32.pl $
+
{
my %args;
@[EMAIL PROTECTED]@_;
@@ -139,12 +142,33 @@
);
}
elsif( $is_mingw ) {
- $libs='' if $libs =~ /\.lib\s/i;
- Configure::Data-set(
- link = 'gcc',
- libs = $libs,
- slash = '/',
- ar= 'ar',
- );
+ my $make=Configure::Data-get(qw(make));
+ if ($make =~ /nmake/i) {
+ # ActiveState Perl
+ Configure::Data-set(
+ 'a' = '.a',
+ 'ar' = 'ar',
+ 'cc' = 'gcc',
+ 'ccflags' = '-s -O2 -DWIN32 ',
+ 'cp' = 'copy',
+ 'ld' = 'g++',
+ 'ld_load_flags' = '-mdll -s ',
+ 'ld_share_flags' = '-mdll -s ',
+ 'ldflags' = '-s ',
+ 'libs' = '-lmsvcrt -lmoldname
Re: Module popularity
Let's not stir the mud. Then Robert better suggested cpanratings. On Wed, Mar 16, 2005 at 01:41:06AM +1100, Robert wrote: cpanratings.perl.org? Which seems fit for the CPAN FAQ. Ok, thanks. One of these months we will get around to updating the CPAN FAQ a bit. -- Jarkko Hietaniemi [EMAIL PROTECTED] http://www.iki.fi/jhi/ There is this special biologist word we use for 'stable'. It is 'dead'. -- Jack Cohen
Re: int(0x123) == int(0x123) ?
Larry Wall wrote: And we might even allow exponents on 0x et al., though what radix the exponent is assumed to be is an interesting question, though. Well, the perl6-documentation guys tried to hash this out, but were hampered by a lack of both bits that effected the bits that we were trying to work on, and a clear wish by the powers that be (that'd by you, Larry) to take what we worked out, and bless the good bits, and fix the bad bits. If you're interested, check p6-documentation for the last post of the form numeric literals, take \d+. I've got to get to bed, though. Goodnight, -=- James Mastros, theorbtwo
Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)
For things like MMD --- I'd like to traverse the hypertext 'linkbacks' to any given method. Which method *exactly* will get called in the super class? A hypertext documentation system that introspects on classes could help here. Wouldn't it also be good to link back to the modules that use the current module in its operating environment? I am not sure if Perl6 is capable of that level of introspection without actually parsing the code itself, or running it (like a profiler). I also question if that much depth is always nessecary. Sure in some cases it is, but I would argue that in those cases you should be reading the code anyway. PPI is slowly getting towards the point where this can be done. I have a VERY early prototype documentation generator with a class tree on the left, and a tabbed right panel that switches between normal POD and auto-generated structural documentation views. Given that I'm relatively confident some sort of equivalent document parser will be doable using a different parsing mode of the Perl 6 parser (I had a conversation with Damian at YAPC.AU last year about this), I'm fairly sure this can be done. Adam K
Re: s/true/better name/
Isn't saying false doesn't exist like saying, dark doesn't exist? Why have a word for that? I'm really afraid I'm missing something obvious here, but I'm worried that neither whether nor indeed work very well in many contexts. It seems to me that testing trueness exists in so many contexts that it's going to be hard to find an English word that fits all the important ones. Additionally I question whether this is truly a case improving to the point of least surprise? After all, I don't know a programmer who's going to be surprised by what true means. There are still *some* things you may have to learn in software dev 101 ;) Marcus
Testing .pl executables
I'm new to unit testing in Perl, so this may be a stupid question. Using Test::More to test .pm perl modules is quite simple as you just use the module in your test executable and call the module's subroutines inside your tests. However, I was wondering if there is a standard, safe way of testing simple .pl scripts? I can just use or eval the file at the top of the test script and call the subroutines, but this isn't safe if the .pl file actually executes when called with no parameters. There is a module Sub::Import that can import the subroutines in the .pl file without executing the code, but this doesn't import the modules the .pl file uses, so it only works for scripts that are completely self contained and don't use external modules. Is there a clean workaround for this, or is it general practice to put all code into modules? Thanks for any help.
Re: test logging
Is there a place for Test.pm from perl5 in the perl6 world? That's the one I want to use. -kolibrie
wrap, call and goto sub
Just a quick question. In Pugs t/op/arith.t we have:
sub tryeq_sloppy ($lhs, $rhs, ?$todo1 = '') {
...
ok($lhs==$rhs,$ todo);
...
}
But it breaks the $?CALLER based error reporting, because
it introduces another layer of caller.
In Perl5, I'd do this:
{ local @_ = ($lhs == $rhs, $todo); goto ok; }
Does that form still work with Perl 6? Or should I use this?
{ local _ := ok; call($lhs == $rhs, $todo); }
However, I did not see A/E/S06 specifying that call() will assume the
goto semantic of erasing itself from the caller chain, so I hesitate
to implement it that way.
Is using wrap/call the correct choice here, or is there another way
to do it that I missed?
Thanks,
/Autrijus/
pgpQJWCfm30YZ.pgp
Description: PGP signature
Re: wrap, call and goto sub
On Wed, Mar 16, 2005 at 08:46:03PM +0800, Autrijus Tang wrote:
Does that form still work with Perl 6? Or should I use this?
{ local _ := ok; call($lhs == $rhs, $todo); }
s/local/my/ of course. :-)
Thanks,
/Autrijus/
pgpeQ1rscre2e.pgp
Description: PGP signature
Re: Testing .pl executables
--- Anuradha Dissanayake [EMAIL PROTECTED] wrote: I'm new to unit testing in Perl, so this may be a stupid question. Using Test::More to test .pm perl modules is quite simple as you just use the module in your test executable and call the module's subroutines inside your tests. However, I was wondering if there is a standard, safe way of testing simple .pl scripts? Hmmm. The identical question was asked a bit over a week ago: http://www.nntp.perl.org/group/perl.qa/3722 I suggest you start by browsing the answers given there. /-\ Find local movie times and trailers on Yahoo! Movies. http://au.movies.yahoo.com
Re: test logging
On Mar 15, 2005, at 1:23 PM, Nathan Gray wrote: Is there a place for Test.pm from perl5 in the perl6 world? That's the one I want to use. You are certainly free to write it, and I think it would be a great exercise in multi-subs to do so. However the name Test.pm has already been taken. But I would encourage you to look more closely at both perl5 Test::More and the perl6 Test.pm as I really and truely feel they are superior to perl5 Test.pm. But then again, this is perl, so there is certainly more than one way to do it, and you are free to do so. As for contributing to the Pugs tests, I personally would prefer though that you stick with the perl6 Test.pm model as we already have over 1500 tests which use it. But in the end, this is Autrijus's descision and not mine. - Stevan
[PUGS] stdin bug
When pugs is invoked as Cpugs - so that it reads the program from
standard in, I think it should re-open stdin before the code is
executed.
In perl 5:
--
[EMAIL PROTECTED]:~/pugs$ perl -
while (STDIN) {
print $_;
}
(Ctrl+d)
I type and it repeats
I type and it repeats
In pugs:
--
[EMAIL PROTECTED]:~/pugs$ ./pugs -
for =$*IN - $line {
print $line;
}
(Ctrl+d)
Fail: stdin: hGetContents: illegal operation (handle is closed)
However, it does work if I put it in a file and run it the normal way.
Tom
[perl #34452] [TODO] Add return signature to Parrot_call_sub that returns multiple values
# New Ticket Created by Matt Diephouse # Please include the string: [perl #34452] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=34452 This TODO item is from an email from Leo, reproduced below with some context. Message-ID: [EMAIL PROTECTED] Original Message William Coleda [EMAIL PROTECTED] wrote: Given the perldoc for src/extend.c, void* Parrot_call_sub(Parrot_INTERP interpreter, Parrot_PMC sub, const char *signature, ...) Call a parrot subroutine the given function signature. The first char in signature denotes the return value. Next chars are argu- ments. The return value of this function can be void or a pointer type. If only the first character is the return value, how does one deal with subroutines that return multiple values? Well, you can't access multiple return values from within the C function, where you are calling the PIR code. OTOH, if the PIR code did return more values, we should get them back to the caller. We should probably have a new return signature for this, e.g. @ - collect all return values, stuff them into an array and return that. OTOH you could use Parrot_runops_fromc() and pick up return values from the returned frame pointer Cbp. leo
Q: index(Hello, , 999)
What should index(Hello, , 999) return in perl6? In perl5 that returns 5, but IMHO -1 would be right result. -- Markus Laire Jam. 1:5-6
Re: Q: index(Hello, , 999)
On Wed, 2005-03-16 at 10:31, Markus Laire wrote: What should index(Hello, , 999) return in perl6? In perl5 that returns 5, but IMHO -1 would be right result. Urk... exception? Seriously, if you give index a position that is off the end of the string, your options should be: a. Extend the string b. Fail silently c. Throw an exception a. is kind of non-Perlish. b. is Perl 5ish, but I'm not convinced it's the right solution in all cases. In this case, specifically, I think it should be c. (perhaps with some use nonfatal that causes library functions to fail more gracefully). That said, the current Perl 5 behavior is very broken. You should never return POS unless it's a negative number flagging failure. -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On Tue, 2005-03-15 at 13:48, Brian Ingerson wrote:
Aaron,
Upon reading this, it is unclear to me whether you have read about the
Kwid format or you are simply guessing that Kwid is the same syntax
used by Kwiki.
I read the Kwid documentation from the Pugs distribution in depth.
To create Kwid I carefully studied the POD information model
(the semantic tree that POD parses to). Kwid uses the exact same
info model. This means that switching between the two without
loss of information is possible.
I noted that in my original message.
This makes the Kwid experiment much less risky
Risk was not my concern. My concern was a Wiki-like model which is
inconsistent with many of the goals of POD. POD is intended to be PLAIN
OLD documentation. Kwid breaks this model of simplicity by introducing
unique boundary characters for many types of operations, and by making
the overall presentation more complex.
While I appreciate several features of Kwid, I feel that it should not
replace POD without first adopting a POD-like simplicity.
Some people have argued that Kwid is only a syntactic change to
Pod. I would argue that they are correct.
They are demonstrably wrong. You cannot Parse Kwid correctly by changing
the syntax of a POD parser.
For example, the behavior of
* foo
bar
Is totally dependent on what context it is enclosed in (.list or
top-level). This cannot be emulated with simple syntactic changes to a
POD parser.
Interestingly, this is one of the main benefits of Kwid, IMHO.
Re-read what I wrote and think about it. I think you'll find that it
avoids some of the major pitfalls of old-POD and incorporates all of the
useful features of Kwid while maintaining a simplicity that is as
elegant as POD's.
POD 1:1 mappings:
POD My Kwid Proposal
x... x[...] or x{...} (where x is C, B, I, X, L, etc)
=item * *
=item foo *= foo
=item n *1
=for someformat =for someformat
=over n =begin list
The one obvious thing to POD users is the replacement of with [] or
{}. Why is this? Because and are used in un-balanced ways in a large
number of situations, so they should not be the primary bracketing
constructs. Also because the visual cue to many users of POD is that
it's SGML-like, and that way lies danger, since POD's -bracketed
constructs are not intended to be balanced.
Also, there should be a =begin block which in HTML would be
blockquote, and in POD would be =over n.
Kwid 1:1 mappings:
KwidMy Kwid Proposal
* *
.list =begin list ... =end list
.someformat =begin someformat ... =end someformat
.comment=begin comment ... =end comment
[generic] [generic]
Extensions I proposed:
=begin x,y,zSection used only in the given formats
=begin !x,y,z Section NOT used in the given formats
As you can see, what I proposed IS a simple syntactic transformation of
Kwid.
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: [Pugs] short-circuit operators
On Wed, Mar 16, 2005 at 05:33:04PM +0800, Autrijus Tang wrote:
: Also, how does that philosophy fit with the bare thunking in array
: slices, as listed in A05?
:
: @3d_slice = @array[ !($_ % 2) ; 0..9:3; ?test($_) ];
If I recall, the discussions around S9 indicated that it might be a bad
idea to enable that by default, so maybe we could enable such behavior
by marking the array or otherwise declaring a pragma to enable it. The
concern was that it would foil the optimizer if it could not
assume that the subscripts of @array[$x;$y;$z] are integral, and
if the parameters could contain thunks, it can't assume that.
Since it's not a problem for syntax that can be recognized at compile
time, your slice above might be allowed if you declare the thunks
with curlies:
@3d_slice = @array[ {!($_ % 2)}; 0..9:3; {?test($_)} ];
We could conceivably allow explicit boolean operators to be interpreted
as thunks, but arguably, if someone passes a boolean as a subscript,
they might actually be wanting to subscript on 0 or 1. And whether
a particular operator returns boolean is kind of a fuzzy set.
So let's stick with the explicit closure rule for now. Another of
those things we can relax later, if we see a way to do it cleanly.
Or there's always the pragma approach to enable the pessimization.
Larry
Re: [Pugs] Some experiments with the for loop
On Wed, Mar 16, 2005 at 06:52:31PM +1100, Andrew Savige wrote:
: # length() and bytes() seem not implemented yet (?) ...
And length will never be implemented because that word is now taboo,
because it is not specific enough as to units in a Unicode world.
More specific methods are now used:
.bytes length in bytes
.codes length in codepoints
.graphs length in graphemes (language independent)
.chars length in letters under current pragmatic linguistic context
and for arrays
.elems length in elements
as well as
.bytes length of concatenated elements in bytes
.codes length of concatenated elements in codepoints
.graphs length of concatenated elements in graphemes
.chars length of concatenated elements in letters
Other types may also define those where appropriate. And there could be
other related methods, such as .memoryfootprint, or whatever we decide
to call that.
: Now since for =$fh {...} works with Pugs yet for *$fh {...} does
: not work, which needs updating: Pugs or S02 or both ... or have I
: misunderstood? :-)
S02 needs updating. =$fh was a rather recent invention.
Larry
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On Wed, Mar 16, 2005 at 12:00:28PM -0500, Aaron Sherman wrote:
The one obvious thing to POD users is the replacement of with [] or
{}. Why is this? Because and are used in un-balanced ways in a large
number of situations, so they should not be the primary bracketing
constructs.
Actually, I quite like as the bracketing characters. They are
visually distinctive, they connect well with their adjacent C/X/L/etc
without visually merging into it (compare Lfoo with L[foo]), and in
the circumstance that you want to bracket an unbalanced bracket, you
just double (triple, whatever) up and add some space:
C $x $y
Looks pretty clear to me.
--Dks
Re: Q: index(Hello, , 999)
On Wed, Mar 16, 2005 at 05:31:17PM +0200, Markus Laire wrote: : What should index(Hello, , 999) return in perl6? : : In perl5 that returns 5, but IMHO -1 would be right result. Well, neither of those is the right result, since index is probably not going to be returning integers in Perl 6, but string positions which might have different integer values depending on whether you look at them as bytes, codepoints, graphemes, etc. And the string position value will be true for valid string positions and false/undef otherwise. When you call index, it's going to assume that 999 is to be converted to a string position under the current Unicode pragma, which turns out to be undefined on the string in question, so your call above probably either warns or throws an exception because you tried to use an undefined value to do something defined. Larry
Re: pop, push, reverse, sort, and splice on a multidimensional array
On Tue, Mar 15, 2005 at 02:22:13AM -0600, Rod Adams wrote: : : my int @a is shape(Int ; Int) = (1..10 ; 2..100 :by(2) ; 4); : : $x = pop @a : push @a, $x; : @b = sort @a; : # etc : : I see two views to take with these cases. : : 1) flatten the array to one dimension, and act accordingly. : : or : : 2) assume : : my int @a is shape(Int ; Int); : my @a is Array of Array of int; : : Mean exactly the same thing, as do : : @a[3;4] : @a[3][4] : : And then operate the Perl 5 way, where Cpop @a would return an array ref. : : : #2 seems like the way to go, but I'm open to other suggestions. Seems right to me too. Could always reshape the array to one dimension to get the other behavior, and since the array is reshaped, it wouldn't end up lopsided. : I'm especially interested in hearing people's view on how Csplice : should work with multi-dim arrays. I suppose that would depend on the dimensionality of the subscript. :-) Larry
Re: zip
On Tue, Mar 15, 2005 at 02:47:33AM -0600, Rod Adams wrote:
: I'm trying to define zip(), but can't come up with a signature for a
: function that returns a lazy list of lvalues, but the list itself is not
: lazy?
If we go with my once-upon-a-time notion of using zip(@a;@b), then it
naturally comes in as [EMAIL PROTECTED],[EMAIL PROTECTED]
: As a second matter, can you declare a type for the elements of a slurpy
: array?
Yes, and it distributes as any array return type declaration would.
: So far I have:
:
: multi sub zip (Array [EMAIL PROTECTED]) returns List {
: gather {
: while any(@lists) {
any() is not guaranteed to produce left-to-right order.
: for @lists - @list {
: take shift @list;
: }
: }
: }
: }
:
: But I can't tackle the lvalue problem.
Why do they need to be lvalues? I always thought of zip as non-destructive.
Has zip historically been destructive in other languages?
: btw, I'm defining the semantics of some of several functions by simply
: supplying a reference implementation.
That's cool.
Larry
Re: Referencing a caller's slurpy array.
On Tue, Mar 15, 2005 at 01:54:09AM -0600, Rod Adams wrote: : A06 says: : : If you |shift| or |pop| without an argument, it shifts or pops whatever : slurpy array is in scope. : : : Shall we assume that @_ is always an alias for this array, so I can say : something like: : : multi sub pop (Array [EMAIL PROTECTED] = @caller::_) returns Scalar : : ? Well, the alternative would be to have an explicit compiler variable like @?SLURPY, but maybe using @_ for that is more parsimonious. : btw, is ?@ legal in a signature? It's not specifically mentioned in : A/S04, but it makes sense it would be allowed along with ?%. Certainly. The zone markers are as orthogonal to sigils as we can make 'em. Though I'm not sure we've given a meaning to *foo yet. I suppose that would have to mean that the next slurpy parameter has to be a sub ref. Larry
Re: Q: index(Hello, , 999)
Markus Laire wrote:
What should index(Hello, , 999) return in perl6?
Since the first thing that needs definition is how does
the empty string match, it could be e.g. any(0..Hello.elems).
As described in A12 string positions are much more these days
than simple ints. There is a class StrPosition or Pos[Str]
or Pos of Str or some such. So one signature could be:
multi sub index( Str $searched,
Str $substr,
Pos[Str] ?$pos where { 0 = $_ $searched.elems }
)
returns Undef[Pos[Str]]
^ Pos[Str] where { 0 = $_ $searched.elems }
{
...
}
In perl5 that returns 5, but IMHO -1 would be right result.
This is because of the usage of . Otherwise it's -1.
Regards,
--
TSa (Thomas Sandlaß)
Re: Q: index(Hello, , 999)
On Wed, Mar 16, 2005 at 06:44:47PM +0100, Thomas Sandlaß wrote:
: Markus Laire wrote:
: What should index(Hello, , 999) return in perl6?
:
: Since the first thing that needs definition is how does
: the empty string match, it could be e.g. any(0..Hello.elems).
If the position of the first attempt is specified, the null string
should match right there. It's an infinite loop if they don't add 1
next time (implying our position type needs to be able to add and
subtract in whatever the current units are).
One nit, .elems is not defined on strings. .chars works under whatever
the current Unicode regime is (default graphemes).
: As described in A12 string positions are much more these days
: than simple ints. There is a class StrPosition or Pos[Str]
: or Pos of Str or some such. So one signature could be:
:
: multi sub index( Str $searched,
: Str $substr,
: Pos[Str] ?$pos where { 0 = $_ $searched.elems }
:)
: returns Undef[Pos[Str]]
: ^ Pos[Str] where { 0 = $_ $searched.elems }
: {
: ...
: }
:
:
:
: In perl5 that returns 5, but IMHO -1 would be right result.
:
: This is because of the usage of . Otherwise it's -1.
Well, that, and Perl 5 is being kind in rounding 999 down to 5 on
the assumption that the programmer was specifically using 999 to mean
end of string. It's kind of stupid to assume that for index, but
rindex is another matter.
Larry
Re: wrap, call and goto sub
On Wed, Mar 16, 2005 at 08:46:03PM +0800, Autrijus Tang wrote:
: Just a quick question. In Pugs t/op/arith.t we have:
:
: sub tryeq_sloppy ($lhs, $rhs, ?$todo1 = '') {
: ...
: ok($lhs==$rhs,$ todo);
: ...
: }
:
: But it breaks the $?CALLER based error reporting, because
: it introduces another layer of caller.
:
: In Perl5, I'd do this:
:
: { local @_ = ($lhs == $rhs, $todo); goto ok; }
:
: Does that form still work with Perl 6?
We will have some equivalent way to do an explicit substituting
tail call, but perhaps not with that syntax, since passing @_ through
is kind of bogus these days. Probably we end up with
func.goto(@args)
or some such.
: Or should I use this?
:
: { local _ := ok; call($lhs == $rhs, $todo); }
:
: However, I did not see A/E/S06 specifying that call() will assume the
: goto semantic of erasing itself from the caller chain, so I hesitate
: to implement it that way.
call() doesn't erase itself from the call chain, but it does cloak
itself so that CALLER doesn't see it by default. (Presumably there's
an option to caller() that makes hidden frames visible.) The whole
point of wrappers is that the aren't realy there in some logical sense.
: Is using wrap/call the correct choice here, or is there another way
: to do it that I missed?
wrap/call should do what you want there, but if you want to hack in
func.goto, that'd be good too.
Larry
Re: s/true/better name/
Juerd writes: Nicholas Clark skribis 2005-03-15 17:53 (+): On Tue, Mar 15, 2005 at 05:57:57PM +0100, Juerd wrote: And re its spelling, that's a very good feature, because it'll slowly teach me how to spell this word. And when I know how to spell it, I can use it on IRC without dict(1)ing to see if I remembered correctly. This will eventually save me hours! :) One problem you may find with dict is that one common misspelling, wether, is also a valid English word, which any decent word list should contain. (It's a castrated ram) Dict uses dictionaries, not just word lists. It outputs the definition(s), so this misspelling is easily detected. I know both words exists. I just can't manage to remember which one is which, and maybe Perl 6 can help me :) Meany other hackers halve trouble remembering witch is witch to. I'm all ways perfectly rite thou. Luke
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On Wed, 2005-03-16 at 12:25, David Storrs wrote: I quite like as the bracketing characters. They are visually distinctive, they connect well with their adjacent C/X/L/etc without visually merging into it (compare Lfoo with L[foo]), and in the circumstance that you want to bracket an unbalanced bracket, you just double (triple, whatever) up and add some space: C $x $y Looks pretty clear to me. You are confusing aesthetics with usability. Yes, the above looks clear, but then I have to type C and just to tell the POD parser that there might be unbalanced or characters in my string. You're failing to apply Larry's rules of Perl 6. Huffman and the easy things easy, while hard things are possible principles demand that a common case not require copious extra gunk, and noting could be simpler than: C[$x $y] is about as B[easy] as it gets in [Perl] vs: C $x $y is about as Beasy as it gets in L[Perl|perl] without going full Wikish: [=$x $y] is about as *easy* as it gets in [Perl] However, saving a couple of keystrokes and cleaning up the above text is inconsequential compared to the massive savings in terms of taking advantage of the legions of people who are learning Wiki syntax these days. Making POD *more* Wiki-like without sacrificing useful features of POD is invaluable in terms of tech writers and other non-Perl-programmers writing useful docs in POD! -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: s/true/better name/
Marcus Adair writes:
Additionally I question whether this is truly a case improving to the
point of least surprise? After all, I don't know a programmer who's
going to be surprised by what true means. There are still *some* things
you may have to learn in software dev 101 ;)
The problem is this (common) one:
if answer() == true {
# do something
}
We want to give the programmer no good way to do that, because it's
wrong.
Either that, or we could define true to be the disjunction of all things
true. Then that would work correctly, even when answer() is returning
something more interesting than a bare bool.
Luke
Re: Markup language-like features in Perl6?
Michele Dondi writes: However I have the impression that there's still too much to it. Granted, GUIs are intrinsically some order of complexity above textual IO, but I think that letting the language have intrinsic markup language(-like) features may make things much easier from the huffmanization POV in these regards. Well, I don't really know how Perl's very expressive declarative data structure support doesn't help you. Maybe you could give a rough, ugly (if you don't have a nice proposal) description of what you mean. Luke
Re: wrap, call and goto sub
On Wed, Mar 16, 2005 at 10:24:16AM -0800, Larry Wall wrote: On Wed, Mar 16, 2005 at 08:46:03PM +0800, Autrijus Tang wrote: : Is using wrap/call the correct choice here, or is there another way : to do it that I missed? wrap/call should do what you want there, but if you want to hack in func.goto, that'd be good too. Done as r804. It also passes the expected context (want) of its original caller to func, which I assume is the correct behaviour. Thanks, /Autrijus/ pgpPRXk2qHuKt.pgp Description: PGP signature
Re: s/true/better name/
On Tue, Mar 15, 2005 at 12:28:15PM -0700, Marcus Adair wrote:
: Isn't saying false doesn't exist like saying, dark doesn't exist?
: Why have a word for that?
:
: I'm really afraid I'm missing something obvious here, but I'm worried
: that neither whether nor indeed work very well in many contexts. It
: seems to me that testing trueness exists in so many contexts that it's
: going to be hard to find an English word that fits all the important
: ones.
Most of those contexts are implicitly boolean, and this function would
be redundant there. The main use for this function is to provide a
boolean context for its argument and return 0 or 1 when you really
do want 0 or 1 for some context that isn't directly boolean. This
is actually relatively rare.
: Additionally I question whether this is truly a case improving to the
: point of least surprise? After all, I don't know a programmer who's
: going to be surprised by what true means. There are still *some* things
: you may have to learn in software dev 101 ;)
The point is that most people coming from other languages would expect
true to be a true value, not a function testing whether some other
value is true. It would be particularly confusing if we made it
default to testing $_, in which case
$_ = 0;
if 1 == true { say true } else { say false }
would say false. It is a little less confusing in
given $value {
when true {...}
except that, in fact, both of those cases would be syntax errors if
true were a function, since it would parse the following block as an
argument to true.
So if we really want to test a value for whether its .bit property
returns the bool::true value, we will probably require you to use
the method syntax:
when .true {...}
and then it's obvious that there's some object involved. (And it parses
right, because .true would require parens if there were arguments.) On
the other hand, these also do the same thing underneath, at least in
the abstract:
when ?$_ {...}
if $_ {...}
The optimizer is likely to bypass actually calling the .bit/.true method on
known types, however.
Larry
Re: s/true/better name/
Luke Palmer wrote:
Marcus Adair writes:
Additionally I question whether this is truly a case improving to the
point of least surprise? After all, I don't know a programmer who's
going to be surprised by what true means. There are still *some* things
you may have to learn in software dev 101 ;)
The problem is this (common) one:
if answer() == true {
# do something
}
We want to give the programmer no good way to do that, because it's
wrong.
What do you mean wrong? It looks perfectly valid to me. It's
redundant, since answer() by itself would suffice as a condition with no
comparison, but does that make it wrong?
Re: [Pugs] short-circuit operators
Larry Wall wrote:
Since it's not a problem for syntax that can be recognized at compile
time, your slice above might be allowed if you declare the thunks
with curlies:
@3d_slice = @array[ {!($_ % 2)}; 0..9:3; {?test($_)} ];
How does the compiler know that those ';'s within curlies are
List-of-lists separators, and not statement-separators?
That looks a lot like normal closure/code-block where ; just separates
different statements.
--
Markus Laire
Jam. 1:5-6
Re: [Pugs] short-circuit operators
Markus Laire writes:
Larry Wall wrote:
Since it's not a problem for syntax that can be recognized at compile
time, your slice above might be allowed if you declare the thunks
with curlies:
@3d_slice = @array[ {!($_ % 2)}; 0..9:3; {?test($_)} ];
How does the compiler know that those ';'s within curlies are
List-of-lists separators, and not statement-separators?
Er, they're not inside curlies. The curlies are inside them. But I
agree that it's visually confusing.
Luke
Re: s/true/better name/
On Wed, Mar 16, 2005 at 01:41:56PM -0500, Mark J. Reed wrote:
: Luke Palmer wrote:
:
: Marcus Adair writes:
: Additionally I question whether this is truly a case improving to the
: point of least surprise? After all, I don't know a programmer who's
: going to be surprised by what true means. There are still *some* things
: you may have to learn in software dev 101 ;)
:
: The problem is this (common) one:
:
: if answer() == true {
: # do something
: }
:
: We want to give the programmer no good way to do that, because it's
: wrong.
:
:
: What do you mean wrong? It looks perfectly valid to me. It's
: redundant, since answer() by itself would suffice as a condition with no
: comparison, but does that make it wrong?
It could be forced to work if MMD is smart enough to call an ==
function that we were smart enough to define that is smart enough to
look at the .bit property of the left argument to coerce that value
to 0 or 1. But the naive implementation ends up comparing 42 == 1
and returning false. Unfortunately, == is one of those things we'd
like to optimize heavily, and it's hard if there's a lot of MMD
cruft in the way.
Larry
Re: wrap, call and goto sub
On Thu, Mar 17, 2005 at 02:38:45AM +0800, Autrijus Tang wrote: : On Wed, Mar 16, 2005 at 10:24:16AM -0800, Larry Wall wrote: : On Wed, Mar 16, 2005 at 08:46:03PM +0800, Autrijus Tang wrote: : : Is using wrap/call the correct choice here, or is there another way : : to do it that I missed? : : wrap/call should do what you want there, but if you want to hack in : func.goto, that'd be good too. : : Done as r804. It also passes the expected context (want) of its : original caller to func, which I assume is the correct behaviour. Yes. Larry
Re: Referencing a caller's slurpy array.
Larry Wall writes:
Certainly. The zone markers are as orthogonal to sigils as we can
make 'em. Though I'm not sure we've given a meaning to *foo yet.
I suppose that would have to mean that the next slurpy parameter has
to be a sub ref.
Uhmm... isn't *foo the adverbial block? That is, isn't it where grep
gets its code block in:
@list.grep:{ $_ % 2 }
Luke
Re: Referencing a caller's slurpy array.
On Wed, Mar 16, 2005 at 11:53:43AM -0700, Luke Palmer wrote:
: Larry Wall writes:
: Certainly. The zone markers are as orthogonal to sigils as we can
: make 'em. Though I'm not sure we've given a meaning to *foo yet.
: I suppose that would have to mean that the next slurpy parameter has
: to be a sub ref.
:
: Uhmm... isn't *foo the adverbial block? That is, isn't it where grep
: gets its code block in:
:
: @list.grep:{ $_ % 2 }
Maybe it can mean either of those things without conflict, as long
as you don't try to make it mean both. :{...} is just short for a
named parameter that happens to bind to the *foo looking parameter,
but as with ordinary list operators, they can be passed positionally
as well as by name.
But yes, to be perfectly frank, I'd forgotten about that. Doubtless
a sign of premature senility.
Larry
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On 16/03/05 12:00 -0500, Aaron Sherman wrote:
On Tue, 2005-03-15 at 13:48, Brian Ingerson wrote:
Aaron,
Upon reading this, it is unclear to me whether you have read about the
Kwid format or you are simply guessing that Kwid is the same syntax
used by Kwiki.
I read the Kwid documentation from the Pugs distribution in depth.
To create Kwid I carefully studied the POD information model
(the semantic tree that POD parses to). Kwid uses the exact same
info model. This means that switching between the two without
loss of information is possible.
I noted that in my original message.
This makes the Kwid experiment much less risky
Risk was not my concern. My concern was a Wiki-like model which is
inconsistent with many of the goals of POD. POD is intended to be PLAIN
OLD documentation.
I think consistency with goals is fine, but consistency with the data
model is more important. POD has a very nice data model that maps well
to other formats. It is really well done. So logic stands that any
format which can map cleanly to POD and yet offer an advantages to the
author is a benefit to the author without needing to retool the
extensions. Further any dialect can be converted to any other without
information or structure loss.
POD's syntax is certainly good enough, but doesn't match the way that
people commonly write structured prose; especially in this era of text
based formatting such as in wikis. POD's syntax /elegance/ also tends to
break down into workarounds too fast in edge cases.
NOTE: POD does have some minor warts in the data model, but they can be
fixed later on.
Kwid breaks this model of simplicity by introducing unique boundary
characters for many types of operations, and by making the overall
presentation more complex.
Let's look at an example and explore the rationale:
Pod uses this syntax Bbold stuff which is fine, but it is a very
common idiom to use *bold stuff* outside of Pod. Usenet posts, email,
irc, etc. People use this, they grok it, and lots of tools grok it as
well. (I'm thinking irc clients as an example).
So how do we get *there* formally and avoid making a mess where * is
just supposed to be an asterisk?
Kwid does this by formally changing
X...
into
{X...X}
Where `X` is any Pod code like `B`, `I` or `C`. Since there are only 3
codes in common use (ignore `L` for a second), Kwid thus uses {*bold*}
{/italic/} and {`code`}.
This has a subtle but significant advantage over X The difference
is that instead of the ending marker being '' it is 'X}', which is
orders of magnitude less likely to show up in the content being escaped.
This means you avoid the X ... mess almost entirely.
But the better part of this is that the Kwid forms can be relaxed to
drop the curlies in most cases. This technique uses the principle of
hugging. So you can say *$a = $b * $c* and get the bolded equation
since the middle * isn't hugging anything. Hugging is a nontrivial
heuristic, but let's just say it Does The Right Thing. And if you aren't
sure just say {*$a = $b * $c*}. ie, just add some curlies to what you
already have.
*Bold* and /italics/ are rather obvious, intuitive and commonly used.
Backticks for `code` was chosen because backticks are rarely used in
code. Except of course when writing about Kwid itself. But to get
C`code` you just go to the curlies: {``code``}. Simple. Backticks also
seem to be right visually, but that's just my opinion.
For L..., I decided to use the very common wiki idiom of [...] for a
link. Everything in the `...` is the same as Pod.
I is purely subjective whether Kwid's overall presentation is more or
less complex than Pod's. Kwid attempts to elegantly move towards the
modern internet era of social software, with the hope that those
participating in those arenas might feel more at home.
While I appreciate several features of Kwid, I feel that it should not
replace POD without first adopting a POD-like simplicity.
Some people have argued that Kwid is only a syntactic change to
Pod. I would argue that they are correct.
They are demonstrably wrong. You cannot Parse Kwid correctly by changing
the syntax of a POD parser.
For example, the behavior of
* foo
bar
The behaviour of this is completely consistent. You may need to reread the
perlkwid document for it has recently changed.
ie
* foo
bar
* baz
boom
matches
* foo bar
* baz boom
matches
.list
* foo bar
* baz boom
.list.
The explicit `.list` is only needed when the parser cannot guess from
the context.
...
I would encourage those interested in further fleshing out Kwid to join
irc://irc.freenode.net/#kwid where all of this is actively being
discussed.
Cheers, Brian
Re: s/true/better name/
Larry Wall wrote: On Tue, Mar 15, 2005 at 12:28:15PM -0700, Marcus Adair wrote: : Isn't saying false doesn't exist like saying, dark doesn't exist? : Why have a word for that? : : I'm really afraid I'm missing something obvious here, but I'm worried : that neither whether nor indeed work very well in many contexts. It : seems to me that testing trueness exists in so many contexts that it's : going to be hard to find an English word that fits all the important : ones. Most of those contexts are implicitly boolean, and this function would be redundant there. The main use for this function is to provide a boolean context for its argument and return 0 or 1 when you really do want 0 or 1 for some context that isn't directly boolean. This is actually relatively rare. Doesn't C +?(...) take care of those cases? Sure, it's line noise, but do we really need a new keyword for something that's relatively rare? Especially when that keyword is likely to confuse people a lot more than the application of two unary operators? -- Rod Adams
Re: Referencing a caller's slurpy array.
Luke Palmer wrote:
Larry Wall writes:
Certainly. The zone markers are as orthogonal to sigils as we can
make 'em. Though I'm not sure we've given a meaning to *foo yet.
I suppose that would have to mean that the next slurpy parameter has
to be a sub ref.
Uhmm... isn't *foo the adverbial block? That is, isn't it where grep
gets its code block in:
@list.grep:{ $_ % 2 }
In S29, I currently have Cgrep as:
multi sub grep (Any|Junction $test : [EMAIL PROTECTED]) returns List {
gather {
for @values - $x {
take $x if $x ~~ $test;
}
}
}
If you wish to supply a closure for C$test, you're free to do so.
If I were building it to accept just a closure, I would think:
multi sub grep (Code test : [EMAIL PROTECTED])
or
multi sub grep (: Code +test = defaulttest , [EMAIL PROTECTED])
would make more sense than:
multi sub grep (: Code *test, [EMAIL PROTECTED])
At least to me it does. If you see some advantage to that way, please
inform me of it. It might change Cmap away from:
multi sub map (Code $expression : [EMAIL PROTECTED]) returns List {
gather {
while @values {
take $expression
.( splice(@values, 0, $expression.arity) );
}
}
}
-- Rod Adams
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On 16/03/05 13:30 -0500, Aaron Sherman wrote: On Wed, 2005-03-16 at 12:25, David Storrs wrote: I quite like as the bracketing characters. They are visually distinctive, they connect well with their adjacent C/X/L/etc without visually merging into it (compare Lfoo with L[foo]), and in the circumstance that you want to bracket an unbalanced bracket, you just double (triple, whatever) up and add some space: C $x $y Looks pretty clear to me. You are confusing aesthetics with usability. Yes, the above looks clear, but then I have to type C and just to tell the POD parser that there might be unbalanced or characters in my string. You're failing to apply Larry's rules of Perl 6. Huffman and the easy things easy, while hard things are possible principles demand that a common case not require copious extra gunk, and noting could be simpler than: C[$x $y] is about as B[easy] as it gets in [Perl] vs: C $x $y is about as Beasy as it gets in L[Perl|perl] without going full Wikish: [=$x $y] is about as *easy* as it gets in [Perl] vs Kwid: `$x $y` is about as *easy* as it gets in [Perl] Did you really read `perlkwid.kwid`? There is simply no mention of `[=...]` as a markup option, which makes me wonder where you got it from? However, saving a couple of keystrokes and cleaning up the above text is inconsequential compared to the massive savings in terms of taking advantage of the legions of people who are learning Wiki syntax these days. Making POD *more* Wiki-like without sacrificing useful features of POD is invaluable in terms of tech writers and other non-Perl-programmers writing useful docs in POD! Well said! Cheers, Brian
Re: zip
Larry Wall wrote:
If we go with my once-upon-a-time notion of using zip(@a;@b), then it
naturally comes in as [EMAIL PROTECTED],[EMAIL PROTECTED]
It pretty much has to use the list of lists syntax, since the number of
Arrays we are zipping is variadic, and that means using a slurpy, which
would flatten the arrays into one. So the semicolons stay. Unless
there's a non-flattening slurpy syntax out there
: As a second matter, can you declare a type for the elements of a slurpy
: array?
Yes, and it distributes as any array return type declaration would.
Does this mean that we can define multiple slurpuy arrays (and
hashes?!?) in a parameter list, of different types, and Perl will sort
the arguments into the right slurpy for us? If so, how does this
interact with the answer about C@CALLER::_?
: So far I have:
:
: multi sub zip (Array [EMAIL PROTECTED]) returns List {
: gather {
: while any(@lists) {
any() is not guaranteed to produce left-to-right order.
I'm not counting on it being ordered. I'm testing to see if any of the
lists still has anything left in it. The left to right-ness of the
processing is done in the Cfor.
: for @lists - @list {
: take shift @list;
: }
: }
: }
: }
:
: But I can't tackle the lvalue problem.
Why do they need to be lvalues? I always thought of zip as non-destructive.
Has zip historically been destructive in other languages?
I wasn't aware of a Czip in other languages.
My thought was that people might want to update the values stored
inside, as an homage to my common Perl 5 construct:
for ($var1, $var2) {
s/.../.../;
s/.../.../;
}
(and yes, I'm a bit chagrined that Perl6 is converting that lovely thing to:
for $var1, $var2 - $_ is rw {
s/.../.../;
s/.../.../;
}
though
given $var1 {
s/.../.../;
s/.../.../;
}
is nice.
)
But if you don't see the need for lvalueing the elements coming out of
Czip, that certainly makes things easier. :-)
-- Rod Adams
Re: s/true/better name/
On Wed, Mar 16, 2005 at 01:22:06PM -0600, Rod Adams wrote: : Larry Wall wrote: : : On Tue, Mar 15, 2005 at 12:28:15PM -0700, Marcus Adair wrote: : : Isn't saying false doesn't exist like saying, dark doesn't exist? : : Why have a word for that? : : : : I'm really afraid I'm missing something obvious here, but I'm worried : : that neither whether nor indeed work very well in many contexts. It : : seems to me that testing trueness exists in so many contexts that it's : : going to be hard to find an English word that fits all the important : : ones. : : Most of those contexts are implicitly boolean, and this function would : be redundant there. The main use for this function is to provide a : boolean context for its argument and return 0 or 1 when you really : do want 0 or 1 for some context that isn't directly boolean. This : is actually relatively rare. : : : Doesn't C +?(...) take care of those cases? : : Sure, it's line noise, but do we really need a new keyword for something : that's relatively rare? : Especially when that keyword is likely to confuse people a lot more than : the application of two unary operators? Well, sure, but by a similar argument we don't need not, and, or or either. I think an acknowledgement of its rarity could show up in making it something relatively long like whether. On the other hand, I have a linguistic problem with whether in that in English it seems to be looser than and, and or, while as a positive not in Perl, it would be classified as tighter. That is, $x = whether $a or $b; $x = not $a or $b; would actually be parsed as $x = whether($a) or $b; $x = not($a) or $b; whereas as a native English speaker would probably expect $x = whether($a or $b); So I'm thinking we'll just go back to true, both for that reason, and because it does syntactically block the naughty meaning of true as a term (as long as we don't default true() to $_), as Luke reminded us. Larry
Re: s/true/better name/
On Wed, Mar 16, 2005 at 12:09:40PM -0800, Larry Wall wrote: whereas as a native English speaker would probably expect $x = whether($a or $b); So I'm thinking we'll just go back to true, both for that reason, and because it does syntactically block the naughty meaning of true as a term (as long as we don't default true() to $_), as Luke reminded us. But true() reads weird, and it does not read like an unary (or list) operator at all to me. As the bikeshedding is still going on, may I suggest aye()? It is the same length as not(), both are adverbs, and is rare enough to not conflict with user-defined subs. Thanks, /Autrijus/ pgprIOwawnyBA.pgp Description: PGP signature
Re: zip
Larry Wall wrote:
Well paint yourself unchagrined, because S04 sez:
Parameters are by default constant within the block. You can
declare a parameter read/write by including the is rw trait. If
you rely on $_ as the implicit parameter to a block, then then $_
is considered read/write by default. That is, the construct:
for @foo {...}
is actually short for:
for @foo - $_ is rw {...}
so you can modify the current list element in that case. However,
any time you specify the arguments, they default to read only.
gets out unchagrining paint and splashes it about. :-)
You know, the amazing thing about those Synopses and Apocalypses you
wrote is that no matter how many times I read them, I always find 5 new
things in them on each pass. And I'm the kind of guy who typically
absorbs entire 200 page reference manuals in one pass. I swear you found
the English equivalent of Quantum Mechanics in there, where entire
paragraphs exist and don't exist at the same time, without changing. :-)
Of course, I now have to question the need for Cgiven. Other than
linguistics, which is not to be dismissed, what difference is there between
given $expr { ... }
and
for $expr { ... }
with equivalent ...'s?
hmm. Come to think of it, the Cfor would flatten $expr if it happened
to look like an array or something equally bumpy, where Cgiven would
not. But perhaps it would make sense to define Cfor and Cgiven as
synonyms in all other ways but autoflatten.
As far as linguistics go, for makes a suitable replacement for given
in my head. It's just a very heavily loaded term when you leave English
and enter CS-speak.
-- Rod Adams
Re: zip
Larry Wall skribis 2005-03-16 12:17 (-0800):
for @foo {...}
is actually short for:
for @foo - $_ is rw {...}
Has there been any decision on - yet? If - is there, it's much
easier to say that without arguments, - $_ is used. That way, there is
no surprising magic is rw, but just another operator (that happens to
be the exact same thing in practice).
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On 16/03/05 14:33 -0500, Aaron Sherman wrote:
On Wed, 2005-03-16 at 14:17, Brian Ingerson wrote:
Kwid does this by formally changing
X...
into
{X...X}
Ok, where is THAT proposal?! I'm reading the doc that's in
doc/perlkwid.kwid in the pugs source tree. Hmmm... odd, I just did an
update and it's GONE now... was I looking at some phantom doc that had
an old spec for Kwid?!
Sorry, it has been moved around the pugs source tree a bit. It is
currently swinging from the documentation branch:
ext/Pugs-Documentation/perlkwid.kwid
Where `X` is any Pod code like `B`, `I` or `C`. Since there are only 3
codes in common use (ignore `L` for a second), Kwid thus uses {*bold*}
{/italic/} and {`code`}.
FYI, it turns out that at least one modern format,
[Markdown|http://daringfireball.net/projects/markdown/syntax], uses
backticks for code. Markdown doesn't really map to the Pod space very
well, but it has a few gems...
Well, I'm personally not fond of the bare-bracketting with {}, but as
long as it's not a stand-alone /italic/ like it was in the original doc,
that sounds fine. Why {/foo/} is more readable than I[foo], I'm not
sure... but I'll try to take your word for it.
In short you don't need to worry about I[[ $foo[3] ]]. Since the ending
marker is '/}', you only ever need to worry about escaping anything but
'/}' itself. I might as well show how that would be done:
{/foo \/} bar/}
{{/foo /} bar/}}
{/foo { /} } bar/}
Those are 3 possible ways to make Ifoo /} bar. Note that '{ ' and ' }'
are the asis or leave me alone indicators. But the real point is
that '/}' is rather unlikely to ever show up in italics outside this
discussion.
For L..., I decided to use the very common wiki idiom of [...] for a
link. Everything in the `...` is the same as Pod.
There, I think you're making a small mistake, but not a huge one. I'd
separate out magical wiki-like [foo] from pedantic, pod-like L[foo] so
that you can get either one. Wiki's [foo] is like a URN, where POD's
L[foo] is more in tune with a relative URL.
So I will give a little extra info on this...
The idea is to DWIM and there is a lot you can do with the `[...|.../...]`
syntax. Pod's strict syntax is:
Ltext|resource/section
/Text/ is obviously the text that should render. /Resource/ can be a
local manpage (ie another Pod document) and then /section/ is a section
in that doc. If /resource/ is empty, the current document is assumed.
/Resource/ can also be a fully qualified url and in that case section
does not apply.
For some reason Pod does not allow Ltext|url but there seems to be no
obvious reason. (This is the the only major thing where Kwid strays from
Pod's info model).
I am not certain what use case `L[...]` could get you that isn't already
covered by `[...]`.
While I appreciate several features of Kwid, I feel that it should not
replace POD without first adopting a POD-like simplicity.
Some people have argued that Kwid is only a syntactic change to
Pod. I would argue that they are correct.
They are demonstrably wrong. You cannot Parse Kwid correctly by changing
the syntax of a POD parser.
The behaviour of this is completely consistent. You may need to reread the
perlkwid document for it has recently changed.
Apparently.
ie
* foo
bar
* baz
boom
matches
* foo bar
* baz boom
matches
.list
* foo bar
* baz boom
.list.
Hrm...
How, then do you differentiate:
* Bullet list.
1. Numbered list.
Other
Term/definition lists
? In POD, that would be:
=item *
Bullet list
=item 1
Numbered list.
=item Other
Term/definition lists
This makes no sense in html and perlpod says:
* And perhaps most importantly, keep the items consistent: either
use =item * for all of them, to produce bullets; or use
=item 1., =item 2., etc., to produce numbered lists; or use
=item foo, =item bar, etc. -- namely, things that look
nothing like bullets or numbers.
In Kwid, therefore, this:
* Bullet list.
+ Numbered list.
- Other
Term/definition lists
would produce 3 single item lists. You can obviously switch types in sublists:
* Bullet list.
++ Numbered list.
* another bullet
-- Other
Term/definition lists
I would encourage those interested in further fleshing out Kwid to join
irc://irc.freenode.net/#kwid where all of this is actively being
discussed.
Sorry, no access to IRC at work. If the specification of core pieces of
P6 are being done off-list, why is there a list?
Honestly this project was started as an /experiment/ and was not
intended to distract p6l. Kwid requires no extra input from the language
side as long as:
=kwid
...
=cut
is ignored by the interpreter. This turns out to
Re: s/true/better name/
On Wednesday 16 March 2005 15:40, Autrijus Tang wrote: On Wed, Mar 16, 2005 at 12:09:40PM -0800, Larry Wall wrote: So I'm thinking we'll just go back to true, both for that reason, and because it does syntactically block the naughty meaning of true as a term (as long as we don't default true() to $_), as Luke reminded us. But true() reads weird, and it does not read like an unary (or list) operator at all to me. As the bikeshedding is still going on, may I suggest aye()? It is the same length as not(), both are adverbs, and is rare enough to not conflict with user-defined subs. A shotgun brainstorming of possible operator names: determine ponder query consider examine veracity inquire bool boolean bin binary propriety
Re: quotemeta
Larry Wall skribis 2005-03-16 9:41 (-0800): Except that q:meta would be an upgrade in terms of specialness, and besides, it's inside out from what you want, which is to quote a particular argument to a string interpolation, not the entire interpolation. It just wants to be a miscellaneous function hidden in the bowels of the core somewhere. Doesn't it want to be the method .escaped then? The method could support all kinds of escaping/encoding. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On 16/03/05 14:56 -0500, Aaron Sherman wrote: On Wed, 2005-03-16 at 14:24, Brian Ingerson wrote: vs Kwid: `$x $y` is about as *easy* as it gets in [Perl] Did you really read `perlkwid.kwid`? Yes, and can you please stop asking that question? I read it several times, and you're starting to get just this side of insulting. If I got something wrong, fine, say so. Stop trying to dismiss everything else I've said by suggesting that I'm completely uninformed. Aaron, /please/ take no offense. I just don't understand where you picked `[=...]` up other than that is the (hated) syntax artifact of the original `CGI::Kwiki`. I don't recall ever using it in regards to Kwid. I'm sure there's a reasonable explanation. :) There is simply no mention of `[=...]` as a markup option, which makes me wonder where you got it from? I got it from that document or so I thought. Since it's now deleted, I'm no longer sure. Having a reference again would be nice. It's hard to have a conversation about a document that does not exist. In my first mail of the thread I pointed to it: http://svn.openfoundry.org/pugs/ext/Pugs-Documentation/perlkwid.kwid As I said in my last mail, it has moved around a bit, so pardon our dust. Ok, that said PLEASE DO NOT USE UNBALANCED CHARACTERS TO DELIMIT! Please, for the love of all that is valid input to any scanner / parser anywhere, do not re-introduce quoting hell. Really. Please. Don't. I'll buy you a beer. I swear, just put the unbalanced operator down and step back. A beer is tempting... Sorry, but I use POD specifically because it makes my life simple. Introducing unbalanced quotes into it would remove that functionality. A few examples: And then I says, `Mabel,' I says, `shut up.' The ``` character is no longer used. And of course, TONS of Gnu documentation which uses the TeX-friendly: This is the way you ``quote'' things. No problem with this example. `` doesn't /hug/ anything so it shows up asis. Cutting and pasting LaTeX doesn't mess anything up in this regard. But really, you'll likely refactor it to: This is the way you quote things. Since `` and '' don't do anything for you in either Pod or Kwid. Cheers, Brian
Re: quotemeta
On Wed, Mar 16, 2005 at 10:46:29PM +0100, Juerd wrote: : Larry Wall skribis 2005-03-16 9:41 (-0800): : Except that q:meta would be an upgrade in terms of specialness, : and besides, it's inside out from what you want, which is to quote : a particular argument to a string interpolation, not the entire : interpolation. It just wants to be a miscellaneous function hidden : in the bowels of the core somewhere. : : Doesn't it want to be the method .escaped then? The method could support : all kinds of escaping/encoding. The question is, escaped for what? quotemeta() is rather Unix-centric in a conservative sort of way. Maybe we're just talking about an option to .as(). Larry
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On Wed, Mar 16, 2005 at 01:30:04PM -0500, Aaron Sherman wrote:
On Wed, 2005-03-16 at 12:25, David Storrs wrote:
I quite like as the bracketing characters. They are
visually distinctive, they connect well with their adjacent C/X/L/etc
without visually merging into it (compare Lfoo with L[foo]), and in
the circumstance that you want to bracket an unbalanced bracket, you
just double (triple, whatever) up and add some space:
C $x $y
Looks pretty clear to me.
You are confusing aesthetics with usability.
No, I am relating simplicity and consistency to usability. If it
costs two extra keystrokes, I'm cool with that.
and noting could be simpler than:
C[$x $y] is about as B[easy] as it gets in [Perl]
C[$x[0] $y] # hmmm...parser ok with that?
C[$x[0] $] # hmmm...error, but what was intended: $y] or $]]?
C $x[0] $y # parser's ok (so's the human)
C $x[0] $# oh, obviously $y was intended
However, saving a couple of keystrokes and cleaning up the above text is
inconsequential compared to
...the power of the Force. Sorry, had to say it.
the massive savings in terms of taking
advantage of the legions of people who are learning Wiki syntax these
days. Making POD *more* Wiki-like without sacrificing useful features of
POD is invaluable in terms of tech writers and other
non-Perl-programmers writing useful docs in POD!
Here's the real crux of your argument, and the real crux of my problem
with this approach. I don't like Wiki syntax; to me, it seems
arbitrary and non-unified. I use Wikis, I run one, I recognize their
usefulness. I just don't like them.
Here are some of the formatting rules for TWiki (the Wiki version I
use):
1) Elements of a bulleted list must match /^ {3}\* /
2) Elements of a numbered list must match /^ {3}1 /
3) Headings must match /^*\++/. Number of +s determines level
4) *bold*
5) /italic/
6) =fixed font=
7) verbatim put text to be rendered as-is here /verbatim
What is the organizing priciple? What similarities do they have?
Quick, what level heading is this: + ? And this is just the
beginning...I didn't even get into the weird cases like ==bold fixed
font== and __bold italic__, which have no perceptible relation to
their component pieces (I would have expected */bold italics/*). Yes,
it's powerful and it can do useful things, but as soon as I stray from
the most basic stuff I find myself going back to the docs to look up
how it's done.
Contrast this to POD (I'm not trying for point-to-point equivalence):
1) All formatting starts with = in the first column.
2) Every POD command must have a blank line above and below it.
3) A list of any type starts with =over N and finishes with =back
4) List items are denoted with =item X where X is either * (bullets),
an int (numbered), or word/phrase. Use only one type per list.
5) Headings are denoted by =head1, =head2, etc
6) Formatting effects are done with Xtext where X is one of:
B (bold), C (code), I (italics). You may also use
X text or X text if you have or in your text.
7) Text that is indented will be rendered as-is in fixed width font.
Aside from links, that's pretty much the entire perlpodtut boiled down
into 7 bullets; a little experimentation to get the hang of it and it
all holds together nicely, easy to remember.
I freely admit that the link syntax in POD is difficult to manage and
not as powerful as it could be.
--Dks
PS I'm subscribed to the list so feel free to just reply there; I
don't need a personal copy as well.
--
[EMAIL PROTECTED]
Re: Referencing a caller's slurpy array.
Rod Adams writes:
Uhmm... isn't *foo the adverbial block? That is, isn't it where grep
gets its code block in:
@list.grep:{ $_ % 2 }
In S29, I currently have Cgrep as:
multi sub grep (Any|Junction $test : [EMAIL PROTECTED]) returns List {
gather {
for @values - $x {
take $x if $x ~~ $test;
}
}
}
That's the listop form. I was referring to the method form:
multi sub grep (@array: *code) returns List {
...
}
The fact that there is a conflict in context in the argument points out
one of the weaknesses of the current multi declaraition semantics.
Currently, it would just default to list context.
I think the *compiler* should be able to tell the difference between the
two forms without having to go to runtime method dispatch (perhaps it
still does dispatch, but if you're in the latter form, you don't even
try to dispatch to the former routine). But that's a big brainstorm
that needs to happen, and I'm not prepared to do that right now.
Luke
Re: Testing .pl executables
On Thu, Mar 17, 2005 at 12:06:36AM +1100, Andrew Savige wrote: However, I was wondering if there is a standard, safe way of testing simple .pl scripts? Hmmm. The identical question was asked a bit over a week ago: http://www.nntp.perl.org/group/perl.qa/3722 I suggest you start by browsing the answers given there. And I just happen to be taking that and making a perl.com article out of it which I promised chromatic I'd give him inside two more weeks. I'll post up the draft for comments when its ready.
Re: Testing .pl executables
Michael G Schwern wrote: On Thu, Mar 17, 2005 at 12:06:36AM +1100, Andrew Savige wrote: However, I was wondering if there is a standard, safe way of testing simple .pl scripts? Hmmm. The identical question was asked a bit over a week ago: http://www.nntp.perl.org/group/perl.qa/3722 I suggest you start by browsing the answers given there. And I just happen to be taking that and making a perl.com article out of it which I promised chromatic I'd give him inside two more weeks. I'll post up the draft for comments when its ready. Awesome. I feel special now. :) -ofer
RE: New S29 draft up
-Original Message-
From: Rod Adams [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 16, 2005 3:18 AM
To: Perl6 Language List
Subject: New S29 draft up
I just posted a fresh copy of S29 to:
http://www.rodadams.net/Perl/S29.pod
http://www.rodadams.net/Perl/S29.html
New:
All defined functions have been restructured into packages.
Perl6::Arrays, Perl6::Lists, and Perl6::Hashes are (mostly) written.
Some Math::Basic and Math::Trig functions added.
:'s have been added into signatures where they belong.
various other clean ups.
Isn't there also supposed to be an Arrays::kv? Also, I'm pretty sure
Larry said the Lists::reduce should go in the core.
Let me try to define them.
multi sub kv (Array @array : [EMAIL PROTECTED]) returns List
Returns the indexes and associated values stored in @array, lazily and in
order by index. Optionally, only those of the slice defined by @indices.
multi sub reduce (Code $expression : [EMAIL PROTECTED]) returns List
{
my $res;
for @values - $cur {
FIRST {$res = $cur; next;}
$res = $expression($res, $cur);
}
$res;
}
Joe Gottman
Four MANIFEST files not found
I just now did cvs -q update make distclean perl Configure.pl on my x86 SuSE 9.2 laptop and got . . . Checking MANIFEST..No such file: languages/parrot_compiler/lib/Parrot/Test/ParrotCompiler.pm No such file: languages/parrot_compiler/t/basic/hello.t No such file: languages/parrot_compiler/t/harness No such file: runtime/parrot/library/YAML/Parser/Syck.imc Ack, some files were missing! I can't continue running without everything here. Please try to find the above files and then try running Configure again. The following patch deletes the missing files from MANIFEST, after which Configure.pl succeeds, and make test works. (Actually, the tests are still running, but at least the parrot squawks.) -- Bob Rogers http://rgrjr.dyndns.org/ --- MANIFEST.~1.848.~ 2005-03-16 20:38:22.0 -0500 +++ MANIFEST2005-03-16 20:43:41.790067113 -0500 @@ -2253,12 +2253,9 @@ languages/parakeet/README.txt [parakeet] languages/parakeet/parakeet.imc [parakeet] languages/parakeet/test.pk[parakeet] -languages/parrot_compiler/lib/Parrot/Test/ParrotCompiler.pm [parrot_compiler] languages/parrot_compiler/parrot_compiler.imc [parrot_compiler] languages/parrot_compiler/parrot.pasm [parrot_compiler] languages/parrot_compiler/sample.pasm [parrot_compiler] -languages/parrot_compiler/t/harness [parrot_compiler] -languages/parrot_compiler/t/basic/hello.t [parrot_compiler] languages/perl6/ChangeLog [perl6] languages/perl6/P6C/Addcontext.pm [perl6] languages/perl6/P6C/Builtins.pm [perl6] @@ -2706,7 +2703,6 @@ runtime/parrot/library/postgres.declarations [library] runtime/parrot/library/postgres.imc [library] runtime/parrot/library/postgres.pasm [library] -runtime/parrot/library/YAML/Parser/Syck.imc [library] ops/bit.ops [] ops/cmp.ops [] ops/core.ops []
Test::Inline is now Alias'
Folks may have read that Alias has written Test::Inline 2.00 http://use.perl.org/~Alias/journal/23653 I've given up all illusions that I'm ever going to get around to updating Test::Inline so I've handed the namespace over to Alias. There's some things which need to be done before its backwards compatible with the existing TI (like implmenting testing examples) but at least now an alpha can get onto CPAN. Take it away Alias.
Interested in joining Phalanx
Hi, I've been lurking perl.com for years and have always wanted to contribute. Seems like the Phalanx project is a good place to start. I'm particularly interested in testing the Net_SSLeay.pm module. Any tips on getting started or any 'hoplites' out there who need help with testing this module? Thanks, Walter Goulet
Re: Interested in joining Phalanx
I've been lurking perl.com for years and have always wanted to contribute. Seems like the Phalanx project is a good place to start. I'm particularly interested in testing the Net_SSLeay.pm module. Take a look at the Kwiki on the Hoplites wanted page. You can be the leader of the team if you want. We're very ad hoc here. xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: New S29 draft up
Joe Gottman writes:
multi sub kv (Array @array : [EMAIL PROTECTED]) returns List
Returns the indexes and associated values stored in @array, lazily and in
order by index. Optionally, only those of the slice defined by @indices.
This one is real easy:
multi sub kv (@array) returns List {
zip(1...; @array);
}
Array @array means an array of arrays. The [EMAIL PROTECTED] parameter seems
superflous, since you could just do:
for @array[1..10].kv - $k, $v {...}
Luke
Re: New S29 draft up
Luke Palmer wrote:
Joe Gottman writes:
multi sub kv (Array @array : [EMAIL PROTECTED]) returns List
Returns the indexes and associated values stored in @array, lazily and in
order by index. Optionally, only those of the slice defined by @indices.
This one is real easy:
multi sub kv (@array) returns List {
zip(1...; @array);
}
Doesn't Czip go until the longest input is exhausted, returning undef
at the end of the shorter ones?
multi sub kv (@array) returns List {
zip([EMAIL PROTECTED] ; @array);
}
Should work, though.
Array @array means an array of arrays.
Grr. Another thing I knew better on and was getting wrong. If nothing
else, I'm getting used to thinking Perl 6 more and more by writing this
thing.
The [EMAIL PROTECTED] parameter seems
superflous, since you could just do:
for @array[1..10].kv - $k, $v {...}
Yea, but I saw Larry mention somewhere about supplying an optional list
of values to kv, etc. Forget exactly where, but I know I saw it. At
least, that was a reference to the Hash kv, where it makes sense, when
it's not painfully obvious that the keys mentioned already exist.
My thinking is that the kv/values/etc method of supplying a slice omits
elements that don't exist from the output, while the subscript slices
would generate undef. Also, I've taken a step and made it where it's now:
multi sub keys (@array : Any|Junction [EMAIL PROTECTED]) returns Int|List
multi sub kv (@array : Any|Junction [EMAIL PROTECTED]) returns Int|List
multi sub pairs (@array : Any|Junction [EMAIL PROTECTED]) returns Int|(List
of Pair)
multi sub values (@array : Any|Junction [EMAIL PROTECTED]) returns Int|List
Which slices based on C$index ~~ any(@indextests), which seems a bit
more flexible.
Thanks to Joe for pointing out the missing functions. They've been added
locally and will be posted shortly. (Any others?)
-- Rod Adams
Re: Referencing a caller's slurpy array.
Luke Palmer wrote:
Rod Adams writes:
In S29, I currently have Cgrep as:
multi sub grep (Any|Junction $test : [EMAIL PROTECTED]) returns List {
gather {
for @values - $x {
take $x if $x ~~ $test;
}
}
}
That's the listop form. I was referring to the method form:
multi sub grep (@array: *code) returns List {
...
}
Got it. I'll be adding that form to various functions shortly.
Could I please get a list of what forms I need to be defining in S29?
Right now I have:
- General non-OO form.
- adverbial code block form (where applicable).
I haven't gotten a solid answer on when and how Perl will autogenerate
methods from subs.
For instance, would
@array.grep(/foo/);
generate a call to the list op Cgrep above, or do I need to be
defining another form of Cgrep that's more agreeable to
autogeneration? If so, what makes a sub more agreeable to auto method
generation?
-- Rod Adams
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On Wed, 2005-03-16 at 13:42 -0800, Brian Ingerson wrote: First off, thanks for your kind responses. I'm sure I just got confused by some web page I was looking at, and overwrote part of my stack that I'd just populated from the Kwid doc. And thanks also for pointing me to the Kwid docs where they live now. In short you don't need to worry about I[[ $foo[3] ]]. Since the ending marker is '/}', you only ever need to worry about escaping anything but '/}' itself. I might as well show how that would be done: We're suffering a major disconnect over the nature of bracketting. I see no reason to I[[ $foo[3] ]] at all. That would simply be I[$foo[3]] ... we are using a real parser here, no? I can't imagine basing this on some pile of regexps, and we all have matched the balanced brackets tools at our disposal, regardless of what parser / parser-generator we're using these days. Here's a simple Parse::RecDescent grammar for my proposal, so that we can talk about it in more reasonable terms. Please note that I'm TERRIBLE with P::RD, so I'm sure someone can figure out why I keep ending up with the string text_chunk in my resulting syntax tree ;-) See attached program and sample input. Just run parseajskwid.pl on ajskwid.kwid. For some reason Pod does not allow Ltext|url but there seems to be no obvious reason. (This is the the only major thing where Kwid strays from Pod's info model). That's not POD's info model, that's POD's implementation limitation. I am not certain what use case `L[...]` could get you that isn't already covered by `[...]`. I'm very happy with the modern Wiki convention (keep in mind, when we talk about Wiki, we're talking about something that's either nearly as old as or older than the Web, depending on what you count as it's birth) of using [...] as a sort of magical indexer. Like I said elsewhere, you might have: [Kwid] in your document. This is a hint that you expect there to be a thing named Kwid somewhere and you wish that somewhere to be applied thusly: L[Kwid|somewhere] in your document. Where L[Kwid] would simply fail because it is as strict as POD, and it won't find L[Kwid|perlkwid]. Other examples of this DWIMery: [http://www.perl.org/] = L[http://www.perl.org/|http://www.perl.org] [;-)] = =for html img src=winksmily.png alt=;-) / =for !html ;-) How, then do you differentiate: * Bullet list. 1. Numbered list. Other Term/definition lists [...] In Kwid, therefore, this: * Bullet list. + Numbered list. - Other Term/definition lists That was the answer I was looking for, thanks. I'm not thrilled with it (again, too many special characters that people might have thought they could get away with using in their documentation), but it's not too bad at all. Sorry, no access to IRC at work. If the specification of core pieces of P6 are being done off-list, why is there a list? Honestly this project was started as an /experiment/ and was not intended to distract p6l. Kwid requires no extra input from the language side as long as: =kwid ... =cut Well, look over AJS Kwid, and see what you think. The bullet syntax you give could work fine as a replacement for what I demonstrate, but I think everything else is pretty much 1:1. Now it's just a matter of: do you make it Wikiish or PODish? = AJS Kwid == Introduction Hello, and welcome to B[AJS Kwid], an experimental form of a proposed syntax and grammar for Perl 6 documentation. == Why Kwid? Kwid was originally proposed for several reasons, and I'll let the authors of that proposal speak for themselves. However, it has been selected as the basis of AJS Kwid for the following reasons: * It is much terser, while maintaining readability. * It maps closely to Wiki syntax, which is well known. * Some features (e.g. the C[[...]] linking) are more flexible. == Why AJS Kwid? AJS Kwid is an attempt to introduce a bit more I[PODishness] to the Kwid syntax. Not much of Kwid is changed in any real way, only the extent to which it closely resembles POD. === Was Kwid Broken? Not at all. Kwid was fine as is, when taken on its own. Only in terms of the human elements of POD compatibility was it problematic (that is, internally it was construct-for-construct, a complete POD replacement, but did not feel like POD, and thus the transition from Perl 5 would be even more jarring than Perl 6 is likely to make it). == AJS Kwid Elements The elements of AJS Kwid are fairly simple: =begin list * Newline (or CR/NL) separated lines * Empty lines are treated as paragraph breaks. * Each line can start with C[=], C[*], whitespace, or any text-component. **= C[=] Introduces a command. ***= C[=begin word] Begins a block of type word, which is ended with an C[=end word] line, later in the document. Such typed blocks must match up, so you have to end a C[=begin foo] with a C[=end foo]. ***= C[=[=...]] string Is a heading
return of copies vs references
I need some clarification on the semantics of subroutine or method return statements, regarding whether copies or references are returned. It will help me in my p6ification of p5 code. Say I had a class with 3 private attributes, named [$:foo, @:bar, %:baz], and I was making an explicit accessor for returning the full values of each. Take these 3 example method statements: return $self.foo; return $self.bar; return $self.baz; For each of the above cases, is a copy of or a reference to the attribute returned? For each, will the calling code be able to modify $obj's attributes by modifying the return values, or not? Going further, what is the exact syntax for each type of attribute to specify whether a copy or a reference is returned? In Perl 5, with the latter two, the difference was a return $bar vs return [EMAIL PROTECTED] for reference vs copy. I would like that Perl 6 is also at least as clearly disambiguated. Note that specifying this in the attribute definition isn't appropriate, since an attribute could just as easily be an array of arrays, or hash of hashes, and I am returning an inner array or hash that I either do or don't want to be modifiable by calling code. Separate question, just to confirm, I assume that plain '=' always does a copy? Thank you for any clarification. -- Darren Duncan
Re: s/true/better name/
Larry Wall wrote: On Wed, Mar 16, 2005 at 01:22:06PM -0600, Rod Adams wrote: : Larry Wall wrote: : : On Tue, Mar 15, 2005 at 12:28:15PM -0700, Marcus Adair wrote: : : Isn't saying false doesn't exist like saying, dark doesn't exist? : : Why have a word for that? : : : : I'm really afraid I'm missing something obvious here, but I'm worried : : that neither whether nor indeed work very well in many contexts. It : : seems to me that testing trueness exists in so many contexts that it's : : going to be hard to find an English word that fits all the important : : ones. : : Most of those contexts are implicitly boolean, and this function would : be redundant there. The main use for this function is to provide a : boolean context for its argument and return 0 or 1 when you really : do want 0 or 1 for some context that isn't directly boolean. This : is actually relatively rare. : : : Doesn't C +?(...) take care of those cases? : : Sure, it's line noise, but do we really need a new keyword for something : that's relatively rare? : Especially when that keyword is likely to confuse people a lot more than : the application of two unary operators? Well, sure, but by a similar argument we don't need not, and, or or either. Well, and and or serve the purpose of being at a much lower precedence level than and ||. I would see the value in alphabetic not as serving the same relation to !. But I would still see it returning a Bool, not a numified 0 or 1. I could see a boolean operator serving the same relation to ?. But for those cases where someone absolutely has to have a 1 or 0, not some Boolean object, sticking a + or int in front of a !, ?, not, or boolean seems to cover that case fine. I think an acknowledgement of its rarity could show up in making it something relatively long like whether. On the other hand, I have a linguistic problem with whether in that in English it seems to be looser than and, and or, while as a positive not in Perl, it would be classified as tighter. That is, $x = whether $a or $b; $x = not $a or $b; would actually be parsed as $x = whether($a) or $b; $x = not($a) or $b; whereas as a native English speaker would probably expect $x = whether($a or $b); You're going to have that problem with any word you come up with, given and and or's relationship with assignment. Unless you make the word magically alter the operator precedence table for any statement it's a part of... Which could happen if you make it a macro that adds some strategic parens for the user. But that jumps way over the least surprise line So I'm thinking we'll just go back to true, both for that reason, and because it does syntactically block the naughty meaning of true as a term (as long as we don't default true() to $_), as Luke reminded us. Wouldn't a warning cover that? -- Rod Adams
Re: return of copies vs references
Darren Duncan writes:
I need some clarification on the semantics of subroutine or method
return statements, regarding whether copies or references are
returned. It will help me in my p6ification of p5 code.
Say I had a class with 3 private attributes, named [$:foo, @:bar,
%:baz], and I was making an explicit accessor for returning the full
values of each.
Take these 3 example method statements:
return $self.foo;
return $self.bar;
return $self.baz;
For each of the above cases, is a copy of or a reference to the
attribute returned? For each, will the calling code be able to
modify $obj's attributes by modifying the return values, or not?
Well if you're making accessors, why the heck are you making them
private? But I can't really answer your question, because it depends on
how you write the accessors.
I'll answer your question by rephrasing it to use `$.foo`, [EMAIL PROTECTED],
`%.baz`. Assume they are all declared with `is rw`:
a) my $x = $obj.foo;
b) $obj.foo = $x;
d) my $ref = \$obj.foo;
e) $$ref = $x;
a) my @x = $obj.bar; # @x is now a copy, because = copies
b) @obj.bar = (1, 2, 3);
c) @obj.bar[2] = 3;
d) my $ref = $obj.bar;
e) @$ref = (1, 2, 3);
a) my %x = $obj.baz;
b) %obj.baz = (a = 1, b = 2);
c) %obj.baz{b} = 2;
d) my $ref = $obj.baz;
e) %$ref = (a = 1, b = 2);
These are all legal. If you don't declare your attributes with `is rw`,
then the bs, cs (perhaps), and the es are illegal.
Now back to your question. You could write rw accessors for each of
your private variables that behave like the ones above like so:
sub foo() is rw { $:foo }
sub bar() is rw { @:bar }
sub baz() is rw { %:baz }
If you want to intercept the write and do something with it, you can do
this (see S06 for details):
sub foo() is rw {
new Proxy:
FETCH = sub ($self) { $:foo },
STORE = sub ($self, $val) {
say Setting to $val;
$:foo = $val;
};
}
Luke
Re: return of copies vs references
On Wed, Mar 16, 2005 at 09:49:47PM -0800, Darren Duncan wrote:
: I need some clarification on the semantics of subroutine or method
: return statements, regarding whether copies or references are
: returned. It will help me in my p6ification of p5 code.
:
: Say I had a class with 3 private attributes, named [$:foo, @:bar,
: %:baz], and I was making an explicit accessor for returning the full
: values of each.
I am assuming you're talking about read-only accessors, not rw accessors.
: Take these 3 example method statements:
:
: return $self.foo;
: return $self.bar;
: return $self.baz;
Those would have to be:
return $self.:foo;
return $self.:bar;
return $self.:baz;
or
return $:foo;
return @:bar;
return %:baz;
: For each of the above cases, is a copy of or a reference to the
: attribute returned?
Perl 5 always makes a copy of return values, but that just turns
out to not matter for references, since a copy of a reference is as
good as the original reference. Perl 5 also propagates scalar/list
context into subs. For $:foo it doesn't matter--it always behaves
as a scalar value even in list context. In list context, @:bar and
%:baz should probably return copies of their values much like they
do in Perl 5, (or more likely, some kind of lazy COW reference that
can lazily interpolate into the surrounding lazy list context).
Whether $self.:bar and $self.:baz should behave the same is an
interesting question. They *look* scalar, so maybe they should imply
reference return, and you'd have to say
return $self.:bar[];
return $self.:baz{};
to get the equivalent of
return @:bar;
return %:baz;
But bare
return $self.:bar;
return $self.:baz;
would be equivalent to:
return \@:bar;
return \%:baz;
But I could argue it the other way too.
: For each, will the calling code be able to
: modify $obj's attributes by modifying the return values, or not?
The caller can modify the value only if an explicit ref is returned (or
the accessor is marked rw).
Where we seem to differ from Perl 5 is that in scalar context, a bare
array or hash automatically enreferences itself rather than returning
some kind of size. So in scalar context, it would seem that
return @:bar;
return %:baz;
and
return $self.:bar;
return $self.:baz;
are equivalent to:
return \@:bar;
return \%:baz;
(Again, $:foo is never a problem unless it's already a reference.)
So the issue is whether this interpretation will encourage people to
accidentally
return references to things they didn't want to give write access to. On the
other hand, making the private methods context sensitive doesn't actually
seem to fix this particular problem, but just pushes it down one level into
the implicit accessor. Maybe we need to work something up where
references returned from read-only accessors are always COW references.
If we assume that [...] is lazy when it can be, then that would be saying that
scalar context forces
return @:bar;
to mean
return [@:bar];
and you'd have to write an explicit
return \@:bar;
to get around that. But that seems kind of hacky and special-casey.
On the other hand, there are going to be strong cultural forces
discouraging people from writing such accessors in the first place,
so maybe we just go ahead and let people return hard refs in scalar
context on the assumption they know what they're doing. I suspect
that most actual accessors to arrays and hashes will just look like
ordinary getter and setter methods with extra args for subscripts, or
will return an explicit proxy if they want to behave like an lvalue.
And in either of those cases, you don't try to return the entire
array or hash. So maybe we should settle for the clean but slightly
dangerous semantics here.
Except that we've defined default read-only accessors that would,
under the clean rules, give people automatic access to arrays and
hashes if called in scalar context. So I think we really only have
three options here for the public accessors:
Don't generate autogenerate accessors at all for arrays and hashes.
Generate array and hash accessors that refuse to work in scalar context.
Generate array and hash accessors that autocopy in scalar context.
Of those three, the last seems the most friendly.
: Going further, what is the exact syntax for each type of attribute to
: specify whether a copy or a reference is returned?
:
: In Perl 5, with the latter two, the difference was a return $bar vs
: return [EMAIL PROTECTED] for reference vs copy. I would like that Perl 6
: is also at least as clearly disambiguated.
If we go dwimmy rather than clean, and assume private array and
hash accessors always return refs, then these return refs from public
accessors:
return \$self.:foo; # in any context
return $self.:bar; # in any context
return $self.:baz; # in any context
return \$:foo; #
Re: return of copies vs references
On Wed, Mar 16, 2005 at 11:10:40PM -0800, Darren Duncan wrote: : When I last asked a related question here, I was told that simply : returning an attribute will allow the caller to modify the original : attribute by default. That used to be true for arrays and hashes, but I just changed my mind on it. (Scalars always copy.) : I wanted to make sure this didn't happen. It : is possible that there was a misunderstanding regarding the previous : question, and the default action is in fact a copy. See my other message--it should make you a little happier. I had not sufficiently thought through what would happen with autogenerated read-only accessors in scalar context. Larry
