Re: Demagicalizing pairs

[Damian Conway]

Larry wrote:


Plus I still think it's a really bad idea to allow intermixing of
positionals and named.  We could allow named at the beginning or end
but still keep a constraint that all positionals must occur together
in one zone.


If losing the magic from =>'d pairs isn't buying us named args wherever we 
like, why are we contemplating it?




I suspect a lot of people would still prefer to write named args with =>,


I'd say so.



so we should put some thought into making it syntactically trivial, if
not automatic like it is now.   Even making named() a listop would help.


I'd say that's the best alternative. I'd certainly prefer that to repurposing 
:(...)




I hate to say it, but the named args should probably be marked
with : instead of + in the signature.

One other idle thought is that, if we don't mind blowing a different
kind of consistency, and if we s/+/:/ in sigs, a sig containing
:$foo could instead be written $:foo (presuming we take : away from
privates as we've postulated),


Yes please. Underscore is much better in that role.

Damian

Re: ~ and + vs. generic eq

[Larry Wall]

On Wed, Aug 24, 2005 at 12:43:46AM +0300, Yuval Kogman wrote:
: On Tue, Aug 23, 2005 at 10:28:01 -0700, Larry Wall wrote:
: > On Tue, Aug 23, 2005 at 06:19:33PM +0300, Yuval Kogman wrote:
: > :   "10" == "10"; # dispatches to Str, due to better match
: > 
: > Nope, that will continue to coerce to numeric comparison.  The design
: > team did in fact consider pure "equivalence" MMD dispatch of == in
: > the last meeting, but rejected it in favor of "eqv"
: 
: BTW, regardless of whether it's called 'eqv' or '==', the semantics
: shared between the MMD variants of ~~ and eqv as proposed in the
: bottom of the message are not utter crap, right?

Hmm, well, I don't think >>&op<< is valid syntax, but you did say
"semantics", so I can't criticize that part.  :-)

Not that the rest of what I say amounts to criticism.  More just thinking
in your general direction.

I don't know how close ~~ and eqv will end up.  There are some
differences in emphasis, and when two operators get too much like each
other, I tend to add more differences to make them inhabit different
parts of the solution space.  One current difference is that, despite
the symmetry of ~~, it's not actually a symmetrical operator much of
the time, such as when matching values to rules.  ~~ is intended to
be heavily dwimmical, so it's allowed to do various kinds of abstract
coercions to figure out some mystical "good enough" quotient.  But eqv
on the other hand should probably be false in asymmetrical situations.
The implementation of ~~ may delegate to eqv in certain symmetrical
situations, of course.

Another difference in emphasis is that eqv is intended to equate values
(one of the reasons for the 'v') that would be treated as equal when used
as keys of an object hash.  Now the funny thing about an object hash is
that you don't ever want to hash based on a mutable value.  Ordinary
value types are immutable, so this 42 is the same as that 42 over there.
So we have

$a = 42;
$b = 42;
$a eqv $b   # always true
$a =:= $b   # might be true

The =:= operator always compares object identities, even if the
objects want to pretend to be values.  So eqv lets them pretend,
while =:= doesn't.  But for objects that don't want to pretend to be
values, eqv can delegate to =:=.

On the other hand, it's not clear whether eqv (and by extension hashes)
should take "snapshots" of mutable values.  That is, it's not clear
whether this should say "true true" or "false false":

my %hash is shape(Object);

%hash{ [1,2,3] } = 1;
if exists %hash{ [1,2,3] } { say "true" } else { say "false" }
if [1,2,3] eqv [1,2,3] { say "true" } else { say "false" }

But whatever it says, I think it should say the same thing both times.
Certainly if we had Pythonic immutable tuples

if (1,2,3) eqv (1,2,3) { say "true" } else { say "false" }

should say "true", since those are the same values, and they can't
change.  However, in Perl-5-Think, [1,2,3] produces mutable arrays,
so unless we come up with some kind of fancy COW for [1,2,3] to be
considered immutable until someone, er, mutes it, I think eqv would
have to return false, and consider two such objects to be different
values (potentially different if not actually different).

It would be possible to declare %hash some way that forces a "snapshot"
via some kind of serialization or other, but then it gets hard to keep
the identity around.  Then the question arises how we doctor

if [1,2,3] eqv [1,2,3] { say "true" } else { say "false" }

to do the same snapshot comparison.  Arguably ~~ could do it, since it's
explicitly *not* about identity.

if [1,2,3] ~~ [1,2,3] { say "true" } else { say "false" }

Or we could have a more explicit way of doing whatever it is that the
snapshot hash does to each argument.

if [1,2,3].snap eqv [1,2,3].snap { say "true" } else { say "false" }

Or we could have a different operator that coerces like == and eq, only
via .snap:

if [1,2,3] equals [1,2,3] { say "true" } else { say "false" }

(Actual name negotiable, of course).  The advantage of the latter approach
is that you can say

@foo >>equals<< @bar

and the .snaps are automatically distributed.  Otherwise you'd have to say

@foo<<.snap >>eqv<< @bar<<.snap

which is a pain.  On top of which, equals doesn't actually have to
implemented in terms of .snap--it could just compare the current
values of the mutable objects directly.  (Just as =:= doesn't have
to be implemented in terms of .id.)

Larry

Re: ~ and + vs. generic eq

[Yuval Kogman]

On Tue, Aug 23, 2005 at 10:28:01 -0700, Larry Wall wrote:
> On Tue, Aug 23, 2005 at 06:19:33PM +0300, Yuval Kogman wrote:
> : "10" == "10"; # dispatches to Str, due to better match
> 
> Nope, that will continue to coerce to numeric comparison.  The design
> team did in fact consider pure "equivalence" MMD dispatch of == in
> the last meeting, but rejected it in favor of "eqv"

BTW, regardless of whether it's called 'eqv' or '==', the semantics
shared between the MMD variants of ~~ and eqv as proposed in the
bottom of the message are not utter crap, right?

-- 
 ()  Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418  perl hacker &
 /\  kung foo master: /me does a karate-chop-flip: neeyah!!



pgpXv1WO6rB8S.pgp
Description: PGP signature

Re: Can a scalar be "lazy" ?

[Yuval Kogman]

On Tue, Aug 23, 2005 at 10:56:08 -0700, Larry Wall wrote:

> We could probably extend "is cached" to attributes (and their implied
> accessors) if lazy blocks aren't sufficient.

Hmm... With the whole distinction of &foo as a value and &foo() as a
application of the value, maybe we can sometimes assign a sub as an
rvalue by making a "weak" call.

sub lazy (Code &f) {
return &f.weak_call;
}

I like the relation to is cached, but I think it might be incorrect,
if the lazy block is reused.

BTW, I'm the "nothingmuch" who initially lobbied for lazy { }... =)

> : sub &infix:<||> ($left, $right is delayed) {
> : $left ?? $left :: ** $right; # can you steamroll a scalar?
> : }
> 
> I'd really like to discourage people from writing thunks without curlies.

Then how do we define &infix:<||>'s prototype?

> I don't think steamrollering a scalar works--it would just take it
> as an operation on a list rather than on the elements of the list.
> You can't really delazify until you know what kind of a scalar you
> want, I suspect, because the lazy closure itself might need to know
> in what context to run.  Otherwise you just have to return a proxy
> object that might turn into a string or number or int or whatever
> value is eventually wanted.  Of course, presumably infix:<||> has
> that context already, so maybe we're looking for something like
> 
> $right.want

This makes sense, but shuts off the 'want' behavior.

I think we should have an implicit $?CONTEXT object in each sub, and
then you can say to it

$?CONTEXT.unwrap($right);

or something along that metaphor.

This is also nice for things like

method moose (...) {
my Container $x = $?CONTEXT.eval( $?SELF.SUPER::moose ); # 
maybe even a bit like Sub::Uplevel
...
# you can look inside $x now, but you can't "damage" it
# anymore
...
$x.unwrap; # this serves as context passthrough
}

> to force value-finding behavior iff it's called for.  After all, you
> probably want it to stay lazy if you call it in undifferentiated scalar
> context:
> 
> $x = $y || lazy { z() }

Yes, I didn't think about that... This is lazyness stacking though,
I think.

-- 
 ()  Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418  perl hacker &
 /\  kung foo master: /methinks long and hard, and runs away: neeyah!!!



pgpxtNeHzOOee.pgp
Description: PGP signature

Re: Can a scalar be "lazy" ?

[Larry Wall]

On Tue, Aug 23, 2005 at 11:03:52AM +0300, Yuval Kogman wrote:
: On Mon, Aug 22, 2005 at 13:25:57 -0700, Larry Wall wrote:
: > On Tue, Aug 23, 2005 at 04:09:29AM +0800, Yiyi Hu wrote:
: > : my( $s, $t ); $s = "value t is $t"; $t = "xyz"; print $s;
: > : in perl 5, it will give a warning, and won't do "right" thing.
: > : we have to use other way or eval '$s' before print to get a "correct" 
answer.
: > : 
: > : So I wonder, If we can make $scalar lazy also. As array now is lazy by 
default.
: > : 
: > : Even if making scalar lazy might cause problem sometimes, Is it
: > : possible to add a property which is like
: > : my $var is lazy; to handle these situation?
: > 
: > In Perl 6 you make lazy scalars by putting curlies around them:
: > 
: > my( $s, $t ); $s = { "value t is $t" }; $t = "xyz"; print $s();
: > 
: > Currently we also require the de-lazifying context to supply a
: > postfix .() marker, but possibly that could be assumed in a string
: > or numeric context.
: > 
: > I really don't see much benefit in making it easier than that.
: 
: I see one:
: 
:   class Object {
:   has $.expensive_to_compute_but_cachable = delay {
:   ...
:   };
:   }

Which already seems to be there with

lazy {...}

which is, I presume, mostly syntactic sugar for something like:

sub is cached {...}

along with the notion of implicit .() on "value" use, as I already
conceded above.  Plus we can assume "is cached" on any function
that can be proven "pure".  So I think maybe you're responding to a
different position than the one I'm actually taking.

: OR
: 
:   class Object {
:   has $.expensive_to_compute_but_cachable is delayed = 
...;
:   }
: 
: And no one has to know that it's lazy.
: 
: With explicit code refs, you need to make an accessor:
: 
:   class Object {
:   has $.expensive_to_compute_but_cachable;
: 
:   method expensive_to_compute_but_cachable (
:   $.expensive_to_compute_but_cachable # i forget 
how
:   # autrijus's "returned" attr on params works
:   ) {
:   $.expensive_to_compute_but_cachable //= ...;
:   }
:   }
: 
: Which is just as much headache that we had to do in perl 5.

We could probably extend "is cached" to attributes (and their implied
accessors) if lazy blocks aren't sufficient.

: Also, lazifying semantics are consistent with
: 
:   sub &infix:<||> ($left, $right is delayed) {
:   $left ?? $left :: ** $right; # can you steamroll a scalar?
:   }

I'd really like to discourage people from writing thunks without curlies.

I don't think steamrollering a scalar works--it would just take it
as an operation on a list rather than on the elements of the list.
You can't really delazify until you know what kind of a scalar you
want, I suspect, because the lazy closure itself might need to know
in what context to run.  Otherwise you just have to return a proxy
object that might turn into a string or number or int or whatever
value is eventually wanted.  Of course, presumably infix:<||> has
that context already, so maybe we're looking for something like

$right.want

to force value-finding behavior iff it's called for.  After all, you
probably want it to stay lazy if you call it in undifferentiated scalar
context:

$x = $y || lazy { z() }

But maybe I'm confusing levels there.  Wouldn't be the first time...

Larry

Re: ~ and + vs. generic eq

[Larry Wall]

On Tue, Aug 23, 2005 at 06:19:33PM +0300, Yuval Kogman wrote:
:   "10" == "10"; # dispatches to Str, due to better match

Nope, that will continue to coerce to numeric comparison.  The design
team did in fact consider pure "equivalence" MMD dispatch of == in
the last meeting, but rejected it in favor of "eqv", which has the
benefit of looking more Huffmanly abstract to Perl 5 and C programmers.
Otherwise we lose the main point of being an operator-rich language,
which is to use the operators to drive coercion in the common cases
instead continually casting between strings and numbers.

Larry

Re: Calling positionals by name in presence of a slurpy hash

[Larry Wall]

On Tue, Aug 23, 2005 at 09:11:15AM -0600, Luke Palmer wrote:
: On 8/23/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
: > Hi,
: > 
: > (asking because a test testing for the converse was just checked in to
: > the Pugs repository [1])
: > 
: > sub foo ($n, *%rest) {...}
: > 
: > foo 13;
: > # $n receives 13, of course, %rest is ()
: > 
: > foo 13, foo => "bar";
: > # $n receives 13 again, %rest is (foo => "bar")
: > 
: > foo n => 13;
: > # $n receives 13, %rest is (), right?
: > 
: > foo n => 13, foo => "bar";
: > # $n receives 13, %rest is (foo => "bar"), right?
: 
: Yep, that's all correct.  Matter of fact, what %rest actually gets has
: not been defined. "Maybe %rest mirrors all the named arguments, maybe
: it doesn't".  I can see a very small utility if it does, but it seems
: like it would be faster[1] if it didn't.  I think it's fair to say no
: here.
: 
: [1] Yeah, yeah, premature optimization and whatnot.  You always have
: the sig (*%hash) if you really want to.

The Apocalypse explicitly left the question open because of the
performance issue, since we might be forced into copying all the
entries of a potentially huge hash just to weed out a few entries.
(Think environment variables.)

You can't just mark certain entries as unavailable since it's probably
a reference to someone else's hash.  You could set up a proxying
filter hash that makes some of the keys vanish, but then you're at
the mercy of the owner of the real hash not to change the proxied
hash while your function is executing, and there's some overhead in
setting up the proxy hash.  It's possible that COW hashes can be made
to work efficiently.  We'll need to copy hashes if we want to modify
them to pass to subfunctions, just as when you change your environment
it doesn't affect your parent process's environment variables.

Actually, I envision the named arguments coming in as a separate list
of pairs and hash refs, so we could just say that all readonly access
to the slurpy hash actually scans that argument list.  That assumes
that we don't care that much about the efficiency of "environmental"
lookups, but I think it might optimize for the common case of argument
binding if we process positionals in order and do scanning lookups in
the named list for missing positionals.  Doing your primary scan on
the named list to look for things that might or might not be wanted
in the positional list is going to be really slow in cases where a
lot of "environment" is passed around.

Anyway, what I'm saying is that, assuming we bind the slurpy hash
interface to the list implementation, we could just put "nulling"
entries on the front of that list as we use up keys.  So maybe that's
a way to remove keys that's not too much overhead.  I suppose we could
even suppress that if there was a pragma allowing dups.  So there's
something to be said for the cleaner semantics.

On the other hand, maybe those semantics are not actually cleaner.
If we take environment variables as our model, we *don't* remove
them from the environment when we "use" them, since child processes
may want the same value.  If we weed out values from the slurpy
hash, we force environmental hashes to be passed some other way.
Whether that's a feature or not depends on whether you view such an
"environment" as default values for named parameter bindings.

Larry

Re: ~ and + vs. generic eq

[Yuval Kogman]

On Tue, Aug 23, 2005 at 18:15:07 +0200, Ingo Blechschmidt wrote:
> sorry, I've some problems with this proposal:
> 
> == has always meant numeric equality in Perl and I'd like it to stay
> that way.

For "simple" values like numbers and strings == is numberic, because
it's affinity to it.


> > "10" == 10; # dispatched to Num, by means of coercion (== has some
> > affinity to it for backwards compatibility)


I guess the difference is that this will fallback to dispatching to
strings if "10" can't be numified.

I think what sets perl 6 apart from perl 5 is that it's 95% as
optimized for "simple" values as perl 5 was, but a magnitude times
better for complex types (first class functions, better objects),
and in this sense generic equality is a place I find the current
spec lacking.

> More importantly, the distinction between +== and ~== is far too subtle,
> I think -- the two long =s kind of hide the +~?. You have to look more
> carefully to see the distinction between +== and ~==; == vs. eq is much
> more apparent, IMHO.

Arguably it should only matter when it's explicitly stated, so in
this case I think your argument is very strong. The only difference
is that I don't feel that ~== and +== are very close to == visually,
and although they are hard to distinguish, they do stand apart from
just bare ==.

> 
> Oh and +== isn't as good huffmanized as == is.

99% of the time you should use == for numbers anyway... It's
unambiguous.

> > The "matchic MMD generator" in the prelude, that makes the complex
> > set of rules found in s04 should simply apply to any infix operator
> > (and should be applied in the prelude to ~~, as well as ==), so that
> > ~~ and == on collections are defined with the same aggregate
> > semantics, but MMD ~~ or == applies to the nested elements in the
> > same "shape":
> > 
> > sub extend_comparators (&op) {
> [...]
> 
> I think I like that idea, although I have to admit that I might have not
> understood it fully.
> 
> I wonder whether it's possible to use an adverbial modifier to specify
> the comparator:
> 
> say @foo ~~ @bar;  # is really
> say @foo ~~ @bar :comparator{ $^a ~~ $^b };
> 
> say @foo ~~ @bar :comparator{ $^a eq $^b };
> say @foo ~~ @bar :comparator{ $^a == $^b };

In this example I would say

my sub comparator ($a, $b) { .. your comparison here };
Prelude::extend_comparators(&comparator);

say comparator(@foo @bar);

and the name "comparator" could be a lexically scoped &infix:<~~> just the
same.

It's not as short, but I'm sure an evil macro could be cooked up if
it recurrs.

We can even specify

multi &infix:<~~> (Any $a, Any $b, :&comparator) { # what is the
# syntax for mandatory positionals nowadays?
my &augmented = &comparator; # a copy
Prelude::extend_comparators(&augmented);
&augmented($a, $b);
}

And have your interface wrap around this behavior.

-- 
 ()  Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418  perl hacker &
 /\  kung foo master: /me beats up some cheese: neeyah!



pgp9aYZ5J4EQD.pgp
Description: PGP signature

Re: ~ and + vs. generic eq

[Ingo Blechschmidt]

Hi,

Yuval Kogman wrote:
> I think this is more consistent, and just as useful:
> 
> 10 == 10; # dispatches to num
> "10" == 10; # dispatched to Num, by means of coercion (== has some
> affinity to it for backwards compatibility) "10" == "10"; # dispatches
> to Str, due to better match "10.0" == "10"; # unlike perl 5 this is
> false "10.0" +== "10"; # but this is true
> 10 ~== 10; # like eq

sorry, I've some problems with this proposal:

== has always meant numeric equality in Perl and I'd like it to stay
that way.

More importantly, the distinction between +== and ~== is far too subtle,
I think -- the two long =s kind of hide the +~?. You have to look more
carefully to see the distinction between +== and ~==; == vs. eq is much
more apparent, IMHO.

Oh and +== isn't as good huffmanized as == is.

> The "matchic MMD generator" in the prelude, that makes the complex
> set of rules found in s04 should simply apply to any infix operator
> (and should be applied in the prelude to ~~, as well as ==), so that
> ~~ and == on collections are defined with the same aggregate
> semantics, but MMD ~~ or == applies to the nested elements in the
> same "shape":
> 
> sub extend_comparators (&op) {
[...]

I think I like that idea, although I have to admit that I might have not
understood it fully.

I wonder whether it's possible to use an adverbial modifier to specify
the comparator:

say @foo ~~ @bar;  # is really
say @foo ~~ @bar :comparator{ $^a ~~ $^b };

say @foo ~~ @bar :comparator{ $^a eq $^b };
say @foo ~~ @bar :comparator{ $^a == $^b };


--Ingo

-- 
Linux, the choice of a GNU | "The future is here. It's just not widely
generation on a dual AMD   | distributed yet."  -- William Gibson  
Athlon!|

~ and + vs. generic eq

[Yuval Kogman]

I don't like eqv, because it's ugly, inconsistent with anything else
in Perl 6, especially &&, ||, and ^^. It might be forced to fit into
the and, or, and xor family, but you'd expect to find 'eq' there,
and that's not what it means.

IMHO == is as "generic" as && and ||, and is even more like ^^ since
it also returns a boolean.

the v in eqv is not much of a mnemonic, and overall looks like a
typo more than a meaningful distinction.

Furthermore, people culturally lean towards '==' for generic
equality, and that's what 99% of 'use overload' uses choose on the
CPAN.

Moreover, after a while of programming only "real" apps, that is,
few throw-away scripts (i think it was a period of 2-3 months) I
suddenly found myself comparing strings with == in such scripts.

I think this is more consistent, and just as useful:

10 == 10; # dispatches to num
"10" == 10; # dispatched to Num, by means of coercion (== has some 
affinity to it for backwards compatibility)
"10" == "10"; # dispatches to Str, due to better match
"10.0" == "10"; # unlike perl 5 this is false
"10.0" +== "10"; # but this is true
10 ~== 10; # like eq

$obj == $obj; # if $obj.ref implements ==, then goody, if not, i guess 
it numifies, or falls back to =:= or whatever identity equality is this week

$obj eq $obj; # just a wrapper for == that is parsed with lower 
precedence

$obj +== $obj; # numifies
$obj ~== $obj; # stringifies

@array +== @array; # length
@array == @array; # nested

Here are some reference implementations:

sub &infix:<+==> (Any $l, Any $r --> Bool) { +$l == +$r }
sub &infix:<~==> (Any $l, Any $r --> Bool) { ~$l == ~$r }
sub &infix: (Any $l, Any $r --> Bool) { ?$l == ?$r } # useless?

multi sub &infix:<==> (Num $l, Num $r --> Bool) { ... }
multi sub &infix:<==> (Str $l, Str $r --> Bool) { ... }

multi sub &infix:<==> (@l, @r --> Bool) { @l.elems +== @r.elems and @l 
>>==<< @r }

sub &infix: (Any $l, Any $r) is tighter(&infix:) { $l == $r }

The behavior of == is akin to ~~, for example regarding:

Array   Array arrays are identical match if $_ >>=<< @x

extracted from S04.

The "matchic MMD generator" in the prelude, that makes the complex
set of rules found in s04 should simply apply to any infix operator
(and should be applied in the prelude to ~~, as well as ==), so that
~~ and == on collections are defined with the same aggregate
semantics, but MMD ~~ or == applies to the nested elements in the
same "shape":

sub extend_comparators (&op) {
...

my sub apply_to_arrays (Code &op, Array @l, Array @r) {
@l >>&op<< @r
}

&op.add_mmd_variant(&apply_to_arrays.assuming(&op);
}

for (&infix:<~~> &infix:<==>) &extend_comparators;

-- 
 ()  Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418  perl hacker &
 /\  kung foo master: /me whallops greyface with a fnord: neeyah!!!



pgp68o8sMhxKr.pgp
Description: PGP signature

Re: Calling positionals by name in presence of a slurpy hash

[Luke Palmer]

On 8/23/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> (asking because a test testing for the converse was just checked in to
> the Pugs repository [1])
> 
> sub foo ($n, *%rest) {...}
> 
> foo 13;
> # $n receives 13, of course, %rest is ()
> 
> foo 13, foo => "bar";
> # $n receives 13 again, %rest is (foo => "bar")
> 
> foo n => 13;
> # $n receives 13, %rest is (), right?
> 
> foo n => 13, foo => "bar";
> # $n receives 13, %rest is (foo => "bar"), right?

Yep, that's all correct.  Matter of fact, what %rest actually gets has
not been defined. "Maybe %rest mirrors all the named arguments, maybe
it doesn't".  I can see a very small utility if it does, but it seems
like it would be faster[1] if it didn't.  I think it's fair to say no
here.

[1] Yeah, yeah, premature optimization and whatnot.  You always have
the sig (*%hash) if you really want to.

Luke

Calling positionals by name in presence of a slurpy hash

[Ingo Blechschmidt]

Hi,

(asking because a test testing for the converse was just checked in to
the Pugs repository [1])

sub foo ($n, *%rest) {...}

foo 13;
# $n receives 13, of course, %rest is ()

foo 13, foo => "bar";
# $n receives 13 again, %rest is (foo => "bar")

foo n => 13;
# $n receives 13, %rest is (), right?

foo n => 13, foo => "bar";
# $n receives 13, %rest is (foo => "bar"), right?


--Ingo

[1] http://svn.openfoundry.org/pugs/t/subroutines/slurpy_param.t 

-- 
Linux, the choice of a GNU | Row, row, row your bits, gently down the
generation on a dual AMD   | stream...  
Athlon!| 

Re: Perl 6 Summary for 2005-08-15 through 2005-08-22

[Tim Bunce]

On Mon, Aug 22, 2005 at 09:43:41PM -0400, Matt Fowles wrote:
> 
>Java on Parrot
> Tim Bunce asked some preliminary questions about Java on Parrot. I
> provide preliminary answers, and Nattfodd and Autrijus posted links to
> related work. The important question of what it should be called
> remained unraised. I vote for "Jot".
> 

For the record, my interest isn't so much "Java ON Parrot" as "Java WITH 
Parrot".
Bidirectional interface between the Parrot VM and a linked-in Java VM.

Tim.

Re: Perl 6 Summary for 2005-08-15 through 2005-08-22

[Leopold Toetsch]

On Aug 23, 2005, at 3:43, Matt Fowles wrote:



Perl 6 Summary for 2005-08-15 through 2005-08-22



   Java on Parrot



I vote for "Jot".


That's already occupied by another language  
http://en.wikipedia.org/wiki/Iota_and_Jot.



  Perl 6 Language
   Type Inferencing in Perl 5
Autrijus (while discussing type inference in Perl 6) recalled that  
there
was a google summer of code project on Type Inferencing in Perl 5.  
Gary
Jackson, the summer coder, provide a more detailed description of  
his

work.


http://search.cpan.org/~bargle/Devel-TypeCheck-0.01/lib/Devel/ 
TypeCheck.pm


Thanks for the summary,
leo

Re: Can a scalar be "lazy" ?

[Yuval Kogman]

On Mon, Aug 22, 2005 at 13:25:57 -0700, Larry Wall wrote:
> On Tue, Aug 23, 2005 at 04:09:29AM +0800, Yiyi Hu wrote:
> : my( $s, $t ); $s = "value t is $t"; $t = "xyz"; print $s;
> : in perl 5, it will give a warning, and won't do "right" thing.
> : we have to use other way or eval '$s' before print to get a "correct" 
> answer.
> : 
> : So I wonder, If we can make $scalar lazy also. As array now is lazy by 
> default.
> : 
> : Even if making scalar lazy might cause problem sometimes, Is it
> : possible to add a property which is like
> : my $var is lazy; to handle these situation?
> 
> In Perl 6 you make lazy scalars by putting curlies around them:
> 
> my( $s, $t ); $s = { "value t is $t" }; $t = "xyz"; print $s();
> 
> Currently we also require the de-lazifying context to supply a
> postfix .() marker, but possibly that could be assumed in a string
> or numeric context.
> 
> I really don't see much benefit in making it easier than that.

I see one:

class Object {
has $.expensive_to_compute_but_cachable = delay {
...
};
}

OR

class Object {
has $.expensive_to_compute_but_cachable is delayed = 
...;
}

And no one has to know that it's lazy.

With explicit code refs, you need to make an accessor:

class Object {
has $.expensive_to_compute_but_cachable;

method expensive_to_compute_but_cachable (
$.expensive_to_compute_but_cachable # i forget 
how
# autrijus's "returned" attr on params works
) {
$.expensive_to_compute_but_cachable //= ...;
}
}

Which is just as much headache that we had to do in perl 5.

Also, lazifying semantics are consistent with

sub &infix:<||> ($left, $right is delayed) {
$left ?? $left :: ** $right; # can you steamroll a scalar?
}

-- 
 ()  Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418  perl hacker &
 /\  kung foo master: /me spreads pj3Ar using 0wnage: neeyah!!!



pgpqbfguyPqSX.pgp
Description: PGP signature