Re: .method == $self.method or $_.method?

2005-04-04 Thread Thomas Sandlaß
HaloO,
I'll just use what Paul Seamons wrote:
Consider:
method foo {
 .do_one_thing
 .and_another_thing
 map { $_.do_something_with( .bar ) } .items;
 # .bar worked on the invocant - not the items
 .and_the_last_thing
}
because I don't have to invent examples on my own---thanks Paul!
My idea is to steal the postfix : from labels and use a keyword there.
I propose 'land', which nicely fits 'goto hell' with 'land hell'.
But linguistics is Larry's department. Actually these might be just
be yet another control flow pair.
Then the above example could become:
BTW: don't the statements need termination/separation with semicolon?
method foo
{
 .do_one_thing;
 .and_another_thing;
 map { do_something_with: .bar } .items;
 # .bar worked on the invocant - not the items
 #  map { do_something_with $_: $invocant.bar } .items
 .and_the_last_thing  # here semicolon is optional
}
the absence of . in front of do_something_with is easily spotted by an
eye trained to Perl6 method code while the same applies to the : which
indicates an indirect object and thus syntactically linked to the dynamic
dispatcher.

It seems that the oc behavior and the .method acts on $_ are huffmanized 
the wrong direction.
Hmm, outside of methods .method is just an operator that can be parsed
generically---without declaration that is. So dot to me is the method
sigil:
methodmeans closure variable
$methodmeans variable
.methodmeans postfix operator (needs explicit lhs)
.$method   means operator ref (e.g. $method = postfix:++)
method:means method call with $_ passed in as invocant
$method:   same via method ref
method means predeclared sub/multi call (or generic listop?)
method()   same
method $x: indirect object syntax meaning $x.method
In method scope no invocant is needed as lhs because it is the invocant:
$.method   means public instance variable (from lexical class environment)
.methodmeans public method on invocant
.$method   means public method ref on invocant
$:method   means private instance variable
:methodmeans private method on invocant
:$method   means private method ref on invocant

The more I think about it the more I think the current behavior of .method on 
$_ is wrong.  I don't think you should be able to dynamically set the 
invocant.  Consider the danger of:

method foo {
  some_sub_bar();
  .do_something();
I agree. If the programmer of the method wants to dispatch do_something
as usual she could leave out the dot. But whatever happens in there it
should not be able to modify the method's invocant.
BTW, is there a $?SELF for methods and @?SELF for multi methods?
And are the following multi calls:
($x, $y, $z).multimethod;
@array.multimethod;  # might interfere with container methods
or is that syntax too weird?

  # this now does get_some_other_object.do_something()
}
Of course do_something() could change $_ but that is no surprise.
The invocant variable is off-limits. In an abstract sense a method
is not mutating it's self but rebinds the value that $?SELF is
referring to.
As a side effect of not binding $_ to the invocant, the method
can easily check if it was invoked on the topic with $_ =:= $?SELF
--- Wait a moment, are you talking about me?.
Regards,
--
TSa (Thomas Sandlaß)



Re: identity tests and comparing two references

2005-04-04 Thread Thomas Sandlaß
Juerd wrote:
my $four := three;
Assuming you meant $three instead of three.
Indeed. Sorry.

my $five = 5;
$four = 4; # $one == 4 now?
No, $four (and thus $three, which it is bound to) is now 4. $three is a
reference, which is a value, which is now *replaced* with the new value.
OK. Then you need to define the behaviour of referential values.
In particular what does infix=Scalar of Ref of Ref of Int,Int do?
I get from your remarks that you intend to treat it exactly like
'Scalar of Ref of Any' without dispatching to 'Ref of Int'. That means
creating a new value 'Ref of Int' from the rhs, binding the Scalar and the
Ref to it or some such.

Is that so? Are we going to walk the path of inefficiency where $foo++
is really actually literally just $foo = $foo + 1, throwing away the old
variable, assigning a new one?
Heck, no! The $foo++ means postfix:++( $foo ) the second is
infix:=Any( infix:+Any,Int( $foo, 1 ) ) either dispatched
at runtime or optimized at compile if possible. How efficient that
is compared to each other I don't know.

And will Perl 6 reference values rather than their containers, that is:
will \$foo differ when $foo gets a new value, just as in Python id(foo)
changes after foo += 1?
Depends on the definition of the semantics of 'Ref of Scalar of Any'
versus 'Scalar of Any' versus 'Ref of Any' versus 'Scalar of Ref of Any'.
My question was actually about the language level definition of *chains
of references*!
1) Is the referene creation done with \, := and implicit in scalar context?
   Or do \ and := differ? And what's different with ::=?
2) Is derefencing still done with $ chains where you have to know how far
   to go? Is $$$foo still valid Perl 6 syntax?
3) How are Refs dispatched in comparison to Scalars, Arrays and Hashes?
Here is another attempt to pose my question with - depicting an indirection.
After the declarations with my we have two chains:
$four - $three - $two - $one - 1
$five - 5
Now what does $four = 4 mean? Dump the chain from $three downwards
and end up with
$four - 4
$five - 5
or go all the way down and just rebind $one and dumping the value 1
$four - $three - $two - $one - 4
$five - 5
The next question was about how far down $$four goes and how rebinding
at that level works. If it goes one down and rebinds there we get:
$two - $one - 4
$four - $three - $five - 5
BTW, Parrot could collapse chains of reference in a GC run
or as side effect of identity checks.

I certainly hope we still have mutable values by design and
In my head mutable value and constant variable sound funny.

Is your view of the world like Python or like Perl 5?
More like an any-junction of all languages supported by Parrot :)

Values have no identity in Perl 5. Containers (variables, named or
anonymous) do. That also means that even though $foo = 5 and $bar = 5,
\$foo != \$bar. In Python, with foo = 5 and bar = 5, that means id(foo)
== id(bar), but I don't like that at all.
Once again \$foo != \$bar just means a dispatch to infix:«!=»Ref,Ref
which might need to be different for PerlRef and PythonRef if the latter
exists at all. The difficult thing for the Parrot folks is the mixed case!
The homogenous cases are up to the languages. But for the mixed case some
meta language level has to define semantics or the languages have to adapt
from the inside out by explicit foreign knowlegde.
Regards,
--
TSa (Thomas Sandlaß)


Re: identity tests and comparing two references

2005-04-04 Thread Juerd
Thomas Sandlaß skribis 2005-04-04 18:50 (+0200):
 In particular what does infix=Scalar of Ref of Ref of Int,Int do?

Depends. What does it mean? :)

Specifically, what is infix, what is =?

 'Scalar of Ref of Any' without dispatching to 'Ref of Int'. That means

References and aliasing should have nothing to do with types, except for
checking. That is, even my Scalar $foo := my Int $bar should let $foo
=:= $bar and \$foo == \$bar.

 1) Is the referene creation done with \, := and implicit in scalar context?

A reference points to a variable the same way a name does. Only the
level at which these exists is different, but that brings along a lot of
different thinking.

A name is visible in the source, a reference is an unmentioned value.

The difference between

my $foo = \$bar;  #1

and

my $foo := $bar;  #2

is that in #1, $$foo =:= $bar, and in #2, $foo =:= $bar (assuming =:=
does NOT autoderefence, and this again makes clear why that'd be a bad
idea). In English: in #1, the value of $foo is a reference that points
to the container that is known as $bar, and in #2, $foo itself is the
same thing as $bar, with both names pointing to the same container.

Or do \ and := differ? And what's different with ::=?

They differ.

::= is like :=, but at compile time rather than runtime. I'm not sure
what the benefit of this is, but I imagine it speeds things up and saves
a few BEGIN blocks.

 2) Is derefencing still done with $ chains where you have to know how far
to go? Is $$$foo still valid Perl 6 syntax?

I should hope so!

 Here is another attempt to pose my question with - depicting an
 indirection.  After the declarations with my we have two chains:

I don't understand how your chains relate to the code you posted before.

 I certainly hope we still have mutable values by design and
 In my head mutable value and constant variable sound funny.

Well, in Perl, values and variables have always been exactly the same
thing. That is, $foo is as much a scalar as the thing that is created
for the number 3. The big difference is that variables are mutable and
literal values are read-only. I would like to avoid the word
constant because that, in Perl 5 jargon, is an inlineable subroutine.

We're used to calling scalars that have a name or are explicitly
referenced variables, and scalars that just are there, like what
subroutines return or what is in source code literally, values. But in
fact, the value is somewhere INSIDE the scalar.

$foo = $bar;   # copies $bar's value to $foo's value
$foo = \$bar;  # creates a reference to $bar's scalar and stores it
   # in $foo's value
$foo = 3;  # copies 3's value (the integer three) to $foo's
   # value
$foo = \3; # creates a reference to 3's scalar and stores it in
   # $foo's value

After $foo = \3, $$foo is immutable because 3 is immutable. However,
after $bar = 3, $bar is mutable because not the variable 3, but only its
value was copied. The read-only flag, which is part of the scalar, is
left out of the copying process.

(Note that for simplicity's sake, I'm talking of value as a single
thing, while in Perl (at least Perl 5), a scalar can have several values
all at once, the best known being dualvars: string and number. A
scalar's value can be string, number, reference, glob or undef. (Should
you really care, then note that undef itself is a special scalar, which,
would you take away its readonly flag, would just as easily hold the
string forty-two.))

 Once again \$foo != \$bar just means a dispatch to infix:«!=»Ref,Ref
 which might need to be different for PerlRef and PythonRef if the latter
 exists at all. 

I hope variables have the semantics of the language they're used in, and
values are copied to another interpreter's variables as needed.
Otherwise in order to use a library written in, for example, Python, you
would have to know how variables work in that language. Bluntly put,
that'd suck.


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html


:=: (OT)

2005-04-04 Thread Juerd
For some reason, I keep typing :=: instead of =:=. Do other people
experience similar typo-habits with new operators?

One of my other Perl 6 typo-habits is ^H^Hargh!^H^H^H^H^H«, but that's
because I like how « and » look, but can't yet easily type them.


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html


[S29] pick on other things than junctions

2005-04-04 Thread Ingo Blechschmidt
Hi,


I remembered Damian saying that pick does not only work on junctions,
but on arrays and hashes, too (and I even found his posting :):
http://groups.google.com/groups?selm=420DB295.3000902%40conway.org).

Are the following assumptions correct?
  my $junc = 1|2|3;
  print $junc.pick; # 1, 2, or 3
  print pick $junc; # same

  my @array = a b c;
  print @array.pick; # a, b, or c
  print pick @array; # same

What does pick return on hashes? Does it return a random value or a
random pair? (I suppose returning a pair is more useful.)


--Ingo

-- 
Linux, the choice of a GNU | The next statement is not true. The
generation on a dual AMD   | prevoius statement is true.  
Athlon!| 



Re: [S29] pick on other things than junctions

2005-04-04 Thread Rod Adams
Ingo Blechschmidt wrote:
I remembered Damian saying that pick does not only work on junctions,
but on arrays and hashes, too (and I even found his posting :):
http://groups.google.com/groups?selm=420DB295.3000902%40conway.org).
Are the following assumptions correct?
 my $junc = 1|2|3;
 print $junc.pick; # 1, 2, or 3
 print pick $junc; # same
 my @array = a b c;
 print @array.pick; # a, b, or c
 print pick @array; # same
What does pick return on hashes? Does it return a random value or a
random pair? (I suppose returning a pair is more useful.)
 

Most likely a pair.
Now if I could only find some more time to work on S29. I've been making 
progress (slowly) on getting the string functions written up, but life 
seems to be conspiring against rapid progress.

-- Rod Adams


Re: :=: (OT)

2005-04-04 Thread Aaron Sherman
On Mon, 2005-04-04 at 15:07, Sam Vilain wrote:

 «»«»«»«»«»«»«»«»«»«»«»«»«»!  :-þ
 
 an excerpt from my xkb config...

I think we've been over this ground before, but if you use EMACS, you'll
find this handy:

http://www.cs.tut.fi/~jkorpela/emacs-iso.html

Of course, some of the sequences used might end up being common in Perl
6, so that could be interesting ;-)

In vim, you want:

http://www.vim.org/htmldoc/digraph.html

but if you use vim or emacs inside a terminal, you'll want to make sure
it's in iso-latin-1 mode (e.g. in gnome-terminal, you have to use the
menu: Terminal-Set Character Encoding)

I can't tell you how long I thought my vim was broken because it would
just output blanks when I used the digraphs. ;-»

We need an S-1 that describes the environmental / egronomic / aesthetic
issues surrounding the use of the latin-1 and/or Unicode characters.

-- 
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback




Re: :=: (OT)

2005-04-04 Thread Larry Wall
On Mon, Apr 04, 2005 at 03:55:23PM -0400, Aaron Sherman wrote:
: but if you use vim or emacs inside a terminal, you'll want to make sure
: it's in iso-latin-1 mode (e.g. in gnome-terminal, you have to use the
: menu: Terminal-Set Character Encoding)

If you going to that trouble, at least try your terminal's utf-8
mode to see if it works.  If it does, you can also see things like
 or , not to mention  and .  Vim supports utf-8; dunno
about emacs.

Larry


Re: :=: (OT)

2005-04-04 Thread Aaron Sherman
On Mon, 2005-04-04 at 16:41, Larry Wall wrote:
 On Mon, Apr 04, 2005 at 03:55:23PM -0400, Aaron Sherman wrote:
 : but if you use vim or emacs inside a terminal, you'll want to make sure
 : it's in iso-latin-1 mode (e.g. in gnome-terminal, you have to use the
 : menu: Terminal-Set Character Encoding)
 
 If you going to that trouble, at least try your terminal's utf-8
 mode to see if it works.  If it does, you can also see things like
  or , not to mention  and .  Vim supports utf-8; dunno
 about emacs.

The default mode for my vim was Latin-1. I was being lazy because I knew
how to tell gnome-terminal to do Latin-1, but I have no clue how to tell
vim to display and save UTF-8. I'm sure it's easy enough though.

On second thought... do I really want to have to figure out:

$pie = $face;

or is that:

$pie;






Re: [S29] pick on other things than junctions

2005-04-04 Thread Trey Harris
In a message dated Mon, 4 Apr 2005, Ingo Blechschmidt writes:
 What does pick return on hashes? Does it return a random value or a
 random pair? (I suppose returning a pair is more useful.)

I'd assume in all cases that pick returns an *alias*, and in the case of
hashes, an alias to the pair:

  # Add entropy to your hash
  for 1..$entropy_thresshold {
  %hash.pick.value *= rand $scribble_factor;
  }

Trey



Re: :=: (OT)

2005-04-04 Thread Mark Reed

:set encoding=utf8
:set fileencoding=utf8

The first controls the display, the second file saves.  Vim has to have been
compiled with multibyte support, though.


From: Aaron Sherman [EMAIL PROTECTED]
Date: Mon, 4 Apr 2005 17:01:58 -0400
To: Larry Wall [EMAIL PROTECTED]
Cc: Perl6 Language List perl6-language@perl.org
Subject: Re: :=: (OT)


The default mode for my vim was Latin-1. I was being lazy because I knew
how to tell gnome-terminal to do Latin-1, but I have no clue how to tell
vim to display and save UTF-8. I'm sure it's easy enough though.

On second thought... do I really want to have to figure out:

$pie = $face;

or is that: 

$pie; 

 




is flattening the word to use when describing lazy lists?

2005-04-04 Thread Terrence Brannon

A Perl 5 user thinks of flattening a data structure as taking
something which is nested and linearizing it.

FOR EXAMPLE:

 use Data::Hash::Flatten;

  # NESTED DATA
  my $a = { bill = { '5/27/96' = { 'a.dat' = 1, 'b.txt' = 2,
  'c.lsp' = 3 } },
jimm = { '6/22/98' = { 'x.prl' = 9, 'y.pyt' = 8,
'z.tcl' = 7 } } } ;


  my @a = Data::Hash::Flatten-this($a, [qw(name date file)]);
  
  use Data::Dumper;
  print Dumper([EMAIL PROTECTED]);

  # FLATTENED DATA
  $VAR1 = [
  {
'date' = '6/22/98',
'name' = 'jimm',
'file' = 'z.tcl'
  },
  {
'date' = '6/22/98',
'name' = 'jimm',
'file' = 'y.pyt'
  },
  {
'date' = '6/22/98',
'name' = 'jimm',
'file' = 'x.prl'
  },
  {
'date' = '5/27/96',
'name' = 'bill',
'file' = 'c.lsp'


HERE'S ANOTHER EXAMPLE:

@ary = (@a,@b,@c);

All three arrays are not nested into @ary, but flattened into @ary.

TO SUMMARIZE:

flatten means something particular to Perl 5 users and the usage of
the term flatten in http://dev.perl.org/perl6/synopsis/S06.html
has no relation to its previously understood meaning.

A more accurate term might be generated or reified, because the
abstract, existent-only-in-conception list members are
concretized/generated/reified via slurping.


SUGGESTIONS:

Change this

quote
Slurpy parameters are treated lazily -- the list is only flattened
into an array when individual elements are actually accessed:

@fromtwo = tail(1..Inf);# @fromtwo contains a lazy [2..Inf]

/quote

To this:

quote
Slurpy parameters are treated lazily -- the list is only
concretized/generated/realized/reified/actualized
into an array when individual elements are actually accessed:

@fromtwo = tail(1..Inf);# @fromtwo contains a lazy [2..Inf]

/quote


Change this:

quote
Flattening argument lists
/quote

to this:

quote
Actualizing argument lists
/quote


Second use of flattening

2005-04-04 Thread Terrence Brannon
The first discussion of flattening had to do with a list of data being
flattened into an array.

Further down we see another different use of the word flattening : 

quote 
   src=http://dev.perl.org/perl6/synopsis/S06.html
   section=Flattening lists

  The unary prefix operator * flattens its operand (which allows the
  elements of an array or iterator to be used as an argument list). 

/quote

Here I understand this to mean that the array is spreading or
distributing its elements to individual scalars.

So, to avoid confusion with the common understanding of flattening in
Perl, perhaps it should be called spreading or distributing.


Re: [S29] pick on other things than junctions

2005-04-04 Thread Trey Harris
I'd assume you'd get an *alias* to a random pair:

  # Test error-correction
  for 1..$entropy_threshhold {
 %hash.pick.value = rand $scribble_factor;
  }

Trey

In a message dated Mon, 4 Apr 2005, Ingo Blechschmidt writes:

 Hi,


 I remembered Damian saying that pick does not only work on junctions,
 but on arrays and hashes, too (and I even found his posting :):
 http://groups.google.com/groups?selm=420DB295.3000902%40conway.org).

 Are the following assumptions correct?
   my $junc = 1|2|3;
   print $junc.pick; # 1, 2, or 3
   print pick $junc; # same

   my @array = a b c;
   print @array.pick; # a, b, or c
   print pick @array; # same

 What does pick return on hashes? Does it return a random value or a
 random pair? (I suppose returning a pair is more useful.)


 --Ingo



-- 


Re: [S29] pick on other things than junctions

2005-04-04 Thread Trey Harris
In a message dated Mon, 4 Apr 2005, Ingo Blechschmidt writes:
 What does pick return on hashes? Does it return a random value or a
 random pair? (I suppose returning a pair is more useful.)

I'd assume in all cases that pick returns an *alias*, and in the case of
hashes, an alias to the pair:

  # Add entropy to your hash
  for 1..$entropy_thresshold {
  %hash.pick.value *= rand $scribble_factor;
  }

Trey


Re: [S29] pick on other things than junctions

2005-04-04 Thread Trey Harris
Yikes.  Sorry about the ressends... my email client kept dying and I
thought the mail was lost.  Guess not. :-)

Trey

In a message dated Mon, 4 Apr 2005, Trey Harris writes:

 In a message dated Mon, 4 Apr 2005, Ingo Blechschmidt writes:
  What does pick return on hashes? Does it return a random value or a
  random pair? (I suppose returning a pair is more useful.)

 I'd assume in all cases that pick returns an *alias*, and in the case of
 hashes, an alias to the pair:

   # Add entropy to your hash
   for 1..$entropy_thresshold {
   %hash.pick.value *= rand $scribble_factor;
   }

 Trey


-- 


Re: Second use of flattening

2005-04-04 Thread Juerd
Terrence Brannon skribis 2005-04-04 18:45 (+):
 So, to avoid confusion with the common understanding of flattening in
 Perl, perhaps it should be called spreading or distributing.

I agree.

Likewise, slurping is probably best explained as collecting.


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html


Re: Second use of flattening

2005-04-04 Thread Andrew Rodland
On Monday 04 April 2005 06:34 pm, Juerd wrote:
 Terrence Brannon skribis 2005-04-04 18:45 (+):
  So, to avoid confusion with the common understanding of flattening in
  Perl, perhaps it should be called spreading or distributing.

 I agree.

 Likewise, slurping is probably best explained as collecting.

I like this. I'd be tempted to suggest scatter / gather, but that's 
probably a bit opaque to the average reader. How about describing them as 
expand / collect for a matched pair? That's got a legacy in math, and 
some mathematically-oriented languages.

Andrew