Re: Private contracts?
On Thu, 3 Oct 2002, Trey Harris wrote: : In a message dated Thu, 3 Oct 2002, Allison Randal writes: : > So far, classes are uppercase and properties are lowercase, but that's : > convention, not law. : : Do runtime (value) properties and compile-time (variable) properties share : the same namespace? In general, no. : That is, to go back to an earlier discussion, if there is a system-defined : value property C which marks a value as true in boolean contexts, : can I also define a compile-time property C that makes the variable : evaluate as true, whatever its value? No, I think the boolean test would probably ignore the variable at that point. Think of variable properties as more of a "tie". The variable could contrive to always return a true value, but that's about it. There's unlikely to be any implicit relationship between variable properties and value properties. A major exception to that might be that the type declared on the variable is checked against the value's type at appropriate times. Larry
Re: Private contracts?
On Fri, Oct 11, 2002 at 05:50:55PM -0700, Larry Wall wrote: > On Sat, 5 Oct 2002, Allison Randal wrote: > : use Acme::N-1_0; # or whatever the format of the name is > > I don't see why it couldn't just be: > > use Acme::1.0; I agree thats better. But why not separate the version more by using a different separator than :: between the module name and the version. Or even something like use Acme[1.0]; > After all, we don't have package names starting with numbers right now... Er, we do. http://search.cpan.org?perldoc?Pod::Simple::31337 It would seem that (currently) only the top-level namespace may not start with a number. But I would also not that CPAN only has 3 such modules, all by the same author and all ::31337 Graham.
Re: Private contracts?
* Larry Wall ([EMAIL PROTECTED]) [12 Oct 2002 10:51]: [...] > use Acme::1.0; > After all, we don't have package names starting with numbers right now... Well, there's than Pod::Simple::31337, which confused search.cpan.org for a bit. But none which _start_ with a number, no. cheers, -- Iain.
Re: [PATCH] Removing two-arg ne
Nicholas Clark wrote:
> On Fri, Oct 11, 2002 at 05:01:49PM -0400, Dan Sugalski wrote:
>
>>At 9:02 PM +0100 10/11/02, Nicholas Clark wrote:
>>
>
>>>I would like to kill all generated variants of all the 3 argument opcodes
>>>where both input arguments are constants. They truly are superfluous.
>>Where both operands are ints or nums, I think it's a good idea. I'm
>>less sure in the case where there's a PMC or string involved, as
>>there may be some assumption of runtime behaviour (in the case of
>>constant PMCs that might have some methods overloaded) or strings
>>where the compiler is expecting runtime conversion to happen before
>>whatever gets done.
Ok, we need 2 + 3 args PMC ops becaus of overloading.
> I think I agree with this reasoning. I was really thinking of the ints
> as being easiest to bump off, providing we can be sure that things will
> consistently for bytecode compile on a 32 bit parrot, but run by a 64
> bit parrot (or likewise for different length floating point)
By preprocessing ints and nums, we would move overflow/precision issues
from the running machine to the compiling machine. But the issue itself
would remain.
So we could end up with:
add_i_icadd_n_nc
add_i_i_i add_n_n_n
add_i_i_ic add_n_n_nc
add_i_ic_i add_n_nc_n
where the latter could be tossed, when the assebler/imcc swaps
arguments. This saves 6 opcodes for each and and ~2 opcodes
for each , and . with constants could be rewritten
to . Saving a total of ~20 ops.
Some 2 operand bitwise operations are there some not - there is no
consistency - I would remove the to operand bitwise integer ops.
> More free speedup. I had this crazier idea - experiment with splitting
> every parrot function out into its own object file, and see what happens
> with permuting the order of all of them.
I have s small shell script (attached), which generates opcode coverage
for all PBC files in the parrot tree:
total ops 866
ops types 177
op usage stat
540 op-list-all
161 op-list-s
So only ~2/3 opcodes are currently used/tested (ops types/op-list-s are
ops short names w/o variants).
To run the script do:
make test
cd languages/perl6
make
perl6 --test
cd -
make disassemble
./op-stat
> But I think I need a lot of tuits, and a decent way of doing permutations
> with genetic algorithms. (I've got access to a fast machine, but it will
> have to stop smoking perl5 for the duration).
This would keep the machine busy for some time ;-) Interesting idea.
> Nicholas Clark
leo
#!/bin/sh
DIS=disassemble
[ -e .op-list1 ] && rm .op-list1
[ -e op-list-all ] && rm op-list-all
[ -e op-list-s ] && rm op-list-s
find . -name '*.pbc' -fprint /dev/stderr -exec $DIS {} \; |
sed -e's/^[[:blank:]]*L[0-9]*://' | \
sed -e's/^[[:blank:]]+//' | cut -d\ -f1 >> .op-list1
sort < .op-list1 | uniq -c | sort -rg > op-list-all
sort < .op-list1 | sed -e's/_.*//' | uniq -c | sort -rg > op-list-s
echo
T=`grep NAME lib/Parrot/OpLib/core.pm | wc -l`
S=`grep NAME lib/Parrot/OpLib/core.pm | sort | uniq | wc -l`
echo total ops $T
echo ops types $S
echo op usage stat
wc -l op-list* | head -2
signal 11 when run on x86, JIT enabled
Perhaps this is a known issue... Most parrot programs seem to crash on x86 when the latest CVS parrot is compiled with "-O2" or "-g -O2" and when JIT is enabled. The programs appear to run to completion and only crash prior to exitting. Repeatable on both Cygwin and Linux x86. When JIT is not used, everything is fine. Cygwin: gcc version 2.95.3-5 (cygwin special) Linux: gcc 2.96 $ perl ./assemble.pl examples/assembly/mops.pasm | ./parrot -j - Iterations:1 Estimated ops: 2 Elapsed time: 1.133729 M op/s:176.409004 Segmentation fault (core dumped) $ gdb ./parrot core GNU gdb 5.1.1 #0 runops_jit (interpreter=0x80f7a90, pc=0x810e668) at interpreter.c:239 239 Interp_flags_CLEAR(interpreter, PARROT_JIT_FLAG); (gdb) print interpreter $1 = (struct Parrot_Interp *) 0x1 (gdb) where #0 runops_jit (interpreter=0x80f7a90, pc=0x810e668) at interpreter.c:239 #1 0x080499c4 in runops (interpreter=0x80f7a90, code=0x810e4f0, offset=0) at interpreter.c:371 #2 0x08070dbc in Parrot_runcode (interpreter=0x80f7a90, argc=1, argv=0xb9ac) at embed.c:311 #3 0x0809e67a in main (argc=1, argv=0xb9ac) at test_main.c:50 #4 0x400a9280 in __libc_start_main () from /lib/libc.so.6 `interpreter' seems to change in value from 0x80f7a90 to 0x1 when it drops out of the call to `(jit_code) (interpreter);' The stack (or stack pointer?) appears to be corrupted. parrot compile flags: -fno-strict-aliasing -I/usr/local/include -g -O2 -Wall -Wstrict-prototypes -Wmissing-prototypes -Winline -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Waggregate-return -Winline -W -Wno-unused -Wsign-compare -I./include -DHAS_JIT -DI386 -DHAVE_COMPUTED_GOTO __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com
Win32 src test failure
Hello all,
While writing the "getting started" guide, I was playing with the tests.
(I am on Windows XP). I noticed that the src tests fail or are not
even run for Win32.
I tinkered with it for a while and got some of the tests to pass. It
turns out there was a linking problem. The libparrot.def file does not
define some of the exports.
So I:
1) added some of the missing functions in the def file.
2) ran nmake shared
3) moved libparrot.dll to the parrot dir
4) took out the wierd TODO:{ } thingy from t/src/intlist.pl
5) ran perl t/harness t/src/intlists.pl
6) and it passed
Problem seems to be in the
parrot/config/gen/libparrot_def/libparrot_def.in file. What mechanism
is supposed to keep this up to date?
I added these:
intlist_get
intlist_push
intlist_new
Since I am only playing around and am a Parrot novice. Would someone
tell me if I have found something. Or did I just stumble on something
that everyone else knew. Either way I feel like I am starting to get a
handle on this stuff, and am looking forward to being a productive coder
soon.
If you want. I think I can get the other src tests working (if it's the
same problem). I may need some guidance with the proper procedure.
Can someone explain this odd syntax? Is this an odd type of comment?:
TODO: {
local $TODO="t/src doesn't work on Windows" if $^O =~ /Win32/;
$TODO=$TODO; #warnings
...
...
...
}
Thanks,
Erik
Re: [perl #17864] [PATCH] Warnings fixes
Simon Glover (via RT) <[EMAIL PROTECTED]> writes: > Brent's sprintf patch introduced a couple of new warnings here: > > exceptions.c: In function `do_panic': > exceptions.c:69: warning: signed and unsigned type in conditional > expression > trace.c:22: warning: no previous prototype for `dump_pmc' > > These seem to be harmless and the enclosed patches fix them. > > Simon I was about submitting nearly the same patch. A little too late... [...] > --- include/parrot/trace.h.oldFri Oct 11 11:45:41 2002 > +++ include/parrot/trace.hFri Oct 11 11:46:50 2002 > @@ -15,6 +15,8 @@ > > #include "parrot/parrot.h" > > +void dump_pmc(struct Parrot_Interp *interpreter, PMC* pmc); > + > void trace_key_dump(struct Parrot_Interp *interpreter, PMC *key); > > void trace_op_dump(struct Parrot_Interp *interpreter, opcode_t * code_start, I had also renamed the function dump_pmc to trace_dump_pmc because all function in trace.h are prefixed with trace, but I was not clear if this is necessary. bye b. -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
[perl #17876] [PTACH] Parrot_snprintf writes 1 char too much
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #17876]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17876 >
I didn't look, if this is really intended, but I wouldn't like to behave
Parrot_snprintf different then snprintf(3).
It would also be nice, if we could have a return value, consistent with
glibc 2.1.
leo
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/39675/32138/4b302e/snprintf.patch
--- parrot/misc.c Fri Oct 11 10:00:38 2002
+++ parrot-leo/misc.c Sat Oct 12 13:11:01 2002
@@ -65,15 +65,22 @@
Parrot_vsnprintf(struct Parrot_Interp *interpreter, char *targ,
size_t len, const char *pat, va_list args)
{
-STRING *ret = Parrot_vsprintf_c(interpreter, pat, args);
+STRING *ret;
+if (len == 0)
+return;
+len--;
+if (len) {
+ret = Parrot_vsprintf_c(interpreter, pat, args);
string_transcode(interpreter, ret, NULL, NULL, &ret);
if (len > ret->bufused) {
len = ret->bufused;
}
+if (len)
memcpy(targ, ret->strstart, len);
-targ[len + 1] = 0;
+}
+targ[len] = 0;
}
STRING *
--- parrot/t/src/sprintf.t Fri Oct 11 10:00:43 2002
+++ parrot-leo/t/src/sprintf.t Sat Oct 12 13:14:00 2002
@@ -21,11 +21,15 @@
double dval;
FLOATVAL fltval;
char *fmt;
+ char dest[20];
struct Parrot_Interp * interpreter;
interpreter = Parrot_new();
Parrot_init(interpreter, (void*) &dummy_var);
+ Parrot_snprintf(interpreter, dest, 2, "%s", "CERT");
+ printf("%s\n",dest);
+
S = Parrot_sprintf_c(interpreter, "Hello, %s\n", "Parrot!");
printf(string_to_cstring(interpreter, S));
@@ -81,6 +85,7 @@
return 0;
}
CODE
+C
Hello, Parrot!
PerlHash[0x100]
PerlHash[0x100]
Re: Private contracts?
On Sat, 5 Oct 2002, Allison Randal wrote: : use Acme::N-1_0; # or whatever the format of the name is I don't see why it couldn't just be: use Acme::1.0; After all, we don't have package names starting with numbers right now... Larry
Re: Interfaces
On Fri, 11 Oct 2002, Michael Lazzaro wrote:
: On Friday, October 11, 2002, at 04:11 PM, Larry Wall wrote:
: > has Nose $.snout;
: > has Ear @.ears is cut("long");
: > has Leg @.legs;
: > has Tail $.tail is cut("short");
: >
: > method Wag () {...}
: > }
:
: What's the rationale again for the dot in $.snout? Does it imply that
: it should be
:
: method .Wag () {...}
:
: to match?
Yes, that's part of it, presuming you actually meant:
method .snout () {...}
It also doesn't look like either a lexical or a global when you use
it within the method. I always hated that about C++.
I suppose it could be argued that the . is redundant within a "has",
but I kinda like the consistency. It could also be argued that
the '$' should be dropped on scalar attributes, but that's another
consistency thing. You can certainly drop it within the methods,
since there's also the accessor methods.
Larry
RE: Private contracts?
On Fri, 4 Oct 2002, Garrett Goebel wrote:
: That wasn't the way I remembered it from Apoc 4... The following example is
: not in A4, but its what I inferred from it...
:
: Class Foo {
: method eat($food) is abstract {
: PRE { ... }
: POST { ... }
: }
: }
A4 was proposing those for a different purpose, and confusing the issue with DBC.
Those are now FIRST and LAST, and the pre/post syntax is still undecided.
Larry
Re: Private contracts?
On Fri, 4 Oct 2002, Peter Haworth wrote:
: This is the one nice thing about the Pascal-like syntax of Eiffel. It allows
: this situation to be unambiguous and sensibly ordered (as well as giving each
: condition labels, so that violations can be better reported):
:
: foo(this: ThisType, that: ThatType): FooType IS
: REQUIRE
: small: this <= 42
: half: that = this / 2
: DO
: -- implementation goes here
: ENSURE
: fooed_ok: RESULT = baz(this) + that
: END
:
: If you're declaring an abstract feature, just replace the whole DO clause with
: "DEFERRED".
That is exactly what a literal C< {...} > means in Perl 6, and why it's required on
forward declarations of
anything that takes a block, if you really mean it that way. You can't say
sub foo;
in Perl 6. You have to say
sub foo {...}
: Also notice how Eiffel's syntax also somehow makes statement
: terminators completely optional.
Yes, well, let's not go there... :-)
: Aren't sub declarations in Perl 6 all expressions? Why couldn't we put the
: post condition at the end, then?
:
: sub foo($this, $that) is memoized is something
: is pre{ $this <= 42 }
: is pre{ $that == $this / 2 }
: {
: # implementation goes here
: } is post{
: # postcondition 1
: } is post{
: # postcondition 2
: }
:
: If you want an abstract method, just omit the implementation block.
The absence of something is hard to notice. Put {...} for an abstract method.
Larry
Re: [perl #17876] [PTACH] Parrot_snprintf writes 1 char too much
In message <[EMAIL PROTECTED]> Leopold Toetsch (via RT) <[EMAIL PROTECTED]> wrote: > I didn't look, if this is really intended, but I wouldn't like to behave > Parrot_snprintf different then snprintf(3). > > It would also be nice, if we could have a return value, consistent with > glibc 2.1. One slight problem with makeing Parrot_snprintf consistent with snprintf is that there are at least three different ways that snprintf is implemented on different platforms. It's probably best to do whatever C99 does, which I think is the same as what glibc does, namely to return the amount of space that would be needed to avoid truncation if the result is truncated. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/
Re: [PATCH] Removing two-arg ne
On Fri, Oct 11, 2002 at 05:01:49PM -0400, Dan Sugalski wrote: > At 9:02 PM +0100 10/11/02, Nicholas Clark wrote: > >I would like to kill all generated variants of all the 3 argument opcodes > >where both input arguments are constants. They truly are superfluous. > > Where both operands are ints or nums, I think it's a good idea. I'm > less sure in the case where there's a PMC or string involved, as > there may be some assumption of runtime behaviour (in the case of > constant PMCs that might have some methods overloaded) or strings > where the compiler is expecting runtime conversion to happen before > whatever gets done. I think I agree with this reasoning. I was really thinking of the ints as being easiest to bump off, providing we can be sure that things will consistently for bytecode compile on a 32 bit parrot, but run by a 64 bit parrot (or likewise for different length floating point) IIRC C99 states that the pre-processor must do all calculations in its longest int type, and it's sort of related. I think we'd need to state that constant folding will be done at compile time, and will be done at the precision of the compiling parrot. > >It should make the computed goto core compile more rapidly. > > True, though I'm not hugely worried about this, as it happens only once. Per user who compiles parrot. The current computed goto code hurts my desktop at work (128M RAM, x86 linux) and with more ops it will get worse. It may turn out that gcc improves to the point that it can build measurably better code for specific CPUs, but distributions/*BSDs require a lowest common denominator build (typically 486 in the x86 family, isn't it?) In which case many people may gain quite a lot by building their own custom parrot, and they're going to notice the compile time. I admit this is low down any list of priorities, but it ought to be somewhere. I find with my work code (the C, not perl related) that gcc3.2 with all the stops out generates code that was about 5% faster than deadrat's (default 2.96 heresy non-)gcc. And at YAPC::EU someone reported that (IIRC) he'd seen 12% speedup from newer gcc and option tweaking. And getting even 5% without changing your perl6 code or parrot's code is nice. However, the more interesting thing about getting compile times down is you get more smoke in finite time. (And also developers get more done if they spend less time waiting for the compiler. BUT EVERYONE SHOULD ALREADY BE USING ccache AS THAT MAKES REBUILDS AND EDITING COMMENTS DAMN FAST (unless they can think of good reason not to)) > True. I think reordering is a bigger win, honestly. Lightly used > opcode functions won't get swapped in until they're really needed. More free speedup. I had this crazier idea - experiment with splitting every parrot function out into its own object file, and see what happens with permuting the order of all of them. But I think I need a lot of tuits, and a decent way of doing permutations with genetic algorithms. (I've got access to a fast machine, but it will have to stop smoking perl5 for the duration). Although potentially I'll end up with an order optimised for x86 FreeBSD, which should keep the Linux vs FreeBSD performance arms race going nicely. Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
RE: Win32 src test failure
Erik Lechak:
# Problem seems to be in the
# parrot/config/gen/libparrot_def/libparrot_def.in file. What
# mechanism
# is supposed to keep this up to date?
I'm not directly involved in maintenance of this file, but at a glance
it looks like it's only supposed to include functions in the external
interfaces.
Others who know more about this than I: Is that assessment correct? If
so, what should we do about these tests? (My personal opinion is that
we shouldn't use libparrot.[so|dll] for these; we should link in the
..[o|obj] files directly. After all, we're testing the guts of
Parrot...)
# I added these:
#
# intlist_get
# intlist_push
# intlist_new
#
# Since I am only playing around and am a Parrot novice. Would someone
# tell me if I have found something. Or did I just stumble on
# something
# that everyone else knew. Either way I feel like I am
# starting to get a
# handle on this stuff, and am looking forward to being a
# productive coder
# soon.
#
# If you want. I think I can get the other src tests working
# (if it's the
# same problem). I may need some guidance with the proper procedure.
It certainly looks like you're on to something. I'd suggest you wait on
continuing this until we get word on the correct solution. We wouldn't
want to waste your work, after all.
Good work, by the way. This problem has been bugging me for a while,
but I doubt I know enough about how linkers work to have tracked down
the problem.
# Can someone explain this odd syntax? Is this an odd type of comment?:
# TODO: {
# local $TODO="t/src doesn't work on Windows" if $^O =~ /Win32/;
# $TODO=$TODO; #warnings
#...
#...
#...
# }
That notation is common to Perl test files; if $TODO is set, the test
harness (t/harness, the program that runs all the tests and tallies up
the results) is supposed to ignore any tests that fail within that
block. Unfortunately, somehow the TODO isn't getting to the
harness--probably a bug in Parrot::Test::c_output_is, and probably
something recently introduced, since the $TODO worked fine when I added
it a week or so ago. I'll look into this if some time pops up from
behind a bush or something. :^)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Re: Interfaces
On Tue, Oct 08, 2002 at 05:00:20PM -0400, Michael G Schwern wrote: > Unfortunately, Java doesn't ship with JUnit nor do Java libraries usually > ship with tests nor does a simple convention to run them nor an expectation > that the user will run the tests before installing. Score one for Perl. :) I blame that Schwern character, and his partner in crime, Chromatic. They keep encouraging us to use more 'tests'; Very bad habit - I mean, with more tests we'll probably be shipping software with less bugs, and where's that going to lead? I tell you, less bugs mean less jobs for us programmers, and that's not good. We'll have trouble occupying all the time that will free up. We might even be forced to do fun stuff. :-) Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: Private contracts?
On Thu, 3 Oct 2002, John Williams wrote:
: On Thu, 3 Oct 2002, Trey Harris wrote:
:
: > Incidentally, has there been any headway made on how you DO access
: > multiple classes with the same name, since Larry has (indirectly) promised
: > us that? I.e., I import two classes "LinkedList" and "BTree", both of
: > which define a "Node" class?
:
: Hopefully, LinkedList defines a LinkedList::Node class, and BTree defines
: a BTree::Node class. Either by explicitly naming them that or by virtue
: of being defined as an "inner" class (which might also make it private).
A private inner class:
my class Node {...}
A public inner class:
our class Node {...}
That last one actually declares a subclass of the current class, just as
our $foo;
puts $foo into the current package.
Larry
Re: Private contracts?
On Thu, 3 Oct 2002, Michael G Schwern wrote:
: On Thu, Oct 03, 2002 at 05:23:08PM -0500, Jonathan Scott Duff wrote:
: > I don't know, but I think it's supposed to be like this:
: >
: > # part of the signature
: > method turn($dir,$ang) is pre { $ang <= 20 } {
: > ...
: > }
: >
: > # part of the implementation
: > method turn($dir,$ang) {
: > PRE { $ang <= 20 }
: > ...
: > }
: >
: > turn() methods of derived classes would inherit the precondition in the
: > first case but not the second. I don't know why you'd want to do this
: > exactly, but it seems to me that perl should allow it.
:
: I see us already smashing too many things into the method signature as it
: is. It will rapidly get messy if you have a method with a complex signature
: and a handful of attributes and preconditions.
:
: Also, where do the postconditions go? In the signature at the front? That
: doesn't make sense, it should go at the end so you can keep them in mind
: when you're writing the return code.
:
: Consider...
:
: method foo($this, $that) is memoized is something
: is pre { $this <= 42 }
: is pre { $that == $this / 2 }
: is pre { a lot of code which is hard to
:shove into a block of code
:this close to the right margin }
: is post { what is a post condition
: doing at the front? }
: {
: ...
: }
:
: They can, of course, be pulled back from the margin:
:
: method foo($this, $that) is memoized is something
: is pre { $this <= 42 }
: is pre { $that == $this / 2 }
: is pre { now we have a little bit more room to play with using
: a differnt indentation style }
: is post { but post conditions are still distanced from the
:code which return()s }
: {
: ...
: }
:
: I realize that conditions are technically part of the signature, but putting
: them in there paints us into a stylistic corner.
Hmm. It sounds like a cry for help. :-)
method foo($this, $that) is memoized is something
{
...
}
# Additionaly...
also &foo
is pre { $this <= 42 }
is pre { $that == $this / 2 }
is pre { now we have a little bit more room to play with using
a differnt indentation style }
is post { but post conditions are still distanced from the
code which return()s };
One is tempted to make it:
also note that &foo is pre { ... }
It might be possible to allow "is" after the {...} block, much like an C block.
But an "also" would let us defer all the extras to the end of the class definition.
: I'm also not fond of the pre/PRE distinction. Few of the other special
: blocks (given, eval, try, invar, etc...) use all cap names. At least I hope
: not.
All caps indicates a BEGIN-like block that is not evaluated inline, but
sets a property in the surrounding scope. It's a useful distinction.
: Simply attaching an "is private" attribute to a pre condition block
: seems the simplest way to go about it.
Except that you'd have to parenthesize it:
is pre ({...} is private)
Otherwise it'd merely privatize whatever the first "is" is "issing".
: Just like any other private thing,
: it's not inherited and not visible outside the current class. "pre" vs
: "PRE" doesn't convey that meaning.
Well, yes it does, because the pre is in the declaration, and the
PRE is embedded in the implementation, albeit known at compile time.
Not that we're necessarily going to have PRE/POST blocks anyway,
but that's how they'd parse.
I think it'd be kinda strange (but possible (but possibly useless))
to have a declaration like:
sub foo {
...
PRE { @_ > 0 }
}
That is, the precondition would go away as soon as you redefined the {...}.
Larry
Re: Private contracts?
On 4 Oct 2002, Aaron Sherman wrote:
: There are a very large number of good things that I think we should put
: into properties for meta-programming purposes (e.g. constraints,
: assertions, optimization hints, documentation, etc).
:
: For example:
:
: sub f(int $a is constrained($a>=1,"must be positive),
: documented("an integer"))
: is constrained(some_global_condition),
: documented("applies transformation f to an integer") {
: ...
: }
Another good reason to allow:
sub f(int $a is constrained($a>=1,"must be positive),
documented("an integer")) {
...
}
also &f is constrained(some_global_condition),
documented("applies transformation f to an integer");
or possibly even
sub f(int $a) {
also $a is constrained($a>=1,"must be positive),
documented("an integer");
...
}
also &f is constrained(some_global_condition),
documented("applies transformation f to an integer");
One could argue that, given that "is" is always compile-time, the "also"
is redundant.
sub f(int $a) {
$a is constrained($a>=1,"must be positive),
documented("an integer");
...
}
&f is constrained(some_global_condition),
documented("applies transformation f to an integer");
But maybe that's too weird.
Larry
Re: perl6 operator precedence table
[EMAIL PROTECTED] (Larry Wall) writes: > I'm not sure either, and that's why I'm thinking about it. :-) Phew. -- Only two things are infinite: the Universe and human stupidity, and I'm not sure about the former - Albert Einstein
Re: perl6 operator precedence table
[EMAIL PROTECTED] (Larry Wall) writes: > I was thinking more along the lines of: > > $x &&& $y > $x ||| $y This isn't Perl; this is merely some language that looks a bit like it. I can understand the attraction for confusing anyone who comes from a standard Unix language background, but I'm not sure it's a great idea, all told. -- By God I *KNOW* what this network is for, and you can't have it. - Russ Allbery, http://www.eyrie.org/~eagle/writing/rant.html
popping an empty intlist
Hi there, I just discovered that: a) my befunge interpreter is broken (would you stop beaking it please? :o)) b) push and pop operations are now supported by lists c) there's a pmc for handling list of integers: intlist I'll get back to point a) later when I'll have investigated it. Point c) is interesting because intlists are supposed to be faster. And since Befunge is sometimes used for critical tasks (such as kernel scheduling), I thought I had to take advantage of intlists. :-) Point b) is interesting too, since I wrote my own PUSH and POP routines in Parrot assmbly. Now, I can get rid of them... That's what I wanted to do. I switched from PerlArray to IntList, and converted my PUSH and POP routines into push and pop calls... But I have a problem. When popping a value from an empty list, I get a "No entries on list!" exception. Instead, I want to get a zero. I can add something like: CHECK_EMPTY: set I0, P2 eq I0, 0, PUSH_ZERO ret PUSH_ZERO: push P2, 0 ret And then, before popping, I can add "bsr CHECK_EMPTY"... But that's clumsy IMHO. So, what else can I do? Catching exceptions (is that possible with Parrot)? Jerome -- [EMAIL PROTECTED]
Re: the getting started guide
On Thu, 10 Oct 2002 00:37:22 -0400, [EMAIL PROTECTED] (Erik Lechak) wrote: --snip-- >Where can I get a reliable port of cvs for Windows? >My old executable (v1.11)works fine. Here are some pointers for you, and for possible inclusion in your "getting started" document. CVSHome.org is re-organizing their site, and the Win32 command-line client is hard to find. Here is the direct URL for the latest version: http://ftp.cvshome.org/win32/cvs-1-11-2.zip Concurrent Versions System (CVS) 1.11.2 (client) cvs.exe dated 2002-05-06 I just now tested that client against the parrot CVS server; it works: set CVSROOT=:pserver:[EMAIL PROTECTED]:/cvs/public cvs login cvs -Q -z3 checkout parrot Please consider using -z in your CVS commands; See Dan's message on this: http:[EMAIL PROTECTED]/msg12054.html http://nntp.x.perl.org/group/perl.perl6.internals/12061 The old CvsGui.org site, which covers CVS GUIs for multiple platforms has moved onto the WinCvs site: http://www.wincvs.org/ Here is command-line CVS or Mac (Old-school and OS-X): http://ftp.cvshome.org/macintosh/ And finally, a Google directory for those who desire further research: http://directory.google.com/Top/Computers/Software/Configuration_Management/Tools/Concurrent_Versions_System/ Hope this helps, Bruce Gray
Re: Private contracts?
> sub f(int $a is constrained($a>=1,"must be positive),
> documented("an integer")) {
> ...
> }
>
I now realize I'm a little fuzzy on the yada-yada-yada operator. What
exactly is it... or what does it do? Is it a statement, an
expression? Could you say things like:
foo(...);
(Admittedly I have no idea what that would mean) Is it just something
that does nothing?
sub f() {
print "Don't see me\n";
}
sub f() {
# do other stuff
}
f;
Would do the same as using ... in the former? I hope not (though I
suppose that's what Perl 5 does). Is it more special than that?
Luke
Re: perl6 operator precedence table
At 3:55 PM -0700 10/11/02, Larry Wall wrote: >On 11 Oct 2002, Simon Cozens wrote: >: [EMAIL PROTECTED] (Larry Wall) writes: >: > I was thinking more along the lines of: >: > >: > $x &&& $y >: > $x ||| $y >: >: This isn't Perl; this is merely some language that looks a bit like >: it. I can understand the attraction for confusing anyone who comes >: from a standard Unix language background, but I'm not sure it's a >: great idea, all told. > >I'm not sure either, and that's why I'm thinking about it. :-) I think that, for me at least, it'll be close enough to C to be really confusing. (I already have the problem of leaving parens off of my function calls when I write XS code...) There's a certain appeal to not having to swap in almost-but-not-quite-the-same sets of punctuations when moving from language to language. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: perl6 operator precedence table
On 11 Oct 2002, Simon Cozens wrote: : [EMAIL PROTECTED] (Larry Wall) writes: : > I was thinking more along the lines of: : > : > $x &&& $y : > $x ||| $y : : This isn't Perl; this is merely some language that looks a bit like : it. I can understand the attraction for confusing anyone who comes : from a standard Unix language background, but I'm not sure it's a : great idea, all told. I'm not sure either, and that's why I'm thinking about it. :-) Larry
Re: Private contracts?
In a message dated Fri, 11 Oct 2002, Larry Wall writes:
> A public inner class:
>
> our class Node {...}
>
> That last one actually declares a subclass of the current class, just as
>
> our $foo;
>
> puts $foo into the current package.
When you say "subclass", do you mean "below the current class in the
naming heirarchy", i.e.
class BTree;
our class Node {...}
would create BTree::Node? Or do you really mean *subclass*, i.e., "our
class" causes Node to inherit from BTree? I hope it's the former, but the
word "subclass" does usually imply inheritance
Trey
Re: the getting started guide
>4)How do I get pod2html to give me html that looks like the docs on >http://www.parrotcode.org/docs/? Ha! :) We're using a slightly tweaked (by Graham Barr for search.cpan.org) version of POD::POM and a stylesheet. You can find the stylesheet here: http://dev.perl.org/perl-styles.css Once HTML support in Pod::Simple is done, we may move to that. Also, if your getting started guide is added to the parrot documentation in the CVS, it will automatically end up on /docs/. -R
Re: perl6 operator precedence table
On Friday, Oct 11, 2002, at 23:21 Asia/Tokyo, Aaron Crane wrote: > Vaguely heretical, I know, but I'd be inclined to do something like > this: > > Perl 5 Proposed Perl 6 > $x && $y $x & $y > $x || $y $x | $y > > $x & $ybitand($x, $y) > $x | $ybitor($x, $y) Objection, your honor. perl5 ($x & $y) might be uncommon enough to justify this. But how about &= vs. &&=, |= vs. ||= ? Those are both used very often so by saving one symbol we lose consistency. Dan |= MAN | FATHER | PERL5POTER | tobe->user->(PERL6)
