> "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
> "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 dis
>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
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 bra
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.
>
>Th
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 Co
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 co
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
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
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 inte
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.
---
scenar
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
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
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
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 maintaine
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 f
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
"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
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 m
-Melvin Smith
IBM :: Atlanta Innovation Center
[EMAIL PROTECTED] :: 770-835-6984
Dan Sugalski
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
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/pa
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 ki
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.
> 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 ...
> }
>
> ..
>>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 muc
> 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 sh
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 folk
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.
>> Resourc
> 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 deallocati
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 PROTEC
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 th
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 us
> 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()
> 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 respons
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 diffic
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.
> 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 y
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 th
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,
> 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
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
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
> >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 corr
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
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
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.
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.
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.
>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
>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
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
>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
> 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
> > This requires the use of C++, rather than C.
> See the FAQ.
Where would the FAQ be?
Dave
Simon Cozens
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 th
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
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 la
> 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 _PARR
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
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
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,
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 = <$
63 matches
Mail list logo
