Re: String concatentation operator
[EMAIL PROTECTED] (Larry Wall) writes:
> While no assumption is going unquestioned for Perl 6, I do still
> believe that the decision not to overload + for concatenation is one
> of the few things I did right in Perl 1.
Fair enough. And maybe I'm getting ahead of myself (or behind myself)
anyway. Presumably those who want Ruby-style can do something resembling
sub operator:+(STRING, STRING) { $^a ~ $^b }
anyway.
--
I've looked at the listing, and it's right!
-- Joel Halpern
Bitwise operators any("and", "are") junctions
Apologies if this has already been covered, but I haven't been able to keep up to date much recently. It occurs to me that the distinction between the use of &, | and ^ for bitwise ops and their use for junctions can be flattened. For instance, consider $a = 2 | 3; print $a; Of course, it could say JUNCTION(0xDEADBEEF) but here's another way of looking at it. Given that we have a junction of two integers, we look at the zeroth bit of the junction. If ANY of the zeroth bits in 2 and 3 are set, then we set the zeroth bit in the result. If ANY of the first bits in 2 and 3 are set, then we set the first bit in the result. Hey presto, we've just defined bitwise or in terms of junctions. Because basically, that's what people do with bitwise ops - they munge a bunch of values together, and look to see if any or all of a certain bit in the result is true. From that point of view, junctions are just a delayed version of what people are already doing with bitwise ops. This naturally leads to ^ being syntactic sugar for the one() operator, but I don't know if that's been already covered either. -- You're all sick, except Simon. And he's sick, too. -- Kake Lemon Pugh
RE: Bitwise operators any("and", "are") junctions
Simon Cozens:
# $a = 2 | 3;
# print $a;
#
# but here's another way of looking at it. Given that we have a
# junction of two integers, we look at the zeroth bit of the
# junction. If ANY of the zeroth bits in 2 and 3 are set, then
# we set the zeroth bit in the result. If ANY of the first bits
# in 2 and 3 are set, then we set the first bit in the result.
# Hey presto, we've just defined bitwise or in terms of junctions.
Yup, and that's what we're doing (last I heard). Except that we'll make
them say something like C so they don't accidentally do
the Wrong Thing. (Of course, the C (or whatever) class would
probably do this conversion implicitly for, say, passing into a
subroutine.)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
"If you want to propagate an outrageously evil idea, your conclusion
must be brazenly clear, but your proof unintelligible."
--Ayn Rand, explaining how today's philosophies came to be
Re: C#/Parrot Status
"Iacob Alin" <[EMAIL PROTECTED]> writes: > This might be a stupid question, but are this datatypes going to be > PMCs? And a related question: What about trapping integer arithmetic?
Re: [perl #18565] [PATCH] Simple exception message improvement
Juergen Boemmels <[EMAIL PROTECTED]> writes: > Without varargs macros this is not really simple. (IIRC they are > introduced in C99, but are in gcc for years now). Indeed, C99 standardized them, but in a way that differs from GCC.
Re: Selfbootstrapping compilers (Was: faq)
[EMAIL PROTECTED] (Brent Dax) writes: > We have to--otherwise we can't have the self-modifying parser Larry > desperately wants. That's funny. I wondered precisely why I'd been working on self-modifying parsers in C. -- 10. The Earth quakes and the heavens rattle; the beasts of nature flock together and the nations of men flock apart; volcanoes usher up heat while elsewhere water becomes ice and melts; and then on other days it just rains. - Prin. Dis.
Re: long double error
On Sat, 23 Nov 2002, David Robins wrote: > When's the long double "KNOWN ISSUE" going to be fixed? What's the work > around, just to build a perl with NV==double? I've looked around, can't > find anything about it except in KNOWN_ISSUES (only match in RT is > "Parrot_sprintf-related stuff"). Scan of the archives turns up nothing. It's (at least partly) a packfile alignment thing. I think if you look in the packfile.c sources you'll find some more comments about it. (Search for problem spots marked with "XXX".) Also, if you look in the archives back in Februrary 2002 or so, I think I posted something about the "padding of FLOATVALs in CONSTANT section of bytecode". This, of course, doesn't answer your question about when it's going to be fixed :-). -- Andy Dougherty [EMAIL PROTECTED]
Re: Learning curve
Philippe 'BooK' Bruhat <[EMAIL PROTECTED]> writes: > I suppose it's very doable to have a FrenchPerl6 editor/parser/whatever > that makes most of this transparent, but the thing I like the most about > programming languages it that their are foreign languages. Microsoft once made a huge experiment in the realm of localized programming languages. It turned out to be a failure, even in an environment where code sharing is not as important as it is among Perl coders.
Re: Dynamic scoping (take 2)
If I misunderstood you -- correct me. It seems that all you worry
about is that you want some variable be seen in several subroutines
.. you propose a mechanism of passing them between desired subroutins
by default through all the dynamical chain of sub calls "connecting
them. It seems , on the other hand , that there is already existing
and ( to my taste ) simpler mechanism of making several subroutines (
and in general -- any lexical scopes ) share *the same* variable --
package ... ;
sub a { our $x is private ; ... } ; #...but see below ...
sub b { our $x is private ; ... } ;
so $x is *package* variable that can be seen *only* from "a" and "b".
it plays the role of "mailbox" : "a" can put there whatever it want to
pass to "b" . "b" should know about it ( and it knows because it
declares $x inside its body ) and should fetch whatever it wants.
it seems that this mechanism is cleaner and clearer and .. more
intuitive.
although...
on the second thought I have a feeling that I am pulling "is private"
property too much -- this way of using it was not discussed in Exe3.
so probably we should invent the property that does exactly that :
this variable is package *but* it is seen only from *several* lexical
scopes , something like this :
package ... ;
sub a { our $x is shared ; ... } ;
sub b { our $x is shared ; ... } ;
we can even prescribe which lexical scope is allowed to change it :
package ... ;
sub a { our $x is shared is rw; ... } ;
sub b { our $x is shared is ro; ... } ;
but maybe this is abuse for rw and ro here -- so this should be
package ... ;
sub a { our $x is shared(rw) ; ... } ;
sub b { our $x is shared(ro) ; ... } ;
also there is one thing that bothers me about even the original "is
private" property : what if my package is *really big* and I have in
two distant places two function that each want its own "static"
variable that they declare as Exe3 prescribe as
our $var is private;
but since I dont remember about having two such subs I can happen to
give them the same name - so that naively they will be aliased to the
same package variable . Now, with "is private" that is , probably not
a problem , because compiler can notice this and complain about it .
but If I want to pull similar mechanism for *sharing* variables --
this becomes a problem -- compiler cannot know that I wanted to share
one variable $x between aub A and sub B and *another* variable (
which I mistakenly called $x too ) between sub C and sub D . In this
case it will share $x between *all four* subs. I dont know how to
stop this source of errors . currently . but anyway that is what
bothered me with "is private" property.
anyway, my feeling is that once it is necessary to pass variable far
enough it is clearer to do it with globals -- which are restricted to
be seen only in the restricted set of lexical scopes.
arcadi .
Me writes:
> In summary, I am proposing that one marks
> variables that are to be automatically
> passed from sub to sub with 'is yours'
> where appropriate.
>
> An example of what I'm suggesting follows.
> Code with brief comments first then explanation.
>
> {
> my $_; # $_ can't be touched
> # unless it is passed
> # to a sub explicitly.
>
> my $foo;# same for $foo
>
> my $baz is yours; # $baz will automatically
> $baz = 10; # be passed to /directly/
> # called subs that "ask"
> # explicitly for $baz.
>
> &waldo($foo);
> }
>
> sub waldo ($b ; $baz is yours)
> { print $baz; &emer; }
>
> sub emer (;$baz is yours(no))
> { print $baz; &qux; }
>
> sub qux { ... }
>
> Running this prints '1010'. Here's why:
>
> A property exists that can mark any lexical
> as "yours". When a variable is marked yours
> it is automatically passed to any directly
> called sub (not nested subs) that mentions
> it appropriately.
>
> The "automatic" $_ (available without
> declaring with a 'my') is marked "yours"
> by default.
>
> All other (ie declared) lexicals are, by
> default, not yours, hence guaranteed to be
> private lexicals unless explicitly passed
> to a sub. This is safer than the current
> perl 6 design in which use of $CALLER::,
> and even builtins and subs that merely
> use the topic, might accidentally clobber
> one of my lexicals at any time.
>
> Once execution reaches the body of waldo,
> there is a new lexical called $baz that is
> bound to the lexical with the same name in
> the body of the caller.
>
> The C in waldo's sig has two
> effects:
>
> 1. It requires that any /caller/ has a
>variable of the same name marked as
>yours or must pass a variable/value
>using the named arg syntax for that
>arg name;
>
> 2. It propogates the marking of $baz as
>a yours marked variable for any sub
>called
Re: Dynamic scoping (take 2)
I think , ( on the second reading of your post ) , that your proposal of "my $x is yours" is logically very similar to my proposal of "our $x is shared" but your proposal is cleaner if I understand it as follows ( although I like more "shared" instead of "yours" for that purpose ) : instead of aliasing the lexical variable variable $x to the variable of the same name in the *current package* is yours *create* a new (secret) symbol-table that is remembered by compiler to be associated with variable $x and *aliases* $x to the variable of the same name in that (secret) symbol-table . *Any* other instances of "$x is yours" *alias* $x to *the same* variable $x in that (same) secret symbol-table. I do understand that strictly speaking you proposal is *very* different -- since you want only those function that will *ever* call each other ( not necessarily directly ) to share ( by default ) some variable -- so you propose dynamic (???) sharing . I propose *static* sharing -- but in practice they are *the same* -- the only difference is that I may happen to make two functions that *never* call each other ( or never happen to be in the same dynamic scope ) to share the same variable . But I am in controll of this ( If I am carefull lI will not do it -- and share variables only between those functions that it makes sence to share between ). my point is that static sharing is simpler to understand ( to me ) and it is a simpler concept -- just some "mailbox" variable that "hangs" somewere above the "battlefield" that only several people can access . dynamic sharing is like a *red* message that have to be passed ( secretly ) every time a soldier have it happens to *meet* another soldier that know that it have to receive *red* message. and I am not talking about implementation . arcadi
Re: Numeric Literals (Summary 2)
On Wednesday, November 20, 2002, 6:16:41 PM, you (mailto:[EMAIL PROTECTED]) wrote: > On Monday, November 18, 2002, at 08:34 PM, Martin D Kealey wrote: >> On Tue, 2002-11-19 at 08:28, Michael Lazzaro wrote: >>> - floating point becomes allowed in explicit radix (and 0b,0c,0x) >> >> How can one have floating point if "E" is a valid digit? >> >> 0x1.0e1 # 1.054931640625 or 16 ? > Oops, sorry. I meant radix-point-but-not-exponential. It still seems > exponential notation in bases other than 10 is not possible, because of > "e". We could adopt the C99 version and use "p" or "P" for hex decimal values (this, reportedly, allows certain values not expressible in decimal for floats to be specified). Thus 0x.4Ap10 0xA.BCDp-15 (The exponent cannot be in hex in C99). However this clearly cannot generalise for all bases <= 36... -- Richard mailto:[EMAIL PROTECTED]
Re: long double error
At 9:20 AM -0500 11/24/02, Andy Dougherty wrote: On Sat, 23 Nov 2002, David Robins wrote: When's the long double "KNOWN ISSUE" going to be fixed? What's the work around, just to build a perl with NV==double? I've looked around, can't find anything about it except in KNOWN_ISSUES (only match in RT is "Parrot_sprintf-related stuff"). Scan of the archives turns up nothing. It's (at least partly) a packfile alignment thing. I think if you look in the packfile.c sources you'll find some more comments about it. (Search for problem spots marked with "XXX".) Also, if you look in the archives back in Februrary 2002 or so, I think I posted something about the "padding of FLOATVALs in CONSTANT section of bytecode". This, of course, doesn't answer your question about when it's going to be fixed :-). I'll try and get it fixed, but unfortunately I managed to kill the compiler on the only machine I have handy that does long doubles (Screwed up the headers on my RedRat 6.2 system somehow--if someone knows about fixing this sort of stuff, drop me a line off-list) so it might be a little while. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: C#/Parrot Status
At 1:46 PM +0100 11/24/02, Florian Weimer wrote: "Iacob Alin" <[EMAIL PROTECTED]> writes: This might be a stupid question, but are this datatypes going to be PMCs? And a related question: What about trapping integer arithmetic? That'll be done with the standard exception handling mechanism. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: C#/Parrot Status
Florian Weimer wrote: "Iacob Alin" <[EMAIL PROTECTED]> writes: This might be a stupid question, but are this datatypes going to be PMCs? And a related question: What about trapping integer arithmetic? Sorry for the ignorant question: This does mean what and implying that and whatsoever? A little bit more verbosity about requirements for data type extensions would be really helpful, (IMHO always). leo
Re: [perl #18622] [PATCH] Befunge now supports the pop and push instructions of the PerlArray PMC
At 9:34 AM + 11/23/02, Jerome Quelin (via RT) wrote: Well, the topic says it pretty much: befunge now supports the push and pop instructions builtin in PerlArray PMC, and I can get rid of my own crafted version of push and pop in Parrot Assembly. Fear, cause now I'll be able to find even more bugs! :-) Committed, with the appropriate amount of fear. :) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: C#/Parrot Status
At 8:07 PM +0100 11/24/02, Leopold Toetsch wrote: Florian Weimer wrote: "Iacob Alin" <[EMAIL PROTECTED]> writes: This might be a stupid question, but are this datatypes going to be PMCs? And a related question: What about trapping integer arithmetic? Sorry for the ignorant question: This does mean what and implying that and whatsoever? ..NET has exception-throwing versions of its math operations. If you do an add of two 8-bit integers and the result overflows, you should get an exception (if you've used the "check overflow" versions of the ops) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: C#/Parrot Status
Dan Sugalski <[EMAIL PROTECTED]> writes: > .NET has exception-throwing versions of its math operations. If you do > an add of two 8-bit integers and the result overflows, you should get > an exception (if you've used the "check overflow" versions of the ops) Actually, I thought about implementing Ada. The standard requires the following: 20. For a signed integer type, the exception Constraint_Error is raised by the execution of an operation that cannot deliver the correct result because it is outside the base range of the type. And this is painfully to implement if the machine doesn't support it (e.g. by overflow flags or trapping arithmetic). Unfortunately, in Ada, the base range of a type has to be known at compile time (at least if you want to use any existing compiler), so Ada needs fixed-width types, too.
Re: C#/Parrot Status
At 10:33 PM +0100 11/24/02, Florian Weimer wrote: Dan Sugalski <[EMAIL PROTECTED]> writes: .NET has exception-throwing versions of its math operations. If you do an add of two 8-bit integers and the result overflows, you should get an exception (if you've used the "check overflow" versions of the ops) Actually, I thought about implementing Ada. The standard requires the following: 20. For a signed integer type, the exception Constraint_Error is raised by the execution of an operation that cannot deliver the correct result because it is outside the base range of the type. And this is painfully to implement if the machine doesn't support it (e.g. by overflow flags or trapping arithmetic). Just becaues the base math ops don't throw exceptions doesn't mean that there can't be exception-throwing versions. :) We should get those added. Need to get exceptions done first, at least partially. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: C#/Parrot Status
On Sun, Nov 24, 2002 at 10:33:23PM +0100, Florian Weimer wrote: > Dan Sugalski <[EMAIL PROTECTED]> writes: > > > .NET has exception-throwing versions of its math operations. If you do > > an add of two 8-bit integers and the result overflows, you should get > > an exception (if you've used the "check overflow" versions of the ops) > > Actually, I thought about implementing Ada. The standard requires the > following: > > 20. For a signed integer type, the exception Constraint_Error is > raised by the execution of an operation that cannot deliver the > correct result because it is outside the base range of the type. > > And this is painfully to implement if the machine doesn't support it > (e.g. by overflow flags or trapping arithmetic). For integer maths if the machine uses 2s complement arithmetic I believe it's not that painful. (And even if it doesn't it's not hugely painful) [ie I think I know how to do it] Floating point fills me with fear. Nicholas Clark -- Befunge better than perl? http://www.perl.org/advocacy/spoofathon/
Re: Dynamic scoping (take 2)
> you propose a mechanism of passing [vars]
> between desired subroutins by default
> through all the dynamical chain of sub
> calls "connecting them.
There's more, or rather, less to it than that.
The same mechanism also includes a clean way
to pass "it", something that needs to be done.
And a way to smoothly extend that for user
defined "pronouns" like $first, $rest and
$last, through to mini-vocabularies like
$source, $target, $user, ...
(Imagine you pull in fop1, fop2, fop3 that
are file ops written by three independent
authors that just agreed to conventions on
naming args. With the mechanism I propose
you can now do something like:
my $source, $target, $user;
...
fop1;
fop2;
fop3;
To get this sort of simplicity, you have
to decouple inter-sub interfaces in a
couple ways, including arg positions and
package names.)
So I'm addressing several idioms that range
from passing one or two pronouns around in
the local vicinity, between a caller and a
called sub, to passing a whole suite of
values (an "environment") to an execution
thread and the far away subs it will contain.
> anyway, my feeling is that once it is
> necessary to pass variable far enough
> it is clearer to do it with globals --
> which are restricted to be seen only
> in the restricted set of lexical scopes.
That's name restriction, not the container.
This doesn't help when dealing with threads.
Basically, global /containers/ is the root
of all evil, not so much global names.
> package ... ;
> sub a { our $x is shared ; ... } ;
> sub b { our $x is shared ; ... } ;
This isn't thread-safe.
There are other significant issues too, but
I'll move on.
> [accidentally aliasing vars to the same global]
> I dont know how to stop this source of errors.
Having lots of little local namespaces that
get chained across long distances does away
with this problem.
--
ralph
Re: Dynamic scoping (take 2)
> I like more "shared" instead of "yours" But that's because that's the way you are thinking about the problem/solution. I'm just talking about a very local trick of having autoargs instead of explicitly passing args in parens. The fact that this ends up creating an elegant alternative to dangerous globals is in an important way a mere somewhat surprising side-effect that you don't even need to tell a newbie or even an expert. It just works. I've considered names like "passed", "autoarg", "implied", and so on. But ultimately yours seems to say it all: my $foo is yours; My means my lexical and yours means your lexical where sub calling is the boundary of what's mine and yours. > (secret) symbol-table I would have thought the symbol table handling for implicit (your) args would be the exact same as for regular explicit args passed in parens. > so you propose dynamic (???) sharing. > I propose *static* sharing -- but in > practice they are *the same* -- I'd claim that: 1. Autoargs would work with threads, static sharing won't. 2. By requiring explicit marking of autoargs all along the call chain, one retains a key advantage of explicitly passing args, namely avoidance of accidental action-at-a-distance. Just look at a sub's sig to know what is being shared between it and its callers. 3. Autoargs are significantly less verbose in many scenarios. 4. Autoargs are conceptually simpler than shared variables, for both newbies and experts. But clearly this is subjective. :> -- ralph
Re: long double error
On Sun, 24 Nov 2002, Dan Sugalski wrote:
> At 9:20 AM -0500 11/24/02, Andy Dougherty wrote:
> >On Sat, 23 Nov 2002, David Robins wrote:
> >> When's the long double "KNOWN ISSUE" going to be fixed? What's the work
> >It's (at least partly) a packfile alignment thing. I think if you look in
> >the packfile.c sources you'll find some more comments about it. (Search
> >for problem spots marked with "XXX".) Also, if you look in the archives
> >back in Februrary 2002 or so, I think I posted something about the
> >"padding of FLOATVALs in CONSTANT section of bytecode".
>
> I'll try and get it fixed, but unfortunately I managed to kill the
> compiler on the only machine I have handy that does long doubles
> (Screwed up the headers on my RedRat 6.2 system somehow--if someone
> knows about fixing this sort of stuff, drop me a line off-list) so it
> might be a little while.
I'm absolutely willing to try to fix it, given a few pointers in the right
direction. I've been stumbling around packfile.[ch]/packout.c to see how
things work.
Actually it looks like the problem is in assemble.pl's sub constant_table;
even though $PConfig{numvalsize} is 12, $PConfig{packtype_n} is 'd' and
pack('d',$n) uses 8 bytes. This is after hacking NUMVAL_SIZE to 12,
though, which explains why it wasn't caught in config/auto/pack.pl.
perldoc for pack shows no way to pack a native NV. Should assemble.pl be
using packout.c via XS/Inline? If this is decided to be the way to go then
I'd be glad to work on a patch to do it.
For now, since my concern is working on Cardinal (Ruby -> parrot), I'll hack
on a temporary Inline::C sub to assemble.pl to pack an NV for myself. With:
use Inline C => <[1]);'
with '$const .= packNV($_->[1]);' in assemble.pl's constant_table
sub, I was able to successfully build and run the IMCC sample.imc
(Mandelbrot) example and a few others in examples/ (and there was much
rejoicing).
Dave
Isa. 40:31
Re: C#/Parrot Status
Nicholas Clark wrote: > Floating point fills me with fear. If it makes you feel better, C# does not require overflow detection on floating-point operations. FP overflow results in +/-INF, underflow results in zero, and undefined is NAN. Only integer overflow detection is required, and then only on 32-bit, 64-bit, and native-sized integer types (8-bit types don't need it). If Parrot wants to add more opcodes for completeness sake, then it won't do any harm to us, but don't bend over backwards on FP for our sakes. Cheers, Rhys.
Re: Dynamic scoping (take 2)
Me writes:
>
> 4. Autoargs are conceptually simpler than
> shared variables, for both newbies and
> experts. But clearly this is subjective. :>
>
thats exactly the point where I tryed to improve. Think of me as a
newbe ( which I am ) -- If I understand your proposal , I can explain it to
myself through the "sort of" shared variable :
$x is yours
tells that $x is aliased to variable in some "secret scope symbol
table" that ( the table ) is shared between caller and callee
also, another way :
$x is yours
is like saying that all functions that will ever call each other (
that is, if in my programm A calls B and B calls C and ... , then I
will croup them in a group that "ever call each other" ) and
which each have a declaration "$x is yours" may be thought
of as being in special common *enclosing* lexical scope , at the top
of which there is a declaration
my $x ;
so they all *share* the same variable .
I think the effect here is the same as what you are saying .
but may be I am wrong.
also , there is another question :
{
my $x is yours = 1;
a ;
print $x # print 1 or 5 ?
}
sub a { $x is yours ; $x = 5 ; }
( in my formulation it prints 5 ) .
so the question is : is "is yours" variable assigned or aliased in the
callee scope ? probably I missed this from your explanations .
probably we should have both , and then "is yours" mechanism is more
general .
also , anothre question . if "is shared" isn't thread safe , is static
scoping using
our $x is private ;
thread safe ??
arcadi .
Re: C#/Parrot Status
At 10:55 AM +1000 11/25/02, Rhys Weatherley wrote: Nicholas Clark wrote: Floating point fills me with fear. If it makes you feel better, C# does not require overflow detection on floating-point operations. FP overflow results in +/-INF, underflow results in zero, and undefined is NAN. Only integer overflow detection is required, and then only on 32-bit, 64-bit, and native-sized integer types (8-bit types don't need it). If Parrot wants to add more opcodes for completeness sake, then it won't do any harm to us, but don't bend over backwards on FP for our sakes. We need it for our own purposes, so it'll have to go in. FP over/underflow, of course, is one of those wonderfully platform-dependent things. :( -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Dynamic scoping (take 2)
Warning: I just watched The Wizard Of Oz
for the first time tonight.
> $x is yours
>
> tells that $x is aliased to variable in
> some "secret scope symbol table" that
>( the table ) is shared between caller
> and callee
The "secret" place is MyYourca, a Subterranean
island. People think it's an old, dangerous and
complex place, but actually it's a new, simple,
friendly, safe yet dynamic principality that
juxtaposes two localities each of which is just
an ordinary lexicality, as a defense against the
evils of globalization.
I'm not sure about the symbolism of all this;
I'll let others hash that out.
> also, another way :
>
> $x is yours
>
> is like saying that all functions that
> will ever call each other ... then I
> will croup them in a group ... may be
> thought of as being in special common
> *enclosing* lexical scope
Perhaps. I find what you've said confusing
so I'm not sure what you mean.
MyYourca already exists for transfer of
variables to called subs via parens; the
scheme I'm talking about just uses the
same MyYourca.
> *share* the same variable.
In the sense that $foo in:
sub baz ($foo) { print $foo };
sub bar { my $foo; baz ($foo); };
is shared (between baz and bar), then yes.
Anything more complicated than that, then,
technically, no.
> {
> my $x is yours = 1;
> a ;
> print $x # print 1 or 5 ?
> }
>
> sub a { $x is yours ; $x = 5 ; }
In my scheme, that would print 1 and some
variable $x that was declared either
package-wise or lexically at the point
where sub a was defined has been changed
to 5.
If sub a were defined this way:
sub a (;$x is yours) { $x = 5 ; }
then it would print 5.
> is "is yours" variable assigned or aliased
> in the callee scope ? probably we should
> have both , and then "is yours" mechanism
> is more general .
Well I was thinking it's always aliased but
can be read-only by attaching C
to a variable declaration (as part of an
explicit my, not in a sig; you can't put
C in a sig -- I can't see an
alias/copy distinction, nor ability to set
ro in a sig, being worth the complexity
they introduce).
> also , anothre question . if "is shared"
> isn't thread safe , is static scoping using
>
> our $x is private ;
>
> thread safe ??
I may have incorrectly used the term "thread
safe". The point is that you can't arrange
for there being a unique $x for multiple
threads of the same code. At least I don't
see how.
--
ralph
