Some quick questions.

[Autrijus Tang]

Today I have finished implementing 90% of primitive operators; Pugs can
now evaluate most simple expressions, including junctive autothreading
and magical/infinite ranges. Their implementation are in:

http://wagner.elixus.org/~autrijus/darcs/pugs/Prim.hs

As such, there are some corner cases I couldn't find in the spec; please
correct me if my treatment is wrong:

* What is the value of a pair in numeric context? in string context?

Currently I'm taking the ".value" part as its value.

* What is the value of a reference in any of the scalar contexts?

Currently I'm blindly dereferencing it.

* How many bits are "+^" operating on?

Currently it is using a native Unsigned Int.

* Does "**" flatten recursively?

Currently it only flattens the first level of the list.

* Does "(3&0) and (4|0)" evaluate to "(3&0)" or "False"?

Currently it evaluates to "(3&0)".

Thanks,
/Autrijus/

[Autrijus Tang]

On Sat, Feb 05, 2005 at 04:44:41AM +0800, Autrijus Tang wrote:
> * What is the value of a reference in any of the scalar contexts?
>
> Currently I'm blindly dereferencing it.

It seems that I got four out of five correct; the "blind referencing"
has an important exception in the references are always (by default)
true.

Here's another quick question: In S03 zip() is used like this:

for zip(@names, @codes) -> $name, $zip { ... }

But in S04 it becomes:

for zip(@a;@b) -> $a, $b { ... }

Why semicolon? Is it a special form? Or am I missing something deeply
equivalent about semicolons and list separators?

Thanks,
/Autrijus/

[Autrijus Tang]

On Sat, Feb 05, 2005 at 02:08:32PM +0800, Autrijus Tang wrote:
> Here's another quick question: In S03 zip() is used like this:
>
> for zip(@names, @codes) -> $name, $zip { ... }
>
> But in S04 it becomes:
>
> for zip(@a;@b) -> $a, $b { ... }
>
> Why semicolon? Is it a special form? Or am I missing something deeply
> equivalent about semicolons and list separators?

So it turns out that A03 says that semicolons within "brackets" defaults
to a list-of-list builder. Curiously, it is missing from S03, and the
behaviour is not documented in detail.

Currently I assume the "brackets" above listish generators -- (), [], {}
-- but not blocks under list context. That is:

sub foo { 1 ; 2 ; 3 } # returns 3
sub bar { ( 1 ; 2 ; 3 ) } # returns ([1],[2],[3])

Is this the correct understanding? If so, S03 needs to be patched to
say that (and more).

Thanks,
/Autrijus/

[Larry Wall]

On Sat, Feb 05, 2005 at 04:30:58PM +0800, Autrijus Tang wrote:
: So it turns out that A03 says that semicolons within "brackets" defaults

: to a list-of-list builder. Curiously, it is missing from S03, and the
: behaviour is not documented in detail.

That's because it's still a bit hand-wavey.

: Currently I assume the "brackets" above listish generators -- (), [], {}

: -- but not blocks under list context. That is:
:
: sub foo { 1 ; 2 ; 3 } # returns 3
: sub bar { ( 1 ; 2 ; 3 ) } # returns ([1],[2],[3])
:
: Is this the correct understanding?

Yes, unless it returns [[1],[2],[3]] instead. (What you have written is
context dependent.)

: If so, S03 needs to be patched to say that (and more).

S09 talks about it some. Basically semicolon is useful where you want
to talk about a list of lists, such as in a multidimensional slice.

Larry

[Larry Wall]

On Sat, Feb 05, 2005 at 02:08:32PM +0800, Autrijus Tang wrote:

: On Sat, Feb 05, 2005 at 04:44:41AM +0800, Autrijus Tang wrote:
: > * What is the value of a reference in any of the scalar contexts?
: >
: > Currently I'm blindly dereferencing it.
:
: It seems that I got four out of five correct; the "blind referencing"
: has an important exception in the references are always (by default)
: true.

Hmm, I believe I said somewhere that references are no longer always true
in Perl 6. So perhaps it's not an exception after all. We're trying
to get rid of as many useless exceptions as possible in Perl 6, after all.

Larry

[Autrijus Tang]

On Sat, Feb 05, 2005 at 06:52:49AM -0800, Larry Wall wrote:
> Hmm, I believe I said somewhere that references are no longer always true
> in Perl 6. So perhaps it's not an exception after all. We're trying
> to get rid of as many useless exceptions as possible in Perl 6, after all.

Yes, the relevant place in S02 is:

* Unlike in Perl 5, references are no longer always considered true. It
depends on the state of their .bit property. Classes get to decide which of
their values are true and which are false.

So, should I make the default implementation of Scalar Refs to return the .bit
value of the referent?

Thanks,
/Autrijus/

[Autrijus Tang]

On Sat, Feb 05, 2005 at 06:56:00AM -0800, Larry Wall wrote:
> Yes, unless it returns [[1],[2],[3]] instead. (What you have written is
> context dependent.)

Yup. Thanks!

Oh, by the way, may I use the infix:<!> operator for creating none()
junctions? I was writing pretty-printing code for junction .values,
and it followed quite naturally.

Cheers,
/Autrijus/

...Hmm. I was going to ask something about infix:<?> and function
composition, but that seems to be a really bad idea, so never mind that. :)