"Non-yet-thrown exceptions must be a useful concept."

[Me]

"Non-yet-thrown exceptions must be a useful concept."

This is a bullet point from a list in Apo4 introducing
coverage of exception handling. Was Larry talking
about an exception object that hasn't yet been thrown?
Did he refer to this issue again anywhere else in the Apo?

--me

Parrot strings: are strings like "\x{FF10}" false?

[David Chan]

Hi,

Which Parrot strings are supposed to be false in a boolean context?
For instance, is "\x{FF10}" (FULLWIDTH DIGIT ZERO) false?

docs/strings.pod says[1] a string is false if it "consists of one
digit character whose numeric value (as decided by its character type)
is zero".

However, string.c says[2] 'A string is true if it is equal to anything
but "" and "0"' - implying that "\x{FF10}" is true.  But then it 
calls s->type->get_digit, and strangely enough,  chartypes/unicode.c
has a FIXME comment which implies[3] that unicode_get_digit(U+FF10)
should return 0.

Allowing things like "\x{FF10}" to be false sounds like a bit of a
nightmare to me.  There are already over 20 forms of zero in Unicode
3.1; if the next version of unicode adds another one at, say, U+3,
does the next version of parrot change to think that "\x{3}" is
a false string?

Thanks,
-- 
David


[1] docs/strings.pod:
> To test a string for truth, use:
> 
> BOOLVAL string_bool(struct Parrot_Interp *, STRING* s);
> 
> A string is false if it
> 
>  o  is not yet allocated
>  o  has zero length
>  o  consists of one digit character whose numeric value (as
> decided by its character type) is zero.
> 
> Otherwise the string will be true.



[2] string.c:
> /* A string is "true" if it is equal to anything but "" and "0" */
> BOOLVAL string_bool (const STRING* s) {
[...]
> if (len == 1) {
> UINTVAL c = s->encoding->decode(s->bufstart);
> if (s->type->is_digit(c) && s->type->get_digit(c) == 0) {
> return 0;
> }
> }
> 
> return 1; /* it must be true */
> }



[3] chartypes/unicode.c:
> static BOOLVAL
> unicode_is_digit(UINTVAL c) {
> return (BOOLVAL)(isdigit(c) ? 1 : 0); /* FIXME - Other code points are also 
>digits */
> }
> 
> static INTVAL
> unicode_get_digit(UINTVAL c) {
> return c - '0'; /* FIXME - many more digits than this... */
> }

Re: CPP Namespace pollution

[Ask Bjoern Hansen]

On Fri, 25 Jan 2002, Melvin Smith wrote:

> >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."

That sounds good to me.


 - ask

-- 
ask bjoern hansen, http://ask.netcetera.dk/   !try; do();

Re: Config police

[Nicholas Clark]

On Fri, Jan 25, 2002 at 11:14:38PM -0500, Melvin Smith wrote:
> 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.

Bletch. Unless I'm much mistaken that means that WinCE SDK therefore isn't
a full ANSI conformant C library. [Which it is allowed to be - IIRC
compilers without libraries are "allowed"]
I can't remember all the terms for compilers that are conformant but don't
have the libraries but I am surprised that the SDK isn't a full implementation
of compiler&libraries.

Part of me therefore thinks that NOT putting an ifdef around the include
and having other systems fake errno.h if they need to.

> 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.

This is the start of a more generate cross compiling problem, isn't it?

> 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.

That doesn't feel right either.

Nicholas Clark
-- 
ENOCHOCOLATE http://www.ccl4.org/~nick/CV.html

Re: Config police

[Segher Boessenkool]

> Bletch. Unless I'm much mistaken that means that WinCE SDK therefore isn't
> a full ANSI conformant C library. [Which it is allowed to be - IIRC
> compilers without libraries are "allowed"]
> I can't remember all the terms for compilers that are conformant but don't
> have the libraries but I am surprised that the SDK isn't a full implementation
> of compiler&libraries.

Hosted vs. freestanding.

A freestanding implementation is only required to provide
, , , , , 
and ; furthermore, the entry point is not required to
be main().


Cheers,

Segher

Re: Parrot strings: are strings like "\x{FF10}" false?

[Alex Gough]

On Sat, 26 Jan 2002, David Chan wrote:

> Hi,
>
> Which Parrot strings are supposed to be false in a boolean context?
> For instance, is "\x{FF10}" (FULLWIDTH DIGIT ZERO) false?
>
> docs/strings.pod says[1] a string is false if it "consists of one
> digit character whose numeric value (as decided by its character type)
> is zero".
>
> However, string.c says[2] 'A string is true if it is equal to anything
> but "" and "0"' - implying that "\x{FF10}" is true.  But then it

The comment is meant to be encoding and character set agnostic.  The
unicode character set will need to eventualy provide a get_digit
method which does turn \x{FF10} into a numeric zero.  It's just that
our unicode support is lagging behind ascii, with most (all?) of the
methods being nothing more than placeholders.

Alex Gough

Re: 123_456

[Bart Lateur]

On Fri, 25 Jan 2002 17:34:12 +, Simon Cozens wrote:

>Should we be allowed to use _ to group numbers, now that _ is concat?
>If not _, then what? (if anything?)

I don't really understand your question. Currently, "." is used for
concat and that doesn't inhibit using it in a number, does it? Or what
would you suppose that 3.14 means?

Quite the countrary: ("100" . "000") as a number is indeed 10, as is
100_000. So there's *less* of a conflict than today, in perl5.

-- 
Bart.

Re: Parrot strings: are strings like "\x{FF10}" false?

[Simon Cozens]

On Sat, Jan 26, 2002 at 10:42:17AM +, David Chan wrote:
> Which Parrot strings are supposed to be false in a boolean context?

Thinking more deeply about this, I guess it depends entirely on the 
language, although we can provide string_bool as a sensible default.

> For instance, is "\x{FF10}" (FULLWIDTH DIGIT ZERO) false?

Yes.

> > unicode_is_digit(UINTVAL c) {
> > return (BOOLVAL)(isdigit(c) ? 1 : 0); /* FIXME - Other code points are also 
>digits */
> > }
> > 
> > static INTVAL
> > unicode_get_digit(UINTVAL c) {
> > return c - '0'; /* FIXME - many more digits than this... */
> > }

Yep, once these functions are fixed to really grok Unicode numeric value and
digit value properties, string_bool will just work.

-- 
Thermodynamics in a nutshell:
1st Law:  You can't win.  (Energy is conserved)
2nd Law:  You can't break even.  (Entropy)
0th Law:  You can't even quit the game.  (Closed systems) -- Taki Kogoma

JIT Regression

[Simon Cozens]

I'm sure I wasn't seeing this before:

 % ./test_parrot -j examples/assembly/mops.pbc
 Iterations:1zsh: 17990 illegal hardware instruction

-- 
Hildebrant's Principle:
If you don't know where you are going, any road will get you there.

GCC-specific (?) options in Makefile.in

[Simon Cozens]

Intel's icc doesn't like the -Wl,... What's it doing there, anyway?

blib/lib/libparrot$(SO).${VERSION}: $(O_FILES)
$(LD) -shared -Wl,-soname,libparrot$(SO).${MAJOR} $(LDFLAGS) -o 
blib/lib/libparrot$(SO).${VERSION} $(O_FILES)

blib/lib/libcore_prederef$(SO).${VERSION}: core_ops_prederef$(O)
$(LD) -shared -Wl,-soname,libparrot$(SO).${MAJOR} $(LDFLAGS) -o 
blib/lib/libcore_prederef$(SO).${VERSION} core_ops_prederef$(O)

-- 
"The elder gods went to Suggoth and all I got was this lousy T-shirt."

Re: Comm. Unity - (was Re: CPP Namespace pollution)

[Bryan C. Warnock]

On Friday 25 January 2002 18:55, 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...

"...in those situations..."  If we've a concern, we can pipe up.

Brevity of answer is sometimes good.  Answers that provide exactly the right 
amount of information are better.  Contextual or personality clues are often
needed to decide how much is enough, which is tough to do with folks that 
provide neither.

No one wants to read through any of my diatribes when a simple "you can find 
an entry here" will suffice.  (This occasionally happens to me with things 
that have changed in recent versions of Perl.  "I *have* read the manuals, 
and if you didn't have so many of them, I'd read them all again.")

>
> > 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. :) 

Smiley aside, neither.  It's just commentary.  Tom provides (provided?) 
spiciness to the Perl community.  Sometimes a slap upside the head is 
*exactly* what's needed.  (If nothing else, as refreshment to those that
*do* patiently explain the Way Things Are while secretly wishing that a kill 
file could contain more than just email.)

> 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.

A perfectly valid response.  I'm not saying that *you* should be more 
cautious in what you say and how you say it - I'm saying that the community 
should feel free to add their own responses if they're not happy with the 
phraseology of yours.

After all, without "Read the FAQ", it wouldn't have become clear that the 
FAQ hadn't been imported yet.

>
> [1] Even though on the other hand, it is relatively easy to find via
> Google.

-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Re: CPP Namespace pollution

[Dan Sugalski]

At 4:55 PM -0500 1/25/02, 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, 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?)

I was watching out for both the VMS case and the case where someone 
just ups and throws extend.h and embed.h into a global directory 
somewhere even though they shouldn't. VMS should be OK, and if people 
toss files around without paying attention they probably should 
expect problems.
-- 

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: What can be hyperoperated?

[Randal L. Schwartz]

> "Larry" == Larry Wall <[EMAIL PROTECTED]> writes:

Larry> @result = for @a; @b -> $a, $b { $a op $b }

Larry> (presuming we make C actually act like C).

Why not just make map do that?

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: What can be hyperoperated?

[Damian Conway]

> Larry> @result = for @a; @b -> $a, $b { $a op $b }
> 
> Larry> (presuming we make C actually act like C).
> 
> Why not just make map do that?

The order of C's arguments is wrong. To make the -> extraction
syntax work we need the data being iterated to be on the left and the
processor block (actually a closure in Perl 6) to be on the right.

Damian

Barewords and subscripts

[Simon Cozens]

A4 said that there were no barewords in Perl 6. Does this mean that
$foo{bar}
actually should be written
%foo{"bar"}
?

I'm vaguely hoping that the answer is yes, because then we could treat
*all* instances of {...} as a block returning either a closure, a value
for subscripting, or an anonymous hash, rather than having to decide at
tokeniser time.

-- 
Overall there is a smell of fried onions.  (fnord)

Re: Barewords and subscripts

[Peter Scott]

At 05:01 PM 1/26/02 +, Simon Cozens wrote:
>A4 said that there were no barewords in Perl 6. Does this mean that
> $foo{bar}
>actually should be written
> %foo{"bar"}
>?

No.  That's not a bareword.

>I'm vaguely hoping that the answer is yes, because then we could treat
>*all* instances of {...} as a block returning either a closure, a value
>for subscripting, or an anonymous hash, rather than having to decide at
>tokeniser time.

--
Peter Scott
Pacific Systems Design Technologies
http://www.perldebugged.com

Re: Barewords and subscripts

[Simon Cozens]

On Sat, Jan 26, 2002 at 09:28:18AM -0800, Peter Scott wrote:
> >%foo{"bar"}

It's bare, and it's a word.

I presume you're also happy with these ambiguities:
$foo{shift} vs. $foo{"shift"}

$foo{bar} vs. sub bar() { ... } $foo{bar} 
  vs. $foo{+bar} 
  vs. $foo{bar()}
  vs. $foo{"+bar"} 
  vs. $foo{"bar()"}

and they never cause any problems?

> Pacific Systems Design Technologies
> http://www.perldebugged.com

Although I suppose if we make it harder for people to write buggy 
Perl, there's less of a market for debugging books. :)

-- 
10. The Earth quakes and the heavens rattle; the beasts of nature flock
together and the nations of men flock apart; volcanoes usher up heat
while elsewhere water becomes ice and melts; and then on other days it
just rains. - Prin. Dis.

Re: Apoc4: The loop keyword

[Richard J Cox]

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] 
(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.
> 
> 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.


As someone how comes from the C++ world, I'm really glad that C99 saw 
sense and added

if (int i = x()) {
// i in scope here
...
}

// i not in scope here

and therefore was really disappointed that Larry wants to take it out of 
Perl. The argument about consistency ("only variables declared in a block 
go out of scope at the end of that block") is valid, but of course Perl6 
will not always be following that rule anyway.

The exception is function declarations, named parameters will be declared 
outside the statement block that forms the body of the function; yet will 
be scoped to that block.

For example, I really don't think that &closure and @fileList are expected 
to have file scope (for want of a better term), after declaring a function 
such as:

sub attempt_closure_after_successful_candidate_file_open
(&closure, @fileList) {
#...
}

(From about half way through Apoc4).


If we already have one case where the rule is actually "only variables 
declared in a block or in its 'controlling statement' go out of scope at 
the end of that block", so why not make that the general rule and allow 
code such as

while (defined(my $line = $file.readline())) {
# ...
}

not to interfere with code elsewhere in the block that may use a variable 
called $line (it certainly makes maintenance easier to add a variable with 
out extraneous braces but to have a tightly contained scope).



-- 
[EMAIL PROTECTED]

Warnock's dilemma [PATCH] harness just the tests you want

[Nicholas Clark]

Any thoughts on this patch?
- Forwarded message from Nicholas Clark <[EMAIL PROTECTED]> -

Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
List-Post: 
List-Help: 
List-Unsubscribe: 
List-Subscribe: 
To: [EMAIL PROTECTED]
Subject: [PATCH] harness just the tests you want
From: Nicholas Clark <[EMAIL PROTECTED]>

À la perl 5, it can be useful just to run 1 test script under the harness.

Nicholas Clark
-- 
ENOCHOCOLATE http://www.ccl4.org/~nick/CV.html

--- t/harness.orig  Wed Jan  2 19:19:09 2002
+++ t/harness   Mon Jan 21 11:46:54 2002
@@ -1,7 +1,9 @@
 #! perl -w
+# $Id: $
 
 use strict;
 use Test::Harness qw(runtests);
 
-my @tests = map { glob( "t/$_/*.t" ) } ( qw(op) );
+# Pass in a list of tests to run on the command line, else run all the tests.
+my @tests = @ARGV ? @ARGV : map { glob( "t/$_/*.t" ) } ( qw(op) );
 runtests(@tests);

- End forwarded message -

Re: Apoc4: The loop keyword

[Jonathan Scott Duff]

On Fri, Jan 25, 2002 at 12:50:51PM -0800, Erik Steven Harrison wrote:
> >>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
> }

ENOCONDITIONAL

$? would be set to the result of the most recently evaluated
conditional (things like if(), elsif(), while(), or until())

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: What can be hyperoperated?

[Jonathan Scott Duff]

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.  Any operator
> 
> @result = @a ^op @b
> 
> is really just something like
> 
> @result = for @a; @b -> $a, $b { $a op $b }

Just to make sure I'm not confused, the for loop above should really
look like this:

@result = for @a; @b -> $a; $b { $a op $b }

right?  I re-read the Apocalypse and it says that both of these would
be the same, but if that's the case, then I don't understand how you
would take items two at a time across multiple streams.

I expect @a;@b->$a;$b to assign @a[0] to $a, @b[0] to $b, etc.
and @a;@b->$a,$b to assign @a[0] to $a, @a[1] to $b, etc, 

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: Barewords and subscripts

[Peter Scott]

At 05:43 PM 1/26/02 +, Simon Cozens wrote:
>On Sat, Jan 26, 2002 at 09:28:18AM -0800, Peter Scott wrote:
> > >%foo{"bar"}
>
>It's bare, and it's a word.

Maybe you want to come up with another term to describe it then... but it 
isn't a "bareword" in Perl.  Camel III p.64 footnote: "... It's only a 
bareword when the parser has no clue."  p.65: "If you say C then any bareword will produce a compile-time error."

>I presume you're also happy with these ambiguities:
> $foo{shift} vs. $foo{"shift"}

I'm not arguing with the ambiguities you pointed out (which have vexed me 
on occasion also); just that it ain't a bareword. "Unquoted identifier used 
as hash subscript" is a bit of a mouthful, though.

Maybe there will be a Perl 6 rule forcing the keys to be quoted, but it 
won't be because of the "no barewords" rule.  If there were such a rule, I 
presume you'd also apply it to the LHS of =>?

--
Peter Scott
Pacific Systems Design Technologies
http://www.perldebugged.com

Re: Warnock's dilemma [PATCH] harness just the tests you want

[Simon Cozens]

On Sat, Jan 26, 2002 at 05:47:19PM +, Nicholas Clark wrote:
> Any thoughts on this patch?

It should go in. Sorry. It's in now, thanks.

-- 
Relf Test Passed.

I send too much mail...

[Dan Sugalski]

And this is one of them.

So, for Bryan, who's keeping track...

"This is my 2500th message"

:)

Dan

Re: Barewords and subscripts

[Tom Christiansen]

>Maybe there will be a Perl 6 rule forcing the keys to be quoted, but it
>won't be because of the "no barewords" rule.  If there were such a rule, I
>presume you'd also apply it to the LHS of =>?

There is another way to resolve the ambiguity of foo meaning either
"foo" or foo() depending on current subroutine visibility.  This
would also extend then to issue of $hash{foo} meaning either
$hash{foo()} or $hash{"foo"}.  Just use parens.  

Oh, I know, I know.  I can already hear the mass reaction now: "Oh,
horrors!" cry the masses from every timezone.  But let's think about
it anyway.

Perl's historical optionality of explicit parentheses to delimit a
function's argument list is, like its similar optionality of explicit
quotation marks, a source of ambiguity.  And while ambiguity can
be a source flexibility, expressibility, and convenience, it can
also have a darker side that would be better relegated to obfuscated
programming contests than to production-calibre code.

In my experience, many programmers would prefer that all functions
(perhaps restricted to only those of no arguments to appease
hysterical cetaceans?) mandatorily take (even empty) parens.  Thus,
shift() in lieu of shift, no matter whether it's as a hash subscript
or the left-hand operand of the comma arrow, or whether it's floating
around free, outside of any such autoquoting construct.

Since this matter has now been mentioned, I would like to suggest that 
there lurk other related and perhaps even more important ramifications to 
the current optionality of parentheses than the one concerning strings.

Witness:

% perl -MO=Deparse,-p -e 'push @foo, reverse +1, -2'
push(@foo, reverse(1, -2));

% perl -MO=Deparse,-p -e 'push @foo, rand +1, -2'
push(@foo, rand(1), -2);

% perl -MO=Deparse,-p -e 'push @foo, time +1, -2'
push(@foo, (time + 1), -2);

[ Gr.  That should read time(). ]

% perl -MO=Deparse,-p -e 'push @foo, fred +1, -2'
push(@foo, ('fred' + 1), -2);

Do you see what I'm talking about?  The reader unfamiliar with the
particular context coercion templates of the functions used in code
like

use SpangleFrob;
frob @foo, spangle +1, -2;

can have no earthly idea how that will even *parse*.  This situation
seems at best, unfortunate.

I'm sure that if it were somehow possible to require proper placement of all
those parens, even with something like the hypothetical and wholly optional
"use strict 'parens'", that this would raise the hackles of many a current
Perl programmer.  But perhaps this owes more to the fact that those folks
do not have to explain or justify this particular--well, let's be charitable
and merely call it an "issue"--to those whom it befuddles or annoys than it
owes to any legitimate convenience or desirable functionality.  When you get
to see non-wizards repeatedly stumble on these ambiguities on a regular basis,
this whole situation can quickly become a source of frustration, embarrassment,
or both.  Whether this scenario inspires apologetics or apoplectics is not
consistently predictable.

However, if one were simply *able* to write something like

use SpangleFrob;
use strict 'parens';  # subsumed within a blanket "use strict"

frob(@foo, spangle(1, -2));
frob(@foo, spangle(1), -2);
frob(@foo, spangle() + 1, -2);

then, without even inflicting grievous harm on compile-time checking of
arguments, one could at least always readily discern which arguments went
where--which hardly seems an undesirable goal, now does it?

Nevertheless, even that wouldn't help in being able to know whether
that's really  meaning

frob(@foo, 
frob(   \@foo, 
frob( scalar @foo, 

It all would depend upon the existence of coercion templates such
as frob(@...), frob(\@...), and frob($...).  Sadly, there's no
B::Deparse switch to tell you under which scenario your operating,
but that's all probably best left for a semi-separate discussion
(if at all).

The devil's advocate might suggest that not knowing which of the
three treatments of @foo silently occurred in the frobbing function
call--which they with some credibility assert a desirable goal--goes
hand in glove with not knowing whether spangle is here acting as a
list-op, as a un(ary)-op, or as a non(e)-op.  But considering that
such devils need no help in their advocacy, I shan't bother to do
so myself.  :-)

--tom

Parrot test harness and stdout/stderr

[Melvin Smith]

Dan, I am gonna turn off -debug in the interp test below, since the
test harness is picking up stderr as well as stdout and the test
below is failing. (-d causes Parrot to be talkative, no pun intended)

It just showed up when I fixed in interpreter local IO stuff (will commit 
later).

Can the test harness ignore stderr?

-Melvin


output_is(<<'CODE', <<'OUTPUT', "runinterp");
--newinterp P0, 1
++newinterp P0, 0
 print "calling\n"
 runinterp P0, foo
 print "ending\n"
 end
 print "bad things!\n"
foo:
 print "In 2\n"
 end
CODE
calling
In 2
ending
OUTPUT

[MAYBE PATCH] the 2 warnings in jit.c

[Nicholas Clark]

Appended patch gets rid of these two:

cc -pipe -Os  -Wall -Wstrict-prototypes -Wmissing-prototypes -Winline -Wshadow 
-Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Wconversion 
-Waggregate-return -Winline -W -Wsign-compare -Wno-unused-I./include  -DHAS_JIT 
-DI386 -o jit.o -c jit.c
jit.c: In function `build_asm':
jit.c:192: warning: cast discards qualifiers from pointer target type
jit.c:195: warning: cast discards qualifiers from pointer target type


However, I'm not really convinced that it's quite the right way to do it.
It more feels like a brute force splattering of "const" in a few places to
make gcc shut up, rather than anything that adds to the readability or
maintainability of the code. And not tested on alpha, because I don't have
one.

Nicholas Clark
-- 
ENOCHOCOLATE http://www.ccl4.org/~nick/CV.html

--- jit.c.orig  Sun Jan 20 22:57:30 2002
+++ jit.c   Sat Jan 26 21:36:32 2002
@@ -30,7 +30,8 @@
 build_asm(struct Parrot_Interp *interpreter,opcode_t *pc, opcode_t *code_start, 
opcode_t *code_end)
 {
 char *arena, *arena_start;
-INTVAL *address,ivalue,size,i,k;
+const INTVAL *address;
+INTVAL ivalue,size,i,k;
 INTVAL *op_address, prev_address, bytecode_position;
 #ifdef ALPHA
 char *interpreter_registers = ((char *)&interpreter->int_reg->registers[0]) + 
0x7fff;
@@ -189,10 +190,10 @@
 address = (INTVAL *)&s->strlen;
 break;
 case 6: 
-address = (INTVAL *)s->encoding;
+address = (const INTVAL *)s->encoding;
 break;
 case 7: 
-address = (INTVAL *)&s->type;
+address = (const INTVAL *)&s->type;
 break;
 case 8: 
 address = &s->language;
@@ -322,11 +323,12 @@
 ivalue = (INTVAL) (arena+v.info[i].position) + 4;
 
 if (address > (INTVAL *)ivalue) {
-address = (INTVAL *)((char *)address - (char *)ivalue);
+address = (const INTVAL *)((const char *)address
+   - (const char *)ivalue);
 } else if (address < (INTVAL *)ivalue) {
-address = (INTVAL *)
+address = (const INTVAL *)
   (-(arena - 
- (char *)address + 
+ (const char *)address + 
  op_assembly[*pc].size));
 } else {
 address = 0;
@@ -375,11 +377,12 @@
 ivalue = (INTVAL) (arena+v.info[i].position) + 4;
 
 if (address > (INTVAL *)arena) {
-address = (INTVAL *)((char *)address - (char *)ivalue);
+address = (const INTVAL *)((const char *)address
+   - (const char *)ivalue);
 } else {
-address = (INTVAL *)
+address = (const INTVAL *)
   (-(arena - 
- (char *)address + 
+ (const char *)address + 
  v.info[i].position + 4));
 }
 #ifdef ALPHA

Re: Parrot test harness and stdout/stderr

[Alex Gough]

On Sat, 26 Jan 2002, Melvin Smith wrote:

> Dan, I am gonna turn off -debug in the interp test below, since the
> test harness is picking up stderr as well as stdout and the test
> below is failing. (-d causes Parrot to be talkative, no pun intended)
>
> It just showed up when I fixed in interpreter local IO stuff (will commit
> later).
>
> Can the test harness ignore stderr?
>

No, as we'll soon *cough* have exceptions and language level warnings
which will want to talk to stderr, and which we will want to test for
correct operation.

We also currently test the output of internal (parrot level) fatal
errors and will want to continue to do so.  These should also not be
easily triggered from the language level, so must be exercised by
throwing appropriate bytecode at the interpreter.

Alex Gough
-- 
I keep thinking that people talk about the economy now just like
they'd have talked about appeasing gods, centuries ago.  "Pontifex
Greenspan lowered interest rates again today amid market fears that
the Oracle of Ba'al would demand more sacrifices of live children...".

sometimes you just can't win...

[Nicholas Clark]

cc -pipe -Os  -Wall -Wstrict-prototypes -Wmissing-prototypes -Winline -Wshadow 
-Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Wconversion 
-Waggregate-return -Winline -W -Wsign-compare -Wno-unused-I./include  -DHAS_JIT 
-DI386 -o encodings/utf8.o -c encodings/utf8.c
encodings/utf8.c: In function `utf8_skip_forward':
encodings/utf8.c:101: warning: cast discards qualifiers from pointer target type
encodings/utf8.c: In function `utf8_skip_backward':
encodings/utf8.c:112: warning: cast discards qualifiers from pointer target type

These warnings refer to the two (utf8_t*) in these:

static void *
utf8_skip_forward (const void *ptr, UINTVAL n) {
utf8_t *u8ptr = (utf8_t*)ptr;

while (n-- > 0) {
u8ptr += UTF8SKIP(u8ptr);
}

return u8ptr;
}

static void *
utf8_skip_backward (const void *ptr, UINTVAL n) {
utf8_t *u8ptr = (utf8_t*)ptr;

while (n-- > 0) {
u8ptr--;
while (UTF8_IS_CONTINUATION(*u8ptr)) u8ptr--;
}

return u8ptr;
}

I believe that we can't win on these two. Well, I can't see a way to.
I agree that the function prototype should be const, and the return value
non-const, just like char *strstr(const char *big, const char *little)

But I can't see a way to tell gcc that we want to do this and locally
no warnings 'cast-qual'; (if you see what I mean)
There don't seem to be pragmata to do this, and I can't spot an obvious
construction to launder away the const-ness.

Nicholas Clark
-- 
ENOJOB http://www.ccl4.org/~nick/CV.html

Re: sometimes you just can't win...

[Simon Cozens]

On Sat, Jan 26, 2002 at 10:17:12PM +, Nicholas Clark wrote:
> But I can't see a way to tell gcc that we want to do this and locally
> no warnings 'cast-qual'; (if you see what I mean)
> There don't seem to be pragmata to do this, and I can't spot an obvious
> construction to launder away the const-ness.

It's fine. Warnings are there to help us; we're not supposed to be a slave
to them.

-- 
You are in a maze of UUCP connections, all alike.

Re: Parrot test harness and stdout/stderr

[Melvin Smith]

At 10:10 PM 1/26/2002 +, Alex Gough wrote:
>On Sat, 26 Jan 2002, Melvin Smith wrote:
>
> > Dan, I am gonna turn off -debug in the interp test below, since the
> > test harness is picking up stderr as well as stdout and the test
> > below is failing. (-d causes Parrot to be talkative, no pun intended)
> >
> > It just showed up when I fixed in interpreter local IO stuff (will commit
> > later).
> >
> > Can the test harness ignore stderr?
> >
>
>No, as we'll soon *cough* have exceptions and language level warnings
>which will want to talk to stderr, and which we will want to test for
>correct operation.

I wasn't implying that we ignore stderr for all tests, but I thought it
might be useful for some.

Anyway, I can fix the test easily for this one just to shutup debug info
by removing the informative message...

-Melvin

Re: Parrot test harness and stdout/stderr

[Melvin Smith]

At 06:01 PM 1/26/2002 -0500, Melvin Smith wrote:
>At 10:10 PM 1/26/2002 +, Alex Gough wrote:
>>On Sat, 26 Jan 2002, Melvin Smith wrote:
>>
>> > Dan, I am gonna turn off -debug in the interp test below, since the
>> > test harness is picking up stderr as well as stdout and the test
>> > below is failing. (-d causes Parrot to be talkative, no pun intended)
>> >
>> > It just showed up when I fixed in interpreter local IO stuff (will commit
>> > later).
>> >
>> > Can the test harness ignore stderr?
>> >
>>
>>No, as we'll soon *cough* have exceptions and language level warnings
>>which will want to talk to stderr, and which we will want to test for
>>correct operation.
>
>I wasn't implying that we ignore stderr for all tests, but I thought it
>might be useful for some.

Never mind, I just realized how brain-dead my situtation is.

If I ask for -d (debug) then my test should expect it, so I don't know
why I am griping.. :)

-Melvin

Re: [MAYBE PATCH] the 2 warnings in jit.c

[Daniel Grunblatt]

It will add a warning per call to calculate_displacement in the alpha.

Daniel Grunblatt.


On Sat, 26 Jan 2002, Nicholas Clark wrote:

> Appended patch gets rid of these two:
>
> cc -pipe -Os  -Wall -Wstrict-prototypes -Wmissing-prototypes -Winline -Wshadow 
>-Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Wconversion 
>-Waggregate-return -Winline -W -Wsign-compare -Wno-unused-I./include  -DHAS_JIT 
>-DI386 -o jit.o -c jit.c
> jit.c: In function `build_asm':
> jit.c:192: warning: cast discards qualifiers from pointer target type
> jit.c:195: warning: cast discards qualifiers from pointer target type
>
>
> However, I'm not really convinced that it's quite the right way to do it.
> It more feels like a brute force splattering of "const" in a few places to
> make gcc shut up, rather than anything that adds to the readability or
> maintainability of the code. And not tested on alpha, because I don't have
> one.
>
> Nicholas Clark
> --
> ENOCHOCOLATE http://www.ccl4.org/~nick/CV.html

Re: What can be hyperoperated?

[Larry Wall]

Damian Conway writes:
: > Larry> @result = for @a; @b -> $a, $b { $a op $b }
: > 
: > Larry> (presuming we make C actually act like C).
: > 
: > Why not just make map do that?
: 
: The order of C's arguments is wrong. To make the -> extraction
: syntax work we need the data being iterated to be on the left and the
: processor block (actually a closure in Perl 6) to be on the right.

Well, that's not insurmountable, but it would require parens if we
stuck with the semicolon notation.  This would find an end of statement
too soon, after the @a:

 @result = map -> $a; $b { $a op $b } @a; @b;

so it'd probably have to be written as one of

 @result = map -> $a; $b { $a op $b }, (@a; @b);
 @result = map (-> $a; $b { $a op $b }, @a; @b);
 @result = (map -> $a; $b { $a op $b }, @a; @b);
 (@result = map -> $a; $b { $a op $b }, @a; @b);

That's starting to get up there on the grottiness meter.  Since semicolon
is probably just separating lists within lists, perhaps

 @result = map -> $a; $b { $a op $b }, [@a], [@b];

is a valid alternative.  But it's still not as comely as the C,
which never needs the parens, since it knows the {} is coming.

Perhaps we shouldn't be using ; for this.

Larry

Re: What can be hyperoperated?

[damian]

Larry pondered:

> Perhaps we shouldn't be using ; for this.

That has occurred to me on several occasions but, checking my pockets, I
find I'm fresh out of spare symbols to replace it with.

We could always use colon, of course ;-)

Damian

Re: "Non-yet-thrown exceptions must be a useful concept."

[Larry Wall]

Me writes:
: "Non-yet-thrown exceptions must be a useful concept."
: 
: This is a bullet point from a list in Apo4 introducing
: coverage of exception handling. Was Larry talking
: about an exception object that hasn't yet been thrown?
: Did he refer to this issue again anywhere else in the Apo?

Yep.  The current unthrown exception is put into $!, and that's the
exception that C defaults to throwing.

Larry

Re: What can be hyperoperated?

[Larry Wall]

[EMAIL PROTECTED] writes:
: Larry pondered:
: 
: > Perhaps we shouldn't be using ; for this.
: 
: That has occurred to me on several occasions but, checking my pockets, I
: find I'm fresh out of spare symbols to replace it with.
: 
: We could always use colon, of course ;-)

Well, more likely than that would be double colon.  It would stand out
better:

for @a :: @b :: @c -> $a :: $b :: $c { ... }

And it would probably not interfere much with the doubledoubledots
of the ??:: operator.  (Certainly less than the ; overloading.)

On the other hand, semicolon works out really nicely within brackets
for multidimensional slices, and the mathematicians like it.  And I
don't know how the :: would fit in with other adverbial generalities.

Larry

Re: What can be hyperoperated?

[Simon Cozens]

On Sat, Jan 26, 2002 at 04:52:53PM -0800, Larry Wall wrote:
>  @result = map -> $a; $b { $a op $b } @a; @b;

Something seems wrong with this, but I can't quite put my finger
on what it is. I think it's the -> directly after map - -> looks
too much like an operator. And even if you read "->" as the natural
"to", you get "map to $a and $b, perform $a op $b, for @a and @b"  
I'd be happier with

map @a; @b -> $a; $b { $a op $b }

("Map elements of @a and @b to $a and $b, and do '$a op $b'") but
the semicolons seem blecherous there. But this is starting to look
more like ML than Perl.

> That's starting to get up there on the grottiness meter.  Since semicolon
> is probably just separating lists within lists, perhaps
> 
>  @result = map -> $a; $b { $a op $b }, [@a], [@b];

But (@a; @b) *is* a list of two lists, so you'd want to keep that.

> is a valid alternative.  But it's still not as comely as the C,
> which never needs the parens, since it knows the {} is coming.
> 
> Perhaps we shouldn't be using ; for this.

Given hyperoperators, I wonder if we can actually drop map.

-- 
Calm down, it's *only* ones and zeroes.

Re: What can be hyperoperated?

[damian]

Simon wrote:

> Given hyperoperators, I wonder if we can actually drop map.

So:

@result = map { block } @data;

becomes:

@result = {block}^.(@data);

Hmmm.

Damian

Re: What can be hyperoperated?

[damian]

> On the other hand, semicolon works out really nicely within brackets
> for multidimensional slices, and the mathematicians like it.  And I
> don't know how the :: would fit in with other adverbial generalities.

Yes, I think semicolon is the correct solution.

We just have to explain that it's only allowed to be a "naked
singularity" within a C. Elsewhere it has to be decently shielded
by the "statement event horizon" of a pair of brackets.

;-)

Damian

PMCs leaking memory

[Boris Tschirschwitz]

Hi.

I am still writing on my complex number class.
When trying to add addition and subtraction methods, I came across the
following problem:

PMC functions writing results in a destination PMC like add(PMC *dest, PMC
*val) overwrite the destination PMC's vtable and cache with new values
without testing if it contains any old data that should be freed first.
(see for example perlstring.pmc).

Is this something I
1) shouldn't worry about, because the memory is cleaned--and I am just too
   stupid to see that
2) shouldn't worry about, because it will vanish with the addition of a GC
3) should find a soulution for, because it is a problem

Boris.

--
Boris Tschirschwitz
University of British Columbia
Mathematics Department
email: [EMAIL PROTECTED]

Re: PMCs leaking memory

[Dan Sugalski]

On Sat, 26 Jan 2002, Boris Tschirschwitz wrote:

> I am still writing on my complex number class.
> When trying to add addition and subtraction methods, I came across the
> following problem:
> 
> PMC functions writing results in a destination PMC like add(PMC *dest, PMC
> *val) overwrite the destination PMC's vtable and cache with new values
> without testing if it contains any old data that should be freed first.
> (see for example perlstring.pmc).
> 
> Is this something I
> 1) shouldn't worry about, because the memory is cleaned--and I am just too
>stupid to see that
> 2) shouldn't worry about, because it will vanish with the addition of a GC
> 3) should find a soulution for, because it is a problem

#2. The GC will take care of that. We can certainly work to generate less
garbage in the first place, but the GC will take care of the memory pools.

Dan