Outlaw the \ddd notation
Hi, there~ Perl 5 uses the \ddd notation to index characters by octal numbers (e.g. \187 and \13). Now that Perl 6 has the shiny new \o and \o[] notations, we probably need to outlaw the legacy stuff explicitly in S02 since we have the assumption that everything not mentioned in the Synopses is assumed to stay the same as in Perl 5. Therefore, in Perl 6, \187 eq '187' will hold. BTW, Audrey also thinks it's necessary to add a snippet to S02. :=) Cheers, Agent
[patch] do EXPR
Hello~
Here is a snippet from the Pugs test suite:
{
my $ret = eval 'do 42';
ok(!$ret, 'do EXPR should not work', :todo);
# XXX or should it? Feels weird...
}
which motivated me to create the following patch for S04:
Index: D:/projects/Perl6-Syn/S04.pod
===
--- D:/projects/Perl6-Syn/S04.pod (revision 10955)
+++ D:/projects/Perl6-Syn/S04.pod (working copy)
@@ -349,8 +349,9 @@
$x = do if $a { $b } else { $c };
-This construct only allows you to prefix a statement. If you want to
-continue the expression after the statement you must use the curly form.
+This construct only allows you to prefix Ione statement (or an expression).
+If you want to continue the expression after the statement you must use the
+curly form.
Since Cdo is defined as going in front of a statement, it follows
that it can always be followed by a statement label. This is particularly
Cheers,
Agent
rt problem
Hello,
Yesterday i sent my first patch to parrotbug {at} parrotcode.org
according to the instructions in docs/submissions.pod .
I wanted to check if it actually arrived anywhere, so i tried to look
at rt.perl.org , created a bitcard account, and attempted to fetch
some tickets, but i can see none.
If i go to the Parrot todo list ( http://www.parrotcode.org/todo.html
) and click on a ticket there, i get an error: RT error - No
permission to view ticket. But if i log out and then try to view a
ticket as an anonymous user, i can see its contents.
Is there some problem with the rt server, or am i doing something wrong?
(I apologize if it's a silly newbie question.)
P.S. The file docs/submissions.pod says that to commit patches one
needs an account at https://auth.perl.org/auth/account , and
rt.perl.org login page says that aut.perl.org are no longer required.
Thanks,
--
Amir Elisha Aharoni, http://aharoni.blogspot.com/
We're living in pieces,
I want to live in peace. - Thurston Moore
__
Please avoid sending me Word or PowerPoint attachments
http://www.gnu.org/philosophy/no-word-attachments.html
Re: designing a test suite for multiple implementations (tools thread)
On Mon, Aug 14, 2006 at 07:12:06PM -0700, chromatic wrote: PS - sbk30, please don't send me any more automated followup messages. Fix your mailing software. I've found that our resident neighbourhood BOFHs have been very helpful at forcibly un-subscribing anyone anti-social enough to be sending automated crap in response to mailing list messages. (Given the full headers of the offensive message. BOFH contact details being in the message headers of any message distributed by the list) Nicholas Clark
Re: ===, =:=, ~~, eq and == revisited (blame ajs!) -- Explained
David Green writes: I guess my problem is that [1,2] *feels* like it should === [1,2]. You can explain that there's this mutable object stuff going on, and I can follow that (sort of...), but it seems like an implementation detail leaking out. The currently defined behaviour seems intuitive to me, from a starting point of Perl 5. The difference between: my $new = [EMAIL PROTECTED]; and: my $new = [EMAIL PROTECTED]; is that the second one is a copy; square brackets always create a new anonymous array rather than merely refering to an existing one, and that's the same thing that's happening here. Think of square brackets as meaning something like Array-new and each one is obviously distinct. And I feel this way because [1,2] looks like it should be platonically unique. I'd say that C (1, 2) looks like that. But C [1, 2] looks like it's its own thing that won't be equal to another one. Smylers
Re: ===, =:=, ~~, eq and == revisited (blame ajs!) -- Explained
David Green writes: On 8/13/06, Smylers wrote: Please could the proponets of the various behaviours being discussed here share a few more concrete examples ... OK, Thanks for that. In summary, if I've understood you correctly, it's that: =:= two aliases to the same actual variable === one variable contains a copy of the other's actual contents eqv both contain contents which represent the same thing but may have come from different sources And that being true at one level implies being true for the above levels. Yes? === Example: Suppose I have some employee objects, and I employ two John Smiths. They have the same name, work in the same department, and by stunning coincidence everything my class knows about them just happens to be the same. Except that they wouldn't. Because each one would have a separate payroll number, or some artificial thing invented just for the sake of being different. So this example doesn't sound plausible to me. But they're still different objects (the payroll system definitely needs to produce two cheques, although since they earn the same salary, it doesn't matter which one of them gets which cheque); so $john1 !=== $john2, and I can tell them apart. And why on earth would you be making such a comparison? If you have a list of employees who need cheques then you just iterate through them and process them in turn; you wouldn't be comparing an arbitrary pair of them. So I now understand what this operator does. But I'm still struggling to fathom where I would ever have a use for it. Smylers
[svn:perl6-synopsis] r10969 - doc/trunk/design/syn
Author: larry Date: Tue Aug 15 08:40:59 2006 New Revision: 10969 Modified: doc/trunk/design/syn/S02.pod Log: Explicitly outlawed \123 and the like. Modified: doc/trunk/design/syn/S02.pod == --- doc/trunk/design/syn/S02.pod(original) +++ doc/trunk/design/syn/S02.podTue Aug 15 08:40:59 2006 @@ -12,9 +12,9 @@ Maintainer: Larry Wall [EMAIL PROTECTED] Date: 10 Aug 2004 - Last Modified: 14 Aug 2006 + Last Modified: 15 Aug 2006 Number: 2 - Version: 64 + Version: 65 This document summarizes Apocalypse 2, which covers small-scale lexical items and typological issues. (These Synopses also contain @@ -1365,11 +1365,25 @@ =item * -Characters indexed by hex, octal, and decimal numbers can be interpolated -into strings using either C\x123 (with C\o and C\d behaving -respectively) or using square brackets: C\x[123]. Multiple -characters may be specified within any of the bracketed forms by -separating the numbers with comma: C\x[41,42,43]. +Characters indexed by hex numbers can be interpolated into strings +by introducing with C\x, followed by either a bare hex number +(C\x263a) or a hex number in square brackets (C\x[263a]). +Similarly, C\o12 and C\o[12] interpolate octals, while +C\d1234 and C\d[1234] interpolate decimals--but generally +you should be using hex in the world of Unicode. Multiple characters +may be specified within any of the bracketed forms by separating the +numbers with comma: C\x[41,42,43]. You must use the bracketed +form to disambiguate if the unbracketed form would eat too many +characters, because all of the unbracketed forms eat as many characters +as they think look like digits in the radix specified. None of these +notations work in normal Perl code. They work only in interpolations +and regexes and the like. + +The old C\123 form is now illegal, as is the C\0123 form. +Only C\0 remains, and then only if the next character is not in +the range C'0'..'7'. Octal characters must use C\o notation. +Note also that backreferences are no longer represented by C\1 +and the like--see S06. =item *
[svn:perl6-synopsis] r10970 - doc/trunk/design/syn
Author: larry Date: Tue Aug 15 08:41:37 2006 New Revision: 10970 Modified: doc/trunk/design/syn/S02.pod Log: typo Modified: doc/trunk/design/syn/S02.pod == --- doc/trunk/design/syn/S02.pod(original) +++ doc/trunk/design/syn/S02.podTue Aug 15 08:41:37 2006 @@ -1383,7 +1383,7 @@ Only C\0 remains, and then only if the next character is not in the range C'0'..'7'. Octal characters must use C\o notation. Note also that backreferences are no longer represented by C\1 -and the like--see S06. +and the like--see S05. =item *
[svn:perl6-synopsis] r10971 - doc/trunk/design/syn
Author: larry
Date: Tue Aug 15 08:52:46 2006
New Revision: 10971
Modified:
doc/trunk/design/syn/S04.pod
Log:
Clarifications on Cdo with bare expression.
Modified: doc/trunk/design/syn/S04.pod
==
--- doc/trunk/design/syn/S04.pod(original)
+++ doc/trunk/design/syn/S04.podTue Aug 15 08:52:46 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall [EMAIL PROTECTED]
Date: 19 Aug 2004
- Last Modified: 14 Aug 2006
+ Last Modified: 15 Aug 2006
Number: 4
- Version: 34
+ Version: 35
This document summarizes Apocalypse 4, which covers the block and
statement syntax of Perl.
@@ -349,8 +349,15 @@
$x = do if $a { $b } else { $c };
-This construct only allows you to prefix a statement. If you want to
-continue the expression after the statement you must use the curly form.
+This construct only allows you to attach a single statement to the end
+of an expression. If you want to continue the expression after the
+statement, or if you want to attach multiple statements. you must use
+the curly form. Since a bare expression may be used as a statement,
+you may use Cdo on an expression, but its only effect is to function
+as an unmatched left parenthesis, much like the C$ operator in
+Haskell. That is, precedence decisions do not cross a Cdo boundary.
+Conjectural: a Cdo may be used within a subexpression, but only if
+terminated by an unmatched right bracket of some kind.
Since Cdo is defined as going in front of a statement, it follows
that it can always be followed by a statement label. This is particularly
Re: ===, =:=, ~~, eq and == revisited (blame ajs!) -- Explained
David Green schreef: === ...is equality-of-contents, basically meaning that the things you're comparing contain the same [...] values. How about strings; are normalized copies used with the === ? http://www.unicode.org/faq/normalization.html http://www.unicode.org/notes/tn5/ -- Affijn, Ruud Gewoon is een tijger.
Re: More review of current stm branch code
On Fri, Aug 11, 2006 at 04:38:59PM -0400, Charles Reiss wrote:
On 8/10/06, Chip Salzenberg [EMAIL PROTECTED] wrote:
/* XXX is it okay to combine flatten/slurpy into one flag? */
The answer is No: flat is an output flag, slurpy_array is an input
flag, and there's no guarantee that the input and output flags won't
conflict with each other. So I guess this means that something has to
change.
I suppose trying to make '@' mean something different for signatures and
for calls from C (as I have done) is a Bad Idea as long as the same code
is used to parse the signatures in both cases. The easy solution is to
choose a character other than '@' for one of the directions though I can't
think of what might be most natural ('F' for flat?).
To provide a general ability to wrap any call from C, then you need to add
named parameter support too; flat arrays are _so_ Perl 5. Would '%' and 'N'
work for you? :-) (also see below)
MORE QUESTIONS
* The '@' character for native call signatures is new, and AFAICT is just
syntactic sugar, since the caller could do the array creation himself.
Could you explain what you would have to do if you didn't introduce this
feature? (I'm not necessarily against it, mind you, I just want to know
what the deal is.)
It is just syntactic sugar. So, not using would be as you describe, having
the (most likely PIR) caller construct the array manually. My use of this
feature is only to allow naturally passing an arbitrary number of
arguments to the subroutine that is first executed in a new thread, which
I feel is quite convenient.
Well, as it happens, we've been wanting support for variadic PMC METHODs for
a Long Time. Since you're already introducing necessary infrastructure, are
you inclined to add some PMC METHOD syntactic sugar too, so that we can
conveniently define METHODs that accept arbitrary parameter lists? (This
is not a merge blocker, of course; just a wishlist item.)
* Another comment asks:
# autogenerate for exotic types
# (XXX is this appropriate or do we want them to each
# be explicitly cleared to have the variant?)
Well, that depends. Is there currently any way for a named METHOD to
specify whether it is :write, and if so, is this used? If so, then yes,
making an automatic ro variant is OK. If not, then I think we might
want such a thing...?
The read-only variant generation currently does not handle NCI methods
at all. There are number of implementation options; the best I can
think of is to override findmethod (in the read-only type) to check
for a property on the found method PMC that would indicates it writes
(or vice-versa).
That's actually kind of neat; at least, it's clearly the least bad of all
the options I see.
The only minor downside IMO is that in order to get adequate speed we'll
need to dedicate an easy-to-see flag bit somewhere visible in the method PMC
to mean :write, and there are only so many of those. But fast threading
is hardly a minor feature, so I don't mind that cost at all.
A bigger issue for automatic read-only variant generation is that MMD
methods currently don't do any read-onlyness detection. (Sorry!) (This is
not quite as much as a problem as it may seem because things like String
and Integer, being designed to allow subclassing, call vtable methods from
their MMD methods to do any manipulation.)
Understood, agreed.
As a stopgap solution, it would be easy to reverse the logic I have
now and default to not generating a read-only version except when the
.pmc file says it is okay instead of the other way around.
Well, this is still 0.4, not 1.0. If you can just tell us on the list what
we shouldn't do, so we can include it in the release notes, then I don't
mind having only partial protection. For obvious reasons, nobody's using
the thread support right now, so it won't break anything. ...Or will it?
--
Chip Salzenberg [EMAIL PROTECTED]
Re: More review of current stm branch code
On Sat, Aug 12, 2006 at 08:14:52PM -0400, Charles Reiss wrote: I wrote: The read-only variant generation currently does not handle NCI methods at all. There are number of implementation options; the best I can think of is to override findmethod (in the read-only type) to check for a property on the found method PMC that would indicates it writes (or vice-versa). This is done (w/ s/findmethod/find_method/ of course), returning PMCNULL instead of a method that would write. (This prevents it from being called, but doesn't yield helpful errors.) Yow, done already! Excellent. (Shoulda read the followup first.) It also does not allow .pmc files to overide the default idea of whether a vtable method is read-only. This remains unresolved though I'm not certain it should be allowed. The hard part of doing it correctly is handling inheritance. It's an interface guarantee, and as such I think it's OK that it can't be overridden in a derived class. Agree? A bigger issue for automatic read-only variant generation is that MMD methods currently don't do any read-onlyness detection. (Sorry!) This is now fixed. Yow^2! Nice work. -- Chip Salzenberg [EMAIL PROTECTED]
Register Allocator
Hi, I read the #parrotsketch log from today. I cannot join the IRC now. The Graph based Register allocation is good for statically compiled languages like C. The real value of Graph Based allocation comes when you have limited number of registers and have to spill some of the variables to memory. Which variable goes to memory is decided by a cost function. The other issue might be Def-Usage (DU) chains. In a 9000 lines sub this might be getting to large. Going to Single Static Assignment(SSA) form eliminates the need of DU chains. I plan on implementing SSA in Byte Code Generator. But that is future. I need some decisions to be made on POST nodes to continue my work with BCG. In Parrot we do not have to worry about spilling as we can assume we have infinite number of registers of I,P,N and C type. Linear Scan allocation is good but would require some time to implement as it goes after the data collected from live varaible analysis. The simpler solution is to not do any optimization for reducing the number of registers. This is fine for now as we are in a development phase. IMHO getting things working is more important than optimization. I should be able to hack up a vanilla register allocation scheme that does no live variable analysis to find overlapping registers to reduce the number of registers. Currently I have implemented this scheme in Byte Code Generator (compilers/bcg/src/bcg_reg_alloc_vanilla.c). All this does is it makes sure each varaible gets a unique register. The quality of the code generate might not be good but this should be very fast in compile time performance compared to Graph Based allocator. This should be simple to do and we can still keep the graph allocator but only run it when the optimization flag -Ox is used. Let me know your thoughts. I'll try to catch you guys later on IRC. -- Thanks, Vishal
=== and array-refs
On 8/14/06, Smylers wrote: David Green writes: I guess my problem is that [1,2] *feels* like it should === [1,2]. You can explain that there's this mutable object stuff going on, and I can follow that (sort of...), but it seems like an implementation detail leaking out. The currently defined behaviour seems intuitive to me, from a starting point of Perl 5. But is Perl 5 the best place to start? It's something many of us are used to, but that doesn't mean it's the best solution conceptually, even if it was the most reasonable way to implement it in P5. The reason I think it's an implementation wart is that an array -- thought of as a single, self-contained lump -- is different from a reference or pointer to some other variable. Old versions of Perl always eagerly exploded arrays, so there was no way to refer to an array as a whole; put two arrays together and P5 (or P4, etc.) thinks it's just one big array or list. Then when references were introduced, array-refs provided a way to encapsulate arrays so we could work with them as single lumps. It's not the most elegant solution, but being able to nest data structures at all was a tremendous benefit, and it was backwards-compatible. P6 doesn't have to be that backwards-compatible -- it already isn't. P6 more naturally treats arrays as lumps; this may or may not be *implemented* using references as in P5, but it doesn't have to -- or at least, it doesn't have to *look* as though that's how it's doing it. Conceptually, an array consisting only of constant literals, like (1,2,3), isn't referring to anything, so it doesn't need to behave that way. The difference between: my $new = [EMAIL PROTECTED]; and: my $new = [EMAIL PROTECTED]; is that the second one is a copy; square brackets always create a new anonymous array rather than merely refering to an existing one, and that's the same thing that's happening here. Think of square brackets as meaning something like Array-new and each one is obviously distinct. I agree that [EMAIL PROTECTED] should be distinct from [EMAIL PROTECTED] -- in the former case, we're deliberately taking a reference to the @orig variable. What I don't like is that [EMAIL PROTECTED] is distinct from [EMAIL PROTECTED] -- sure, I'm doing something similar to Array-new(1,2) followed by another Array-new(1,2), but I still want them to be the same, just as I want Str-new(foo) to be the same as Str-new(foo). They're just constants, they should compare equally regardless of how I created them. (And arrays should work a lot like strings, because at some conceptual level, a string is an array [of characters].) And I feel this way because [1,2] looks like it should be platonically unique. I'd say that C (1, 2) looks like that. But C [1, 2] looks like it's its own thing that won't be equal to another one. Except [1,2] can look like (1,2) in P6 because it automatically refs/derefs stuff so that things Just Work. That's good, because you shouldn't have to be referencing arrays yourself (hence my point above about an array conceptually being a single lump). But if we're going to hide the [implementational] distinction in some places, we should hide it everywhere. Actually, my point isn't even about arrays per se; that's just the implementation/practical side of it. You can refer to a scalar constant too: perl -e 'print \1, \1' SCALAR(0x8104980)SCALAR(0x810806c) They're different because the *references* are different, but I don't care about that. A reference to a constant value is kind of pointless, because the value isn't going to change. References to *variables* are useful, because you never know what value that variable might have, and refs give you a pointer to the current value of the variable at any time. The fact that it's even possible to take a reference to a literal is kind of funny, really; but since in P5 you had to be explicit about (de)referencing, it didn't hurt, and you could maybe even find some cute ways to take advantage of it (such as an easy way to get unique IDs out of the str/numification of a ref?). P6 just lets you gloss over certain ref/deref distinctions that in a perfect world wouldn't have existed in the first place. Leibniz's identity of indiscernibles is a perfectly practical principle to pursue in programming. Now [EMAIL PROTECTED] may be discernible from [EMAIL PROTECTED] or [1, @orig] from [1, @other], but \1 is completely the same as \1 in all ways -- all ways except for being able to get a representation of its memory location. And that's not anything about 1, that's a bit of metadata about the reference itself -- something that definitely is based on the implementation. (I can imagine some other implementation where in a ridiculous attempt to optimise for minimal memory footprint, everything with a value of 1 points to the same address. When I say $a=1; $a++, $a first points to
Re: ===, =:=, ~~, eq and == revisited (blame ajs!) -- Explained
On 8/14/06, Smylers wrote: David Green writes: Thanks for that. In summary, if I've understood you correctly, it's that: =:= two aliases to the same actual variable === one variable contains a copy of the other's actual contents eqv both contain contents which represent the same thing but may have come from different sources And that being true at one level implies being true for the above levels. Yes? Right. (Where the ordering for above means =:= implies ===, and === implies eqv, but not in the other direction, of course.) === Example: Suppose I have some employee objects, and I employ two John Smiths. They have the same name, work in the same department, and by stunning coincidence everything my class knows about them just happens to be the same. Except that they wouldn't. Because each one would have a separate payroll number, or some artificial thing invented just for the sake of being different. So this example doesn't sound plausible to me. Well, I didn't say it was a *good* payroll system! OK, it's a silly contrived example; maybe my objects should have represented the reticulated flanges I have in stock, since one piece of inventory is the same as any other. Except I wouldn't really create an object for each one, I'd just have a single group-object that contained a $num_available counter (Anyone cleverer than I should feel free to jump in with a better example.) So I now understand what this operator does. But I'm still struggling to fathom where I would ever have a use for it. Maybe you wouldn't -- eqv is what most of us will use most of the time, I expect (being the ordinary everyday parallel to == and eq). But since it is possible to use variables both by value and by reference, there still needs to be a way to work with and compare both of them when you want to do fancy advanced stuff. -David
Re: More review of current stm branch code
On 8/15/06, Chip Salzenberg [EMAIL PROTECTED] wrote: On Sat, Aug 12, 2006 at 08:14:52PM -0400, Charles Reiss wrote: I wrote: [snip] It also does not allow .pmc files to overide the default idea of whether a vtable method is read-only. This remains unresolved though I'm not certain it should be allowed. The hard part of doing it correctly is handling inheritance. It's an interface guarantee, and as such I think it's OK that it can't be overridden in a derived class. Agree? Er, when I first read that I thought you meant that with respect to the inheritance issue, but reading again I'm not sure. But, anyways, looking over pmc2c I found that doing it 'properly' was not too difficult, so I've done that (read/writeness is inherited by default and can be overridden). I provide the feature in the hope that people will think really hard before using it to violate interface guarantees. -- Charles Reiss
[PROPOSED PATCH] Add Parrot::Embed to Repository
Here's a proposed patch that seems to work okay for me on Linux. It's not great or beautiful, mostly because of the Makefile hackery. It's a starting point though. I suspect Windows might complain. I don't have any particular attachment to any approach here, only that this get in the repository somehow. -- c === MANIFEST == --- MANIFEST (revision 20216) +++ MANIFEST (local) @@ -201,6 +201,7 @@ config/gen/makefiles/dynpmc.in [] config/gen/makefiles/dynpmc_pl.in [] config/gen/makefiles/editor.in [] +config/gen/makefiles/ext.in [] config/gen/makefiles/languages.in [] config/gen/makefiles/parrot.pc.in [] config/gen/makefiles/past.in[] @@ -637,6 +638,15 @@ examples/tge/branch/lib/Branch.pir [main]doc examples/tge/branch/lib/Leaf.pir[main]doc examples/tge/branch/transform.pir [main]doc +ext/Parrot-Embed/t/embed.t [devel] +ext/Parrot-Embed/t/greet.pir[devel] +ext/Parrot-Embed/lib/Parrot/Embed.xs[devel] +ext/Parrot-Embed/lib/Parrot/Embed.pm[devel] +ext/Parrot-Embed/Changes[devel] +ext/Parrot-Embed/MANIFEST [devel] +ext/Parrot-Embed/typemap[devel] +ext/Parrot-Embed/Build.PL [devel] +ext/Parrot-Embed/README [devel] include/parrot/builtin.h[main]include include/parrot/caches.h [main]include include/parrot/cclass.h [main]include === config/gen/makefiles/root.in == --- config/gen/makefiles/root.in (revision 20216) +++ config/gen/makefiles/root.in (local) @@ -186,6 +186,7 @@ compilers/tge/Makefile \ compilers/bcg/Makefile \ editor/Makefile \ +ext/Makefile \ languages/Makefile \ languages/amber/Makefile \ languages/APL/Makefile \ === config/gen/makefiles/ext.in == --- config/gen/makefiles/ext.in (revision 20216) +++ config/gen/makefiles/ext.in (local) @@ -0,0 +1,64 @@ +# $Id: /parrotcode/offline/config/gen/makefiles/languages.in 19764 2006-08-03T18:17:04.907999Z chromatic $ + +# setup of commands [EMAIL PROTECTED]@ +PERL = @perl@ +MAKE = @make_c@ +RM_F = @rm_f@ + +# add new languages here +# remove obsolete languages here +EXT = \ +Parrot-Embed + +# the default target +all: $(EXT) + +# hard-code these for now +test: Parrot-Embed + - cd Parrot-Embed $(PERL) Build test + +clean: Parrot-Embed + - cd Parrot-Embed $(PERL) Build clean + +# This is a listing of all targets, that are meant to be called by users +help: + @echo + @echo Following targets are available for the user: + @echo + @echo all: Make a lot of language implementations. + @echo This is the default. + @echo test: Unified test suite for a lot of languages. + @echo + @echo clean:Clean up a lot of languages. + @echo + @echo help: Print this help message. + @echo + @echo smoke:Run the test suite and send smoke.html to + @echo http://smoke.parrotcode.org/; + @echo + @echo smoke-clean: clean up smoke.html + @echo + @echo + @echo Following languages are available: + @echo $(LANGUAGES) + @echo A particular language lang can be built, tested and cleand up + @echo make lang + @echo make lang.test + @echo make lang.clean + @echo For the status of individual languages see LANGUAGES.STATUS.pod + @echo + +clean: \ +Parrot-Embed.clean + +# +# Extension specific targets +# + +# The *.dummy targets are a replacement for the target .PHONY in 'GNU make' + +Parrot-Embed : Parrot-Embed.dummy + +Parrot-Embed.dummy: + - cd ext/Parrot-Embed $(PERL) Build.PL $(PERL) Build === config/gen/makefiles.pm == --- config/gen/makefiles.pm (revision 20216) +++ config/gen/makefiles.pm (local) @@ -117,6 +117,11 @@ replace_slashes = 1 ); genfile( +'config/gen/makefiles/ext.in' = 'ext/Makefile', +commentType = '#', +replace_slashes = 1 +); +genfile( 'config/gen/makefiles/parrot.pc.in' = 'parrot.pc' ); === ext/Parrot-Embed/Build.PL == --- ext/Parrot-Embed/Build.PL (revision 20216) +++
Re: === and array-refs
It seems to me that there is some confusion being given in this thread and the most recent parts of its predecessor (which can lead to FUD in the wrong hands), so I'll briefly try to clear it up, as I would like to think I understand the issues. At 2:51 PM -0600 8/15/06, David Green wrote: On 8/14/06, Smylers wrote: David Green writes: I guess my problem is that [1,2] *feels* like it should === [1,2]. You can explain that there's this mutable object stuff going on, and I can follow that (sort of...), but it seems like an implementation detail leaking out. There are no implementation details leaking out, but rather we are just dealing with the declared interface behaviour of different types and operators. I agree that [EMAIL PROTECTED] should be distinct from [EMAIL PROTECTED] -- in the former case, we're deliberately taking a reference to the @orig variable. What I don't like is that [EMAIL PROTECTED] is distinct from [EMAIL PROTECTED] -- sure, I'm doing something similar to Array-new(1,2) followed by another Array-new(1,2), but I still want them to be the same, just as I want Str-new(foo) to be the same as Str-new(foo). They're just constants, they should compare equally regardless of how I created them. (And arrays should work a lot like strings, because at some conceptual level, a string is an array [of characters].) You are right, but we have both Seq and Array types, so depending which one you use, you want either the === or eqv operators to do what you want. There is no reason that === should say 2 Array are equal; we have eqv for that, or use 2 Seq instead of 2 Array if you want === to return true on the same values. So, (1,2) always === and eqv (1,2), but [1,2] only eqv [1,2] and [1,2] generally !=== [1,2]. First of all, in Perl 6, there are no separate arrays and array refs; we simply have the 'Array' type, which is treated as a lump on its own. More generally, there are no reference types in Perl 6. We do have a concept of multiple symbols being aliases for the same container, and they only come to be that way if they are explicitly aliased, such as with $a := $b; only in those cases, the operator =:=, which sees if 2 symbols represent the same container, would return true. If you create 2 values separately and don't explicitly alias them like that, =:= will return false, even if the 2 containers have appearances of the same value. Both the === and eqv operators test the actual values of 2 containers, but that their semantics differ in regards to mutable containers. Given an immutable container/type, such as a number or Str or Seq, both will always return true if the values are the same. With a mutable container, such as an Array, only eqv will return true if the value is the same, and === will return false for 2 containers having the same value. The difference between === and eqv is that, if you have 2 symbols, $a and $b, and $a === $b returns true, then that result is guaranteed to be eternal if you don't assign to either symbol afterwards. For a mutable type like an Array, === returns false on 2 containers because it can't guarantee that someone else holding another symbol for either container won't change its content, and so $a or $b could change after we made the === test, without us causing that to happen, and so for mutable types, === only returns true for 2 aliases, because that is the most it can guarantee that they will be the same. By contrast, eqv does not make the eternal guarantee, and works only on snapshots, so eqv can safely deep-compare mutable types like Arrays, since even if one of them changes afterwards, it doesn't matter, since eqv only guaranteed them equal for that point in time when it executed. It is important for some applications to distinguish whether the result of an equivalence test will be valid eternally or not, and hence we have multiple analagous types and multiple equality tests, where pairwise they distinguish eternally vs snapshot. We can say exactly what we mean, and it is unambiguous, which is a GOOD thing. -- Darren Duncan
stm ready (was Re: More review of current stm branch code)
So, given the below, looks like we've got everything sewn up and the long-awaited day of the STM merge is upon us. Charles, care to do the honors? On Tue, Aug 15, 2006 at 06:31:38PM -0400, Charles Reiss wrote: On 8/15/06, Chip Salzenberg [EMAIL PROTECTED] wrote: On Sat, Aug 12, 2006 at 08:14:52PM -0400, Charles Reiss wrote: I wrote: It also does not allow .pmc files to overide the default idea of whether a vtable method is read-only. This remains unresolved though I'm not certain it should be allowed. The hard part of doing it correctly is handling inheritance. It's an interface guarantee, and as such I think it's OK that it can't be overridden in a derived class. Agree? Er, when I first read that I thought you meant that with respect to the inheritance issue, but reading again I'm not sure. Yes, that's what I meant. But, anyways, looking over pmc2c I found that doing it 'properly' was not too difficult, so I've done that (read/writeness is inherited by default and can be overridden). Works For Me, thanks. I provide the feature in the hope that people will think really hard before using it to violate interface guarantees. Big friendly warnings are the right first step. If people start ignoring the signs and wandering onto the live minefields, we'll have to start thinking about audio warnings and fierce guards with pointed sticks. -- Chip Salzenberg [EMAIL PROTECTED]
