pop, push, reverse, sort, and splice on a multidimensional array
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. I'm especially interested in hearing people's view on how Csplice should work with multi-dim arrays. -- Rod Adams
zip
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?
As a second matter, can you declare a type for the elements of a slurpy
array?
So far I have:
multi sub zip (Array [EMAIL PROTECTED]) returns List {
gather {
while any(@lists) {
for @lists - @list {
take shift @list;
}
}
}
}
But I can't tackle the lvalue problem.
btw, I'm defining the semantics of some of several functions by simply
supplying a reference implementation.
Re: [PROPOSAL] MMD: multi sub syntax
Bob Rogers [EMAIL PROTECTED] wrote: What if one wants the first and third arguments to be the invocants? Then the first syntax gives .sub foo @MULTI .invocant Integer a .param pmc b .invocant String c That should better be .sub foo @MULTI .invocant Integer a .invocant pmc b .invocant String c Invocants are positional arguments, there isn't a case where the first and the third are invocants in a Perl6 function signature. It of course boils down to the same, namely that the second argument is a wildcard (Perl6 Any) but it's for the dispatcher nethertheless a dispatch on three invocants. But it's not as obvious how to do that for the second one, unless you use pmc as the explicit type name for any: .sub foo multi(Integer, pmc, String) .param pmc a .param pmc b .param pmc c In that case the first syntax strikes me as cleaner . . . I'm not sure. But there is still another thingy. A12 allows multiple colons to separate invocant classes. If there is a tie, the secondary invocants are used as tie breakers, which could be written as: .sub foo multi(Integer, pmc: String) .param pmc a .param pmc b .param pmc c - try to dispatch on the first two types in the first place - if there is a tie, consider the type of the 3rd argument leo
Re: [perl #34373] [PATCH] Parrot 0.1.2 with MinGW32
François PERRAD [EMAIL PROTECTED] wrote: -win32-mingw +win32-mingw-gcc3.2.3 YYY - - YY/7 20050307 Just 7 failing can't be quite right, when all tests are failing that used dynamic loading. leo
Re: Auto generated methods (was Re:The S29 Functions Project)
Rod Adams [EMAIL PROTECTED] wrote:
Leopold Toetsch wrote:
the method call in PIR can be written as:
d = x.cos() # normal method call
d = Float.cos(x) # class method, argument shifted down
d = P6Num.cos(x) # same
d = cos x # PIR opcode syntax [1]
cos d, x # PASM opcode syntax [1]
There'll be a table of such builtins with name, namespace, signature, so
that the current opcodes can be transparently replaced by methods.
This looks like it's taking
multi method Num::cos (Num|Str +$base) returns Num
and generating
multi sub cos (Num $x, Num|Str +$base) returns Num
No. The above lowlevel Ccos isn't aware of Cbase nor of C$_ and
nothing is autogenerated in Parrot. The Ccos is something like:
class __parrot_core::Float {
multi sub cos(Float x) returns Float ...
}
This is presumably inherited by Cclass P6Num (the Parrot PMC) and
bound to:
multi sub *cos(Num $x) returns Num
at the Perl6 level.
leo
Re: Calling PIR from a PMC
William Coleda [EMAIL PROTECTED] wrote: 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
Re: Auto generated methods (was Re:The S29 Functions Project)
Leopold Toetsch wrote:
No. The above lowlevel Ccos isn't aware of Cbase nor of C$_ and
nothing is autogenerated in Parrot. The Ccos is something like:
class __parrot_core::Float {
multi sub cos(Float x) returns Float ...
}
This is presumably inherited by Cclass P6Num (the Parrot PMC) and
bound to:
multi sub *cos(Num $x) returns Num
at the Perl6 level.
That's all fine for the Parrot side of things, AFAICT.
But it doesn't answer my question about how Perl is going to
autogenerate methods, as alluded to in A/S12, and Larry's previous post.
For now, I'm assuming that I can define just the base multi sub, without
all the associated multi methods
-- Rod Adams
s/true/better name/
In #perl6, Freenode, after again having to explain that true is the opposite of not and NOT the value for true, and that false doesn't exist, and that the real true value is bool::true and shouldn't be used much, and that no, it isn't true, and no, true doesn't always return bool::true, but despite its name can also return bool::false, and then explaining everything again, we kind of agreed that true is a misleading name. In my opinion, it's the biggest violation of the whole least surprise thing in Perl 6's current design. Autrijus suggested indeed or id, of which I like indeed better, because I'd like to continue using id with databases. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: [Pugs] Closing a file handle surprised the heck out of me
[EMAIL PROTECTED] wrote: On the other hand, we can alternatively specify that closing a file handle must force all thunks associated to it, i.e. in this case fill @lines with real data. Pugs can do that just fine, but I have no idea how parrot is to achieve that... But it gets worse. my $lines = [ =$fh ]; seek($fh, 0); my $lines2 = [ =$fh ]; close $fh; $lines2 must somehow remember that seek has happened. Miro
Re: bad file line breaks (was Re: Call for p6ification: Algorithm::Dependency)
You are right, they _SHOULD_ have been Unix line-breaks. I'm not sure how or why they ended up going in as Win32. But I'll look into it. Thanks. Adam Darren Duncan wrote: At 1:09 AM +1100 3/14/05, Adam Kennedy wrote: At the request of Autrijus, I've just checked the P5 current version of Algorithm::Dependency into pugs, and now we need volunteers to P6ify it. As a reminder to those of you for whom it isn't common sense, the standard way to distribute code on the internet involves having all of your files encoded using UNIX line-breaks (not DOS/Windows, not MAC OS 9). All of the Algorithm::Dependency files had DOS linebreaks, and my first commit of them mainly involved changing them to UNIX linebreaks. They should have been UNIX at the initial checkin of the Perl 5 code. I made very few other changes in this commit (just #! and etc), and I made them prior to discovering the linebreak problems. Since any further changes will be a separate commit, it will be easier to see what changes were made between versions. -- Darren Duncan
Behavior of PAST compiler
Hi, I have been adding a PIR implementation and three 'Hello World' tests to 'languages/parrot_compiler'. Code is taken from STDIN, compiled by a builtin compiler, and the resulting Eval PMC is invoked. This works as expected for PASM and PIR. For PAST, Parrot abstract syntax tree as simple text, I get behavior that I don't understand: cd languages/parrot_compiler/ make make test cd ../../ ./parrot languages/parrot_compiler/parrot_compiler.imc --language=PAST languages/parrot_compiler/t/basic/hello_3.code ./parrot languages/parrot_compiler/parrot_compiler.pbc --language=PAST languages/parrot_compiler/t/basic/hello_3.code Calling 'parrot_compiler.imc' gives the expected result Hello Pirate. Calling 'parrot_compiler.pbc' seems to print the generated PASM code. It looks like the compiled sub knows whether it is being rum by PIR or by PBC. Is that that the intended behavior? CU, Bernhard -- /* [EMAIL PROTECTED] */ SMS bei wichtigen e-mails und Ihre Gedanken sind frei ... Alle Infos zur SMS-Benachrichtigung: http://www.gmx.net/de/go/sms
Re: s/true/better name/
On Tue, Mar 15, 2005 at 10:51:57 +0100, Juerd wrote: Autrijus suggested indeed or id, of which I like indeed better, because I'd like to continue using id with databases. whether? -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me beats up some cheese: neeyah! pgpPBNe8zbDvF.pgp Description: PGP signature
Re: [perl #34430] [PATCH] MRO breaks Tcl
Will Coleda [EMAIL PROTECTED] wrote: Attached is a patch that allows (cd languages/tcl make test) to work again. Looks like an unguarded access in MRO. Didn't self apply so Leo could poke at it, in case the tcl pmcs are exploiting a hole in pmc2c2.pl. The CTclObject is defined as an abstract class, i.e. it has no VTABLE. Per convention, such abstract classes should be lower case. Is there a specific reason that it's an abstract PMC? I tried to get rid of abstract noinit in that PMC, which produced these failing tests: cmd_break.t 1 256 21 50.00% 2 cmd_continue.t1 256 21 50.00% 2 cmd_linsert.t 4 1024 54 80.00% 1 3-5 cmd_string.t 6 1536356 17.14% 26-27 29-31 34 leo
Re: Namespaces
Leopold Toetsch [EMAIL PROTECTED] wrote: t/pmc/namespace.t Please have a look at the supported syntax constructs. Are these sufficient for HLL writers? Some more thoughts WRT namespaces. We can define a namespace, where a function or method is stored: .namespace [Foo] .sub bar ... This does effectively (during bytecode loading) store_global Foo, bar, pmc_of_sub_bar where the Cpmc_of_sub_bar is living in the constant table. The general way (and the only one, if the function is in another bytecode segment), to call the function, is: $P0 = find_global Foo, bar $P0() Ok so far. But what happens, if the PIR file contains just a plain bar() The implementation looks into the current namespace and then in other namespaces present in the compiled source file, which seems to be quite wrong to me. Below is a test program [1] that shows how it's working now. The opcode to get at the sub bar is: set_p_pc $P0, bar where the symbol bar (the PMC constant of the sub) is located in the source file. The Cbar() shorthand call syntax could now look into the current namespace only. But that seems to restricted to me - or it would make the shortcut almost useless. I think that the Cbar() shortcut should emit a new opcode: $P0 = find_name bar or maybe: $P0 = HLL.find_name(bar) # HLL := a Perl6, Python, ... PMC The Cfind_name opcode could now look into the current lexicals, the current namespace aka package, the globals, and finally into the builtins in that order. Further: to be able to search the current package namespace, the interpreter has to know, in which namespace it's currently executing. This is also needed for MMD function search. To achieve that, all subroutines would need to remember their namespace and when calling the sub, that namespace could be placed into the interpreter context. Comments very welcome, leo [1] $ cat s.imc .namespace [Main] # try it with and w/o this line .sub main @MAIN print calling foo\n foo() print calling Foo::foo\n $P0 = find_global Foo, foo $P0() print calling baz\n baz() .end .sub foo print foo\n bar() .end .sub bar print bar\n .end .sub fie print fie\n .end .namespace [Foo] .sub foo print Foo::foo\n bar() fie() .end .sub bar print Foo::bar\n .end .sub baz print Foo::baz\n .end $ parrot s.imc calling foo foo bar calling Foo::foo Foo::foo bar # or Foo::bar fie calling baz Foo::baz
Re: Parrot 0.1.2 with MinGW32 (some experimets)
Michal Jurosz [EMAIL PROTECTED] wrote:
TortoiseCVS patch file attached.
SKIP: {
[ ... ]
-}
Please always test your patches.
Thanks, applied.
leo
Re: Parrot 0.1.2 with MinGW32 (some experimets)
# --- Some other ideas: ---
$ perl -e print $^O
msys
--- config\init\hints.pl
sub runstep {
+ my $O = lc($^O);
+ $O = 'mswin32' if $O =~ /^(msys|mingw)/;
- my $hints = config/init/hints/ . lc($^O) . .pl;
+ my $hints = config/init/hints/ . $O . .pl;
This would make MinGW in all aspects identical to a native window build,
wouldn't it? Seems dangerous.
When I follow the instructions what I've published in parrot/README.win32,
the builded perl program gives :
$ perl -e print $^O
MSWin32
For me, mingw is not a platform (MSWin32 and cygwin are a platform), just
the GCC compiler under MSWin32.
$mingw = ($^O eq 'MSWin32' and $Config{cc} eq 'gcc')
So, the case $is_mingw in config/init/hints/mswin32.pl is the good way to
handle this compiler.
Francois Perrad.
S pozdravem Michal Jurosz
Thanks for the detailed report,
It would be great if folks with windows installed could have a look at
these issues.
leo
Parrot_Exec_OS_Command interface ?
When I analyse the failure of t/pmc/sys.t with MinGW32, I see that this script generates a command depending of the OS on MSWin32, cmd = .\parrot temp.imc on *nix, cmd = ./parrot temp.imc (So with MinGw, the generation of Makefile needs /, and the execution needs \) The bug can be fixed in ConfigureLand or in Parrot_Exec_OS_Command function. And the dilemma is : the interface of Parrot_Exec_OS_Command is OS native command as now, or is OS independent, like open dirname/filename Francois Perrad.
test logging
I think it would be really nice for failed, todo, and skipped tests to
log their $expected and $got values, with any $desc or $context
information to a log file (probably test.log).
I also think it would be very nice to be able to use other operators,
such as gt, lt, or isa.
is($got, $expected, $desc, operator = 'gt');
Or something like that.
Anyway, I was just trying to implement logging to a file, first. But I
keep running into errors. At this point, I don't know if it is my bad
perl6 or pugs sand pits.
This is the error I am getting:
$ pugs -c ext/Test/lib/Test.pm
*** Error:
unexpected s
expecting adverb, term postfix, operator, postfix conditional, ternary
conditional, ;, } or end of input
at ext/Test/lib/Test.pm at line 105, column 1
A gentle prod in the right direction would be appreciated.
The line 105 refers to the 'sub write_log' line.
This is what I'm trying to add to Test.pm:
my $log_file = '';
sub log_file (Str $filename) returns Str is export {
$log_file = $filename;
return $log_file;
}
sub write_log (+$got, +$expected, Str +$desc, Str +$errstr, Str +$context, Str
+$operator = 'eq') returns Bool {
# return 0 but true unless $log_file; # not yet implemented
return 1 unless $log_file;
# until we have 'given'/'when'
my $status = 'FAILED';
if (index($?CALLER::CALLER::SUBNAME, 'todo') = 0) {
$status = 'TODO';
} elsif (index($?CALLER::CALLER::SUBNAME, 'skip') = 0) {
$status = 'SKIPPED';
}
if (my $out = open($log_file)) {
$out.say $?CALLER::CALLER::FILE ~ $loop $status;
$out.say $desc if $desc;
$out.say $errstr if $errstr;
$out.say $context if $context;
$out.say '### Expected ###';
$out.say $expected;
$out.say '### Actual Results ###';
$out.say $got, \n;
$out.close;
return 1;
}
return 0;
}
Thank you,
-kolibrie
Re: test logging
On Mar 15, 2005, at 6:45 AM, Nathan Gray wrote:
I think it would be really nice for failed, todo, and skipped tests to
log their $expected and $got values, with any $desc or $context
information to a log file (probably test.log).
I also think it would be very nice to be able to use other operators,
such as gt, lt, or isa.
is($got, $expected, $desc, operator = 'gt');
Personally, I think a more familiar form, like Test::More::cmp_ok would
be better.
cmp_ok($got, 'gt', $expected, $desc);
It should be easy enough to implement.
- Stevan
Or something like that.
Anyway, I was just trying to implement logging to a file, first. But I
keep running into errors. At this point, I don't know if it is my bad
perl6 or pugs sand pits.
This is the error I am getting:
$ pugs -c ext/Test/lib/Test.pm
*** Error:
unexpected s
expecting adverb, term postfix, operator, postfix conditional,
ternary conditional, ;, } or end of input
at ext/Test/lib/Test.pm at line 105, column 1
A gentle prod in the right direction would be appreciated.
The line 105 refers to the 'sub write_log' line.
This is what I'm trying to add to Test.pm:
my $log_file = '';
sub log_file (Str $filename) returns Str is export {
$log_file = $filename;
return $log_file;
}
sub write_log (+$got, +$expected, Str +$desc, Str +$errstr, Str
+$context, Str +$operator = 'eq') returns Bool {
# return 0 but true unless $log_file; # not yet implemented
return 1 unless $log_file;
# until we have 'given'/'when'
my $status = 'FAILED';
if (index($?CALLER::CALLER::SUBNAME, 'todo') = 0) {
$status = 'TODO';
} elsif (index($?CALLER::CALLER::SUBNAME, 'skip') = 0) {
$status = 'SKIPPED';
}
if (my $out = open($log_file)) {
$out.say $?CALLER::CALLER::FILE ~ $loop $status;
$out.say $desc if $desc;
$out.say $errstr if $errstr;
$out.say $context if $context;
$out.say '### Expected ###';
$out.say $expected;
$out.say '### Actual Results ###';
$out.say $got, \n;
$out.close;
return 1;
}
return 0;
}
Thank you,
-kolibrie
Re: Parrot 0.1.2 with MinGW32 (some experimets)
François PERRAD wrote:
When I follow the instructions what I've published in parrot/README.win32,
the builded perl program gives :
$ perl -e print $^O
MSWin32
For me, mingw is not a platform (MSWin32 and cygwin are a platform),
just the GCC compiler under MSWin32.
$mingw = ($^O eq 'MSWin32' and $Config{cc} eq 'gcc')
So, the case $is_mingw in config/init/hints/mswin32.pl is the good way
to handle this compiler.
README.win32: As Configure.pl extracts configuration from the perl
program, first build/install perl with MinGW (no binary distribution
available).
But more obtainable/common are:
# run: cmd.exe
C:\perl -e print $^O
MSWin32
C:\perl -v
This is perl, v5.8.4 built for MSWin32-x86-multi-thread
Binary build 810 provided by ActiveState Corp.
C:\set PATH=%PATH%;C:\mingw\bin
C:\gcc -v
gcc version 3.2.3 (mingw special 20030504-1)
# run: C:\msys\msys.bat
$ perl -e print $^O
msys
$ perl -v
This is perl, v5.6.1 built for msys
$ which gcc
/mingw/bin/gcc
$ gcc -v
gcc version 3.2.3 (mingw special 20030504-1)
# run C:\cygwin\cygwin.bat
$ perl -e print $^O
cygwin
$ perl -v
This is perl, v5.8.6 built for cygwin-thread-multi-64int
$ which gcc
/usr/bin/gcc
$ gcc -v
gcc version 3.3.3 (cygwin special)
See attached win32-env.txt for full listings.
I was thinking about merge cygwin.pl with mswin32.pl.
my $O = lc($^O);
$O = 'mswin32' if $O =~ /^(msys|cygwin)/;
my $hints = config/init/hints/ . $O . .pl;
See attached mswin32.pl
See also http://xrl.us/fddn (MJWiki:Build Parrot with MinGW)
S pozdravem Michal Jurosz
C:\usrperl -e print $^O
MSWin32
C:\usrperl -v
This is perl, v5.8.4 built for MSWin32-x86-multi-thread
(with 3 registered patches, see perl -V for more detail)
Copyright 1987-2004, Larry Wall
Binary build 810 provided by ActiveState Corp. http://www.ActiveState.com
ActiveState is a division of Sophos.
Built Jun 1 2004 11:52:21
Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.
Complete documentation for Perl, including FAQ lists, should be found on
this system using `man perl' or `perldoc perl'. If you have access to the
Internet, point your browser at http://www.perl.com/, the Perl Home Page.
C:\set PATH=%PATH%;C:\mingw\bin
C:\usrgcc -v
Reading specs from C:/mingw/bin/../lib/gcc-lib/mingw32/3.2.3/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=
mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable
-languages=c++,f77,objc --disable-win32-registry --disable-shared --enable-sjlj-
exceptions
Thread model: win32
gcc version 3.2.3 (mingw special 20030504-1)
#
msys
This is perl, v5.6.1 built for msys
Copyright 1987-2001, Larry Wall
Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.
Complete documentation for Perl, including FAQ lists, should be found on
this system using `man perl' or `perldoc perl'. If you have access to the
Internet, point your browser at http://www.perl.com/, the Perl Home Page.
/mingw/bin/gcc
Reading specs from c:/mingw/bin/../lib/gcc-lib/mingw32/3.2.3/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=
mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable
-languages=c++,f77,objc --disable-win32-registry --disable-shared --enable-sjlj
-exceptions
Thread model: win32
gcc version 3.2.3 (mingw special 20030504-1)
#
C:\cygwinperl -e print $^O
cygwin
C:\cygwinperl -v
This is perl, v5.8.6 built for cygwin-thread-multi-64int
Copyright 1987-2004, Larry Wall
Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.
Complete documentation for Perl, including FAQ lists, should be found on
this system using `man perl' or `perldoc perl'. If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.
C:\cygwinwhich gcc
/usr/bin/gcc
C:\cygwingcc -v
$ ./env.bat 21 des
Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/specs
Configured with: /gcc/gcc-3.3.3-3/configure --verbose --prefix=/usr --exec-prefi
x=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/s
hare/man --infodir=/usr/share/info --enable-languages=c,ada,c++,d,f77,java,objc,
pascal --enable-nls --without-included-gettext --enable-libgcj --with-system-zli
b --enable-interpreter --enable-threads=posix --enable-java-gc=boehm --enable-sj
lj-exceptions --disable-version-specific-runtime-libs --disable-win32-registry
Thread model: posix
gcc version 3.3.3 (cygwin special)
{
my %args;
@[EMAIL PROTECTED]@_;
my($cc, $ccflags,
[RFC] Test::Plan
hi all :) following up on the discussion from a few months ago but renewed over the weekend, here is Test::Plan. basically all it does is carry over the exact syntax and helper functions we are already using in Apache-Test land to the greater community. I'm still working up additional tests, but the documentation and functionality is all there, so constructive feedback welcome. http://www.modperlcookbook.org/~geoff/modules/Test-Plan-0.01.tar.gz --Geoff
Re: Behavior of PAST compiler
Bernhard Schmalhofer [EMAIL PROTECTED] wrote: Hi, ./parrot languages/parrot_compiler/parrot_compiler.pbc --language=PAST languages/parrot_compiler/t/basic/hello_3.code Calling 'parrot_compiler.pbc' seems to print the generated PASM code Yes. When you run the .imc version of the program, Cemit_open is called in imcc/main.c:526, which sends the output to the to be generated PBC. If you run the .pbc version of your compiler, the emit_open() function isn't executed and the default emitter (number 0) is used, which produces assembly listings (as parrot -o- does). Is that that the intended behavior? The problem is that such output options can't be passed on to secondary compile runs. They use just what imcc/main used. We probably need a scheme to pass options from the Ccompile opcode to the compiler. CU, Bernhard leo
Re: Parrot 0.1.2 with MinGW32 (some experimets)
François PERRAD [EMAIL PROTECTED] wrote:
For me, mingw is not a platform (MSWin32 and cygwin are a platform), just
the GCC compiler under MSWin32.
$mingw = ($^O eq 'MSWin32' and $Config{cc} eq 'gcc')
So, the case $is_mingw in config/init/hints/mswin32.pl is the good way to
handle this compiler.
Ok. What about the reported problem that the object file ending
o = '.o'
has to be changed in the hints file?
Francois Perrad.
leo
Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)
On Mar 15, 2005, at 12:54 AM, Nigel Hamilton wrote: Hi Steven, Hello Nigel, I think one of the great features of JavaDoc is the ability to generate hyperlinked documentation - so someone can walk the inheritance/interface hierarchy within their browser. It also provides consistency across all Java packages. I agree. My only issue with Javadocs is that sometimes it is very easy to get lost, although one could argue that is a class hierarchy design problem and not a Javadoc problem :) 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. One of the things I liked about Ingy's Kwid idea was that, like a wiki, it is very easy to link. I have always liked the wiki idea of auto-discovered links (although some wiki implemenatation do it better than others). There is a need for a higher level 'structural' documentation that hypertext is well suited to cover - something that spans more than one module. This will be especially important for CPan6 and connecting versions, and modules into bigger 'packages'. Agreed as well. It would be nice if CPAN6 or CP6AN or FreePAN (or whatever it will eventually be called) have a more sophisticated linking/documentation system which goes beyond the actual single module. I even think this would be possible in the current CPAN if we could get the L construct fixed, but that is another issue. Ideally I think the documentation system should be as transparent as possible with the maximum of info found through introspection and a minimum of special tags provided by the programmer. Introspection is nice, but I disagree that documentation should be that transparent. One of the nice things I have found about perl and CPAN in particular is that many people tend to document their modules very well. Which not only includes information about method/function signatures, but also contains both example code and actual written documentation. The mini-articles many people write for the DESCRIPTION section can sometimes be much more informative than their individual method/function docs. besides I like writing documentation ;-) My suggestion is the documentation system should spit out traversable HTML that can be integrated into CPAN6 so as to provide a consistent http://perldoc.com-esque look and feel - that is mirrored in everyone's personal installation as well as on CPAN6. Well, not everyone likes HTML (although I can't imagine why). All that said I think a per-module perldoc documentation reader is still very important too ... maybe your design could allow for traversable HTML conversion in the future? Well my idea is to not dictate the eventual output. But to create a system which allows the most meta-data/contextual-information to be captured with the greatest of ease, and let the specific formatter decide how much information it wants and how to display and/or manipulate it. Thanks for your response and comments. -- Stevan Nige On Mon, 14 Mar 2005, Stevan Little wrote: Gang, My proposal is for an extensible version of POD. Basically what XML is to HTML/SGML, this will be for POD. This is a very very very rough draft. I am submitting it in hopes of getting some basic feedback on the idea to see if I should carry it any further or not. So please if you have an opinion on this, either positive or negative, please chime in and let me know. If nothing more I am hoping this might bring the debate over the future of POD (or Kwid) out of the more transient #perl6 and into the more concrete world of email as I think there are currently too many opinions and not enough dialog. - Stevan (p.s. - I apologize in advance if my ideas sound a little jumbled together, remember,.. this is very very rough) INTRODUCTION There has been a lot of chatter on #perl6 about POD vs. Kwid and how best to do this and that, etc. etc. etc. and so on and so forth. It seems to me that we will never be able to create a documentation format which will make everyone happy in all cases. But my question really is, why should we? Just as with HTML, at some point the formatting information overtakes the data being displayed and the data no longer has any real meaning in relation to the markup around it. IMO, POD (and Kwid) are both too formatting centric, and while much simpler than HTML, suffer on some level from the same problem. The early promise of XML was that data and
Re: Module popularity
cpanratings.perl.org? Ian Langworth wrote: Fair enough. On Tue, 15 Mar 2005 00:37:26 -0600, Andy Lester [EMAIL PROTECTED] wrote: I'd rather it didn't. What people think of as popularity is not what Phalanx measures. Let's not stir the mud.
Re: [RFC] Test::Plan
Rock!
First, just a nitpicky thing -- You could simplify Makefile.PL to not
need File::*:
WriteMakefile(
...
test = { TESTS = join ' ', map { glob } qw( t/*/*.t t/*/*/*.t ) },
...
);
Also, I agree that the use-Test-Plan-after-Test-More caveat is icky.
How about modifying Test::Plan::import() so that it (a) checks to see
if Test::More *has* already been loaded or (b) checks if a plan()
subroutine is already defined in the namespace that the method is
exporting to.
On Tue, 15 Mar 2005 09:17:22 -0500, Geoffrey Young
[EMAIL PROTECTED] wrote:
I'm still working up additional tests, but the documentation and
functionality is all there, so constructive feedback welcome.
--
Ian Langworth
Project Guerrilla
Northeastern University
College of Computer and Information Science
int(0x123) == int(0x123) ?
Currently Pugs numifies hexadecimal and octal strings as if they are literals; that means 0x123 and 0o456 all work as expected. Is that an acceptable treatment? What about Inf and NaN in numeric context? Thanks, /Autrijus/ pgp11vtHJMLL9.pgp Description: PGP signature
Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)
Stevan Little writes: Introspection is nice, but I disagree that documentation should be that transparent. One of the nice things I have found about perl and CPAN in particular is that many people tend to document their modules very well. Which not only includes information about method/function signatures, but also contains both example code and actual written documentation. The mini-articles many people write for the DESCRIPTION section can sometimes be much more informative than their individual method/function docs. I agree. I think the biggest mistake Perl 6's documentation system could make is to make it Javadoc-style automatic. This is one of those weird, backwards, cultural decisions, where we actually want to make the programmer's life a little harder. When I (seldomly) progam in Java, I find it very hard to use any libraries, because all the libraries have good method-level documentation, but none of them has good interface (conceptual, not Cinterface)-level documentation. I basically have to understand how the library author organized his code in order to use his library. On the other hand, Perl has this wonderful module idiom of SYNOPSIS and DESCRIPTION. SYNOPSIS generally shows you how a very small program would use the library (the thing Java libraries are missing), and DESCRIPTION goes in detail about the things you need to know. The things you don't need to know you can get by reading the code. If you give people Javadoc-style documentation, they can feel like they've documented their module that way, and feel that it's not necessary to do any more. I probably would. Luke
Re: test logging
Stevan Little writes: On Mar 15, 2005, at 6:45 AM, Nathan Gray wrote: I think it would be really nice for failed, todo, and skipped tests to log their $expected and $got values, with any $desc or $context information to a log file (probably test.log). I also think it would be very nice to be able to use other operators, such as gt, lt, or isa. is($got, $expected, $desc, operator = 'gt'); Personally, I think a more familiar form, like Test::More::cmp_ok would be better. cmp_ok($got, 'gt', $expected, $desc); It should be easy enough to implement. And of course in Perl 6, you can do that with: cmp_ok($got, infix:gt, $expected, $desc); So that you can use operators which a) aren't infix, or b) implemented locally. Luke
Re: [RFC] Test::Plan
test = { TESTS = join ' ', map { glob } qw( t/*/*.t t/*/*/*.t ) },
but slashes aren't portable, right? I don't think you can get rid of
File::Spec.
Also, I agree that the use-Test-Plan-after-Test-More caveat is icky.
well, it's a caveat, not a requirement :)
the way it works now is that either you load Test::More first and subvert it
with Test::Plan (as I show) or you load Test::Plan first, which successfully
takes over main::plan, then you load Test::More and boom, Test::More
complains about redefining symbols. which is quite normal, actually, when
using modules with like-named functions and Exporter - nothing new in
perl-land. the difference here is that Test::Plan provides some sugar so
you don't need to worry about doing that, provided you load it last.
How about modifying Test::Plan::import() so that it (a) checks to see
if Test::More *has* already been loaded or (b) checks if a plan()
subroutine is already defined in the namespace that the method is
exporting to.
hmm, maybe I'm misunderstanding but neither of those situations are helpful
- Test::Plan::plan() needs to be the one and only plan() for people to use
it as a drop-in replacement - I explicitly don't want to bail if either a)
or b) is true, I want the main::plan() namespace no matter what.
fwiw, I'm not trying to be defensive about this, and I appreciate the
feedback. I was only trying to provide an elegant solution so that test
writers didn't need to worry so much about competing function names.
--Geoff
Re: int(0x123) == int(0x123) ?
Autrijus Tang writes: Currently Pugs numifies hexadecimal and octal strings as if they are literals; that means 0x123 and 0o456 all work as expected. Is that an acceptable treatment? What about Inf and NaN in numeric context? If we follow Perl 5's lead, they all numify to zero (generalizing for Inf and NaN). Of course, we could afford to get stricter about numeric prefix numification, and if we did that, then we could make them work correctly. Personally, I'd like to see C+345abc be an error, and allow a function that extracts a numeric prefix. Luke Thanks, /Autrijus/
Re: test logging
On Mar 15, 2005, at 10:32 AM, Luke Palmer wrote:
Stevan Little writes:
On Mar 15, 2005, at 6:45 AM, Nathan Gray wrote:
I think it would be really nice for failed, todo, and skipped tests
to
log their $expected and $got values, with any $desc or $context
information to a log file (probably test.log).
I also think it would be very nice to be able to use other operators,
such as gt, lt, or isa.
is($got, $expected, $desc, operator = 'gt');
Personally, I think a more familiar form, like Test::More::cmp_ok
would
be better.
cmp_ok($got, 'gt', $expected, $desc);
It should be easy enough to implement.
And of course in Perl 6, you can do that with:
cmp_ok($got, infix:gt, $expected, $desc);
So that you can use operators which a) aren't infix, or b) implemented
locally.
So if I understand you correctly, then the implementation code would
look something like this right?
sub cmp_ok (Str $got, Code $comparison_func, Str $expected, Str ?$desc)
returns Bool is export {
my $test := $comparison_func($got, $expected);
}
- Stevan
Luke
Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)
All that said I think a per-module perldoc documentation reader is still very important too ... maybe your design could allow for traversable HTML conversion in the future? Well my idea is to not dictate the eventual output. But to create a system which allows the most meta-data/contextual-information to be captured with the greatest of ease, and let the specific formatter decide how much information it wants and how to display and/or manipulate it. Thanks for your response and comments. Sounds likes a plan! :-) I see documentation generation as another type of compiler. Instead of the computer being the target audience it's human beings. Writing a compiler for targeting humans has much of the same problems. A human has limited memory, it should be able to link in a new module quickly, and we want the transfer of ideas to be as quick as possible. +=== ByteCode Perl6 Source = Compiler = | +=== HumanCode Maybe your documentation compiler can take source, distill all the good bits for human consumption and then this intermediate 'bytecode' is translated into different target presentation formats - which is pretty much what you're suggesting. Perl 6 Source = Documentation Compiler = Good Bits = HTML (code browsing / CPAN) = txt (perldoc) = PDF (management) But I think a compilation step may be needed to gather as much intelligence about the code as possible. NIge
Re: test logging
Stevan Little writes:
So if I understand you correctly, then the implementation code would
look something like this right?
sub cmp_ok (Str $got, Code $comparison_func, Str $expected, Str ?$desc)
returns Bool is export {
my $test := $comparison_func($got, $expected);
}
Umm, except for the :=, I think that's right. And I think the := is
right too, but it's awkward. Maybe. So, sure, that's right.
And currently in pugs, you'd call it like:
cmp_ok(3, infix:gt, 2, 3 2);
That is, pugs doesn't grok the infix:operator syntax yet.
Luke
Re: int(0x123) == int(0x123) ?
On Tue, Mar 15, 2005 at 08:35:54AM -0700, Luke Palmer wrote: Autrijus Tang writes: Currently Pugs numifies hexadecimal and octal strings as if they are literals; that means 0x123 and 0o456 all work as expected. Is that an acceptable treatment? What about Inf and NaN in numeric context? If we follow Perl 5's lead, they all numify to zero (generalizing for Inf and NaN). In absence of anything to the contrary in the synopses/apocalypses, string numification should work as it does in Perl 5. In other words, all of the above are zero, and we only numify leading digits as decimal numbers. FWIW, I ran into a similar problem with Inf in some PHP programming I did a year or so ago. The question is, how does the string Information numify? Just as 8abcde numifies to 8, PHP took the approach that Information numifies to Inf. (Actually, it was worse than this, as someone decided that Inf should not numify, so they did a string comparison for Inf and had it return zero, thus Inf returned zero while Info returned Inf. Sigh.) Perl 5's approach, while somewhat controversial, does at least have the advantage of being consistent and reducing the number of surprises. And from a compiler writing perspective, we'll follow the spec as it's written until/unless p6l changes them. Of course, we could afford to get stricter about numeric prefix numification, and if we did that, then we could make them work correctly. Personally, I'd like to see C+345abc be an error, and allow a function that extracts a numeric prefix. Instead of an error, how about a warning? Pm
Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)
Without commenting on the merits of any of the proposals, I'll note that discussions about changing POD are probably design-level discussions that belong on p6l instead of p6c (which are implementation decisions). I don't mind if it's discussed here, but p6c is really the forum for how do we implement XYZ and not what should XYZ be? Pm On Tue, Mar 15, 2005 at 09:23:45AM -0600, Nigel Hamilton wrote: All that said I think a per-module perldoc documentation reader is still very important too ... maybe your design could allow for traversable HTML conversion in the future? Well my idea is to not dictate the eventual output. But to create a system which allows the most meta-data/contextual-information to be captured with the greatest of ease, and let the specific formatter decide how much information it wants and how to display and/or manipulate it. Thanks for your response and comments. Sounds likes a plan! :-) I see documentation generation as another type of compiler. Instead of the computer being the target audience it's human beings. Writing a compiler for targeting humans has much of the same problems. A human has limited memory, it should be able to link in a new module quickly, and we want the transfer of ideas to be as quick as possible. +=== ByteCode Perl6 Source = Compiler = | +=== HumanCode Maybe your documentation compiler can take source, distill all the good bits for human consumption and then this intermediate 'bytecode' is translated into different target presentation formats - which is pretty much what you're suggesting. Perl 6 Source = Documentation Compiler = Good Bits = HTML (code browsing / CPAN) = txt (perldoc) = PDF (management) But I think a compilation step may be needed to gather as much intelligence about the code as possible. NIge
Re: [Pugs] short-circuit operators
Hi, Andrew Savige wrote: The following program: my $x = 1; my $y = 2; $x == 1 or $y = 42; ^ typo? printx='$x' y='$y'\n; prints x='1' y='2' in perl5, but prints x='1' y='42' in pugs. using r763, it works correctly: $ ./pugs -we 'my $x = 1; my $y = 2; $x == 1 or $y == 42; say x=$x y=$y' x=1 y=2 --Ingo -- Linux, the choice of a GNU | Elliptic paraboloids for sale. generation on a dual AMD | Athlon!|
Re: test logging
On Tue, Mar 15, 2005 at 08:27:32AM -0500, Stevan Little wrote: On Mar 15, 2005, at 6:45 AM, Nathan Gray wrote: I also think it would be very nice to be able to use other operators, such as gt, lt, or isa. is($got, $expected, $desc, operator = 'gt'); Personally, I think a more familiar form, like Test::More::cmp_ok would be better. cmp_ok($got, 'gt', $expected, $desc); It should be easy enough to implement. Fair enough. That syntax is easier to read. In addition to adding functionality, I would like to avoid having to add subroutines. I think we need a subroutine for each of the following: compare two values skip test because of reason ignore failure because it's still todo Those three would all accept the same parameters, in the same order, so it would be very easy to change which subroutine we are calling. Those three could also handle every type of comparison, including comparison to truth if $expected was not passed in. Thinking out-loud, we could even remove the skip subroutine, and just pass the reason in as a named parameter 'skip'. ok($got, $expected, $desc, skip = $skip_test_if_true); But adding in an operator parameter could be more confusing than creating new subroutines for that purpose. So that would leave us with four subroutines: ok($got, $expected, $desc); todo($got, $expected, $desc); ok_cmp($got, $operator, $expected, $desc); todo_cmp($got, $operator, $expected, $desc); Each of these subroutines would take an optional named parameter 'skip', which if true, would skip the test, if false, would still test. I'm not sure how accurate it would be to compare a single value to truth, such as the current ok($got, $desc); becoming ok($got, true, $desc); That may be completely inaccurate. But if not, Oh the simplicity of it all! -kolibrie
Re: test logging
On Mar 15, 2005, at 10:53 AM, Nathan Gray wrote: On Tue, Mar 15, 2005 at 08:27:32AM -0500, Stevan Little wrote: On Mar 15, 2005, at 6:45 AM, Nathan Gray wrote: I also think it would be very nice to be able to use other operators, such as gt, lt, or isa. is($got, $expected, $desc, operator = 'gt'); Personally, I think a more familiar form, like Test::More::cmp_ok would be better. cmp_ok($got, 'gt', $expected, $desc); It should be easy enough to implement. Fair enough. That syntax is easier to read. In addition to adding functionality, I would like to avoid having to add subroutines. I disagree. I feel that testing is kind of another form of documentation. And the test function you choose helps to document your assumptions. Test code is not like regular code. IMO, test code should be as verbose and obvious as possible. So following that train of thought, the more specific individual test functions the better. I think we need a subroutine for each of the following: compare two values we already have is(), and then what you propose for cmp_ok(). skip test because of reason I don't know if we should skip because of the reason (assuming by reason you mean the $desc parameter). I say this because most of the time when doing a skip test, it is because something really won't compile, or makes a really big/bad error when you try to compile it. So to just add it as another parameter would defeat the purpose because it would blow up just trying the test anyway. But then to be honest, I almost never use skip(). In my mind it's either todo or not todo. ignore failure because it's still todo We already have this with the todo_is(), todo_ok(), todo_isa_ok() and todo_fail() functions. And then when we add cmp_ok() we will also add a todo_cmp_ok() function as well. Those three would all accept the same parameters, in the same order, so it would be very easy to change which subroutine we are calling. Those three could also handle every type of comparison, including comparison to truth if $expected was not passed in. snip That may be completely inaccurate. But if not, Oh the simplicity of it all! I am sorry, but I really don't like this idea at all. I think that will defeat the self-documenting nature of the tests. And while it might seem simpler in some ways, I think it will actually complicate things since it wont be immediately obvious (from the function used) what I am trying to compare/test. I also see very little reason to ever change the test routines being called except to change todo_something() to something(). Test writing is one place where I am really not at all concerned about programmer efficiency. In a way I think test writing *should* be tedious. - Stevan
Re: s/true/better name/
On Tue, Mar 15, 2005 at 10:51:57AM +0100, Juerd wrote: : Autrijus suggested indeed or id, of which I like indeed better, : because I'd like to continue using id with databases. id is too heavily overloaded with identifiers and identities and such. But indeed doesn't work right in context, while indeed... I'd go with either istrue or so. ok is another possibility, though that seems to connote definedness more than truth. Larry
Re: s/true/better name/
On Tue, Mar 15, 2005 at 08:23:19AM -0800, Larry Wall wrote: I'd go with either istrue or so. ok is another possibility, though that seems to connote definedness more than truth. Hmm, so is so good. So can we make it so? :) Thanks, /Autrijus/ pgpB1Zkr9MgHy.pgp Description: PGP signature
Re: s/true/better name/
Autrijus Tang skribis 2005-03-16 0:25 (+0800): On Tue, Mar 15, 2005 at 08:23:19AM -0800, Larry Wall wrote: I'd go with either istrue or so. ok is another possibility, though that seems to connote definedness more than truth. Hmm, so is so good. So can we make it so? :) So is great for Perl poetry too. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: s/true/better name/
On Tue, Mar 15, 2005 at 12:13:52PM +0200, Yuval Kogman wrote: : On Tue, Mar 15, 2005 at 10:51:57 +0100, Juerd wrote: : : Autrijus suggested indeed or id, of which I like indeed better, : because I'd like to continue using id with databases. : : whether? That's an interesting possibility, though I think about half the people would misspell it. Maybe that's a feature. It works well for: $yesno = whether any(@foo) == @any(@bar); I don't mind it being long. I should point out I'm rethinking the idea of whether or not whether and not should be list operators. not @foo would have unexpected consequences if it forces list context, so I think we better let people hyper those manually if needed. I think we can leave not at the precedence of list operators without actually making it one, but maybe we should make a separate precedence level for it to keep list op precedence pure. Larry
Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)
On Tue, 2005-03-15 at 09:37, Stevan Little wrote:
On Mar 15, 2005, at 12:54 AM, Nigel Hamilton wrote:
There is a need for a higher level 'structural' documentation that
hypertext is well suited to cover - something that spans more than one
module. This will be especially important for CPan6 and connecting
versions, and modules into bigger 'packages'.
Agreed as well. It would be nice if CPAN6 or CP6AN or FreePAN (or
whatever it will eventually be called) have a more sophisticated
linking/documentation system which goes beyond the actual single
module. I even think this would be possible in the current CPAN if we
could get the L construct fixed, but that is another issue.
Actually, I don't think that's at all another issue. It's the core of
what you're talking about. L gives you the ability to link, and in
several different ways. It's also broken in Perl 5, which makes a
replacement sound attractive, but fixing it solves for much of that
need.
Taking a cue from the wiki world makes sense to me. Kwid is almost ideal
as far as I can tell in that it:
a) Does everything POD does
b) Is backward compatible with Perl 5 in that it can be ignored by the
parser in the same way.
c) Makes many things easier
Now, it does need some tweaking, I think, but nothing too severe. It
just makes a few things harder, and a few other things non-POD-like for
no particular reason. I like CPOD for the ease of including keywords
in Cperl documentation. It's also Btrivial to Irecognize all
markup quickly (visually or programmaticly).
Kwid /on the other hand/ makes it a bit harder to [=find] that markup,
and is *thus* not quite as easy to de-parse visually.
I'd be thrilled if we just changed the .-introduced things to
=-introduced things:
= heading level 1
== heading level 2
=begin list
* You don't really need the begin
* But it doesn't hurt
* and it allows
some(code())
to appear inside a list item.
* Hmmm
=end list
And then replaced [...] and [=...] and /.../ and *...* with their more
POD-like: L[...], C[...], I[...] and B[...] with a bare [foo] working as
a I have no idea what I'm linking to, but do the right thing sort of
wikiness, where L[...] is a more structured, POD-like link. For example:
= Proposed Kwid Changes
== Introduction
It is my I[goal] to introduce an easier to use (for [POD] users)
version of [Kwid], and impose it B[mercilessly] on the heathen
masses!
Markup can consist of C[[]]-delimited text such as C[[Kwid]] or
a prefixed C[[]]-delimited text such as C[C[Kwid]]. Possible
prefixes are:
=begin list
*= L
A structured link ala POD C[L]
*= B, I
Bold or italics
*= C
Code
=end list
Anywhere a C[[]] can be used, a C[{}] can also be used. This is
useful when you need to enclose unbalanced C[{], C[}], C{[},
or C{]} characters.
All formatting is introduced with C[=for] just as in POD, so:
=for html hr /
works as you might expect. C[=begin] is similar, but introduces
a block, ended by C[=end]
=for html,xhtml,xml img src=foo.png alt=A foo! /
=begin !html,xhtml,xml
You can't see the image, but it would be pretty!
=end !html,xhtml,xml
Notice the use of C[!format[,format...]] to indicate all formats
not listed.
comment is the null format, so you can always introduce a
C[=for comment] or C[=begin comment], but lines which start with
C[#] are always treated as comments anyway.
Lists are introduced with C[=begin list], which is a special
format. A list can be numbered, bulletted or defintion-style.
Each type is introduced differently, e.g.:
*1 numbered
* bullets
*= term
definition
Only a C[1] can follow the C[*]. So, your numbered list would
look like:
*1 First
*1 Second
*1 Third
This tells Kwid to number your items, but does not allow strange
things like:
*2 First prime
*3 Second prime
*5 Third prime
For that, you need C[*=]
Thoughts?
Well, not everyone likes HTML (although I can't imagine why).
* It's hard for humans to read
* It imposes too much display-think on what should be content-think
* It is not a proper super-set of the other documentation formats.
XHTML addresses some of this, but still provides far too much
display-oriented power for a high-level markup like POD or Kwid.
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)
On Tue, 2005-03-15 at 11:38, Stevan Little wrote: On Mar 15, 2005, at 10:58 AM, Patrick R. Michaud wrote: Without commenting on the merits of any of the proposals, I'll note that discussions about changing POD are probably design-level discussions that belong on p6l instead of p6c (which are implementation decisions). You are absolutely correct. I will repost over on p6l later today. Sigh, I guess I need to move my comment over as well, sorry. -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
[Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
Wherein I propose (to the wrong list, sigh) a re-envisioning of Kwid in
a more POD-like form.
I did leave out some POD markup forms. Assume that, if I did not mention
them, then I think they should keep the same prefix character (e.g. X)
---BeginMessage---
On Tue, 2005-03-15 at 09:37, Stevan Little wrote:
On Mar 15, 2005, at 12:54 AM, Nigel Hamilton wrote:
There is a need for a higher level 'structural' documentation that
hypertext is well suited to cover - something that spans more than one
module. This will be especially important for CPan6 and connecting
versions, and modules into bigger 'packages'.
Agreed as well. It would be nice if CPAN6 or CP6AN or FreePAN (or
whatever it will eventually be called) have a more sophisticated
linking/documentation system which goes beyond the actual single
module. I even think this would be possible in the current CPAN if we
could get the L construct fixed, but that is another issue.
Actually, I don't think that's at all another issue. It's the core of
what you're talking about. L gives you the ability to link, and in
several different ways. It's also broken in Perl 5, which makes a
replacement sound attractive, but fixing it solves for much of that
need.
Taking a cue from the wiki world makes sense to me. Kwid is almost ideal
as far as I can tell in that it:
a) Does everything POD does
b) Is backward compatible with Perl 5 in that it can be ignored by the
parser in the same way.
c) Makes many things easier
Now, it does need some tweaking, I think, but nothing too severe. It
just makes a few things harder, and a few other things non-POD-like for
no particular reason. I like CPOD for the ease of including keywords
in Cperl documentation. It's also Btrivial to Irecognize all
markup quickly (visually or programmaticly).
Kwid /on the other hand/ makes it a bit harder to [=find] that markup,
and is *thus* not quite as easy to de-parse visually.
I'd be thrilled if we just changed the .-introduced things to
=-introduced things:
= heading level 1
== heading level 2
=begin list
* You don't really need the begin
* But it doesn't hurt
* and it allows
some(code())
to appear inside a list item.
* Hmmm
=end list
And then replaced [...] and [=...] and /.../ and *...* with their more
POD-like: L[...], C[...], I[...] and B[...] with a bare [foo] working as
a I have no idea what I'm linking to, but do the right thing sort of
wikiness, where L[...] is a more structured, POD-like link. For example:
= Proposed Kwid Changes
== Introduction
It is my I[goal] to introduce an easier to use (for [POD] users)
version of [Kwid], and impose it B[mercilessly] on the heathen
masses!
Markup can consist of C[[]]-delimited text such as C[[Kwid]] or
a prefixed C[[]]-delimited text such as C[C[Kwid]]. Possible
prefixes are:
=begin list
*= L
A structured link ala POD C[L]
*= B, I
Bold or italics
*= C
Code
=end list
Anywhere a C[[]] can be used, a C[{}] can also be used. This is
useful when you need to enclose unbalanced C[{], C[}], C{[},
or C{]} characters.
All formatting is introduced with C[=for] just as in POD, so:
=for html hr /
works as you might expect. C[=begin] is similar, but introduces
a block, ended by C[=end]
=for html,xhtml,xml img src=foo.png alt=A foo! /
=begin !html,xhtml,xml
You can't see the image, but it would be pretty!
=end !html,xhtml,xml
Notice the use of C[!format[,format...]] to indicate all formats
not listed.
comment is the null format, so you can always introduce a
C[=for comment] or C[=begin comment], but lines which start with
C[#] are always treated as comments anyway.
Lists are introduced with C[=begin list], which is a special
format. A list can be numbered, bulletted or defintion-style.
Each type is introduced differently, e.g.:
*1 numbered
* bullets
*= term
definition
Only a C[1] can follow the C[*]. So, your numbered list would
look like:
*1 First
*1 Second
*1 Third
This tells Kwid to number your items, but does not allow strange
things like:
*2 First prime
*3 Second prime
*5 Third prime
For that, you need C[*=]
Thoughts?
Well, not everyone likes HTML (although I can't imagine why).
* It's hard for humans to read
* It imposes too much display-think on what should be content-think
* It is not a proper super-set of the other documentation formats.
XHTML addresses some of this,
Re: [Pugs] Closing a file handle surprised the heck out of me
On Tue, Mar 15, 2005 at 12:46:49AM +0800, Autrijus Tang wrote: : On Mon, Mar 14, 2005 at 05:28:29PM +0100, Miroslav Silovic wrote: : But it gets worse. : : my $lines = [ =$fh ]; : seek($fh, 0); : my $lines2 = [ =$fh ]; : close $fh; : : $lines2 must somehow remember that seek has happened. : : That is fine because the three thunks are registered to the fh : in evaluation order. What will be more fun is if they are all : part of some other lazy lists, which may be accessed in some : unpredictable order. You could treat seek as a synchronization point like close. : : That is why lazy languages typically use some sort of typechecking to : avoid mixing computations with actions... :) Which is also what we're doing, except that we're hiding that fact from the user whenever we can rather than rubbing their nose in it. :-) Larry
Re: s/true/better name/
Larry Wall skribis 2005-03-15 8:41 (-0800): On Tue, Mar 15, 2005 at 12:13:52PM +0200, Yuval Kogman wrote: : On Tue, Mar 15, 2005 at 10:51:57 +0100, Juerd wrote: : Autrijus suggested indeed or id, of which I like indeed better, : because I'd like to continue using id with databases. : whether? That's an interesting possibility, though I think about half the people would misspell it. Maybe that's a feature. It works well for: $yesno = whether any(@foo) == @any(@bar); Seeing it in an example, I love this suggestion. 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! :) I should point out I'm rethinking the idea of whether or not whether and not should be list operators. Nice use of both languages. I've wondered today how their being list ops would work in practice. Does it work like any(), all(), or is only one of the elements evaluated? Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: [Pugs] Closing a file handle surprised the heck out of me
On Tue, Mar 15, 2005 at 08:52:07AM -0800, Larry Wall wrote: : That is fine because the three thunks are registered to the fh : in evaluation order. What will be more fun is if they are all : part of some other lazy lists, which may be accessed in some : unpredictable order. You could treat seek as a synchronization point like close. True. So maybe the trick is define such a set of synchronization points for resources that has lazy/eager conflicts, instead of forcing eager context on RHS of all infix:=, especially because most assignments probably only involve simple COW copying, so it'd be sad to lose the laziness benefit. : That is why lazy languages typically use some sort of typechecking to : avoid mixing computations with actions... :) Which is also what we're doing, except that we're hiding that fact from the user whenever we can rather than rubbing their nose in it. :-) As long as surprises can be minimized (or at least explained), that's entirely fine, I think. :) Thanks, /Autrijus/ pgpBwUmlY7MeT.pgp Description: PGP signature
[Pugs] Test for localtime and gmtime builtins
Hi All, Started looking at porting modules to pugs and Time::namespace seemed like a simple place to begin. These modules need the builtins localtime and gmtime to run, so I've written my first attempt at a perl6 test for these builtins. Its based on t/op/test.t from current perl5. Obv it barfs at them not being there so the todo_ tests are not run. A question on dev process then, I'm guessing that when a feature is added the feature and its testcase are iterated to perfection together? Comments and suggestions most welcome... Cheers, mattc -- Matthew Campbell [EMAIL PROTECTED]
Re: Analysis of operator ?? ::
On Tue, Mar 08, 2005 at 11:02:23AM +0800, Shu-chun Weng wrote: Hello, this mail is an analysis of implementing operator ternary operator ?? :: in pugs. Greetings. Thanks for your extensive survey, which helped a lot on pruning dead ends in my attempt in getting this implemented. The key insight was provided a few minutes ago by kosmikus on #haskell: 00:52 kosmikus could you somehow view the whole thing from ? to : as an infix binary operator? 00:52 kosmikus the binary operators can be parametrized over arbitrary parsers, can't they? and, to keep a long story short, ?? :: is now parsed correctly as (ternOp ?? :: if) in Parser.hs, with ternOp defined thus: ternOp pre post syn = (`Infix` AssocRight) $ do symbol pre y - parseTightOp symbol post return $ \x z - Syn syn [x, y, z] that is, it reads everything between ?? and ::, allowing only tight operators (i.e. = and everything tighter than it, but not and etc), and bind the left and right inside an if syntactic form. The AssocRight lets us parse (x ?? y :: z ?? v :: w) as (x ?? y :: (z ?? v :: w)) instead of the other way around. So, I consider this case closed. Let me know if you manage to uncover any subtle errors in ?? :: parsing. Thanks again for your investigation work and unit tests! Thanks, /Autrijus/ pgpYd6TDEPOSt.pgp Description: PGP signature
Markup language-like features in Perl6?
I am aware of at least one program that adopts XML for (customizable/skinnable) GUI descriptions. This has a sense for markup languages are typically descriptive, i.e. they say how something IS as opposed to, say, procedural languages that let one implement something that DOES something[1]. Of course as far as GUIs are concerned, they provide an interface for something that does something as well, so one needs both charachteristics and in fact an OO approach is typically applied, which provides an IMHO excellent approximation to the concept of describing how something IS also including details about the parts of it that DO something. 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. Now what I'm thinking about is a means of specifiying, say, portions in the source that ARE (something). By default they won't be executed at all, but they may provide useful hooks for a suitable module to assign a meaning to them, and of course they should also provide the link with code that does something (e.g. callbacks et similia). Of course I began talking about GUIs, but I wouldn't like to restrict everything to this particular aspect. Perl(6) is supposed to be a mutiparadigmatic language with means to be specialized and strenghtened into any of the supported paradigms. So I cannot see why a priori the markup language pardigm shouldn't fit in this picture. HOW to do it (efficiently/elegantly, etc.) is a whole another story... [1] Although this varies from language to language. If you come to think of TeX and its macro language you can see how approximative this claim is. Michele -- A question out of curiousity: who is this Green of Green's functions? Is he the same person of Green's theorem? :) Yes. He was also an early environmentalist; hence the current phrases green this and green that... - David C. Ullrich in sci.math, thread Who is Green?
Re: s/true/better name/
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) Nicholas Clark
Re: s/true/better name/
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 :) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)
I agree. I think the biggest mistake Perl 6's documentation system could make is to make it Javadoc-style automatic. This is one of those weird, backwards, cultural decisions, where we actually want to make the programmer's life a little harder. When I (seldomly) progam in Java, I find it very hard to use any libraries, because all the libraries have good method-level documentation, but none of them has good interface (conceptual, not Cinterface)-level documentation. I basically have to understand how the library author organized his code in order to use his library. On the other hand, Perl has this wonderful module idiom of SYNOPSIS and DESCRIPTION. SYNOPSIS generally shows you how a very small program would use the library (the thing Java libraries are missing), and DESCRIPTION goes in detail about the things you need to know. The things you don't need to know you can get by reading the code. Hi Luke, I agree that SYNOPSIS and DESCRIPTION sections are really important and I would not want them to be lost - maybe these should be a requirement for uploading to CPAN6? I seldom program in Java too :-) But one of the few things I liked about Javadoc is the ability to traverse the interfaces of classes quickly - and this is tied to hypertext. Forget I used the J word --- what I'd like to see in the documentation system is the ability to quickly browse and traverse the linkages between modules and 'things'. The documentation requirements for Perl6 are a step up from Perl5. Perl6 programs will have 'backlinks' and relationships with a number of things: rules, grammars, classes, methods, roles, subs and traits etc. These in turn may have their own hierarchies. The structural aspects of the contract of a Perl6 class needs to be prominently and uniformly communicated. I think we need a hypertext browsing capability so that we can jump around the distilled contract of a class: both our own modules and each other's. In this way you could traverse the interlinkages between ALL things on CPAN6: What grammar inherits from that? What modules use this grammar? What classes do this role? What programs test this class? What grammars inherit from this grammar? I'm not advocating terse documentation - but I would like to add to the wishlist: * universal consistent hypertext code browsing both locally and on ~~ /CPAN6/. Nige
Re: Exists and Delete
Rod Adams wrote: How am I supposed to define a signature that says A scalar that refers to a hash or array element, but do not evaluate or autovivify the element? I'll make a guess: Ref of Int of Array. This assumes Int has a polymorphic subtype that allows pointing into arrays. But unfortunately you need two values to describe the reference: the index and the array. So it should be more like a pair: Ref of Pair[Int,Array]. my @array; my Ref of Int of Array $iref = 17 of $array; # 17 = @array perhaps $iref = blahh; say @array[17]; # prints blahh Or are these two are now strictly methods without functional forms? Sorry I don't know what you are asking for. What is then a method with functional form? Do you mean that the entries in an array are off-limits to the outside and can be accessed only by the subscripting methods? Regards, -- TSa (Thomas Sandlaß)
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
Aaron Sherman skribis 2005-03-15 11:46 (-0500):
= heading level 1
== heading level 2
=begin list
I see this going wrong with =heading level 1 already. I like the numbers
in =headN too, by the way, as it makes inconsistencies easier to spot.
And then replaced [...] and [=...] and /.../ and *...* with their more
POD-like: L[...], C[...], I[...] and B[...] with a bare [foo] working as
a I have no idea what I'm linking to, but do the right thing sort of
wikiness, where L[...] is a more structured, POD-like link. For example:
L[] C[] I[] B[] are all hard to read. With , the weight is evenly
distributed, while with [], the weight is on the outside, next to that
capital letter that is just as large.
Visual comparison:
L[] C[] I[] B[] # I is worst
L C I B
So if [] is going to be used, may I suggest using lc letters with it
then?
l[] c[] i[] b[]
L[] C[] I[] B[]
L C I B
Still not great, but better IMO. Why are bad, by the way? Can't we
just change the meaning to be qq-like, that is: with nested content?
That means only for non-unicode you need extra angle brackets.
Or maybe we introduce [] as an alternative for .
Also, how is [EMAIL PROTECTED] parsed? # I find this very hard to parse,
# visually
Likewise, %?INC{something}?
Two possible sources of inspiration for the whole documentation thing:
* Text::MetaMarkup
* Paragraphs CAN begin with a block level html tag, h1: heading
* Inline HTML tags can be used as {b:bold}
* Paragraph starting with * is a list
* Paragraph starting with # is comment
* Verbatim paragraphs simply start with pre:
* No support for tables yet
* PodTables
* See http://pugs.kwiki.org/?PodTables
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Module popularity
Greetings and OOK, Jarkko. Ian asked the musical question http://www.nntp.perl.org/group/perl.qa/3850 The CPAN Search FAQ at http://search.cpan.org/faq.html reads: Q: Do you keep statistics on which modules are most popular? A: Not right now. But there are plans to add some kind of popularity metrics. I think the answer should be updated to point to the Phalanx project. Whom do we contact? But Andy didn't want to conflate Phalanxing with popularity http://www.nntp.perl.org/group/perl.qa/3852 I'd rather it didn't. What people think of as popularity is not what Phalanx measures. 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.
Re: [RFC] Test::Plan
On Tue, Mar 15, 2005 at 10:33:25AM -0500, Geoffrey Young wrote:
test = { TESTS = join ' ', map { glob } qw( t/*/*.t t/*/*/*.t ) },
but slashes aren't portable, right? I don't think you can get rid of
File::Spec.
In this case they should be portable. Windows will understand them and I
believe VMS can handle it if you change it to ./t/*/*.t.
But I don't see what the problem is, File::Spec and Find have been in the
core for years.
Re: [Pugs] Test for localtime and gmtime builtins
Umm, my attached test was stripped off. Who can I send it to for review? Cheers mattc On Tue, 2005-03-15 at 17:28 +, Matthew Campbell wrote: Hi All, Started looking at porting modules to pugs and Time::namespace seemed like a simple place to begin. These modules need the builtins localtime and gmtime to run, so I've written my first attempt at a perl6 test for these builtins. Its based on t/op/test.t from current perl5. Obv it barfs at them not being there so the todo_ tests are not run. A question on dev process then, I'm guessing that when a feature is added the feature and its testcase are iterated to perfection together? Comments and suggestions most welcome... Cheers, mattc -- Matthew Campbell [EMAIL PROTECTED]
Re: [Pugs] Test for localtime and gmtime builtins
On Tue, Mar 15, 2005 at 05:28:51PM +, Matthew Campbell wrote: Started looking at porting modules to pugs and Time::namespace seemed like a simple place to begin. These modules need the builtins localtime and gmtime to run, so I've written my first attempt at a perl6 test for these builtins. Its based on t/op/test.t from current perl5. Hi there. It seems that you've forgot the attachment. That is fine, though, because I have just sent you an invitation mail to become a committer, so you can commit it yourself. :-) Obv it barfs at them not being there so the todo_ tests are not run. The recommended way is to wrap the call into an eval ''. Thanks, /Autrijus/ pgp4P8RTPx05R.pgp Description: PGP signature
Re: int(0x123) == int(0x123) ?
On Tue, Mar 15, 2005 at 11:09:11PM +0800, Autrijus Tang wrote: : Currently Pugs numifies hexadecimal and octal strings as if they : are literals; that means 0x123 and 0o456 all work as expected. : Is that an acceptable treatment? It's okay by me. The restriction on not autoconverting hex and octal stems from the days when 0777 was assumed to be octal. Since we've changed that to 0o777, it's much less likely to autoconvert zip codes to a different number. We can allow 0b111 as well. (Scientific notation is already allowed in Perl 5 autoconversion.) : What about Inf and NaN in numeric context? We should be intelligent about Inf and NaN, which means Inf is infinity but Info is 0 (plus warning). NaN is not a number, while NaNa is 0 (plus warning). We also recognize +Inf and -Inf. Larry
Re: Analysis of operator ?? ::
On Wed, Mar 16, 2005 at 01:35:12AM +0800, Autrijus Tang wrote: : that is, it reads everything between ?? and ::, allowing only : tight operators That is correct. Larry
Re: s/true/better name/
Larry Wall wrote: On Tue, Mar 15, 2005 at 12:13:52PM +0200, Yuval Kogman wrote: : On Tue, Mar 15, 2005 at 10:51:57 +0100, Juerd wrote: : : Autrijus suggested indeed or id, of which I like indeed better, : because I'd like to continue using id with databases. : : whether? That's an interesting possibility, though I think about half the people would misspell it. Maybe that's a feature. It works well for: $yesno = whether any(@foo) == @any(@bar); I don't mind it being long. I should point out I'm rethinking the idea of whether or not whether and not should be list operators. not @foo would have unexpected consequences if it forces list context, so I think we better let people hyper those manually if needed. I think we can leave not at the precedence of list operators without actually making it one, but maybe we should make a separate precedence level for it to keep list op precedence pure. I don't see the point of making them list ops. Leaving them at that precedence level makes sense, but leave them unary. For a list version, you can write C?any(...) or C?none(...) to do the same thing. -- Rod Adams
Re: Exists and Delete
Thomas Sandlaß wrote:
Rod Adams wrote:
How am I supposed to define a signature that says A scalar that
refers to a hash or array element, but do not evaluate or autovivify
the element?
I'll make a guess: Ref of Int of Array.
This assumes Int has a polymorphic subtype that allows
pointing into arrays. But unfortunately you need two values
to describe the reference: the index and the array. So it should
be more like a pair: Ref of Pair[Int,Array].
my @array;
my Ref of Int of Array $iref = 17 of $array; # 17 = @array perhaps
$iref = blahh;
say @array[17]; # prints blahh
Or are these two are now strictly methods without functional forms?
Sorry I don't know what you are asking for. What is then a method with
functional form? Do you mean that the entries in an array are off-limits
to the outside and can be accessed only by the subscripting methods?
What I'm asking is if we are going to continue allowing:
delete %xfoo;
if exists %xfoo { ... }
or make it where you instead have to say
%x.delete('foo');
if %x.exists('foo') { ... }
-- Rod Adams
Regards,
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
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. It is not the same format at all. Kwid is merely /inspired/ by Kwiki, which in turn is inspired by the (more usenix) features of modern wiki languages. It is more fair to say that Kwid is much more inspired by Pod than Kwiki. Please read what is considered to be the de facto spec: http://svn.openfoundry.org/pugs/ext/Pugs-Documentation/perlkwid.kwid carefully and recomment. A few notes. 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. This makes the Kwid experiment much less risky, since it will be trivial to convert in either direction. As to the syntax, care has been taken to ensure that all the corner cases are covered. And also covered elegantly. Some people have argued that Kwid is only a syntactic change to Pod. I would argue that they are correct. :) But this does not mean it is not an important change. Kwid has an emphasis on minimizing the markup, and using the markup one might use to discuss programming in everyday email. This is hard to do in POD, but very easy to do in Kwid. Thus a bug win. It is also wrong to imply that important semantic changes cannot be made in the future. Things like introspection and transclusion. But that is not the current concern. In reality, Kwid does vary ever so slightly in semantics from POD. But only in cases where POD seemed to have a wart. For instance Kwid allows named hyperlinks: [The Pugs Source|http://svn.openfoundry.org/pugs]. Cheers, Brian On 15/03/05 11:46 -0500, Aaron Sherman wrote: Wherein I propose (to the wrong list, sigh) a re-envisioning of Kwid in a more POD-like form. I did leave out some POD markup forms. Assume that, if I did not mention them, then I think they should keep the same prefix character (e.g. X) Content-Description: Forwarded message - Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT) From: Aaron Sherman [EMAIL PROTECTED] Date: Tue, 15 Mar 2005 11:43:39 -0500 To: Stevan Little [EMAIL PROTECTED] Cc: perl6-compiler@perl.org Subject: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT) X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) On Tue, 2005-03-15 at 09:37, Stevan Little wrote: On Mar 15, 2005, at 12:54 AM, Nigel Hamilton wrote: There is a need for a higher level 'structural' documentation that hypertext is well suited to cover - something that spans more than one module. This will be especially important for CPan6 and connecting versions, and modules into bigger 'packages'. Agreed as well. It would be nice if CPAN6 or CP6AN or FreePAN (or whatever it will eventually be called) have a more sophisticated linking/documentation system which goes beyond the actual single module. I even think this would be possible in the current CPAN if we could get the L construct fixed, but that is another issue. Actually, I don't think that's at all another issue. It's the core of what you're talking about. L gives you the ability to link, and in several different ways. It's also broken in Perl 5, which makes a replacement sound attractive, but fixing it solves for much of that need. Taking a cue from the wiki world makes sense to me. Kwid is almost ideal as far as I can tell in that it: a) Does everything POD does b) Is backward compatible with Perl 5 in that it can be ignored by the parser in the same way. c) Makes many things easier Now, it does need some tweaking, I think, but nothing too severe. It just makes a few things harder, and a few other things non-POD-like for no particular reason. I like CPOD for the ease of including keywords in Cperl documentation. It's also Btrivial to Irecognize all markup quickly (visually or programmaticly). Kwid /on the other hand/ makes it a bit harder to [=find] that markup, and is *thus* not quite as easy to de-parse visually. I'd be thrilled if we just changed the .-introduced things to =-introduced things: = heading level 1 == heading level 2 =begin list * You don't really need the begin * But it doesn't hurt * and it allows some(code()) to appear inside a list item. * Hmmm =end list And then replaced [...] and [=...] and /.../ and *...* with their more POD-like: L[...], C[...], I[...] and B[...] with a bare [foo] working as a I have no idea what I'm linking to, but do the right thing sort of wikiness, where L[...] is a more structured, POD-like link. For example: = Proposed Kwid Changes == Introduction It is my I[goal] to introduce an easier to use (for [POD] users) version of [Kwid], and impose it B[mercilessly] on the heathen masses!
Re: int(0x123) == int(0x123) ?
On Tue, Mar 15, 2005 at 10:43:07AM -0800, Larry Wall wrote: On Tue, Mar 15, 2005 at 11:09:11PM +0800, Autrijus Tang wrote: : Currently Pugs numifies hexadecimal and octal strings as if they : are literals; that means 0x123 and 0o456 all work as expected. : Is that an acceptable treatment? It's okay by me. The restriction on not autoconverting hex and octal stems from the days when 0777 was assumed to be octal. Since we've changed that to 0o777, it's much less likely to autoconvert zip codes to a different number. We can allow 0b111 as well. (Scientific notation is already allowed in Perl 5 autoconversion.) ... pmichaud has since talked me into only allowing only digits and dots during numifying and thereby outlawing scientific notations altogether, which is another end of the spectrum and is also consistent. So, between the two consistencies, do you think that the more DWIMmy one of parsing 0o123 is more helpful? I'll implement it tomorrow if that's the case. :) Thanks, /Autrijus/ pgpoWL5ugYRuI.pgp Description: PGP signature
Re: Exists and Delete
On Tue, Mar 15, 2005 at 12:44:06PM -0600, Rod Adams wrote:
: What I'm asking is if we are going to continue allowing:
:
: delete %xfoo;
: if exists %xfoo { ... }
:
: or make it where you instead have to say
:
: %x.delete('foo');
: if %x.exists('foo') { ... }
They can always just be macros that translate the unary form to the
method. If you define them as term:delete and term:exists they
won't show up unexpectedly when the parser is looking for method names.
Larry
Re: Exists and Delete
Rod Adams skribis 2005-03-15 12:44 (-0600):
%x.delete('foo');
if %x.exists('foo') { ... }
Would renaming exists to has or hasa be a good idea, if it does indeed
exist only in method form?
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: int(0x123) == int(0x123) ?
On Wed, Mar 16, 2005 at 02:57:36AM +0800, Autrijus Tang wrote: : So, between the two consistencies, do you think that the more DWIMmy : one of parsing 0o123 is more helpful? I'll implement it tomorrow : if that's the case. :) Yes, I do. That was one of the main reasons for switching to the less ambiguous 0o123 notation. I do think that we can afford to be picker for the dwimmier things nowadays, but that's probably covered by warnings being on by default. In any event, 123foo, 1e3f4x, 0o789, 0b1x, Info, and NaNa all produce warnings by default if used in numeric context. Extra whitespace should be ignored, however. And we might even allow exponents on 0x et al., though what radix the exponent is assumed to be is an interesting question, though. Larry
Re: Exists and Delete
On Tue, Mar 15, 2005 at 07:47:58PM +0100, Juerd wrote:
: Rod Adams skribis 2005-03-15 12:44 (-0600):
: %x.delete('foo');
: if %x.exists('foo') { ... }
:
: Would renaming exists to has or hasa be a good idea, if it does indeed
: exist only in method form?
I'd think that would be asking if the array has an *attribute* of
that name. Perl 6 objects aren't hashes...
Larry
Re: Exists and Delete
Larry Wall skribis 2005-03-15 11:20 (-0800):
On Tue, Mar 15, 2005 at 07:47:58PM +0100, Juerd wrote:
: Rod Adams skribis 2005-03-15 12:44 (-0600):
: %x.delete('foo');
: if %x.exists('foo') { ... }
: Would renaming exists to has or hasa be a good idea, if it does indeed
: exist only in method form?
I'd think that would be asking if the array has an *attribute* of
that name. Perl 6 objects aren't hashes...
That makes sense. I think %x ~~ 'foo' will be used more than
%x.exists('foo') anyway.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: The S29 Functions Project
On Mon, Mar 14, 2005 at 08:59:32AM -0800, Larry Wall wrote: On Mon, Mar 14, 2005 at 08:10:15AM -0600, Patrick R. Michaud wrote: : I ran into this problem while creating a mini-list of S29 functions : (which Rod's work supercedes, I suspect, and I'm very glad he's taking : this on). What are some guidelines we could use in deciding : which functions are automatically in ::* ? Or is this just a case : where we need to use past experience and best guesses as our guide? * Another confounding factor is that memes tend to come in bundles, and you'd kind of like to keep the bundles together. So my earlier question really amounted to whether POSIX was really a valid bundle of memes. (Probably not.) On the other hand, the trig functions might well be a valid bundle, and we might want to keep them all together either in * or Trig. To me it seems that a there are some groups of core builtins in Perl 5 that group conceptually quite well, and it's sensible to remove en mass, which are the builtins that aren't really useful in Perl 5 without loading an extension module. So all the socket related builtins aren't much use without the constants exported by Socket; and the System V IPC builtins aren't much use without the IPC::SysV, so they could quite easily be exported by that instead. But then it gets less obvious what other groups from the top of perlfunc.pod might manage a discrete exit from ::* without anyone noticing. So, no, I don't have an answer :-) Nicholas Clark
Re: The S29 Functions Project
At 07:59 PM 3/15/2005 +, you wrote: On Mon, Mar 14, 2005 at 08:59:32AM -0800, Larry Wall wrote: On Mon, Mar 14, 2005 at 08:10:15AM -0600, Patrick R. Michaud wrote: : I ran into this problem while creating a mini-list of S29 functions : (which Rod's work supercedes, I suspect, and I'm very glad he's taking : this on). What are some guidelines we could use in deciding : which functions are automatically in ::* ? Or is this just a case : where we need to use past experience and best guesses as our guide? * Another confounding factor is that memes tend to come in bundles, and you'd kind of like to keep the bundles together. So my earlier question really amounted to whether POSIX was really a valid bundle of memes. (Probably not.) On the other hand, the trig functions might well be a valid bundle, and we might want to keep them all together either in * or Trig. To me it seems that a there are some groups of core builtins in Perl 5 that group conceptually quite well, and it's sensible to remove en mass, which are the builtins that aren't really useful in Perl 5 without loading an extension module. So all the socket related builtins aren't much use without the constants exported by Socket; and the System V IPC builtins aren't much use without the IPC::SysV, so they could quite easily be exported by that instead. But then it gets less obvious what other groups from the top of perlfunc.pod might manage a discrete exit from ::* without anyone noticing. So, no, I don't have an answer :-) Nicholas Clark I've put the following note at the top of S29.pod (in an update I haven't posted yet). In Perl 6, all builtin functions belong to a named package. Not all functions are guaranteed to be imported into the global package C::*. In addition, the list of functions imported into C::* will be subject to change with each release of Perl. Authors wishing to Future Proof their code should either specifically import the functions they will be using, or always refer to the functions by their full name. -- Rod Adams
reset() and S29 -- obsoleted?
One function I noticed on the S29 list was reset(). With lexically scoped variables, reset is almost useless. Perl in a Nutshell calls it vaguely deprecated. Can we remove the vagueness and deprcate it completely? Steve Peters [EMAIL PROTECTED]
[perl #34441] [TODO] Clean up 'imcc' targets from main Makefile?
# New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #34441] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=34441 Hi, there are a lot of potentially confusing targets in the main Makefile. In order to simply the Makefile, I propose to remove the 'imcc' targets. Does anybody care for these targets? test_imcc: Run the test suite only for IMCC tests. testcore_imcc: Run the IMCC test suite with a specific core fulltest_imcc: Run IMCC test suite with various options test_imcc-clean imcc-clean The functionality of running only a subset of tests will of course remain, e.g perl t/harness -C imcc/t/*/*.t CU, Bernhard -- /* [EMAIL PROTECTED] */ DSL Komplett von GMX +++ Supergnstig und stressfrei einsteigen! AKTION Kein Einrichtungspreis nutzen: http://www.gmx.net/de/go/dsl
Re: reset() and S29 -- obsoleted?
On Tue, Mar 15, 2005 at 02:39:06PM -0600, Steve Peters wrote: : One function I noticed on the S29 list was reset(). With lexically scoped : variables, reset is almost useless. Perl in a Nutshell calls it vaguely : deprecated. Can we remove the vagueness and deprcate it completely? Yes, please. Larry
Re: reset() and S29 -- obsoleted?
LW == Larry Wall [EMAIL PROTECTED] writes: LW On Tue, Mar 15, 2005 at 02:39:06PM -0600, Steve Peters wrote: LW : One function I noticed on the S29 list was reset(). With lexically scoped LW : variables, reset is almost useless. Perl in a Nutshell calls it vaguely LW : deprecated. Can we remove the vagueness and deprcate it completely? LW Yes, please. i have seen p5 newbies ask about using it. oy!! uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: reset() and S29 -- obsoleted?
Larry Wall wrote: On Tue, Mar 15, 2005 at 02:39:06PM -0600, Steve Peters wrote: : One function I noticed on the S29 list was reset(). With lexically scoped : variables, reset is almost useless. Perl in a Nutshell calls it vaguely : deprecated. Can we remove the vagueness and deprcate it completely? I hadn't thought about it yet. I almost definitely would have come to that conclusion. Yes, please. Done. -- Rod Adams
[perl #34442] [TODO] *BooleanArray PMCs should use single bit per bool
# New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #34442] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=34442 This was mentioned by Leo in Ticket 34934 and 30230: Oh well, while at it, the *BooleanArray should just use one bit per item not an INTVAL. I'll tackle that. First I'll propable take a look at Bit::Vector in Perl5, as there are propably a lot of interesting methods on a boolean array. There are even CPUs with processor instructions for counting set bits. Does that call for some inline assembler in PMC C-code? CU, Bernhard -- /* [EMAIL PROTECTED] */ DSL Komplett von GMX +++ Supergnstig und stressfrei einsteigen! AKTION Kein Einrichtungspreis nutzen: http://www.gmx.net/de/go/dsl
Re: The S29 Functions Project
On Tue, Mar 15, 2005 at 02:25:01PM -0600, Rod Adams wrote: : In Perl 6, all builtin functions belong to a named package. Not all : functions are guaranteed to be imported into the global package : C::*. In addition, the list of functions imported into C::* will be : subject to change with each release of Perl. Authors wishing to : Future Proof their code should either specifically import the : functions they will be using, or always refer to the functions by their : full name. Hmm, what I said was supposed to be policy for just the development release of 6.0.0. However, it's not that far off from the general case if you add something along the lines of: After 6.0.0 comes out, global aliases will not be removed lightly, and will never be removed at all without having gone through a deprecation cycle of at least a year. In any event, you can specify that you want the interface for a particular version of Perl, and that can be emulated by later versions of Perl to the extent that security updates allow. Interestingly, that last sentence means that different modules can have different views of * space. But really, that just falls out of ordinary module versioning, if you can warp your brain around to thinking of * as an ordinary versioned module. The long name of * just happens to include the Perl version number, and could presumably even include different authors if we ever fork Perl. Larry
Re: reset() and S29 -- obsoleted?
On Tue, Mar 15, 2005 at 05:44:07PM -0500, Uri Guttman wrote: : LW == Larry Wall [EMAIL PROTECTED] writes: : : LW On Tue, Mar 15, 2005 at 02:39:06PM -0600, Steve Peters wrote: : : LW : One function I noticed on the S29 list was reset(). With lexically scoped : LW : variables, reset is almost useless. Perl in a Nutshell calls it vaguely : LW : deprecated. Can we remove the vagueness and deprcate it completely? : : LW Yes, please. : : i have seen p5 newbies ask about using it. oy!! There will probably be an emulation of it written in support of the translator, but we don't have to make it terribly easy to get at, and we can even require them to say: use DEPRECATED_PERL_5_FEATURES __p5_resetmatch__ __p5_resetvars__; up at the top. Of course it's no pain for the translator to insert something like that when it needs to. Larry
Re: The S29 Functions Project
Larry Wall wrote: On Tue, Mar 15, 2005 at 02:25:01PM -0600, Rod Adams wrote: : In Perl 6, all builtin functions belong to a named package. Not all : functions are guaranteed to be imported into the global package : C::*. In addition, the list of functions imported into C::* will be : subject to change with each release of Perl. Authors wishing to : Future Proof their code should either specifically import the : functions they will be using, or always refer to the functions by their : full name. Hmm, what I said was supposed to be policy for just the development release of 6.0.0. However, it's not that far off from the general case if you add something along the lines of: After 6.0.0 comes out, global aliases will not be removed lightly, and will never be removed at all without having gone through a deprecation cycle of at least a year. In any event, you can specify that you want the interface for a particular version of Perl, and that can be emulated by later versions of Perl to the extent that security updates allow. Interestingly, that last sentence means that different modules can have different views of * space. But really, that just falls out of ordinary module versioning, if you can warp your brain around to thinking of * as an ordinary versioned module. The long name of * just happens to include the Perl version number, and could presumably even include different authors if we ever fork Perl. Add something along the lines of was interpreted as clip and paste into S29.pod. I wasn't meaning to imply that bindings would be changed willy-nilly in production, but I can see how that could be inferred from what I wrote. My main intention was that it *could* change over time. These whole paragraphs can be reworded later, possibly at the same time we sit down and figure out the policy of what gets imported into *:: when. -- Rod Adams
Re: [Pugs] short-circuit operators
--- Ingo Blechschmidt wrote: Andrew Savige wrote: The following program: my $x = 1; my $y = 2; $x == 1 or $y = 42; ^ typo? No, it's not a typo. I was (perhaps not very clearly) trying to demonstrate that the short-circuiting operators, namely: or and|| are not short-circuiting in Pugs, at least that's what I see. I am assuming that the above test program is valid in p5 and p6, and with the same semantics -- if I'm mistaken, please let me know. Here is a similar test program for the 'and' operator: my $x = 1; my $y = 2; $x == 3 and $y = 42; printx='$x' y='$y'\n; which again produces different results with p5 and pugs. BTW, the program I'm trying to convert, often does things like: open(...) or die ...; /-\ Find local movie times and trailers on Yahoo! Movies. http://au.movies.yahoo.com
Re: [Pugs] short-circuit operators
Ferreting around in the #perl6 logs I noticed an acknowledgement that short-circuiting is borken as at 15 Maart. Oh well, time for the mad golfer to dust off his trusty sand iron and hack his way out of this punishing Pugs sand trap. :-) /-\ Find local movie times and trailers on Yahoo! Movies. http://au.movies.yahoo.com
Re: [perl #34430] [PATCH] MRO breaks Tcl
Switching tclobject seems to work fine here. I suspect you might have something else going on. Committed the change to tclobject, removed my local hack to src/pmc.c, passes 100% now. Regards. Leopold Toetsch wrote: Will Coleda [EMAIL PROTECTED] wrote: Attached is a patch that allows (cd languages/tcl make test) to work again. Looks like an unguarded access in MRO. Didn't self apply so Leo could poke at it, in case the tcl pmcs are exploiting a hole in pmc2c2.pl. The CTclObject is defined as an abstract class, i.e. it has no VTABLE. Per convention, such abstract classes should be lower case. Is there a specific reason that it's an abstract PMC? I tried to get rid of abstract noinit in that PMC, which produced these failing tests: cmd_break.t 1 256 21 50.00% 2 cmd_continue.t1 256 21 50.00% 2 cmd_linsert.t 4 1024 54 80.00% 1 3-5 cmd_string.t 6 1536356 17.14% 26-27 29-31 34 leo
Re: [PROPOSAL] MMD: multi sub syntax
From: Leopold Toetsch [EMAIL PROTECTED] Date: Tue, 15 Mar 2005 08:52:38 +0100 Bob Rogers [EMAIL PROTECTED] wrote: What if one wants the first and third arguments to be the invocants? Then the first syntax gives .sub foo @MULTI .invocant Integer a .param pmc b .invocant String c That should better be .sub foo @MULTI .invocant Integer a .invocant pmc b .invocant String c Invocants are positional arguments, there isn't a case where the first and the third are invocants in a Perl6 function signature. It of course boils down to the same, namely that the second argument is a wildcard (Perl6 Any) but it's for the dispatcher nethertheless a dispatch on three invocants. Thanks for clearing that up. (FWIW, your answer accords well with my personal biases, too. ;-) . . . In that case the first syntax strikes me as cleaner . . . I'm not sure. But there is still another thingy. A12 allows multiple colons to separate invocant classes. If there is a tie, the secondary invocants are used as tie breakers, which could be written as: .sub foo multi(Integer, pmc: String) .param pmc a .param pmc b .param pmc c - try to dispatch on the first two types in the first place - if there is a tie, consider the type of the 3rd argument leo I've only read half of A12 by now, and am still digesting what I've read (and that may take a while), but the section headed multi sub * (tradition multimethods) seems to say that the dispatcher never considers anything after the last colon. So perhaps you meant: .sub foo multi(Integer, pmc: String:) .param pmc a .param pmc b .param pmc c Or is that wrong? The next question is, what happens if you define a method with the long name: .sub bar multi(Integer, Float: Float) and I define one with .sub bar multi(Integer: String, Integer) That would mean that the long names have different name length in this case. It seems to me that can't work, but if A12 rules it out, I couldn't find it. If this is supposed to work, then how should MMD handle disagreement about invocant groups? And if the answer is simply to ignore it, and treat each method independently, doesn't this screw up the distance metric? The distance to your method will be computed on the first two values, whereas the distance to mine will be computed on only the first, so the two distances will be incommensurable, true? TIA, -- Bob Rogers http://rgrjr.dyndns.org/
Re: lists in string context
On Sat, Mar 12, 2005 at 09:36:24PM +0100, Juerd wrote:
Larry Wall skribis 2005-03-12 12:26 (-0800):
And arguably, the current structure of join is that the delimiter is
the invocant, so cat should be defined as
''.join(@foo)
This is what Python does. It does not make any sense to me, and I can't
wrap my mind around it at all. Ruby-ish @foo.join('') seems more
natural.
Just like with how I prefer $fh.print($text) to $text.print($fh), I
cannot explain WHY this is how my mind works.
I'm with you. In my opinion, it is weird to call a method against a
constant value; values aren't supposed to do things, they are supposed
to have things done to /them/. For similar reasons, it is only
slightly less weird to call a method on a variable when that variable
is simply a container for a constant value.
A variable that contains an object or interface element (e.g. a
filehandle), I can understand calling methods against that.
Ob flame retardant: I'm not saying that my opinion is necessarily
right, or the other way isn't valid. Just offering a thought on why
Juerd might have this feeling.
--Dks
Re: s/true/better name/
On Tue, Mar 15, 2005 at 08:23:19AM -0800, Larry Wall wrote: On Tue, Mar 15, 2005 at 10:51:57AM +0100, Juerd wrote: : Autrijus suggested indeed or id, of which I like indeed better, : because I'd like to continue using id with databases. id is too heavily overloaded with identifiers and identities and such. But indeed doesn't work right in context, while indeed... I'd go with either istrue or so. ok is another possibility, though that seems to connote definedness more than truth. It also breaks a huge percentage of the testing code that we would like to be able to automagically port from P5 to P6. --Dks -- [EMAIL PROTECTED]
Re: [Pugs] short-circuit operators
On Wed, Mar 16, 2005 at 12:31:05PM +1100, Andrew Savige wrote: Ferreting around in the #perl6 logs I noticed an acknowledgement that short-circuiting is borken as at 15 Maart. Oh well, time for the mad golfer to dust off his trusty sand iron and hack his way out of this punishing Pugs sand trap. :-) ...as of r781, short circuit operators is now back; I added an isThunk internal trait to parameters, thereby successfully delayed the second parameter from evaluating. 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? Thanks, /Autrijus/ pgpsFZnp0V5ZZ.pgp Description: PGP signature
Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)
On Mon, 14 Mar 2005 20:54:20 -0500
Stevan Little [EMAIL PROTECTED] wrote:
Did any of you look at the excelent work Mark Overmeer did on OOdoc?
Gang,
My proposal is for an extensible version of POD. Basically what XML is
to HTML/SGML, this will be for POD. This is a very very very rough
draft. I am submitting it in hopes of getting some basic feedback on
the idea to see if I should carry it any further or not. So please if
you have an opinion on this, either positive or negative, please chime
in and let me know.
If nothing more I am hoping this might bring the debate over the
future of POD (or Kwid) out of the more transient #perl6 and into the
more concrete world of email as I think there are currently too many
opinions and not enough dialog.
- Stevan
(p.s. - I apologize in advance if my ideas sound a little jumbled
together, remember,.. this is very very rough)
INTRODUCTION
There has been a lot of chatter on #perl6 about POD vs. Kwid and how
best to do this and that, etc. etc. etc. and so on and so forth. It
seems to me that we will never be able to create a documentation
format which will make everyone happy in all cases.
But my question really is, why should we?
Just as with HTML, at some point the formatting information overtakes
the data being displayed and the data no longer has any real meaning
in relation to the markup around it. IMO, POD (and Kwid) are both too
formatting centric, and while much simpler than HTML, suffer on some
level from the same problem.
The early promise of XML was that data and formatting would be
separate. That you put the data in the XML and gave it meaning and
context, then you put the formatting into your stylesheet (XSL or
CSS). Of course we all know XML (and XSL and all its variants) have
now become a big ugly monster, but that does not mean those early
ideas were not good ones.
I am of the opinion that while documentation is traditionally a very
static thing, it should and need not be so. In fact, I feel that
documentation should be as much meta-data as it is prose. I think the
extensible POD-like format I will describe below could possibly bridge
that gap between meta-data and static documentation.
THE BASIC IDEA
When grossly simplified SGML, HTML XML all share a base set of
similar constructs. They are made up of Containers, Elements and
Entities. An Element is basically a tag with no embedded tags (BR or
HR are the most common in HTML). A Container is a tag which itself
has Elements within it. An Entity is just a special chunk of text
embedded within other text (in *ML they begin with '' and end with
';'). (NOTE: I am making the assumption that text is itself an
implicit element)
If we port this idea to a POD like syntax, it might look something
like this:
=container
=element: some string with Eentities in it
Some plain text contained Iwithin this container.
=end
The Container is begun the normal POD-ish way, and easily delimited
by an '=end' marker. An Element is very POD-ish as well, but is
identified by a trailing ':' after it's name. And entities take the
common POD form of an uppercase character and something inside of two
angle brackets.
NOTE: Anything following an Element or a Container declaration on the
same line can be thought of as being part of that element/container.
This is somewhat like how *ML tags have attributes.
A more complex example might be something like this:
=module
=project: Pugs
=name: Perl6::Pugs
=version: 6.0.11
=author
=name: Autrijus Tang
=email: [EMAIL PROTECTED]
=end
=description: Pugs - Perl6 Users Golfing System.
=dependencies
GHC 6.2 or above
=end
=copyright: Copyright 2005 Autrijus Tang.
=url: Lhttp://www.autrijus.org
=license
This library is free software; you can redistribute it
and/or modify it under the same terms as Perl itself.
=end
=end
As you can see any container or element can begin with a normal
identifier ('a-zA-Z_' but no spaces). Since they can be nested name
conflict can be avoided through scoping (module/name and
module/author/name do not conflict). Like *ML (but unlike POD and
Kwid) both whitespace and line breaks are not significant (at least
not in the same way). Unlike *ML, the tags are not so verbose and
are fairly easily readable by humans (at least in IMHO that is). The
entities can be pretty much any single uppercase letter (26 is
likely enough).
Now, I am sure some of you are thinking that it is starting to look a
little like YAML. But YAML is much more complex and structured, and
therefore not really good for documentation. YAML has a much larger
syntax, for what I am proposing, what you see here is all of it.
And really, thats pretty much all of it. Details like code and
Re: [Pugs] short-circuit operators
On Wed, Mar 16, 2005 at 01:30:10PM +0800, Autrijus Tang wrote: : On Wed, Mar 16, 2005 at 12:31:05PM +1100, Andrew Savige wrote: : Ferreting around in the #perl6 logs I noticed an acknowledgement : that short-circuiting is borken as at 15 Maart. Oh well, time : for the mad golfer to dust off his trusty sand iron and hack : his way out of this punishing Pugs sand trap. :-) : : ...as of r781, short circuit operators is now back; I added an : isThunk internal trait to parameters, thereby successfully : delayed the second parameter from evaluating. : : 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. That's not to say that we won't allow people to write their own control structures. But we just shouldn't encourage people to do that without considering the consequences. And certainly we plan to give them most of the standard control structures they want anyway. But I could see someone wanting to do an analog that has additional semantics like unification or hypotheticality built in. Larry
Re: [perl #34441] [TODO] Clean up 'imcc' targets from main Makefile?
Bernhard Schmalhofer (via RT) wrote: there are a lot of potentially confusing targets in the main Makefile. In order to simply the Makefile, I propose to remove the 'imcc' targets. Does anybody care for these targets? I don't test_imcc: Run the test suite only for IMCC tests. testcore_imcc: Run the IMCC test suite with a specific core fulltest_imcc: Run IMCC test suite with various options test_imcc-clean imcc-clean The functionality of running only a subset of tests will of course remain, e.g perl t/harness -C imcc/t/*/*.t Yep. Go ahead. Thanks, leo
Re: [PROPOSAL] MMD: multi sub syntax
Leopold Toetsch [EMAIL PROTECTED] wrote: Leopold Toetsch [EMAIL PROTECTED] wrote: Syntax proposal: .sub foo @MULTI .invocant Integer a .invocant Float b .param pmc c ... Alternate syntax: .sub foo multi(Integer, Float) .param pmc a .param pmc b .param pmc c And another one: .multi sub foo .sub foo__Int_Num_Str Integer,Float:String .sub foo__Num_Int_Any Float,Integer,pmc .endmulti .sub foo__Int_Num_Str ... .sub foo__Num_Int_Any ... The C.multi defines a group of multi subs with it's short name. The members are plain subroutines with their long names. Name mangling is done by Perl6. leo
Re: [perl #34442] [TODO] *BooleanArray PMCs should use single bit per bool
Bernhard Schmalhofer (via RT) wrote: This was mentioned by Leo in Ticket 34934 and 30230: Oh well, while at it, the *BooleanArray should just use one bit per item not an INTVAL. I'll tackle that. First I'll propable take a look at Bit::Vector in Perl5, as there are propably a lot of interesting methods on a boolean array. Great, thanks. There are even CPUs with processor instructions for counting set bits. Does that call for some inline assembler in PMC C-code? Not yet IMHO. But I can imagine that PGE might need all available speed hacks. Let's see. CU, Bernhard leo
Re: [PROPOSAL] MMD: multi sub syntax
Bob Rogers [EMAIL PROTECTED] wrote: From: Leopold Toetsch [EMAIL PROTECTED] .sub foo multi(Integer, pmc: String) .param pmc a .param pmc b .param pmc c - try to dispatch on the first two types in the first place - if there is a tie, consider the type of the 3rd argument leo I've only read half of A12 by now, and am still digesting what I've read (and that may take a while), but the section headed multi sub * (tradition multimethods) seems to say that the dispatcher never considers anything after the last colon. So perhaps you meant: .sub foo multi(Integer, pmc: String:) It depends: if the Cmulti just contains the MMD signature my version is fine. The next question is, what happens if you define a method with the long name: .sub bar multi(Integer, Float: Float) and I define one with .sub bar multi(Integer: String, Integer) That would mean that the long names have different name length in this case. It seems to me that can't work, but if A12 rules it out, I couldn't find it. If the multi sub is called with an Integer argument (or a class derived from Integer) all bar methods of these classes are included in the candidate list. The different long name length doesn't matter for that. If this is supposed to work, then how should MMD handle disagreement about invocant groups? And if the answer is simply to ignore it, and treat each method independently, doesn't this screw up the distance metric? The distance to your method will be computed on the first two values, whereas the distance to mine will be computed on only the first, so the two distances will be incommensurable, true? Seems so yes. Except, if shorter (not so specific) long names get a penalty. This seems to need clarification from p6l. TIA, -- Bob Rogers leo
Re: [perl #34430] [PATCH] MRO breaks Tcl
William Coleda [EMAIL PROTECTED] wrote: Switching tclobject seems to work fine here. I suspect you might have something else going on. I don't have any diffs WRT CVS. Strange. leo
[Pugs] Some experiments with the for loop
This little program worked as I expected:
my @x = ( abc\n, defg\n );
for @x - $k {
print($k);
# length() and bytes() seem not implemented yet (?) ...
# so try to get length via split
my $len = +split(, $k);
say(len=$len);
}
So far so good. Now try this instead:
my @x = ( abc\n, defg\n );
for @x {
print($_); # ok
# print; # yet this does not print anything
my $len = +split(, $_); # this works
# my $len = +split();# this fails (no compatible split found)
say(len=$len);
}
This one also ran ok (note: run with a text file argument @ARGS[0]):
my $fh = open(@ARGS[0]);
for =$fh {
print($_);
my $len = +split(, $_);
say(len=$len);
}
However, I'm a bit confused because S02 states:
Input from a filehandle is no longer done with angle brackets. Instead
of
while (HANDLE) {...}
you now write
for *$handle {...}
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? :-)
/-\
Find local movie times and trailers on Yahoo! Movies.
http://au.movies.yahoo.com
