Re: Apoc4: The loop keyword
On Mon, Jan 21, 2002 at 12:50:38PM -0800, Larry Wall wrote:
> In most other languages, you wouldn't even have the opportunity to put
> a declaration into the conditional. You'd have to say something like:
>
> my $line = <$in>;
> if $line ne "" { ... }
>
> Since
>
> if my $line = <$in> { ... }
>
> is Perl shorthand for those two lines, I don't see how one can say that
> the variable is more related to the inside than the outside of the block.
> One can claim that the code after the C may not be interested in
> C<$line>, but the same is true of the block itself! The conditional
> only decides whether the block runs. It's not part of the block.
>
> Larry
Particularly in perl, boolean values are often very interesting. I
very much like the "curly brackets are the only things that delimit
scopes within a file, dammit" rule, but I also like to use very
localized conditionals:
if (my $result = expensive_computation()) {
...do stuff with $result...
}
if (my $result = expensive_computation2()) { ... }
func($result);
I would like for there to be a way of saying that so that the
func($result) would trigger an error about using an unknown variable.
(I do *not* want the above syntax to be that way, though.)
Perhaps:
if (expensive_computation()) {
my $result = __HOW_DID_I_GET_HERE__;
...do stuff with $result...
}
I'm just not just how to spell __HOW_DID_I_GET_HERE__.
- $LAST, for the value of the last executed expression?
- $__? (ick)
- Say, isn't $? going away, because it's getting absorbed by $!
I rather like that last one.
if (expensive_computation()) {
my $result = $?;
...do stuff with $result...
}
In fact, it seems clear enough that renaming is only necessary if you
have nested conditionals.
while (read(FH, $buf, 10)) { print "Not EOF yet, received $? bytes\n"; }
Though I don't know if
foo() && print "Yeah baby";
should set it or not. I'd vote not.
CPP Namespace pollution
One problem noted recently on the p5p list is that if you do #include in your program, it exposes a *lot* of CPP #defines to your program, whether you want them or not. This is particularly a problem if you wish to embed perl or use it with an extensive 3rd-party library. For parrot, we'd ideally like to make it a lot safer to #include Here's a status check on where we are currently: #include currently #defines 198 global CPP symbols. If you take away the autoconf-ish HAS_HEADER_* and the proabably-quite-safe PARROT_* entries, that leaves 107 entries. Although it's impossible to predict what vendors and third-party software writers will do with the CPP namespace, the following 5 entries seem particularly likely to cause mischief at some point somewhere: Very general names: UNUSED INVALID_CHARACTER IO_ERROR KEY_NOT_FOUND Possible conflict with system headers: SSIZE_MAX This is #defined in parrot/io.h as 8192, but it's also possibly defined in the system headers as the maximum size of the Posix ssize_t type, typically INT_MAX or LONG_MAX. Since it's not used in parrot, I'm unsure of the intent. I don't have a specific proposal at the moment, but would invite others to think creatively about ways to minimize cpp pollution while still keeping the source readable and maintainable. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: How Powerful Is Parrot? (A Few More Questions)
Thanks to everyone for their information on Parrot. A couple more questions have come to mind. 1) Does Parrot support multiple inheritance? 2) Does Parrot support stack variables or is everything allocated on the heap? Thanks again. Dave
Re: CPP Namespace pollution
On Fri, 25 Jan 2002, Andy Dougherty wrote: > One problem noted recently on the p5p list is that if you do > > #include > > in your program, it exposes a *lot* of CPP #defines to your program, > whether you want them or not. This is particularly a problem if you wish > to embed perl or use it with an extensive 3rd-party library. > > For parrot, we'd ideally like to make it a lot safer to > > #include > > Here's a status check on where we are currently: > > #include currently #defines 198 global CPP symbols. > If you take away the autoconf-ish HAS_HEADER_* and the > proabably-quite-safe PARROT_* entries, that leaves 107 entries. > Although it's impossible to predict what vendors and third-party > software writers will do with the CPP namespace, the following 5 > entries seem particularly likely to cause mischief at some point > somewhere: > > Very general names: > UNUSED > INVALID_CHARACTER > IO_ERROR > KEY_NOT_FOUND > > Possible conflict with system headers: > SSIZE_MAX > This is #defined in parrot/io.h as 8192, but it's also > possibly defined in the system headers as the maximum size of > the Posix ssize_t type, typically INT_MAX or LONG_MAX. > Since it's not used in parrot, I'm unsure of the intent. > > I don't have a specific proposal at the moment, but would invite > others to think creatively about ways to minimize cpp pollution while > still keeping the source readable and maintainable. > We could define those as PARROT_UNUSED, PARROT_IO_ERROR, etc. Then, we could have a parrot/aliases.h header that will define an aliases for them: #define UNUSED PARROT_UNUSED. The recommended use of this header would only be internally, and it won't be included by any of the headers that the library would require. Of course, PARROT can be replaced with PRT or with any other prefix. Regards, Shlomi Fish > -- -- Shlomi Fish[EMAIL PROTECTED] Home Page: http://t2.technion.ac.il/~shlomif/ Home E-mail: [EMAIL PROTECTED] He who re-invents the wheel, understands much better how a wheel works.
Re: CPP Namespace pollution
> I don't have a specific proposal at the moment, but would invite
> others to think creatively about ways to minimize cpp pollution while
> still keeping the source readable and maintainable.
One possibility would be to change code like this
#define XYZ 123
to this...
namespace _PARROT
{
const int XYZ = 123;
}
By placing code in namespaces and not using CPP at all, name clashes are
completely avoided.
This requires the use of C++, rather than C. Also, where the CPP #define is
nothing more than text substitution done at compile time, use of constants
in C++ consumes runtine stack space.
Dave
Andy Dougherty
yette.edu> cc:
Subject: CPP Namespace pollution
01/25/02 10:14
AM
One problem noted recently on the p5p list is that if you do
#include
in your program, it exposes a *lot* of CPP #defines to your program,
whether you want them or not. This is particularly a problem if you wish
to embed perl or use it with an extensive 3rd-party library.
For parrot, we'd ideally like to make it a lot safer to
#include
Here's a status check on where we are currently:
#include currently #defines 198 global CPP symbols.
If you take away the autoconf-ish HAS_HEADER_* and the
proabably-quite-safe PARROT_* entries, that leaves 107 entries.
Although it's impossible to predict what vendors and third-party
software writers will do with the CPP namespace, the following 5
entries seem particularly likely to cause mischief at some point
somewhere:
Very general names:
UNUSED
INVALID_CHARACTER
IO_ERROR
KEY_NOT_FOUND
Possible conflict with system headers:
SSIZE_MAX
This is #defined in parrot/io.h as 8192, but it's also
possibly defined in the system headers as the maximum size of
the Posix ssize_t type, typically INT_MAX or LONG_MAX.
Since it's not used in parrot, I'm unsure of the intent.
I don't have a specific proposal at the moment, but would invite
others to think creatively about ways to minimize cpp pollution while
still keeping the source readable and maintainable.
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
Re: How Powerful Is Parrot? (A Few More Questions)
On Fri, Jan 25, 2002 at 10:18:56AM -0500, [EMAIL PROTECTED] wrote: > 1) Does Parrot support multiple inheritance? > 2) Does Parrot support stack variables or is everything allocated on the > heap? There's an easy way to answer these questions for yourself. "Does Parrot support X?" == "Does any language which we hope to run on Parrot support X?" Perl has multiple inheritance. It would be a shame if the interpreter we wrote to run Perl on didn't have multiple inheritance. Perl, and many other languages, have stack variables. Parrot has to support them. -- You are in a maze of little twisting passages, all different.
Re: CPP Namespace pollution
On Fri, Jan 25, 2002 at 10:30:01AM -0500, [EMAIL PROTECTED] wrote: > This requires the use of C++, rather than C. See the FAQ. -- The most effective debugging tool is still careful thought, coupled with judiciously placed print statements. -Kernighan, 1978
Re: How Powerful Is Parrot? (A Few More Questions)
Thanks Simon
I haven't used Perl since its pre-inhertance days, so I was unaware it
supported multiple inheritance.
Most languages I'm familar with that have garbage collection don't have
true stack variables. For example, the code
void f()
{
int x = 0;
...
}
creates x on the stack in C++ (which is not garbage collected), but
creates it on the heap as a garbage collected object in Java. This has
ramifications not only in how programmers write their code, but in how
language designers design their languages.
>From what I've seen, supporting both garbage collection and true stack
variables is a difficult task.
Dave
Simon Cozens
cc: [EMAIL PROTECTED]
Subject: Re: How Powerful Is Parrot? (A
Few More Questions)
01/25/02 10:46
AM
On Fri, Jan 25, 2002 at 10:18:56AM -0500, [EMAIL PROTECTED] wrote:
> 1) Does Parrot support multiple inheritance?
> 2) Does Parrot support stack variables or is everything allocated on the
> heap?
There's an easy way to answer these questions for yourself.
"Does Parrot support X?" == "Does any language which we hope to run
on Parrot support X?"
Perl has multiple inheritance. It would be a shame if the interpreter we
wrote to run Perl on didn't have multiple inheritance.
Perl, and many other languages, have stack variables. Parrot has to support
them.
--
You are in a maze of little twisting passages, all different.
Re: CPP Namespace pollution
> > This requires the use of C++, rather than C. > See the FAQ. Where would the FAQ be? Dave Simon Cozens cc: Perl6 Internals <[EMAIL PROTECTED]> Subject: Re: CPP Namespace pollution 01/25/02 10:52 AM On Fri, Jan 25, 2002 at 10:30:01AM -0500, [EMAIL PROTECTED] wrote: > This requires the use of C++, rather than C. See the FAQ. -- The most effective debugging tool is still careful thought, coupled with judiciously placed print statements. -Kernighan, 1978
RE: CPP Namespace pollution
> See the FAQ. This really isn't a very good answer for several reasons (I know the answer, but that doesn't matter): 1.> There is no link to the FAQ on the Perl6 page (that I could find anyway). (http://www.panix.com/~ziggy/parrot.html - I think this it) 2.> "See the FAQ" for what? Not using CPP? Not asking stupid questions? Why? There were a lot of complaints about this in the past regarding the newbie community, and we really need to make an extra effort to ensure that parrot doesn't get bad press by repeating the same mistakes. RTFM is often just the lazy man's answer (even if it is often the right answer - "Is it plugged in?"). Grant M.
Re: How Powerful Is Parrot? (A Few More Questions)
>From what I've seen, supporting both garbage collection and true stack >variables is a difficult task. Why is that? -Melvin Smith IBM :: Atlanta Innovation Center [EMAIL PROTECTED] :: 770-835-6984
Re: CPP Namespace pollution
On Fri, Jan 25, 2002 at 11:15:15AM -0500, [EMAIL PROTECTED] wrote: > > See the FAQ. > Where would the FAQ be? Hm, the FAQ would be not linked from either of dev.perl.org or www.parrotcode.org. That's a bummer. Thankfully, a quick google for Parrot FAQ (once you get past the avine entries ;) gets you: http://www.panix.com/~ziggy/parrot.html Ask, could we move this to dev.perl.org please? -- "The Write Many, Read Never drive. For those people that don't know their system has a /dev/null already." - Rik Steenwinkel on Exabyte drives, ASR
Parrot FAQ location
>1.> There is no link to the FAQ on the Perl6 page (that I could find anyway). > (http://www.panix.com/~ziggy/parrot.html - I think this it) This really should be stored or linked in the Perl6 Parrot area. -Melvin Smith IBM :: Atlanta Innovation Center [EMAIL PROTECTED] :: 770-835-6984
Re: CPP Namespace pollution
>Hm, the FAQ would be not linked from either of dev.perl.org or >www.parrotcode.org. That's a bummer. >Ask, could we move this to dev.perl.org please? Dare I suggest we check it into the repository and have a script update the site from the repository. At least then we can tell people to check the FAQ "in your parrot distribution." -Melvin Smith IBM :: Atlanta Innovation Center [EMAIL PROTECTED] :: 770-835-6984
Re: Apoc4: The loop keyword
On Mon, 21 Jan 2002 15:43:07 -0500, Damian Conway wrote: >What we're cleaning up is the ickiness of having things declared outside >the braces be lexical to the braces. *That's* hard to explain to beginners. But it's handy. And that was, until now, what mattered with Perl. -- Bart.
123_456
Should we be allowed to use _ to group numbers, now that _ is concat? If not _, then what? (if anything?) -- Hanlon's Razor: Never attribute to malice that which is adequately explained by stupidity.
Re: Apoc4: The loop keyword
On Fri, Jan 25, 2002 at 11:57:25AM +0100, Bart Lateur wrote: > On Mon, 21 Jan 2002 15:43:07 -0500, Damian Conway wrote: > > >What we're cleaning up is the ickiness of having things declared outside > >the braces be lexical to the braces. *That's* hard to explain to beginners. > > But it's handy. And that was, until now, what mattered with Perl. No, handiness still matters with Perl. It's just that the balance has tipped a wee bit towards the consistency/regularity/simplicity/whatever side of the scale. Besides no one has commented on Steve Fink's (I think it was him) idea to store the result of the most recently executed conditional in $?. I kinda like that idea myself. It makes mnemonic sense. But then I'm sure that someone will come out of the woodwork and say "What about if ((my $a = foo()) && ($b < 4)) ?" or something. To which I'd say "Fooey!" I personally don't think that an extra set of curlies are too high a price for getting rid of weird scoping rules. But that's just me. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: 123_456
On Friday 25 January 2002 12:34, Simon Cozens wrote: > Should we be allowed to use _ to group numbers, now that _ is concat? > If not _, then what? (if anything?) Sure, why not? '_' is still a valid character in an identifier. You'd still simply need disambiguating whitespace for concatenation. -- Bryan C. Warnock [EMAIL PROTECTED]
What can be hyperoperated?
I'm trying to answer the question "what does ^ mean?". Can anything be hyperoperated, or just a built-in set of operations? If "anything", can user's subroutines be hyperoperated? How will they know that they're being called in "hyper context"? If a built-in set of operations, which ones? -- You are in a maze of UUCP connections, all alike.
Re: 123_456
On Fri, 2002-01-25 at 12:38, Bryan C. Warnock wrote: > On Friday 25 January 2002 12:34, Simon Cozens wrote: > > Should we be allowed to use _ to group numbers, now that _ is concat? > > If not _, then what? (if anything?) > > Sure, why not? '_' is still a valid character in an identifier. You'd > still simply need disambiguating whitespace for concatenation. Ok, so the concern is that 100_000 could be (100) _ (000) or 10 It seems to me that the way around this is to change _ to space for numbers. Is there ever a reason to have: 100 000 currently? I can't think of one. Such spaces could easily be noted and removed by the tokenizer early on. Then again, _ still bothers me as an operator. I think it's because Perl has trained me to think of _ as being very flexible and context-sensitive (ala $_, @_, etc). And so, it seems odd that the _ operator should have one fixed, narrow purpose.
RE: 123_456
> Should we be allowed to use _ to group numbers, now that _ is concat? > If not _, then what? (if anything?) Sure. In Perl 5, we have 123.456 and a . b, but in Perl 6, we will have 123_456 and 123 _ 456. People have to put space around '_' anway. Hong
Re: How Powerful Is Parrot? (A Few More Questions)
> >From what I've seen, supporting both garbage collection and true stack
> >variables is a difficult task.
> Why is that?
Because stack variables can refer to heap variables and heap variables can
refer to stack variables. The garbage collector needs to be smart enough to
handle all cases correctly. For example, let's say we have the following
two classes...
class A
{
public B b_member;
}
class B
{
public A a_member;
}
and the following declarations and function...
B global_b; // Creates an instance of B with an A member, both
on the stack.
B global_b2;// Creates an instance of B with an A member, both on
the stack.
void f()
{
A a; // Creates an instance of A with a B member, both on
the stack.
B b = new B(); // Creates an instance of B with an A member, both on
the heap.
// 4 objects have now been created in this function, an A and B on the
stack, and an A and B on the heap.
a.b_member = b; // Stack variable a now references heap variable
b.
b.a_member = a; // Heap variable b now references stack variable
a.
global_b.a_member = a; // Stack variable global_b now references
stack variable a.
global_b2 = b; // Stack variable global_b2 now references heap
variable b.
// What happens to the six objects we've created when we leave the
scope of f()?
}
This implies several things.
1) Garbage collection is optional because stack variables are not garbage
collected.
2) Garbage collection knows every object created, how every object was
created (stack or heap), and how every object is referenced by other
objects.
3) The stack interacts seemlessly with garbage collection. When we leave f
() in the above example, referencing global_b.a_member needs to produce an
error or exception.
4) Garbage collection interacts seemlessly with the stack. In the above
example, b can never be garbage collected for the life of the program
because the stack variable global_b2 references it and global_b2 never goes
out of scope.
It's not impossible to write a garbage collector that can handle this, I've
done it myself. This is why I've been asking these questions about Parrot.
I want to know if I can use Parrot as a VM for a language I've designed.
I'm currently generating C++ code. I'd like to use Parot, but I need true
stack variables and 100% deterministic garbage collection.
I don't know of any language that has these features. Java doesn't. C++
doesn't (unless you roll your own and restrict what programmers can do), C#
doesn't.
Dave
"Melvin Smith"
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
m.com> cc: [EMAIL PROTECTED], Simon
Cozens <[EMAIL PROTECTED]>
Subject: Re: How Powerful Is Parrot? (A
Few More Questions)
01/25/02 12:00
PM
>From what I've seen, supporting both garbage collection and true stack
>variables is a difficult task.
Why is that?
-Melvin Smith
IBM :: Atlanta Innovation Center
[EMAIL PROTECTED] :: 770-835-6984
Re: How Powerful Is Parrot? (A Few More Questions)
Thanks for the nice example, except I understand the issue you
are speaking of, I was basically asking what parts of it do you think
are more "difficult" to implement than any other major construct?
There are several ways to address the example you just gave (my computer
science is getting rusty here) but let me think...
> a.b_member = b; // Stack variable a now references heap variable
b.
I see no problem here.
> b.a_member = a; // Heap variable b now references stack variable
a.
> global_b.a_member = a; // Stack variable global_b now references
stack variable a.
> global_b2 = b; // Stack variable global_b2 now references heap
variable b.
> // What happens to the six objects we've created when we leave the
scope of f()?
One approach is
stack = stack (reference)
stack = heap (reference)
heap = heap (reference)
heap = stack (copy)
-Melvin Smith
IBM :: Atlanta Innovation Center
[EMAIL PROTECTED] :: 770-835-6984
David.Leeper@bisy
s.comTo: Melvin
Smith/ATLANTA/Contr/IBM@IBMUS
cc: [EMAIL PROTECTED],
Simon Cozens <[EMAIL PROTECTED]>
01/25/2002 12:45 Subject: Re: How Powerful Is Parrot?
(A Few More Questions)
PM
> >From what I've seen, supporting both garbage collection and true stack
> >variables is a difficult task.
> Why is that?
Because stack variables can refer to heap variables and heap variables can
refer to stack variables. The garbage collector needs to be smart enough to
handle all cases correctly. For example, let's say we have the following
two classes...
class A
{
public B b_member;
}
class B
{
public A a_member;
}
.and the following declarations and function...
B global_b; // Creates an instance of B with an A member, both
on the stack.
B global_b2;// Creates an instance of B with an A member, both on
the stack.
void f()
{
A a; // Creates an instance of A with a B member, both on
the stack.
B b = new B(); // Creates an instance of B with an A member, both on
the heap.
// 4 objects have now been created in this function, an A and B on the
stack, and an A and B on the heap.
a.b_member = b; // Stack variable a now references heap variable
b.
b.a_member = a; // Heap variable b now references stack variable
a.
global_b.a_member = a; // Stack variable global_b now references
stack variable a.
global_b2 = b; // Stack variable global_b2 now references heap
variable b.
// What happens to the six objects we've created when we leave the
scope of f()?
}
This implies several things.
1) Garbage collection is optional because stack variables are not garbage
collected.
2) Garbage collection knows every object created, how every object was
created (stack or heap), and how every object is referenced by other
objects.
3) The stack interacts seemlessly with garbage collection. When we leave f
() in the above example, referencing global_b.a_member needs to produce an
error or exception.
4) Garbage collection interacts seemlessly with the stack. In the above
example, b can never be garbage collected for the life of the program
because the stack variable global_b2 references it and global_b2 never goes
out of scope.
It's not impossible to write a garbage collector that can handle this, I've
done it myself. This is why I've been asking these questions about Parrot.
I want to know if I can use Parrot as a VM for a language I've designed.
I'm currently generating C++ code. I'd like to use Parot, but I need true
stack variables and 100% deterministic garbage collection.
I don't know of any language that has these features. Java doesn't. C++
doesn't (unless you roll your own and restrict what programmers can do), C#
doesn't.
Dave
"Melvin Smith"
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
m.com> cc: [EMAIL PROTECTED],
Simon Cozens <[EMAIL PROTECTED]>
Subject: Re: How Powerful Is
Parrot? (A Few More Questions)
01/25/02 12:00
PM
>From
Re: How Powerful Is Parrot? (A Few More Questions)
> Thanks for the nice example, except I understand the issue you
> are speaking of, I was basically asking what parts of it do you think
> are more "difficult" to implement than any other major construct?
I believe the main difficulty comes from heading into uncharted waters. For
example, once you've decided to make garbage collection optional, what does
the following line of code mean?
delete x;
Does it mean anything at all? Is it even a legal statement? Is garbage
collection optional for all variables, or simply not used for stack
variables, but always used for heap variables?
Or, for example, are the side effects of the following two functions
different?
void f1()
{
// On the stack
MyClass o;
}
void f2()
{
// On the heap
MyClass o = new MyClass();
}
If garbage collection is not 100% deterministic, these two functions could
produce very different results because we do not know when or if the
destructor for MyClass will execute in the case of f2(). The same would be
true when exceptions are thrown from a function. If garbage collection is
not 100% deterministic (and Mark and Sweep is not), we need extra language
features, such as Java's "finally" block, to ensure things can be cleaned
up, and extra training to ensure programmers are smart enough to know how
to use "finally" blocks correctly.
So, as I see it, the choice of garbage collections schemes ripples
throughout the entire language. It effects what statements are legal and
the semantics of even the simplest pieces of code.
The point to all my questions is this: I'm thinking about basing my
language on the Parrot VM. If I do that, what does the call to f2() mean?
What happens to my language when I use the Parrot VM?
Dave
"Melvin Smith"
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
m.com> cc: [EMAIL PROTECTED], Simon
Cozens <[EMAIL PROTECTED]>
Subject: Re: How Powerful Is Parrot? (A
Few More Questions)
01/25/02 01:13
PM
Thanks for the nice example, except I understand the issue you
are speaking of, I was basically asking what parts of it do you think
are more "difficult" to implement than any other major construct?
There are several ways to address the example you just gave (my computer
science is getting rusty here) but let me think...
> a.b_member = b; // Stack variable a now references heap variable
b.
I see no problem here.
> b.a_member = a; // Heap variable b now references stack variable
a.
> global_b.a_member = a; // Stack variable global_b now references
stack variable a.
> global_b2 = b; // Stack variable global_b2 now references heap
variable b.
> // What happens to the six objects we've created when we leave the
scope of f()?
One approach is
stack = stack (reference)
stack = heap (reference)
heap = heap (reference)
heap = stack (copy)
-Melvin Smith
IBM :: Atlanta Innovation Center
[EMAIL PROTECTED] :: 770-835-6984
David.Leeper@bisy
s.comTo: Melvin
Smith/ATLANTA/Contr/IBM@IBMUS
cc:
[EMAIL PROTECTED], Simon Cozens <[EMAIL PROTECTED]>
01/25/2002 12:45 Subject: Re: How Powerful
Is Parrot? (A Few More Questions)
PM
> >From what I've seen, supporting both garbage collection and true stack
> >variables is a difficult task.
> Why is that?
Because stack variables can refer to heap variables and heap variables can
refer to stack variables. The garbage collector needs to be smart enough to
handle all cases correctly. For example, let's say we have the following
two classes...
class A
{
public B b_member;
}
class B
{
public A a_member;
}
.and the following declarations and function...
B global_b; // Creates an instance of B with an A member, both
on the stack.
B global_b2;// Creates an instance of B with an A member, both on
the stack.
void f()
{
A a; // Creates an instance of A with a B member, both on
the stack.
B b = new B(); // Creates an instance of B with an A member, both on
the heap.
// 4 objec
Re: 123_456
Falling back on the "numbers is strings, too" legacy: $a = 100; $b = "000"; $c = ($a _ $b) + 1; # I'd expect $c == 11. If I say: $a = 1 _ 000 _ 000; or $a = 1_000_000; DWIM (In scalar context, coerce arguments to strings). (Frankly, I think this is unlikely. But who knows?) If course, if I say: $a = $1_000_000; You can complain. WARNING: test.pm (line 4): Cannot assemble $1_000_000. =Austin --- Aaron Sherman <[EMAIL PROTECTED]> wrote: > On Fri, 2002-01-25 at 12:38, Bryan C. Warnock wrote: > > On Friday 25 January 2002 12:34, Simon Cozens wrote: > > > Should we be allowed to use _ to group numbers, now that _ is > concat? > > > If not _, then what? (if anything?) > > > > Sure, why not? '_' is still a valid character in an identifier. > You'd > > still simply need disambiguating whitespace for concatenation. > > Ok, so the concern is that > > 100_000 > > could be > > (100) _ (000) > > or > > 10 > > It seems to me that the way around this is to change _ to space for > numbers. Is there ever a reason to have: > > 100 000 > > currently? I can't think of one. Such spaces could easily be noted > and > removed by the tokenizer early on. > > Then again, _ still bothers me as an operator. I think it's because > Perl > has trained me to think of _ as being very flexible and > context-sensitive (ala $_, @_, etc). And so, it seems odd that the _ > operator should have one fixed, narrow purpose. > > __ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com
Re: Apoc4: The loop keyword
At 11:40 AM 01-25-2002 -0600, Jonathan Scott Duff you wrote:
>On Fri, Jan 25, 2002 at 11:57:25AM +0100, Bart Lateur wrote:
> > On Mon, 21 Jan 2002 15:43:07 -0500, Damian Conway wrote:
> >
> > >What we're cleaning up is the ickiness of having things declared outside
> > >the braces be lexical to the braces. *That's* hard to explain to
> beginners.
> >
> > But it's handy. And that was, until now, what mattered with Perl.
>
>No, handiness still matters with Perl. It's just that the balance has
>tipped a wee bit towards the consistency/regularity/simplicity/whatever
>side of the scale.
>
>Besides no one has commented on Steve Fink's (I think it was him) idea
>to store the result of the most recently executed conditional in $?. I
>kinda like that idea myself. It makes mnemonic sense.
>
>But then I'm sure that someone will come out of the woodwork and say
>"What about if ((my $a = foo()) && ($b < 4)) ?" or something. To
>which I'd say "Fooey!" I personally don't think that an extra set of
>curlies are too high a price for getting rid of weird scoping rules.
>But that's just me.
We have
while (foo()) -> $a {...}
doing the right thing.
Why can't
if foo() -> $a { ... }
take the place of the perl5
if (my $a = foo()) {...}
Too bad we can't do
while (foo() -> $a) && ($b < 4) { ... }
and have it do the right thing.
>-Scott
>--
>Jonathan Scott Duff
>[EMAIL PROTECTED]
Comm. Unity - (was Re: CPP Namespace pollution)
On Friday 25 January 2002 14:19, Wizard wrote: > > See the FAQ. > > This really isn't a very good answer for several reasons (I know the > answer, but that doesn't matter): > 1.> There is no link to the FAQ on the Perl6 page (that I could find > anyway). > (http://www.panix.com/~ziggy/parrot.html - I think this it) > 2.> "See the FAQ" for what? Not using CPP? Not asking stupid questions? > Why? > > There were a lot of complaints about this in the past regarding the newbie > community, and we really need to make an extra effort to ensure that > parrot doesn't get bad press by repeating the same mistakes. RTFM is often > just the lazy man's answer (even if it is often the right answer - "Is it > plugged in?"). It's also very Simon-esqe. That's not to praise or condemn his rhetoric, but just to acknowledge it. Now, certainly, someone new to the community won't recognize that, and may even believe that the community is one robotic army of Simons. That, too, isn't necessarily Simon's fault. If anything, it's largely our fault, for allowing, through our silence, Simon to speak on our behalf in those situations. Not only are different viewpoints necessary for a community, but oftentimes different expressions of the same viewpoint are necessary to exude the character of the community, and it's up to the community members to ensure that that is done. Many of the main characters on p5p and p6* have distinctly different styles that mostly complement each other. (Which is a far cry from some other mailing lists, which exemplify "violent agreement") Simon, (occasionally referred to as the Tom Christiansen for a New Generation :-), constantly trying to do 48 hours of stuff a day, is terse and dismissive - "I don't have time for pleasantries, background information, or explanations. Here's the cut-and-dry; if you need more, someone else can provide that." Dan is cleverly aloof in is answers. There's not many folks who flippantly hand-wave and still come across as knowing exactly what he's talking about. Larry is quietly charismatic. He's one of the few folks that can get away with answering a question by not actually addressing the answer or the question. (I'd probably through Jarkko into this category, too.) Most folks, when they do that, just come across as idiots. Damian is a master craftsman. He can provide an overwhelming, highly detailed, completely unintelligible answer that leaves you, at the end, out of breath but in complete understanding of what was said, even if you didn't understand any particular part of it. Some folks are good at explaining things simply without being condescending. Some folks are good at explaining things complexly without being confusing. And other folks just leave you wondering. It's that mix that makes our community. You learn who's got what styles, and who fits best for you. Sometimes RTFM *is* the right answer, but other times an explanation of the manual is needed. Most languages have a personality - simple and one-dimensional. Perl is different. Perl, as the "glue language", has a complex and multi-dimensional personality, simultaneuosly reflecting its disparate roots and influences. The Perl community, by nature of Perl herself, is also built on disparate roots and influences, and it's that complexity to our personality that defines us. Oh, yes, the reputation. The reputation was largely gained by matching the wrong faces with the wrong forums. Any time you open yourself up to questions, you need to expect the type of questions that you'd expect given the nature of what is being questioned about. The reputation was largely started in c.l.p.m, at the time, the only real public forum for asking questions about Perl. The mongers hanging out there wanted questions along the lines of "How can I save the world with Perl in 5 lines or less?" Instead, they received questions along the lines of "What's the difference between 'for' and 'foreach'?" When you provide a language that can be used by beginners, and enough documentation to satisfy any experienced programmer, what kind of questions do you expect to get? It's almost a Catch-22 - if they knew how to RTFM, they wouldn't need to have asked the question in the first place. The p5p and p6* lists are slightly different. We're not for beginners. We're not anywhere close for being for beginners. The occasional newbie that stumbles in unawares may indeed stumble out again feeling slighted - the importantance of never allowing just one "greeter at the door" [1]. Most everyone else at least will understand group dynamics enough to weather the storm until it's clear where they fit in the puzzle. p6i has been extremely tolerant of new blood. Much more than p5p has, I believe. (That's mostly based on p5p reaction to p6l. p5p is very welcome to newcomers in p5p, *if* you come bearing patches.) So is there a point to all this? Probably
Re: How Powerful Is Parrot? (A Few More Questions)
On Friday 25 January 2002 13:50, [EMAIL PROTECTED] wrote:
> > Thanks for the nice example, except I understand the issue you
> > are speaking of, I was basically asking what parts of it do you think
> > are more "difficult" to implement than any other major construct?
>
> I believe the main difficulty comes from heading into uncharted waters.
> For example, once you've decided to make garbage collection optional, what
> does the following line of code mean?
>
> delete x;
>
> Does it mean anything at all? Is it even a legal statement? Is garbage
> collection optional for all variables, or simply not used for stack
> variables, but always used for heap variables?
>
> Or, for example, are the side effects of the following two functions
> different?
>
> void f1()
> {
> // On the stack
> MyClass o;
> }
>
> void f2()
> {
> // On the heap
> MyClass o = new MyClass();
> }
>
> If garbage collection is not 100% deterministic, these two functions could
> produce very different results because we do not know when or if the
> destructor for MyClass will execute in the case of f2(). The same would be
> true when exceptions are thrown from a function. If garbage collection is
> not 100% deterministic (and Mark and Sweep is not), we need extra language
> features, such as Java's "finally" block, to ensure things can be cleaned
> up, and extra training to ensure programmers are smart enough to know how
> to use "finally" blocks correctly.
>
> So, as I see it, the choice of garbage collections schemes ripples
> throughout the entire language. It effects what statements are legal and
> the semantics of even the simplest pieces of code.
>
> The point to all my questions is this: I'm thinking about basing my
> language on the Parrot VM. If I do that, what does the call to f2() mean?
>
> What happens to my language when I use the Parrot VM?
GC (at the Parrot level) isn't finalization (at the language level). In
your last several posts, it hasn't been clear at what level you're trying to
address.
Parrot supports deterministic destruction at the language level. If your
language wants 'o' to be destroyed at the exit from f2(), then 'o' will be
destroyed in whatever manner MyClass destruction means to your language.
Resources allocated strictly by the internal representation responsible for
MyClass (e.g. Leeper_Object) may not be collected at that point, but that's
mostly independent of the language. (You could also trigger a GC run
yourself.)
Consider, for a moment, a C++ object that is dependent on some kernel
resource. C++ makes the determination of when and how that object is
destroyed and finalized, releasing both program memory, user-space
resources, and the attached kernel resources. It shouldn't then matter to
the program if, when, or how the kernel goes about collecting those
resources. (Overcommitting memory is a good example of how some modern
kernels lie to their programs for exactly that reason.)
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: How Powerful Is Parrot? (A Few More Questions)
> Parrot supports deterministic destruction at the language level. If your
> language wants 'o' to be destroyed at the exit from f2(), then 'o' will
be
> destroyed in whatever manner MyClass destruction means to your language.
> Resources allocated strictly by the internal representation responsible
for
> MyClass (e.g. Leeper_Object) may not be collected at that point, but
that's
> mostly independent of the language. (You could also trigger a GC run
> yourself.)
I believe I understand now. I think that what this means to me is that if I
want 100% deterministic destruction, I will have to implement my own
garbage collector. This garbage collector will call object destructors and
free all language-specific resources of the object. Once I've finished
using the object, the Parrot garbage collector will free Parrot resources
associated with the object at some undetermined time in the future.
I think that's acceptable.
Thanks Bryan.
Dave
"Bryan C.
Warnock" To: [EMAIL PROTECTED]
Subject: Re: How Powerful Is Parrot? (A
Few More Questions)
01/25/02 02:10
PM
Please respond
to bwarnock
On Friday 25 January 2002 13:50, [EMAIL PROTECTED] wrote:
> > Thanks for the nice example, except I understand the issue you
> > are speaking of, I was basically asking what parts of it do you think
> > are more "difficult" to implement than any other major construct?
>
> I believe the main difficulty comes from heading into uncharted waters.
> For example, once you've decided to make garbage collection optional,
what
> does the following line of code mean?
>
> delete x;
>
> Does it mean anything at all? Is it even a legal statement? Is garbage
> collection optional for all variables, or simply not used for stack
> variables, but always used for heap variables?
>
> Or, for example, are the side effects of the following two functions
> different?
>
> void f1()
> {
> // On the stack
> MyClass o;
> }
>
> void f2()
> {
> // On the heap
> MyClass o = new MyClass();
> }
>
> If garbage collection is not 100% deterministic, these two functions
could
> produce very different results because we do not know when or if the
> destructor for MyClass will execute in the case of f2(). The same would
be
> true when exceptions are thrown from a function. If garbage collection is
> not 100% deterministic (and Mark and Sweep is not), we need extra
language
> features, such as Java's "finally" block, to ensure things can be cleaned
> up, and extra training to ensure programmers are smart enough to know how
> to use "finally" blocks correctly.
>
> So, as I see it, the choice of garbage collections schemes ripples
> throughout the entire language. It effects what statements are legal and
> the semantics of even the simplest pieces of code.
>
> The point to all my questions is this: I'm thinking about basing my
> language on the Parrot VM. If I do that, what does the call to f2() mean?
>
> What happens to my language when I use the Parrot VM?
GC (at the Parrot level) isn't finalization (at the language level). In
your last several posts, it hasn't been clear at what level you're trying
to
address.
Parrot supports deterministic destruction at the language level. If your
language wants 'o' to be destroyed at the exit from f2(), then 'o' will be
destroyed in whatever manner MyClass destruction means to your language.
Resources allocated strictly by the internal representation responsible for
MyClass (e.g. Leeper_Object) may not be collected at that point, but that's
mostly independent of the language. (You could also trigger a GC run
yourself.)
Consider, for a moment, a C++ object that is dependent on some kernel
resource. C++ makes the determination of when and how that object is
destroyed and finalized, releasing both program memory, user-space
resources, and the attached kernel resources. It shouldn't th
RE: How Powerful Is Parrot? (A Few More Questions)
> I believe the main difficulty comes from heading into uncharted waters.
For
> example, once you've decided to make garbage collection optional, what
does
> the following line of code mean?
>
> delete x;
If the above code is compiled to Parrot, it probably equivalent to
x->~Destructor();
i.e., the destructor is called, but the memory is left to GC, which most
likely
handle free at a later time.
> Or, for example, are the side effects of the following two functions
> different?
>
> void f1()
> {
> // On the stack
> MyClass o;
> }
>
> void f2()
> {
> // On the heap
> MyClass o = new MyClass();
> }
>
> If garbage collection is not 100% deterministic, these two functions could
> produce very different results because we do not know when or if the
> destructor for MyClass will execute in the case of f2().
This is exactly the same case for C++. When you compile f2 with gcc, how
can you tell when the destructor is called. Even the following code does
not work.
void f3()
{
MyClass o = new MyClass();
...
delete o;
}
If there is an exception happens within (...), the destructor will not be
called.
> If garbage collection is
> not 100% deterministic (and Mark and Sweep is not), we need extra language
> features, such as Java's "finally" block, to ensure things can be cleaned
> up, and extra training to ensure programmers are smart enough to know how
> to use "finally" blocks correctly.
That is exactly the case for C++. In your above code f1(), the C++ compiler
already (behind the scene) inserts finally block for "o" destructor. That
is why the destructor of stack allocated objects is called even when
exception
happens. The only difference is that the memory deallocation is
dis-associated
with object destruction.
Summary: the object destruction with GC is as deterministic as C++ heap
allocated object, i.e. you have to call "delete x" (in C++), x.close() (in
Java), x.dispose (in C#), otherwise is 0% deterministic, period.
Hong
Re: CPP Namespace pollution
At 10:14 AM -0500 1/25/02, Andy Dougherty wrote: >One problem noted recently on the p5p list is that if you do > > #include > >in your program, it exposes a *lot* of CPP #defines to your program, >whether you want them or not. This is particularly a problem if you wish >to embed perl or use it with an extensive 3rd-party library. > >For parrot, we'd ideally like to make it a lot safer to > > #include Nope--we'd ideally like to smack anyone writing non-core code that does that. :) Embedders will include parrot/parrot_embed.h, while extension folks will include parrot/parrot_extend.h. Neither will include parrot/parrot.h--not safe. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: CPP Namespace pollution
At 11:19 AM -0800 1/25/02, Wizard wrote: > > See the FAQ. >This really isn't a very good answer for several reasons (I know the answer, >but that doesn't matter): >1.> There is no link to the FAQ on the Perl6 page (that I could find >anyway). > (http://www.panix.com/~ziggy/parrot.html - I think this it) >2.> "See the FAQ" for what? Not using CPP? Not asking stupid questions? Why? > >There were a lot of complaints about this in the past regarding the newbie >community, and we really need to make an extra effort to ensure that parrot >doesn't get bad press by repeating the same mistakes. RTFM is often just the >lazy man's answer (even if it is often the right answer - "Is it plugged >in?"). This is a good point. We can fix the FAQ link, and we should put it into the repository, but I think we should avoid the really terse "go check the FAQ" sorts of answers. Mostly terse "Why we don't do X is answered in the FAQ" is OK as there's at least a little context there. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Comm. Unity - (was Re: CPP Namespace pollution)
On Fri, Jan 25, 2002 at 01:56:20PM -0500, Bryan C. Warnock wrote: [ rather interesting ramble about people, Perl, and personality ] Someone needs to add this stuff to http://dev.perl.org/perl6/people or perhaps start a Perl6-personality guidebook :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
RE: How Powerful Is Parrot? (A Few More Questions)
> That is exactly the case for C++. In your above code f1(), the C++
compiler
> already (behind the scene) inserts finally block for "o" destructor. That
> is why the destructor of stack allocated objects is called even when
> exception
> happens. The only difference is that the memory deallocation is
> dis-associated
> with object destruction.
>
> Summary: the object destruction with GC is as deterministic as C++ heap
> allocated object, i.e. you have to call "delete x" (in C++), x.close()
(in
> Java), x.dispose (in C#), otherwise is 0% deterministic, period.
No, there is a difference. The difference is you do not know when the Java
garbage collector will call an object's finalize() method, and in fact Java
does not even guarentee it will be called at all. C#'s garbage collector is
nondeterministic as well. The garbage collector in these languages are
usually implemented to run on a low priority thread. This thread gets
processor time based on system load, which means objects are collected and
finalized based on thread scheduling, the number of active threads, and
other factors that have nothing to do with a function going out of scope
and which cannot be predicted prior to run time.
In C++, when operator delete is called, the object's destructor is invoked
as part of the call right away, not "at some point in the future, by some
other thread, maybe" as with Java.
This changes the way a programmer writes code. A C++ class and function
that uses the class looks like this:
class A
{
public:
A(){...grab some resources...}
~A(){...release the resources...}
}
void f()
{
A a;
... use a's resources ...
}
looks like this in Java...
class A
{
public:
A(){...grab some resources...}
}
void f()
{
try
{
A a;
... use a's resources ...
}
finally
{
...release the resources...
}
}
because we do not know when or if Java will finalize the "a" object. And
everywhere the programmer uses the class A he must write the finally block
as well. Also note that both examples behave correctly in the face of
exceptions thrown during the execution of f().
Dave
Hong Zhang
cc: [EMAIL PROTECTED]
Subject: RE: How Powerful Is Parrot? (A
Few More Questions)
01/25/02 03:05
PM
> I believe the main difficulty comes from heading into uncharted waters.
For
> example, once you've decided to make garbage collection optional, what
does
> the following line of code mean?
>
> delete x;
If the above code is compiled to Parrot, it probably equivalent to
x->~Destructor();
i.e., the destructor is called, but the memory is left to GC, which most
likely
handle free at a later time.
> Or, for example, are the side effects of the following two functions
> different?
>
> void f1()
> {
> // On the stack
> MyClass o;
> }
>
> void f2()
> {
> // On the heap
> MyClass o = new MyClass();
> }
>
> If garbage collection is not 100% deterministic, these two functions
could
> produce very different results because we do not know when or if the
> destructor for MyClass will execute in the case of f2().
This is exactly the same case for C++. When you compile f2 with gcc, how
can you tell when the destructor is called. Even the following code does
not work.
void f3()
{
MyClass o = new MyClass();
...
delete o;
}
If there is an exception happens within (...), the destructor will not be
called.
> If garbage collection is
> not 100% deterministic (and Mark and Sweep is not), we need extra
language
> features, such as Java's "finally" block, to ensure things can be cleaned
> up, and extra training to ensure programmers are smart enough to know how
> to use "finally" blocks correctly.
That is exactly the case for C++. In your above code f1(), the C++ compiler
already (behind the scene) inserts finally block for "o" destructor. That
is why the destructor of stack allocated objects is called even when
exception
happens. The only difference is that the memory deallocation is
dis-associated
with object destruction.
Summary: the object destruction with GC is as deterministic as C++ heap
allocated object, i.e. you
Re: How Powerful Is Parrot? (A Few More Questions)
At 2:46 PM -0500 1/25/02, [EMAIL PROTECTED] wrote:
> > Parrot supports deterministic destruction at the language level. If your
>> language wants 'o' to be destroyed at the exit from f2(), then 'o' will
>be
>> destroyed in whatever manner MyClass destruction means to your language.
>> Resources allocated strictly by the internal representation responsible
>for
>> MyClass (e.g. Leeper_Object) may not be collected at that point, but
>that's
>> mostly independent of the language. (You could also trigger a GC run
>> yourself.)
>
>I believe I understand now. I think that what this means to me is that if I
>want 100% deterministic destruction, I will have to implement my own
>garbage collector. This garbage collector will call object destructors and
>free all language-specific resources of the object. Once I've finished
>using the object, the Parrot garbage collector will free Parrot resources
>associated with the object at some undetermined time in the future.
I think you're getting confused a bit here--I apologize for not
jumping in earlier.
As far as Parrot's concerned, Garbage Collection is just the
reclamation of unused memory and unused interpreter structures. This
will happen when the interpreter deems it necessary, and you can
force or block a GC run if you need to. The heap may be compacted
when this happens, but variables can be marked as non-moveable if
this is necessary. (for those cases when absolute memory addresses
are referenced outside of the interpreter as well)
Dead Object Detection is the phase where the interpreter determines
which objects are reachable from the root set, and which aren't. Any
objects that aren't reachable *and* are marked as having an active
destructor (and most won't, there's no need in 90% of the cases) will
have their destructor called and the objects can clean up as need be.
Once again this happens when the interpreter deems it necessary and
you may also force or block a DOD run.
In neither case do you have any control over the order that memory is
compacted, or dead objects with destructors have their destructors
called. If you must force some sort of order you need to do so within
the objects destructor. Alternately if your program knows what order
objects should be destroyed in your may explicitly call objects
destructors. This is outside the GC/DOD system however as it happens
from within your mainline code. (When the DOD later runs it won't do
anything with those objects as you've already destroyed them and thus
left nothing for the DOD sweep to do)
> "Bryan
>C.
>
> Warnock" To:
>[EMAIL PROTECTED]
> [EMAIL PROTECTED]
> ta.com> Subject: Re: How
>Powerful Is Parrot? (A Few More Questions)
>
>
>
> 01/25/02
>02:10
>
>PM
>
> Please
>respond
>
> to
>bwarnock
>
>
>
>
>
>
>
>
>
>
>
>On Friday 25 January 2002 13:50, [EMAIL PROTECTED] wrote:
>> > Thanks for the nice example, except I understand the issue you
> > > are speaking of, I was basically asking what parts of it do you think
>> > are more "difficult" to implement than any other major construct?
>>
>> I believe the main difficulty comes from heading into uncharted waters.
>> For example, once you've decided to make garbage collection optional,
>what
>> does the following line of code mean?
>>
>> delete x;
>>
>> Does it mean anything at all? Is it even a legal statement? Is garbage
>> collection optional for all variables, or simply not used for stack
>> variables, but always used for heap variables?
>>
>> Or, for example, are the side effects of the following two functions
>> different?
>>
>> void f1()
>> {
>> // On the stack
>> MyClass o;
>> }
>>
>> void f2()
>> {
>> // On the heap
>> MyClass o = new MyClass();
>> }
>>
>> If garbage collection is not 100% deterministic, these two functions
>could
>> produce very different results because we do not know when or if the
>> destructor for MyClass will execute in the case of
Re: Comm. Unity - (was Re: CPP Namespace pollution)
At 1:56 PM -0500 1/25/02, Bryan C. Warnock wrote: >Dan is cleverly aloof in is answers. There's not many folks who flippantly >hand-wave and still come across as knowing exactly what he's talking about. I really do need to work on the flippant bit when I'm not in front of a roomful of Lisp folks... -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: How Powerful Is Parrot? (A Few More Questions)
> In neither case do you have any control over the order that memory is > compacted, or dead objects with destructors have their destructors > called. If you must force some sort of order you need to do so within > the objects destructor. Alternately if your program knows what order > objects should be destroyed in your may explicitly call objects > destructors. This is outside the GC/DOD system however as it happens > from within your mainline code. (When the DOD later runs it won't do > anything with those objects as you've already destroyed them and thus > left nothing for the DOD sweep to do) If I know what I want to destroy and when, can I just turn off Parrot's automatic garbage collector/memory compactor and send it instructons on what I want deleted? Dave Dan Sugalski <[EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] >cc: [EMAIL PROTECTED] Subject: Re: How Powerful Is Parrot? (A Few More Questions) 01/25/02 03:43 PM At 2:46 PM -0500 1/25/02, [EMAIL PROTECTED] wrote: > > Parrot supports deterministic destruction at the language level. If your >> language wants 'o' to be destroyed at the exit from f2(), then 'o' will >be >> destroyed in whatever manner MyClass destruction means to your language. >> Resources allocated strictly by the internal representation responsible >for >> MyClass (e.g. Leeper_Object) may not be collected at that point, but >that's >> mostly independent of the language. (You could also trigger a GC run >> yourself.) > >I believe I understand now. I think that what this means to me is that if I >want 100% deterministic destruction, I will have to implement my own >garbage collector. This garbage collector will call object destructors and >free all language-specific resources of the object. Once I've finished >using the object, the Parrot garbage collector will free Parrot resources >associated with the object at some undetermined time in the future. I think you're getting confused a bit here--I apologize for not jumping in earlier. As far as Parrot's concerned, Garbage Collection is just the reclamation of unused memory and unused interpreter structures. This will happen when the interpreter deems it necessary, and you can force or block a GC run if you need to. The heap may be compacted when this happens, but variables can be marked as non-moveable if this is necessary. (for those cases when absolute memory addresses are referenced outside of the interpreter as well) Dead Object Detection is the phase where the interpreter determines which objects are reachable from the root set, and which aren't. Any objects that aren't reachable *and* are marked as having an active destructor (and most won't, there's no need in 90% of the cases) will have their destructor called and the objects can clean up as need be. Once again this happens when the interpreter deems it necessary and you may also force or block a DOD run. In neither case do you have any control over the order that memory is compacted, or dead objects with destructors have their destructors called. If you must force some sort of order you need to do so within the objects destructor. Alternately if your program knows what order objects should be destroyed in your may explicitly call objects destructors. This is outside the GC/DOD system however as it happens from within your mainline code. (When the DOD later runs it won't do anything with those objects as you've already destroyed them and thus left nothing for the DOD sweep to do) > "Bryan >C. > Warnock" To: >[EMAIL PROTECTED] > [EMAIL PROTECTED] > ta.com> Subject: Re: How >Powerful Is Parrot? (A Few More Questions) > > > 01/25/02 >02:10 > >PM > Please >respond > to >bwarnock > > > > > > > > >On Friday 25 January 2002 13:50, [EMAIL PROTECTED] wrote: >> > Thanks for the nice example, except I understand the issue you > > > are speaking of, I was basically asking what parts of it do you think >> > are more "difficult" to i
RE: How Powerful Is Parrot? (A Few More Questions)
> This changes the way a programmer writes code. A C++ class
> and function that uses the class looks like this:
>
> class A
> {
> public:
> A(){...grab some resources...}
> ~A(){...release the resources...}
> }
>
> void f()
> {
> A a;
> ... use a's resources ...
> }
>
> ...looks like this in Java...
>
> class A
> {
> public:
> A(){...grab some resources...}
> }
>
> void f()
> {
> try
> {
> A a;
> ... use a's resources ...
> }
> finally
> {
> ...release the resources...
> }
> }
This is exactly the right way to do things in Java. In Java, you
can open hundreds of files, and never trigger any gc, since each
file object is very small. Unless you explicit close file, you
will be dead very quickly.
The difference between C++ and Java is C++ provides you stack allocated
object, and compiler does the dirty job to make sure the dtors are
called at the right time. In Java, you have to do it yourself.
In case you make some mistakes, the finalizer will kick in. But you
should not rely on it. From the runtime poit of view, the above C++
and Java are almost the same, except the memory deallocation.
This is one of the reason Java is so sloppy. Everyone relies on language
feature to do their job, but it is impossible for JVM to know there
are several file objects in thousands of dead object, which need to
be finalized in order to free enough file descriptor.
All you need to do is to treat Java object as C++ heap object, period.
Hong
Re: How Powerful Is Parrot? (A Few More Questions)
At 3:48 PM -0500 1/25/02, [EMAIL PROTECTED] wrote: > > In neither case do you have any control over the order that memory is >> compacted, or dead objects with destructors have their destructors >> called. If you must force some sort of order you need to do so within >> the objects destructor. Alternately if your program knows what order >> objects should be destroyed in your may explicitly call objects >> destructors. This is outside the GC/DOD system however as it happens >> from within your mainline code. (When the DOD later runs it won't do >> anything with those objects as you've already destroyed them and thus >> left nothing for the DOD sweep to do) > >If I know what I want to destroy and when, can I just turn off Parrot's >automatic garbage collector/memory compactor and send it instructons on >what I want deleted? You don't even have to go that far. Just explicitly call the object's destruction code and you're fine. (You do *not* want to turn off Parrot's GC, though, or you'll leak like a sieve) Something like: destroy P4 or whatever. You'll need to make sure your cleanup code properly sets the PMC internals to make itself undef so Bad Things don't happen, but that's about it. > > > > Dan >Sugalski > > <[EMAIL PROTECTED] To: >[EMAIL PROTECTED], [EMAIL PROTECTED] > >cc: >[EMAIL PROTECTED] > Subject: Re: How >Powerful Is Parrot? (A Few More Questions) > 01/25/02 >03:43 > >PM > > > > > > > > > > > >At 2:46 PM -0500 1/25/02, [EMAIL PROTECTED] wrote: >> > Parrot supports deterministic destruction at the language level. If >your >>> language wants 'o' to be destroyed at the exit from f2(), then 'o' will >>be >>> destroyed in whatever manner MyClass destruction means to your >language. >>> Resources allocated strictly by the internal representation responsible >>for >>> MyClass (e.g. Leeper_Object) may not be collected at that point, but >>that's >>> mostly independent of the language. (You could also trigger a GC run >>> yourself.) >> >>I believe I understand now. I think that what this means to me is that if >I >>want 100% deterministic destruction, I will have to implement my own >>garbage collector. This garbage collector will call object destructors and >>free all language-specific resources of the object. Once I've finished >>using the object, the Parrot garbage collector will free Parrot resources >>associated with the object at some undetermined time in the future. > >I think you're getting confused a bit here--I apologize for not >jumping in earlier. > >As far as Parrot's concerned, Garbage Collection is just the >reclamation of unused memory and unused interpreter structures. This >will happen when the interpreter deems it necessary, and you can >force or block a GC run if you need to. The heap may be compacted >when this happens, but variables can be marked as non-moveable if >this is necessary. (for those cases when absolute memory addresses >are referenced outside of the interpreter as well) > >Dead Object Detection is the phase where the interpreter determines >which objects are reachable from the root set, and which aren't. Any >objects that aren't reachable *and* are marked as having an active >destructor (and most won't, there's no need in 90% of the cases) will >have their destructor called and the objects can clean up as need be. >Once again this happens when the interpreter deems it necessary and >you may also force or block a DOD run. > >In neither case do you have any control over the order that memory is >compacted, or dead objects with destructors have their destructors >called. If you must force some sort of order you need to do so within >the objects destructor. Alternately if your program knows what order >objects should be destroyed in your may explicitly call objects >destructors. This is outside the GC/DOD system however as it happens >from within your mainline code. (When the DOD later runs it won't do >anything with those objects as you've already destroyed them and thus >left nothing for the DOD sweep to do) > >> "Bryan >>C. >> Warnock" To: >>[EMAIL PROTECTED] >>
regarding cpp namespace pollution
I think the following would work. * At the beginning of each parrot source code file there must be at least two Parrot-specific defines, e.g. #define PARROT_SOURCE #define PARROT_SOURCE_REGEXEC_C These would declare both being part of Parrot, and being a particular file. If some kind of clear component architecture emerges, then a third define may be in order #define PARROT_SOURCE #define PARROT_SOURCE_GC #define PARROT_SOURCE_BOEHM_C * The parrot header files should be anal-retentively sorted into (at least) three categories: * Private to Parrot (intra-source-file protypes, for example). * Visible to friends of Parrot (XS, in Perl-5-talk) * Public. This should be kept to minimum, and to prototypes and constants. No dark scary ifdef forests, no hackish things mattering only to the Parrot implementation. There should be no (accidental) way for things external to Parrot to get at the category one: the way to do this would be to use the PARROT_SOURCE* defines. It requires some discipline, yes, but wasn't that the whole idea of this...? -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Apoc4: The loop keyword
>>Besides no one has commented on Steve Fink's (I think it was him) idea
>>to store the result of the most recently executed conditional in $?. I
>>kinda like that idea myself. It makes mnemonic sense.
H . . . I could grow used to that. A couple of thoughts.
1) It doesn't seem to buy us much that $_ doesn't already, except some slight
legibility in that we can say what the variable holds as in:
foreach $PIN_number (@list) {
my $PIN = $PIN_number;
#Stuff
}
2) What about our new, more complex foreach:
foreach ($key, $value) %hash {
#What's $? here?
}
Perhaps we could use @_, since we're already used to that giving us arguments from
outside the current scope. Using @_ might very well be logical since custom iterators
will be using it anyway.
3) Even given 2 above I'm not sure that:
foreach ($key, $value) %hash {
my ($key, $value) = @_;
# Do stuff
}
is more useful than
do{
my ($key, $value);
foreach ($key, $value) { . . . }
}
simply because at the end of the first we have $key and $value still overwriting any
previous values, and they'll have values afterward. Even if a $? or @_ implementation
existed I'd probably use the do { . . . } anyway for that reason.
-Erik
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
Re: CPP Namespace pollution
On Fri, 25 Jan 2002, Dan Sugalski wrote: > At 10:14 AM -0500 1/25/02, Andy Dougherty wrote: > >For parrot, we'd ideally like to make it a lot safer to > > > > #include > Nope--we'd ideally like to smack anyone writing non-core code that > does that. :) > Embedders will include parrot/parrot_embed.h, while extension folks > will include parrot/parrot_extend.h. Neither will include > parrot/parrot.h--not safe. Sounds like a good plan. Perhaps something like the following patch is in order then, more as a reminder for the future than anything actually useful for now? (Note the changed file names: parrot/parrot_e*.h is apparently redundant and definitely isn't 8.3-friendly, but perhaps you were guarding against the VMS #include problem I vaguely recall where the directory name "parrot" in "parrot/foo.h" could sometimes get ignored?) diff -r -u parrot-orig/include/parrot/parrot.h parrot-andy/include/parrot/parrot.h --- parrot-orig/include/parrot/parrot.h Mon Jan 14 15:04:29 2002 +++ parrot-andy/include/parrot/parrot.h Fri Jan 25 16:52:14 2002 @@ -10,6 +10,11 @@ * References: */ +/* Only parrot core files should include this file. + Extensions should include . + Programs embedding parrot should include . +*/ + #if !defined(PARROT_PARROT_H_GUARD) #define PARROT_PARROT_H_GUARD -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: CPP Namespace pollution
On Friday 25 January 2002 16:55, Andy Dougherty wrote: > Sounds like a good plan. Perhaps something like the following patch is in > order then, more as a reminder for the future than anything actually > useful for now? (Note the changed file names: parrot/parrot_e*.h is > apparently redundant and definitely isn't 8.3-friendly, I count 86 violations of 8.3 in the tree. 8.3-friendly doesn't appear to be a concern. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Comm. Unity - (was Re: CPP Namespace pollution)
-Melvin Smith IBM :: Atlanta Innovation Center [EMAIL PROTECTED] :: 770-835-6984 Dan Sugalski <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], "Perl6 Internals" <[EMAIL PROTECTED]> cc: 01/25/2002 03:44 Subject: Re: Comm. Unity - (was Re: CPP Namespace pollution) PM >At 1:56 PM -0500 1/25/02, Bryan C. Warnock wrote: >>Dan is cleverly aloof in is answers. There's not many folks who flippantly >>hand-wave and still come across as knowing exactly what he's talking about. > >I really do need to work on the flippant bit when I'm not in front of >a roomful of Lisp folks... *cackle* I also read the Dr Dobbs article, you must have stolen the author's parking spot or something. Actually I enjoyed it because it was classic DDJ, all the talk about academic point of view. Rarely do I ever see "academics" doing much to help the rest of the community. Technically I'm an academic (although a poor one) so this statement isn't prejudiced. I also could care less about reinventing the wheel, if I get to own my own wheel and put my name on it.. and paint it yellow... -Melvin Smith IBM :: Atlanta Innovation Center [EMAIL PROTECTED] :: 770-835-6984
Re: scheme-pairs?
Uri Guttman <[EMAIL PROTECTED]> writes: >> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: > > >> Correct, especially a list is nothing but a pair with another pair or > >> an end-of-list-marker in its second element. To implement set-car! and > >> set-cdr! both elements of this pair must be mutable > > DS> Hmmm. I think we can use one thing for both perl pairs and scheme > DS> pairs. We'll need to be careful in spots, though. Perl pairs must > DS> have scalars on either side. (Just as arrays and hashes can only hold > DS> scalars, not arrays or hashes or lists) > > but lisp dotted pair actually only can hold scalars in each node > too. each node could be a pointer to other stuff or a value. that is > classic lisp data structures, all things are trees or lists made from > pairs. Unless I'm completely misunderstanding the lisp refs I've been reading recently, a scheme pair is restricted to holding pointers. Either to other pairs or to things. If you represent it as an array, then you can have: [\"string", $next_pair is reference] but you couldn't have: ["car", $cdr is referent] But I could be *way* off the mark there. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: Comm. Unity - (was Re: CPP Namespace pollution)
"Melvin Smith" <[EMAIL PROTECTED]> writes: > I also could care less about reinventing the wheel, if I get > to own my own wheel and put my name on it.. and paint it yellow... No mate, you want to paint it purple. You know it makes sense. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: Comm. Unity - (was Re: CPP Namespace pollution)
At 10:21 PM + 1/25/02, Piers Cawley wrote: >"Melvin Smith" <[EMAIL PROTECTED]> writes: >> I also could care less about reinventing the wheel, if I get >> to own my own wheel and put my name on it.. and paint it yellow... > >No mate, you want to paint it purple. You know it makes sense. Just as long as no bikesheds are involved... -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Comm. Unity - (was Re: CPP Namespace pollution)
At 5:01 PM -0500 1/25/02, Melvin Smith wrote: > >At 1:56 PM -0500 1/25/02, Bryan C. Warnock wrote: >>>Dan is cleverly aloof in is answers. There's not many folks who >flippantly >>>hand-wave and still come across as knowing exactly what he's talking >about. >> >>I really do need to work on the flippant bit when I'm not in front of >>a roomful of Lisp folks... > >*cackle* > >I also read the Dr Dobbs article, you must have stolen the author's >parking spot or something. Apparently so. Judging from the pictures, Shriram and I both did something unpleasant to the art director too. >Actually I enjoyed it because it was classic DDJ, all the talk about >academic point of view. Rarely do I ever see "academics" doing much >to help the rest of the community. Apparently producing solid, useable stuff doesn't get you tenure, which I can see could be a big disincentive. OTOH, the workshop was really useful in a number of ways, so it's not like no exchange is going on. Hopefully we can have more in the future. (Greg, the guy who arranged the conference, passed on some really interesting ideas for optimization >Technically I'm an academic (although a poor one) so this statement >isn't prejudiced. Well, we weren't alone in getting shot at. The very first paragraph was a good smack at Greg, which wasn't at all fair. >I also could care less about reinventing the wheel, if I get >to own my own wheel and put my name on it.. and paint it yellow... Works for me. Whatever gets me a wheel fastest... -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Comm. Unity - (was Re: CPP Namespace pollution)
On Fri, Jan 25, 2002 at 01:56:20PM -0500, Bryan C. Warnock wrote: > If anything, it's largely our fault, for allowing, through our silence, > Simon to speak on our behalf in those situations. Hey, if my speaking on behalf of Perl 6 is such a problem, someone else is very welcome to this maintainer's hat... > Simon, (occasionally referred to as the Tom Christiansen for a New > Generation :-) Heh. I'm not sure whether that's a complement or an insult. :) But you're right - like Tom, I'm bigly in favour of people doing their own research before blustering in. We're not, for instance, going to be writing parts of Parrot in C++, as a study of the FAQ (which I honestly did not know was not very well publicised[1]) or the mailing list archives would confirm. Suggestions that we could or ought to just convince me that the questioner has not done his homework, and this makes me less disposed to giving him anything more than terse answers. [1] Even though on the other hand, it is relatively easy to find via Google. -- #define struct union /* Great space saver */
Parrot FAQ in repository
I'm not the author but I checked the FAQ into the repository. Its in HTML format, which seems fine to me, I guess if people have gripes that its not a POD then talk to Adam Turoff. :) -Melvin
Re: Comm. Unity - (was Re: CPP Namespace pollution)
At 11:55 PM 1/25/2002 +, Simon Cozens wrote: >On Fri, Jan 25, 2002 at 01:56:20PM -0500, Bryan C. Warnock wrote: > > If anything, it's largely our fault, for allowing, through our silence, > > Simon to speak on our behalf in those situations. > >Hey, if my speaking on behalf of Perl 6 is such a problem, someone else is >very welcome to this maintainer's hat... Your doing fine in my book, I think everyone should pitch in and make info and documentation more readily available such as "on the website" and in the distribution. -Melvin
Config police
HAS_HEADER_ERRNO does not exist and errno.h is not wrapped in this ifdef. Hopefully the Config police can fix this, I ran into this while working on an embedded compile and Configure is not a module I am useful with. -Melvin
string interpolation
Hello, I was reading stuff on the perl6 web site, and had some ideas about
string interpolation rules. Is this a place to send this?
String interpolation should be controlled by the programmer on a string by
string basis, or on more global quote-type by quote type basis.
---
scenario one, object.method format
---
Lets pretend a string is an object. The "normal" value of the string is the
interpolation of the string using the default rules for the quotes used.
Lets add an .interpolate method. The parameter(s) are rules that control
the interpolation, and the returned value is the interpolated string using
those rules.
$result = 'scalar $vars (only) will be interpolated' .
interpolate($) ;
The .interpolate method would have the additional ability to interpolate the
contents of a variable.
$result = $string.interpolate; # some type of interpolate, probably
like "
$result = $string.interpolate(${}); # interpolate scalar vars
surrounded by {}'s
you could imagine allowing more complex rules, such as mapping
interpolations to user defined functions, or only interpolating defined
variables, otherwise leave them as-is, or perhaps allowing you to map
specific variables to values but just for that one string's interpolation
# only interpolate defined variables
$result = "$some $of $these $will $be
$interpolated".interpolate(defined($)) ;
# interpolate, one variable gets a specific value
$result = "$one $two $three".interpolate('$one'=>'hi there') ;
# interpolate, scalar values come from user defined function
$result = "$one $two $three".interpolate($ => \&my_function) ;
Here's some more examples
# normal interpolation (i.e. none in ' quotes)
$result = 'string with $var';
# override the ' defaults
# use the $ rule, which would mean interpolate scalars just
# as we do today in " strings
$result = 'string with $var' . interpolate($);
# use the ${} rule, which would mean interpolate scalars,
but
# only when bracketed (using {})
$result = 'string with ${var}' . interpolate(${});
# allow a function to interpolate in scalar context
# by using the & rule combined with $-with-round-brackets
rule
# the function parameters would not be interpolated,
$result = 'string with $(my_function($one,$two))' .
interpolate($(&));
# allow a function to interpolate in array context
# by using the & rule combined with @-with-round-brackets
rule
$result = 'string with @(my_function($one,$two))' .
interpolate(@(&));
# allow a function to interpolate in scalar context
# by using the & rule combined with $-with-round-brackets
rule
# and also let the function parameters be interpolated
$result = 'string with $(my_function("$one","$two"))' .
interpolate($(&));
# nested interpolation rules.
# We force regular scalar interpolation on one of the
parameters
# overriding the default ' interpolation rules
$result = 'string with $(my_function('$one'.interpolate($)
,'$two'))'
. interpolate($(&));
You could set the default interpolation on a quote-type basis for a scope.
# allow qq{} to always do scalar, array, and function
interpolation,
# but only if the scalar is surrounded by //, the array by
{}, and
# the function by <>
use interpolate 'qq' => '$//@{}$<&>' ;
$result = "$this does *not* @interpolate $(at{'all'})";
$result = "$/this/ *does* @{interpolate} $";
---
scenario two, same idea but using =~ notation.
---
A string could have interpolation rules "applied" to the string. The rules
would not modify the string, just the value seen by when the value is
extracted. That's not an issue in a simple quoted string, but makes a
difference if you interpolate a variable
$result = "this $is_not interpolated, but ${this_is}" =~ i/${}/;
$result1 = $master_copy =~ i/${}/; # get the result of
interpolating ${} vars
$result2 = $master_copy =~ i/@/;# get the result of
interpolating @ vars
$0.02
Re: string interpolation
On Fri, Jan 25, 2002 at 05:07:48PM -0800, Dew-Jones, Malcolm MSER:EX wrote: > Lets add an .interpolate method. The parameter(s) are rules that control > the interpolation, and the returned value is the interpolated string using > those rules. > > $result = 'scalar $vars (only) will be interpolated' . > interpolate($) ; I'm actually just thinking about how to do interpolation now; I'm basically using Perl 5 rules for the most part. The thing that worries me about this idea of yours is that interpolate certainly looks like a method, but it isn't; the arguments you're passing in aren't real arguments at all, they're not ordinary Perl syntax. In fact, you've made up a special tiny domain-specific language for conveying how to interpolate certain things. Now, there's nothing wrong with tiny domain-specific languages, given the right domain. For instance, regular expressions are the right domain. But when you add a little DSL, you have to tell the parser to stop parsing ordinary Perl, and start parsing something else. And you want to do this when you see an interpolate method on a string. Or maybe not just on a string - maybe "interpolate" becomes a special method on everything, which takes this special syntax. Either way, I'm not sure this is something you want to be making up new syntax for. > scenario two, same idea but using =~ notation. Slightly better, but =~ means "match" in some sense, and that sense is getting broader in Perl 6. And interpolation doesn't have very much in common with matching. -- It's a testament to the versatility of the human mind that we're so able to compensate for our own incompetence. - Darrell Furhiman
Re: What can be hyperoperated?
Simon Cozens writes:
: I'm trying to answer the question "what does ^ mean?".
: Can anything be hyperoperated, or just a built-in set of operations?
Probably anything that is sufficiently "scalar" in its typology.
: If "anything", can user's subroutines be hyperoperated?
Why not? (Provided the type signature isn't too wacky.)
: How will they know that they're being called in "hyper context"?
Do they need to? In the simple case, the hyperoperator provides list
context to its arguments, but just calls the scalar operation repeatedly
to fake up the list operation. Any operator
@result = @a ^op @b
is really just something like
@result = for @a; @b -> $a, $b { $a op $b }
(presuming we make C actually act like C).
For the case where one or the other argument is a scalar, we can just
replicate it to a list.
If the PDL folks want to get fancier, I'm sure we can arrange overloading
of ^op as easily as op.
Larry
Re: What can be hyperoperated?
On Fri, Jan 25, 2002 at 06:03:55PM -0800, Larry Wall wrote: > Do they need to? In the simple case, the hyperoperator provides list > context to its arguments, but just calls the scalar operation repeatedly > to fake up the list operation. Cool. So as far as the parser cares, ^ is simply a flag meaning "carry out the next operation in an interesting way". That helps. -- "He was a modest, good-humored boy. It was Oxford that made him insufferable."
Re: Apocalypse 4 : The Strange Case of the STRANGE CASE
I would not be appalled if Perl 6 were to assume use
of caps for catcher block labels, but I would still like to
see Larry et al reconsider this design choice.
One suggestion is use of label syntax for catcher
blocks (suggests "come-from"). If catch and CATCH
were defined as synonyms, then one could type:
LAST: {
or
last: {
--me
RE: Config police
Melvin Smith: # HAS_HEADER_ERRNO does not exist and errno.h is not wrapped # in this ifdef. Hopefully the Config police can fix this, I # ran into this # while working on an embedded compile and Configure is not a # module I am useful with. That's odd. Does your Perl 5 have i_errno defined in Config.pm? If so, then Parrot should have HAS_HEADER_ERRNO defined as well. (If your Config.pm makes no mention of i_errno, then you shouldn't expect to see HAS_HEADER_ERRNO.) --Brent Dax [EMAIL PROTECTED] Parrot Configure pumpking and regex hacker Check out the Parrot FAQ: http://www.panix.com/~ziggy/parrot.html (no, it's not mine) . hawt sysadmin chx0rs This is sad. I know of *a* hawt sysamin chx0r. I know more than a few. obra: There are two? Are you sure it's not the same one?
RE: Config police
At 07:40 PM 1/25/2002 -0800, Brent Dax wrote: >Melvin Smith: ># HAS_HEADER_ERRNO does not exist and errno.h is not wrapped ># in this ifdef. Hopefully the Config police can fix this, I ># ran into this ># while working on an embedded compile and Configure is not a ># module I am useful with. > >That's odd. Does your Perl 5 have i_errno defined in Config.pm? If so, >then Parrot should have HAS_HEADER_ERRNO defined as well. (If your >Config.pm makes no mention of i_errno, then you shouldn't expect to see >HAS_HEADER_ERRNO.) Nope, it isn't defined. Why I mentioned it is I was working on compiling for WindowsCE for an iPAQ and was included regardless of config. WinCE SDK doesn't have errno.h (I can fake it though) but I figured it we should have an ifdef around the include. Basically for embedded environments I have to fudge stuff because the config runs, for example, on my Win2000 box where I have Microsoft Embedded Visual Tools, but it generates a config for Win32 (not for WinCE). I then was just hand patching to fix stuff. I just wasnt sure how to address this; I added the ifdef HAS_HEADER_ERRNO to get a compile but if I committed this patch then everyone else's would break because, while 99% of systems have , the #define wont exist. I guess what I _could_ do is: #ifndef WIN32_PLATFORM_PSPC /* PocketPC */ # include #endif But I don't think this was the way to fix this. -Melvin
Re: Apoc4: The loop keyword
At 11:40 AM 1/25/2002 -0600, Jonathan Scott Duff wrote: >On Fri, Jan 25, 2002 at 11:57:25AM +0100, Bart Lateur wrote: > > On Mon, 21 Jan 2002 15:43:07 -0500, Damian Conway wrote: > > > > >What we're cleaning up is the ickiness of having things declared outside > > >the braces be lexical to the braces. *That's* hard to explain to > beginners. > > > > But it's handy. And that was, until now, what mattered with Perl. > >No, handiness still matters with Perl. It's just that the balance has >tipped a wee bit towards the consistency/regularity/simplicity/whatever >side of the scale. > >Besides no one has commented on Steve Fink's (I think it was him) idea >to store the result of the most recently executed conditional in $?. I >kinda like that idea myself. It makes mnemonic sense. I like the $? idea, and it could probably be optimized away. -Melvin
RE: How Powerful Is Parrot? (A Few More Questions)
>This is exactly the right way to do things in Java. In Java, you >can open hundreds of files, and never trigger any gc, since each >file object is very small. Unless you explicit close file, you >will be dead very quickly. Although your point is taken, I think in this case it is the programmer who is at fault. Any programmer who opens hundreds of files hoping for GC to take over is asking for it, in any language. >This is one of the reason Java is so sloppy. Everyone relies on language >feature to do their job, but it is impossible for JVM to know there I think it is the programmer who is sloppy. Java just encourages it, IMO. -Melvin
Re: How Powerful Is Parrot? (A Few More Questions)
> "DL" == David Leeper <[EMAIL PROTECTED]> writes: DL> If I know what I want to destroy and when, can I just turn off Parrot's DL> automatic garbage collector/memory compactor and send it instructons on DL> what I want deleted? i have to jump in here because i am seeing the classic discussion of A and B and they are not the same things. in parrot, GC is separated from DoD. you seem to always conflate the two. in general destruction is not related to GC, it is used to clean up stuff like file handles, complex objects, deal with persistance etc. a destroyed object may have its space reclaimed at some future time. destruction is more of a language feature and GC is more of a VM feature. they are not the same thing and you shouldn't keep talking about them as if they are con-joined twins. you can cause object destruction when you want in most langs that parrot will support. and you can probably initiate a GC pass from most langs if they have an API to get into parrot's GC. but you don't have to do one to do the other. many heap allocated things won't be objects (buffers, strings, etc.) and will be purely GC'ed as needed. some objects can be destroyed simply when their context exits (e.g. leaving a block and destroying any my'ed objects which are dead). those will then be marked for later GC. so please note that destruction is not collection and they are and can be separately controlled. you have to stop thinking c++ (which will probably NOT be directly supported by parrot) and think perlish (or as other dynamic langs) more. perl doesn't have a delete thing and doesn't need one. it can detect DoD on its own and then let parrot GC them later. memory usage and objects are not the same. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com -- Stem is an Open Source Network Development Toolkit and Application Suite - - Stem and Perl Development, Systems Architecture, Design and Coding Search or Offer Perl Jobs http://jobs.perl.org
Re: scheme-pairs?
> "PC" == Piers Cawley <[EMAIL PROTECTED]> writes: PC> Uri Guttman <[EMAIL PROTECTED]> writes: >> >> but lisp dotted pair actually only can hold scalars in each node >> too. each node could be a pointer to other stuff or a value. that is >> classic lisp data structures, all things are trees or lists made from >> pairs. PC> Unless I'm completely misunderstanding the lisp refs I've been reading PC> recently, a scheme pair is restricted to holding pointers. Either to PC> other pairs or to things. If you represent it as an array, then you PC> can have: PC>[\"string", $next_pair is reference] PC> but you couldn't have: PC>["car", $cdr is referent] PC> But I could be *way* off the mark there. that is sorta what i meant by scalars there. i should have been clearer. a dotted pair is a pair of pointers but a perl 6 pair is a pair of full scalars. but even so, a PMC would need 2 pointer slots for a dotted pair. one could be the data slot (points to string buffer, etc.) the other could be this new PMC pointer slot that can double as the cdr of a dotted pair. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com -- Stem is an Open Source Network Development Toolkit and Application Suite - - Stem and Perl Development, Systems Architecture, Design and Coding Search or Offer Perl Jobs http://jobs.perl.org
