invocant vs. topic (was: Re: -X's auto-(un)quoting?)

2005-04-26 Thread Thomas Sandlaß
Luke Palmer wrote:
My brother asked me to take out the trash.  I asked him to do it.
I believe that the subject there is my brother in the first sentence
and I in the second.  The topic is either to take out the trash or
just the trash throughout (English speakers wouldn't have any trouble
allowing it to be both).
Let me translate that to my understanding of Perl6:
method Brother::ask( $object ) # $?SELF .does Brother
{
   $_ = please, take out the trash.; # definition of it
   $object.ask; # invocant asks object to do it
}
method ask # $?SELF .does Any
{
   caller.ask; # invocant asks caller to do it (or is the syntax 
caller.self.ask?)
}
my Brother $brother; # declaration needed to dispatch to Brother::ask
$brother.ask( $luke ); # brother asks luke to take out the trash
At runtime the call chain either runs into an undefined object error
in the second invocation of Brother::ask or an endless loop of
invocations of the second method is spawned with alternating callers.
Or, I'm off-topic ;)
PS: We all know that trash doesn't take itself out.
So, $_.ask is pointless :)
--
TSa (Thomas Sandla)



Re: invocant vs. topic (was: Re: -X's auto-(un)quoting?)

2005-04-26 Thread Mark Reed
I¹m only an amateur linguist, but from a linguistic point of view, there are
several related terms in this space.

The term ³subject² has many meanings in English, including ³topic².  But
from a grammatical and linguistic standpoint, there are only two meanings of
³subject², and ³topic² is a distinct term.

One meaning of ³subject² is specific to the grammar of a given language,
such as English, in which we have ³subjects² and ³objects².  The more
general linguistic term is usually capitalized (³Subject²) and even more
usually abbreviated as ³S²; it refers only to what we call the subject of an
intransitive verb.  What we call the subject of a transitive verb is more
generally called the ³Agent², or ³A², and what we call the direct object of
a transitive verb is more generally called a ³Patient², or ³P².  Different
languages group S, A, and P differently in how they are treated by the
grammar; English, like most European languages, lumps S and A together and
separates P; such languages are called ³nominative-accusative² (or just
³accusative²) languages.

Then you have ³topic² and ³focus², which are closely related.  Basically,
the focus is the main thing that you¹re talking about in a given sentence,
and is usually introduced by that sentence.  The topic is a known quantity
under discussion.  So you frequently have the focus of one sentence ­ which
may or may not be its subject - being the topic for subsequent discussion.

Example:

A) I went to the game yesterday.
B) While there, I saw Smoltz strike out 15 batters.

The grammatical subject of sentence A is ³I²,  and it is actually a Subject
in SAP terms.  But the focus is the game.  The definite article implies that
the listener knows which game is being discussed, but it¹s still being
introduced as a new element here.  If there is a topic, we don¹t know what
it is.

The grammatical subject of B is still ³I², but this time it¹s an Agent; the
Patient is an action (Smoltz striking out 15 batters), and that action is
also the focus.  But  the topic is the game.



goto, enter, leave, etc. (Was: Re: -X's auto-(un)quoting?)

2005-04-25 Thread Thomas Sandlaß
Larry Wall wrote:
I should point out that we're still contemplating breaking .foo() so it
no longer means $_.foo().  I wish there were more keys on my keyboard...
What is the status of my proposal to reserve the indirect object syntax
for calls on $_ and the .method form for the invocant in (single)methods?
Thus .method *always* expands to $?SELF which of course isn't available
outside of method definitions.
This postfix colon call syntax has to go with a new syntax for landing sites
into code positions like we have goto for jumping out. I proposed to call
the goto partner 'land' but it could also be the enter function which
defines the entry points into a block, calling the ENTER blocks if
coming from the outside or so. Typical entry points that come to mind
are before/after parameter (type) check. BTW, does goto call all LEAVE
blocks that are left and all ENTER blocks that are entered? If not all,
which ones are picked?
Then the example becomes
given open 'mailto:[EMAIL PROTECTED]' {
say: (...); # space needed to avoid say:(...) syntax?
close: or fail; # or even 'close or fail'
}
This postfix colon syntax is basically needed only if a different entry
point into the dispatch of e.g. close shall be taken. A plain close starts
from MMD, while close: starts from namespace scoped single dispatch on $_
and fails over to MMD. Either syntax '$_.close' and 'close $_:' is already
valid and both need more chars when interpolated: $_.close() or {$_.close}
and {close $_:}.
But some whitespace rules are needed to disambiguate
method: option; #1
from
method :option; #2a
and
method:option; #2b
Case #1 calls method on $_ with the return value of option,
while cases #2 call method with adverbial modifier option set
to true.
A nice extension that also saves the trailing ; is to say that
a single indirect method call in a line autoterminates or some such.
I mean to warp the postfix colon indirect object syntax into doing
double duty as statement separator. Well, actually the
semicolon is half a colon in that respect :)
Then we get:
given baz()# $_ := baz() or with temp?
{
   bar:# $_.bar()
   blubb:  # $_.blubb()
   whatever:   # $_.whatever()
}
and
method foo()# foo( $?SELF: )
{
   .bar;# $?SELF.bar()
   .blubb;  # $?SELF.blubb()
   .whatever;   # $?SELF.whatever()
}
and combined:
method foo()# foo( $?SELF: )
{
 # given foo() works syntactically but could recurse infinitly
   given baz() # temp $_ := baz()
   {
  .bar;   # $?SELF.bar()
  blubb:  # $_.blubb()
  .whatever:  # MMD whatever( $?SELF, $_: )
   }
}
BTW, are the two method examples valid without a surrounding class scope?
I think it's not strictly needed because foo would be added to class Any.
Hmm, this would also produce:
$obj.method $foo, $bar: $x, $y, $z;
to mean
method( $obj, $foo, $bar: $x, $y, $z );
and of course
$obj.method: $x, $y, $z;
means
method( $obj, $_: $x, $y, $z );
--
TSa (Thomas Sandlaß)



Re: -X's auto-(un)quoting?

2005-04-25 Thread Paul Seamons
I think the original (or the latest original) reason for breaking .meth from 
meaning $_.meth is that $_ is transitory and there was no way back to the 
nameless invocant.  In the absense of having a way back, I and others 
strongly advocated breaking the link.   I think we hated to do it.

Now if we can introduce another way back so that we can always get to the 
invocant if we want to, then I'd say lets leave .meth always working on $_ .  
It does have beauty and simplicity.

So then, to get back to the invocant...  I can't say that I liked many of the 
proposals.  The one that seemed to have merit though was $^.  I'd propose the 
following.

  meth foo {
 $_.meth; # defaults to the invocant
 .meth; # operates on $_ which defaults to the invocant
 $^.meth;  # is the invocant
 $^1.meth; # is the first invocant
 $^2.meth; # is the second invocant

 for 1 .. 10 {
$_.say; topic of for
.say; # use $_
$^.say; # stringifies invocant 1
$^1.say; # stringifies invocant 1
$^2.say # stringifies invocant 2
 }
  }

The rules then are simple.  .meth always operates on $_.  $_ is always the 
current topic.  $_ defaults to the invocant of the method.  $^1 refers to the 
first invocant.  $^ is an alias for $^1.  $^n refers to the nth invocant.

Nice and simple.  No conflict with existing naming conventions.

Paul


Re: -X's auto-(un)quoting?

2005-04-25 Thread Juerd
Paul Seamons skribis 2005-04-25  9:52 (-0600):
 a way back

What is this way back you repeatedly mention?

If it is having a name for the invocant, then there has always been one:

method foo ($self:) {
for (1..10) {
$self.method(.sqrt)
}
}

Or, well, two:

method foo {
my $self := $_;
...
}

Three, even:

method foo {
my $self = \$_;
for (1..10) {
$$self.method(.sqrt)
}
}

And probably even more. TAMT0WTDI! :)

 Now if we can introduce another way back so that we can always get to the 
 invocant if we want to, then I'd say lets leave .meth always working on $_ .  
 It does have beauty and simplicity.

Agreed!

  $^.meth;  # is the invocant
  $^1.meth; # is the first invocant
  $^2.meth; # is the second invocant

I don't understand the concept of multiple invocants. How does that
work?

$^ as an alias for the invocant works for me, because  sorts before
anything else, and the invocant's just the 0th argument.

 The rules then are simple.  .meth always operates on $_.  $_ is always the 
 current topic.  $_ defaults to the invocant of the method.

Yes! The problem isn't that this hasn't already been thought of -- it is
the current spec even.

However, the discussion is about changing these simple, clear, and
useful rules to a more complex situation of choosing a default based on
what the default will be used for, making the default for methods the
invocant rather than $_. I hate those plans and would love to see the
current spec, that is as you decribe above, implemented in the final
version.

(Or well, I believed this was the spec until I tried finding it. I can
find the stuff about .method defaulting to $_ in S12, but $_ being an
alias for the invocant is harder to find.)


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


Re: -X's auto-(un)quoting?

2005-04-25 Thread Paul Seamons
 What is this way back you repeatedly mention?

 If it is having a name for the invocant, then there has always been one:

 method foo ($self:) {
 for (1..10) {
 $self.method(.sqrt)
 }
 }

 Or, well, two:

 method foo {
 my $self := $_;
 ...
 }

 Three, even:

 method foo {
 my $self = \$_;
 for (1..10) {
 $$self.method(.sqrt)
 }
 }

By this reasoning - why have a shortcut to any of the invocants at all?  This 
thread has headed in the direction of finding a way to figure out how to call 
methods on the invocant without using the signatures name.  On a method call 
without a signature and without invoking Perl5isms there would not be a way 
back to the invocant once you enter nested block.

The point of all of this discussion is to not have to set $self to anything.  
The argument for .meth as opposed to $self.meth of $_.meth was that .meth was 
clear enough to mean the current topic and was a nice huffmanization. 

 method foo ($self:) {
 for (1..10) {
 $self.method(.sqrt)
 }
 }

That works great - so long as I specify the signature.  I'm lazy, I don't want 
to type the signature all the time.  Consider:

method foo {
   for 1 .. 10 {
  $^.method(.sqrt);
   }
}

Still pretty readable.  I kind of like $^1 too which seems to behave like 
$^variable quite nicely.  I guess that $^1 should actually be $^0 so that we 
are properly zero indexed.  At this point - it sort of looks like Perl5's 
$_[0] except now $^0 is just an alias and and it gets all of the attributes 
given by the signature (should a signature be given) - plus we don't have to 
deal with the [EMAIL PROTECTED] array.

 Or, well, two:

 method foo {
 my $self := $_;
 ...
 }

If I didn't like typing the signature - why would I want to type all of that 
code to bind the variable?  I'm lazy.  The signature wouldv'e been shorter.  
That looks Perl5ish.

 Three, even:

Same argument as the last with a different aliasing.

Yes, I know there can be a way back.  In this thread, none of the examples 
give one using existing Perl 6 syntax.  They are all proposing new ways.  
This is one more.

Paul


Re: -X's auto-(un)quoting?

2005-04-25 Thread Thomas Sandlaß
Juerd wrote:
However, the discussion is about changing these simple, clear, and
useful rules to a more complex situation of choosing a default based on
what the default will be used for, making the default for methods the
invocant rather than $_. I hate those plans and would love to see the
current spec, that is as you decribe above, implemented in the final
version.
I think your basic error in perception is that $_ is a runtime variable
while the invocant(s) are more a design time assumption of what the
method is working on. Perl6 has invented the notion of topic as a global
lexically scoped variable that is orthogonal to the invocant and non-invocant
parameters of (multi) methods. We have two distinct names for these two
concepts: $_ and $?SELF. Additional multi method invocants need names
anyway.
E.g. in methods of GUI classes the invocant would be the selected widget
and the topic the event.

(Or well, I believed this was the spec until I tried finding it. I can
find the stuff about .method defaulting to $_ in S12, but $_ being an
alias for the invocant is harder to find.)
My reading is that the two concepts have developed concurrently and
only recently some pitfalls were identified when they are combined.
--
TSa (Thomas Sandlaß)


Re: -X's auto-(un)quoting?

2005-04-25 Thread Paul Seamons
Paul Seamons wrote:
 Yes, I know there can be a way back.  In this thread, none of the
 examples give one using existing Perl 6 syntax.  They are all proposing new
 ways. This is one more.

Sorry if this sounded brash.  I have a habit of not figuring out that there is 
more of the message to read.

Juerd wrote:
 $^ as an alias for the invocant works for me, because  sorts before
 anything else, and the invocant's just the 0th argument.

Didn't see that in your response - I responded to the first topic section but 
failed to see there was another.

Juerd wrote:
 I don't understand the concept of multiple invocants. How does that
 work?

If my ability to parse the Synopses was very good, I'd tell you where I saw 
mention of it - or maybe it was in the mailing list.  Either way that is the 
point of the colon in the:

method foo ($self: $arg1, $arg2) {}

So that in theory there would be 

method foo ($self, $otherself: $arg1, $arg2) {}

In the end, I'd just like the rules for what .meth does and what $_ is to be 
concise and clear - whatever the sytax is that is adopted.

Paul


Re: -X's auto-(un)quoting?

2005-04-25 Thread Thomas Sandlaß
Paul Seamons wrote:
method foo {
   for 1 .. 10 {
  $^.method(.sqrt);
   }
}
I would make that:
method foo
{
   for 1 .. 10
   {
  .method sqrt:   #  $?SELF.method( $_.sqrt() )
   }
}
Then usage is:
my $x = blubb;
$x.foo;  # $x.method( sqrt(1) ) .. $x.method( sqrt(10) )
Iff blubb has got a method .method that takes a Num as param ;)
--
TSa (Thomas Sandlaß)



Re: -X's auto-(un)quoting?

2005-04-25 Thread Juerd
Paul Seamons skribis 2005-04-25 11:12 (-0600):
 By this reasoning - why have a shortcut to any of the invocants at all?  This 
 thread has headed in the direction of finding a way to figure out how to call 
 methods on the invocant without using the signatures name.  On a method call 
 without a signature and without invoking Perl5isms there would not be a way 
 back to the invocant once you enter nested block.
 The point of all of this discussion is to not have to set $self to anything.  
 The argument for .meth as opposed to $self.meth of $_.meth was that .meth was 
 clear enough to mean the current topic and was a nice huffmanization. 

Agreed, but you put it as if there was no way of getting there, instead
of there being a way that isn't satisfactory.

I agree that having a short way to use the invocant is good, and like
your $^ proposal. I still don't understand what the second invocant
could be, though.

Another character that has no prefix meaning yet is .  are a bit
overused already, but perhaps this can fit in. It has the benefit of
being shift+dot on a US keyboard :P

 That works great - so long as I specify the signature.  I'm lazy, I
 don't want to type the signature all the time.  Consider:

When will people realise that this problem is exactly the same thing
as what you get when two other topicalizers are nested, and TREAT it
like exactly the same problem, so that a solution can be invented that
solve both problems in one stroke.

This said, I really do think the ^ thing is nice. But if you really
think not having a short syntax to reach something in a higher level
block is a problem, then be consistent and declare nested given/for
blocks a problem too. The current invocant problem is really not that
much different from the outer topic problem, or, in larger scope,
the outer block problem, which is solved with labels.

outer topic problem name it, or use OUTER::
outer block problem name it (label it)
invocant problemname it! or use $?SELF

The same problem comes up whenever things can nest. So I'm more or less
expecting discussion about

outer rule problem
outer class|grammar problem (?)
parent process %ENV problem (learn to live with it)
parent object problem (familiar...)

Whether or not naming it is the answer in every occassion is a good
question. Probably when dealing with parent stuff, it is not, because we
want those things to be anonymous more often than the other things.


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


Re: -X's auto-(un)quoting?

2005-04-25 Thread Juerd
Thomas Sandlaß skribis 2005-04-25 19:30 (+0200):
   .method sqrt:   #  $?SELF.method( $_.sqrt() )

I don't like your solution simply because I don't like indirect object
calls. I avoid to and want to continue to avoid them, and do want a
short way for $_. Besides that, I think whatever default is chosen
should be consistently applied to both syntaxes. Of course, the same
consistency prescripbes that $_ be that default...


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


Re: -X's auto-(un)quoting?

2005-04-25 Thread Juerd
Thomas Sandlaß skribis 2005-04-25 19:13 (+0200):
 I think your basic error in perception is that $_ is a runtime variable
 while the invocant(s) are more a design time assumption of what the
 method is working on.

$_ is the *topic*. Its role in design and thinking is gigantic.

The funny thing is that in this way, the invocant is just that: being
important for design and thinking, and that makes it... a topic.

Following this, considering the topic and the invocant the same thing
works. Until you temporarily change the topic, which means that if you
want the previous topic, you have to be more specific when referring to
it. This is consistent with natural languages as well.

Having two topics, one for the short stuff ($_, sentence) and one for
the long stuff ($self, paragraph) makes sense too. I recall having read
that Japanese had something like that. But making the default thing
you're referring to anything but the most recent (in programming:
innermost) topic, is madness.

(While typing this, I realised that there may be, in English, a
difference between subject and topic. If that's true, please educate
me.)

 E.g. in methods of GUI classes the invocant would be the selected widget
 and the topic the event.

In my thinking, the event would not be named, because it is not
something you operate on. Events just happen - it should be the name of
the method, and the code inside should very rarely need that
information (except when needed to call a supermethod, for example).

The event being the topic makes sense only if all events are handled by
the same method, in which you use a dispatch table. But OO itself is a
pretty neat dispatching machine already.


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


Re: -X's auto-(un)quoting?

2005-04-25 Thread Nathan Wiger
Paul Seamons wrote:
So then, to get back to the invocant...  I can't say that I liked many of the 
proposals.  The one that seemed to have merit though was $^.  I'd propose the 
following.

  meth foo {
 $_.meth; # defaults to the invocant
 .meth; # operates on $_ which defaults to the invocant
 $^.meth;  # is the invocant
 $^1.meth; # is the first invocant
 $^2.meth; # is the second invocant
I'm starting to get confused at the need for all these special 
variables. I vote that we steal from prior art in numerous other 
languages and just auto-set $SELF or $THIS or whatever and call it done.

Having .method assume $SELF is an added nicety, but if it introduces 
added parsing problems then it's hardly worth it.

OR, choose $^ and don't set $SELF (or $?SELF or whatever), but having 
dup short and long names is a waste, since people will always chose the 
short one (who uses English in Perl 5, really?)

-Nate


Re: -X's auto-(un)quoting?

2005-04-25 Thread Paul Seamons
meth foo {
   $_.meth; # defaults to the invocant
   .meth; # operates on $_ which defaults to the invocant
   $^.meth;  # is the invocant
   $^1.meth; # is the first invocant
   $^2.meth; # is the second invocant

 I'm starting to get confused at the need for all these special
 variables. I vote that we steal from prior art in numerous other
 languages and just auto-set $SELF or $THIS or whatever and call it done.

The problem is that there is no globally safe name to use that uses letters 
only.  Also there is a certain line noise problem (which may not really be a 
problem - but looks like one once we have a more concise alternative):

method foo {
   $SELF.prop = $SELF.meth($SELF.get_foo, $SELF.get_bar);
   $SELF.say(Hello  ~ $SELF.prop);
}

That looks considerably more messy than:

method foo {
   $.prop = .meth(.get_foo, .get_bar);
   .say(Hello  ~ $.prop);
}

Perl syntax is wonderful for being able to say as much as possible without 
losing meaning - assuming you can read perl.  The short identifiers are able 
to express a lot in a little space.

 Having .method assume $SELF is an added nicety, but if it introduces
 added parsing problems then it's hardly worth it.

The .method problem isn't about parsing - it is about knowing which variable 
it applies to.

Current syntax would do:

method foo ($self:) {
   return grep { $self.is_ok( .value ) } $self.info_pairs;
   # .value called on the topic $_
}

Proposed syntax previous to this thread

method foo {
   return grep { .is_ok( $_.value ) } .info_pairs;
   # .is_ok called on invocant not the topic
}

Proposed syntax in this thread (among various others)

method foo {
  return grep { $^.is_ok( .value ) } $^.info_pairs;
  # .value called on the topic
}

The goal is to be able to be concise yet intuitive - so that you could do:

my @good_objects = grep { .is_ok } @candidate_objects;

 OR, choose $^ and don't set $SELF (or $?SELF or whatever), but having
 dup short and long names is a waste, since people will always chose the
 short one (who uses English in Perl 5, really?)

That is the goal - to find some nice variable that looks vaguely usable and 
that people won't rebel against using.

Paul


Re: -X's auto-(un)quoting?

2005-04-25 Thread Juerd
Paul Seamons skribis 2005-04-25 13:02 (-0600):
 method foo ($self:) {
return grep { $self.is_ok( .value ) } $self.info_pairs;
# .value called on the topic $_
 }

I think that to be fair, you have to leave out the redundant $self
there.

return grep { $self.is_ok( .value ) } .info_pairs;

 Proposed syntax in this thread (among various others)
 method foo {
   return grep { $^.is_ok( .value ) } $^.info_pairs;
   # .value called on the topic
 }

I think that also wanted:

method foo {
return grep { ^is_ok( .value ) } ^info_pairs;
# .value called on the topic
}

 That is the goal - to find some nice variable that looks vaguely usable and 
 that people won't rebel against using.

Variable or alternative for the dot.


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


Re: -X's auto-(un)quoting?

2005-04-25 Thread Nathan Wiger
Paul Seamons wrote:
 meth foo {
$_.meth; # defaults to the invocant
.meth; # operates on $_ which defaults to the invocant
$^.meth;  # is the invocant
$^1.meth; # is the first invocant
$^2.meth; # is the second invocant
I'm starting to get confused at the need for all these special
variables. I vote that we steal from prior art in numerous other
languages and just auto-set $SELF or $THIS or whatever and call it done.

The problem is that there is no globally safe name to use that uses letters 
only.  Also there is a certain line noise problem (which may not really be a 
problem - but looks like one once we have a more concise alternative):
I understand the purported problem, but what I'm saying is that it 
really isn't one. Variables magically coming into existence doesn't seem 
to be a problem for any language but Perl 6. Many other languages set 
this automagically.

 method foo {
   $SELF.prop = $SELF.meth($SELF.get_foo, $SELF.get_bar);
   $SELF.say(Hello  ~ $SELF.prop);
 }
I'm not sure the point of this block; it's hardly horrific. Any external 
script would have to say:

   $invocation = new Class;
   $invocation.meth($invocation.get_foo, $invocation.get_bar);
If the point is that $^ saves typing over $?SELF then I agree; my point 
is simply that we pick one or the other, instead of both/aliases/etc.

-Nate


Re: -X's auto-(un)quoting?

2005-04-25 Thread Luke Palmer
Juerd writes:
 (While typing this, I realised that there may be, in English, a
 difference between subject and topic. If that's true, please educate
 me.)

Well, from a non-linguist's point of view, they are two very different
things.

My brother asked me to take out the trash.  I asked him to do it.

I believe that the subject there is my brother in the first sentence
and I in the second.  The topic is either to take out the trash or
just the trash throughout (English speakers wouldn't have any trouble
allowing it to be both).

Interesting, this is the same kind of reasoning (and backwards naming)
that I used when I proposed ` as the subjective dot.

Speaking of such a dot, there are things I like about ^ and things I
don't.  It is fairly visually intrusive on the one hand.  On the other,
it's on the top of the line rather than the bottom, which makes a nice
contrast from the regular dot.  

As alternatives, Damian has suggested meth(), and I've suggested
meth().  They both look wrong.  I'm not even sure we're on the right
track, changing the dot (changing the dot also includes Thomas's
proposal: his dot is just postfix).  I do think that considering the
distinction between subject and topic is important to getting it
right, however.

Luke


Re: -X's auto-(un)quoting?

2005-04-25 Thread Juerd
Nathan Wiger skribis 2005-04-25 13:35 (-0700):
 My point is simply that we pick one or the other, instead of
 both/aliases/etc.

But TIMTOWTDI. One way may be great for writing maintainable code, while
the other is useful in oneliners (including single line method
definitions).


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


Re: -X's auto-(un)quoting?

2005-04-25 Thread Luke Palmer
Nathan Wiger writes:
 Paul Seamons wrote:
  meth foo {
 $_.meth; # defaults to the invocant
 .meth; # operates on $_ which defaults to the invocant
 $^.meth;  # is the invocant
 $^1.meth; # is the first invocant
 $^2.meth; # is the second invocant
 
 I'm starting to get confused at the need for all these special
 variables. I vote that we steal from prior art in numerous other
 languages and just auto-set $SELF or $THIS or whatever and call it done.
 
 
 The problem is that there is no globally safe name to use that uses 
 letters only.  Also there is a certain line noise problem (which may not 
 really be a problem - but looks like one once we have a more concise 
 alternative):
 
 I understand the purported problem, but what I'm saying is that it 
 really isn't one. Variables magically coming into existence doesn't seem 
 to be a problem for any language but Perl 6. Many other languages set 
 this automagically.
 
  method foo {
$SELF.prop = $SELF.meth($SELF.get_foo, $SELF.get_bar);
$SELF.say(Hello  ~ $SELF.prop);
  }
 
 I'm not sure the point of this block; it's hardly horrific. 

I think it is.  It's obviously a matter of taste.  But all those $SELFs,
in my opinion, really take away from the meaning of the code.  I loathe
reading such Perl 5 OO code, for precisely the same reason.  We already
have a shorthand (which is an only-hand in some cases) for accessing
attributes:

method foo {
$.prop = $self.meth($.foo, $.bar);
$self.say(Hello $.prop);
}

And it seems natural to go for methods too, especially since attributes
are allowed just to be fancy methods.

I have always wondered what would happen if we blurred the distinction
altogether.  It's tricky, because you need direct access to implement
accessors.  But since variables for which accessors are not
automatically generated are already marked as $:, perhaps it is an
option:

class Point {
has $.x is rw;
has $.y is rw;
has Pdl $:coords;

method set_coords(Pdl $new) {
($.x, $.y) = ($new  $:coords.inverse  Pdl.new($.x, $.y)).list;
$:coords = $new;
}

method swap_coords() {
$.set_coords(Pdl([0, 1; 1, 0]));   # calls a method with $. syntax
}
}

Luke


Re: -X's auto-(un)quoting?

2005-04-25 Thread Nathan Wiger
Juerd wrote:
Nathan Wiger skribis 2005-04-25 13:35 (-0700):
My point is simply that we pick one or the other, instead of
both/aliases/etc.

But TIMTOWTDI. One way may be great for writing maintainable code, while
the other is useful in oneliners (including single line method
definitions).
Then I suggest use English for Perl 6 too. I think you'll find that, 
like Perl 5, people always use the short forms.

Has ANYONE on this list ever done something like this?
   use English;
   if ($OSNAME =~ /MSWin32/) {
   $OUTPUT_AUTOFLUSH++;
   local $WARNING = 0;
   print Windoze\n or die Can't print: $OS_ERROR;
   }
I'd bet everyone would write that as:
   if ($^O =~ /MSWin32/) {
   $|++;
   local $^W = 0;
   print Windoze\n or die Can't print: $!;
   }
Crap, I had to open the Camel just to find the long names. :-)
-Nate
P.S. I know this is the first time I've spoken up on Perl 6
 in 5-ish years, so nice to see you all once again


Re: -X's auto-(un)quoting?

2005-04-25 Thread Rod Adams
Nathan Wiger wrote:
Juerd wrote:
Nathan Wiger skribis 2005-04-25 13:35 (-0700):
My point is simply that we pick one or the other, instead of
both/aliases/etc.

But TIMTOWTDI. One way may be great for writing maintainable code, while
the other is useful in oneliners (including single line method
definitions).

Then I suggest use English for Perl 6 too. I think you'll find that, 
like Perl 5, people always use the short forms.

Has ANYONE on this list ever done something like this?
   use English;
   if ($OSNAME =~ /MSWin32/) {
   $OUTPUT_AUTOFLUSH++;
   local $WARNING = 0;
   print Windoze\n or die Can't print: $OS_ERROR;
   }
Not exactly a fair comparison, since it's common to not use English 
due to the $ issue.

I suspect that if that was not the case, it would be used more.
-- Rod Adams


Re: -X's auto-(un)quoting?

2005-04-24 Thread John Macdonald
On Saturday 23 April 2005 14:19, Juerd wrote:
 Mark A. Biggar skribis 2005-04-23 10:55 (-0700):
  After some further thought (and a phone talk with Larry), I now think
  that all of these counted-level solutions (even my proposal of _2.foo(),
  etc.) are a bad idea.
 
 In that case, why even have OUTER::?

Referring to something by relative position is great when refactoring
will not change the relationship.

If you refactor the enclosing context, whatever context is wrapped
around me is changed by refactoring in the right way; while that
specific thing that is 2 levels out (at the time I wrote this code) is
changed in the wrong way, because the specific context you want to
refer to may now be 1 or 3 or 50 levels out.


Re: -X's auto-(un)quoting?

2005-04-23 Thread Juerd
Larry Wall skribis 2005-04-22 18:31 (-0700):
 I should point out that we're still contemplating breaking .foo() so it
 no longer means $_.foo().  I wish there were more keys on my keyboard...

Which I think would be a very bad idea, so while I can (as long as no
other decision has been made), I'm using the current syntax :)

I even consider breaking compatibility with bare Perl 6, for my grammar,
if that's necessary to get .foo to use the same implicit LHS as .[5].

Subs and loops are related, and aliasing the invocant as $_ the same way
a loop aliases the loop variable as $_ makes sense to me. when you use a
loop within a sub, do the same thing as when you use a loop within
another loop: explicitly use the full name, or use OUTER::.

 We do, after all, have better ways of declaring private methods and
 functions now. so maybe we don't need to reserve _ for that anymore.

I was planning on using prefixed underscore for macros that slurp up
till the end of a line, so syntax highlighting could be adjusted for
those things that would otherwise break. With non-underscore, I'd have
to use a litter, or make my macro a prefix operator, which is more work.

 And it would save two characters over $_.foo().  But recovering C
 programmers will scream, and probably prefer _.foo(), even if it only
 saves one character.  

_ on my keyboards is two keys, shift and -, while . is only one.

In fact, I find $_.foo even easier to type than _.foo, and better
looking. Especially because the $ sigil is part of the name now, _
without sigil should not be used.

 Maybe it's time to raid Latin-1 for the next closest thing to a dot,
 middle dot:
 ·say(...);
 ·close or fail;

Please, no.

 But I'm sure some will argue that's too subtle.  (Hi, @LarryDamian.)

String index for an array?

 say¹(...);
 close¹ or fail;
 Then foo² would be $OUTER::_.foo(), foo³ would be $OUTER::OUTER::_.foo().

For that matter, I think repeating prefixed dots works just as well:

.foo# $_.foo
..foo   # $OUTER::_.foo # OUTER::$_.foo
...foo  # $OUTER::OUTER::_.foo  # OUTER::OUTER::$_.foo

This shouldn't clash with yada, I think. (In the case it does (why would
it?), adding parens is an obvious way to break ambiguity: (...).)

 Yes, especially the c: scheme.  :-)

I have no pity for Win32 users :)

For all I care, they can use file:///c|/... or the awful MSIE variant
file://c:\foo\bar.

But I guess it's safe to treat single-letter schemes as Win32/DOS
volumes, as there are no single-letter URI schemes.


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


Re: -X's auto-(un)quoting?

2005-04-23 Thread Juerd
Matt skribis 2005-04-22 21:55 (-0400):
 What about . for each level up you want to go?
 instead of 1.say, 2.say, 3.say
 you use .say, ..say, ...say
 (Ok, I'm just kidding.. really!)

I read your message after I suggested the same thing (I'm too impatient
to read all new messages before sending replies).

Why were you just kidding? I think it's a great idea.


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


Re: -X's auto-(un)quoting?

2005-04-23 Thread Nigel Hamilton
What about . for each level up you want to go?
instead of 1.say, 2.say, 3.say
you use .say, ..say, ...say
(Ok, I'm just kidding.. really!)
I read your message after I suggested the same thing (I'm too impatient
to read all new messages before sending replies).
Why were you just kidding? I think it's a great idea.
I like it too.
In normal writing ... acts as a kind of 'think back' operator. Even though 
the writer uses it to signal an afterthought - it also makes the reader 
'think back' to what preceded the afterthought.

Syntax like .say ..say ...say enables the writer to add an afterthought 
and the reader to 'think back' to precisely the right scope. It allows you 
to have N scopes too .say, that would be cool.

I hope this doesn't cause trouble for yada yada because I really like that 
operator too.

Nige



Re: -X's auto-(un)quoting?

2005-04-23 Thread Matt
On Sat, 23 Apr 2005 07:25:10 -0400, Juerd [EMAIL PROTECTED] wrote:
Matt skribis 2005-04-22 21:55 (-0400):
What about . for each level up you want to go?
instead of 1.say, 2.say, 3.say
you use .say, ..say, ...say
(Ok, I'm just kidding.. really!)
I read your message after I suggested the same thing (I'm too impatient
to read all new messages before sending replies).
Why were you just kidding? I think it's a great idea.
Juerd
Well I like it too.  I just didn't think anyone would actually go for it.   
I guess I underestimated how crazy you guys are ;)


Re: -X's auto-(un)quoting?

2005-04-23 Thread Mark A. Biggar
Matt wrote:
On Sat, 23 Apr 2005 07:25:10 -0400, Juerd [EMAIL PROTECTED] wrote:
Matt skribis 2005-04-22 21:55 (-0400):
What about . for each level up you want to go?
instead of 1.say, 2.say, 3.say
you use .say, ..say, ...say
(Ok, I'm just kidding.. really!)

I read your message after I suggested the same thing (I'm too impatient
to read all new messages before sending replies).
Why were you just kidding? I think it's a great idea.

Well I like it too.  I just didn't think anyone would actually go for 
it.   I guess I underestimated how crazy you guys are ;)
After some further thought (and a phone talk with Larry), I now think
that all of these counted-level solutions (even my proposal of _2.foo(),
etc.) are a bad idea. They have a similar problems to constructs like
next 5; meaning jump to the next iteration of the loop 5 level out.
Any time you refactor you code and change levels, they break in a
subtle and very hard to debug way, causing mysterious errors.  Just like
the current Perl construct of labeled loops so that you can talk about
the target loop explicitly, the proper solution for up-level access to
$OUTER::OUTER::...::OUTER::_ is to create a named binding like
$uplevel_topic := $_; at that upper level and then use that to refer 
to it at lower levels.  Beside is ...foo(); seven of eight levels
up?  Any other way than explicit naming is madness; leading to
unreadable and unmaintainable code.

--
[EMAIL PROTECTED]
[EMAIL PROTECTED]


Re: -X's auto-(un)quoting?

2005-04-23 Thread Matt Creenan
On Sat, 23 Apr 2005 13:55:17 -0400, Mark A. Biggar [EMAIL PROTECTED] wrote:
After some further thought (and a phone talk with Larry), I now think
that all of these counted-level solutions (even my proposal of _2.foo(),
etc.) are a bad idea. They have a similar problems to constructs like
next 5; meaning jump to the next iteration of the loop 5 level out.
Any time you refactor you code and change levels, they break in a
subtle and very hard to debug way, causing mysterious errors.  Just like
the current Perl construct of labeled loops so that you can talk about
the target loop explicitly, the proper solution for up-level access to
$OUTER::OUTER::...::OUTER::_ is to create a named binding like
$uplevel_topic := $_; at that upper level and then use that to refer  
to it at lower levels.  Beside is ...foo(); seven of eight levels
up?  Any other way than explicit naming is madness; leading to
unreadable and unmaintainable code.

Hm.. didn't really think of that.  Though, how often would that really  
happen?  You can just explicility refer to the topic if you refactor.  So  
long as there is another way, I'm not sure that problem constitutes not  
putting in such a shortcut.

I do see this as a being a bit confusing though:
given open 'file a' {
given open 'file b' {
given open 'file c' {
.say(...);
..say(...);
...say(...);
}
}
}
Doesn't that just encourage writing confusing code?  Also, does anyone  
else initial read it as doing say on file a first, then b, then c; instead  
of c, b, a?


Re: -X's auto-(un)quoting?

2005-04-23 Thread Juerd
Mark A. Biggar skribis 2005-04-23 10:55 (-0700):
 After some further thought (and a phone talk with Larry), I now think
 that all of these counted-level solutions (even my proposal of _2.foo(),
 etc.) are a bad idea.

In that case, why even have OUTER::?

I agree, though, and have always found this, that using the full name
(binding one if it doesn't have one already) is the better solution.

given returns_object() - $foo {
when SomeClass { ... }
}

I think we all agree that smart match (implied by when) should work on
$_. The following is consistent with the above:

method ($foo: @bar) {
when SomeClass { ... }
}

Only the first line changes, and everything still works as expected.

The same would work very well for method calls:

method ($foo: @bar) {
.method;
}

I would expect that if we change the first line back (less academically,
copied and pasted the code elsewhere), it would still work on the same
thing.

given returns_object - $foo {
.method;
}

The block passed to given aliases the first argument to $_. Methods
should do the same. And I really beleave that using a : to separate
instead of , does not make the invocant any less the first argument.

 They have a similar problems to constructs like next 5; meaning jump
 to the next iteration of the loop 5 level out.

Yes, that's ugly.

 Any time you refactor you code and change levels, they break in a
 subtle and very hard to debug way, causing mysterious errors.

Same thing for having one thing default to $_ and another to $self, in a
way. If everything defaults to $_, which may or may not be the same
thing as $self, things become more predictable, and you can when
refactoring just copy the body of a loop to a new method without
breaking it.

 Just like the current Perl construct of labeled loops so that you
 can talk about the target loop explicitly, the proper solution for
 up-level access to $OUTER::OUTER::...::OUTER::_ is to create a named
 binding like $uplevel_topic := $_; at that upper level and then use
 that to refer to it at lower levels.

Indeed. Fortunately, many built in constructs involving blocks that get
arguments already set up that binding for you.

 Beside is ...foo(); seven of eight levels up?

A rather irrelevant question, IMHO. It is as irrelevant as the similar
Is 5521243 approximately .5 million or 5.5 million?, because just as
you can write 5_521_243 to make the number more clear, you could write

... ... .foo();

to show it's 7 dots.

 Any other way than explicit naming is madness; leading to unreadable
 and unmaintainable code.

Not if implict naming (completely implicit, that is, so without any
indication of level even) is consistent in what it means. Currently,
things default to $_ in almost every place where a value is needed but
left out. I'd hate to see that change to some other variable for only a
portion of the operations now defaulting to $_.

Automatic binding of the invocant as $_ and the possibility to provide
your own name for the thing (either by specifying it in the signature or
by explicitly using the := operator) makes that .method defaulting to
working on $_ is not a problem.

A method's block shouldn't be too different from a given's block, or any
other closure for that matter. They should both topicalize using the
same semantics, IMO.


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


Re: -X's auto-(un)quoting?

2005-04-23 Thread Juerd
Matt Creenan skribis 2005-04-23 14:19 (-0400):
 Hm.. didn't really think of that.  Though, how often would that really  
 happen? 

Often -- this is exactly the same problem as Python has with its
significant indenting. Move code around and you have to manually adjust
it to the new levels. The problem with ..foo is less apparent because
you're likely to copy all the levels at once, and it's relative rather
than absolute.


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


Re: -X's auto-(un)quoting?

2005-04-23 Thread Matt Creenan
On Sat, 23 Apr 2005 14:21:06 -0400, Juerd [EMAIL PROTECTED] wrote:
Matt Creenan skribis 2005-04-23 14:19 (-0400):
Hm.. didn't really think of that.  Though, how often would that really
happen?
Often -- this is exactly the same problem as Python has with its
significant indenting. Move code around and you have to manually adjust
it to the new levels. The problem with ..foo is less apparent because
you're likely to copy all the levels at once, and it's relative rather
than absolute.
Juerd
Personally I'd never use 3 levels or above.  ..say or .say is it.   
Beyond that, I would start naming the topics.  Also, I would only use  
..say on quick and dirty code probably.

But why are we so keen on finding a way to save a few characters isntead  
of just naming the topic which leads to more readble code?  If it's not  
self-descriptive, I think it does more harm than good.


Re: -X's auto-(un)quoting?

2005-04-23 Thread Brano Tichý
 Personally I'd never use 3 levels or above.  ..say or .say is it.
 Beyond that, I would start naming the topics.  Also, I would only use
 ..say on quick and dirty code probably.

 But why are we so keen on finding a way to save a few characters isntead
 of just naming the topic which leads to more readble code?  If it's not
 self-descriptive, I think it does more harm than good.


then how about alias $OUTER::_ with $__ as a special exception?
it looks familiar (maybe too much), but as it would be used in quick and
dirty code,
there wouldn't be that much $_ to confuse it with.

or is $__ already taken?

brano tichy
[EMAIL PROTECTED]



Re: -X's auto-(un)quoting?

2005-04-23 Thread Rod Adams
Larry Wall wrote:
I suppose bare ^
is also available:
   given open 'mailto:[EMAIL PROTECTED]' {
   ^say(...);
   ^close or fail;
   }
That almost makes sense, given that $^a is like $_.  It also points vaguely
upward toward some antecedent.  I could maybe get used to that, if I
tried real hard for a long time.  Almost makes we wish we could rename
$_ to $^ though.  Hmm...
 

I like this.
Only I'd have C .foo  means C $_.foo  and C ^foo  mean C 
$self.foo , assuming $self is the first invocant.

Why swap them? because $_ is known for performing magical disappearing 
acts all over the place, and the ^ ties in with the $^x of parameters.

As for shortcuts to $OUTER::_, perhaps $-, if it's not put to some 
better usage, but anything beyond that is getting too obscure for common 
usage.

-- Rod Adams


Re: -X's auto-(un)quoting?

2005-04-22 Thread Michele Dondi
On Thu, 21 Apr 2005, Larry Wall wrote:
: perl -lne 'print if -e :q'
It seems to me that -e «$_» would handle most of these cases, as long as
whitespace always comes in quoted so that you always end up with one word.
I would say this is hardly the case for the kind of file lists I was 
referring to. Not that this is terribly relevant from a world wide 
perspective, I guess...

That seems more general than a special option to -X ops.
Speaking of which, I like to think of (some) adverbs in terms of cmd line 
switches, and maybe it's just me, but I think it would be extremely useful 
to have a full set of tricky ones providing reasonable defaults 
(user-overridable, of course), short enough to be easy to type; e.g:

unlink :warn; # roughly equivalent to Perl5's
# unlink or warn Could not remove `$_':$!\n;
Michele
--
Whoa! That is too weird! I asked around among the math
faculty here and it turns out that _every one's_ wife 
is married to a mathematician!
- Dave Rusin in sci.math, Re: Genetics and Math-Ability

Re: -X's auto-(un)quoting?

2005-04-22 Thread Larry Wall
On Fri, Apr 22, 2005 at 09:24:51AM +0200, Michele Dondi wrote:
: Speaking of which, I like to think of (some) adverbs in terms of cmd line 
: switches, and maybe it's just me, but I think it would be extremely useful 
: to have a full set of tricky ones providing reasonable defaults 
: (user-overridable, of course), short enough to be easy to type; e.g:
: 
: unlink :warn; # roughly equivalent to Perl5's
: # unlink or warn Could not remove `$_':$!\n;

The problem with that approach is also evident in Unix culture.
How many different ways are there to ask for help, or to get verbose
output, or to specify the output filename?  How many different ways
are there to specify input and output delimiters?  -e means something
very different to Perl than to rpm.  Does this version of chown use
-r or -R for recursion?

Admittedly, some of these problems would have been reduced if Unix
had gone with long option names to begin with.  But a lot of these
problems come from too many people in too many places inventing too many
similar things without the benefit of a culture that encourages a
common standard without forcing one.  In Perl culture we must guard
against the extremes of central control vs anarchy, and choose a middle
path.

And some of these things can be headed off by designing the interface
differently.  We wouldn't need a recursion option on chmod/chown/cp
etc.  if Unix had a notation for all the files under this one.
Similarly, if Perl has consistent warning and exception mechanisms
that are easy to use and properly scoped, people are less tempted to
make up one of their own.

All that being said, we did design named parameters into Perl 6 so that
an interface could have options.  But people are quick to add options
without thinking about the global consequences of name choice.  I feel
like there's a cultural solution there somewhere, but I don't know what
it is, because that's the sort of thing cultures are better at inventing
than I am.  :-)

Larry


Re: -X's auto-(un)quoting?

2005-04-22 Thread Juerd
Larry Wall skribis 2005-04-21 15:50 (-0700):
 There's one minor problem with -r -w $file, which is that it evaluates
 right-to-left, which is going to surprise some people who think they
 want to say
 -e -r $file
 when they really mean
 -r -e $file

It doesn't have to, of course. The test can be postponed and delegated
to the lexical first -X operator. A matter of letting -X behave
differently in -X context than in any other context, I guess. 

 Now the interesting thing about the ~~ approach is that it naturally
 lends itself to
 given $file {
   when :x {...}
   when :r:w   {...}
   when :r(0)  {...}
   when :u | :g{...}
   default:
 }
 I suppose it's a little bit rude to grab all the pairs for testing
 against all the strings, so maybe we have to say
 given $file.test {...}
 $file.test ~~ :r:w
 or maybe
 given $file.stat {...}
 $file.stat ~~ :r:w

Perfect!

 BTW, I'm assuming the $file is either $filename or $filehandle there.

Which brings me to the following: can open please use the same kind of
$file, so that open $filehandle just checks $filehandle's mode and
returns $filehandle again? That way, every library function that accepts
a filename automatically also accepts an open filehandle, which has a
thousand and one benefits.


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


Re: -X's auto-(un)quoting?

2005-04-22 Thread Matt
On Fri, 22 Apr 2005 14:24:25 -0400, Juerd [EMAIL PROTECTED] wrote:
Because a URI scheme ends in :. It http: followed by anything other than
// should fail because it is invalid, not fall back to file handling.
IFF you're handling URIs.
multi sub open ($u of Str where /^mailto:\/\//, [EMAIL PROTECTED]) 
returns
Handle  {...}
Well, it's mailto:[EMAIL PROTECTED], not mailto://[EMAIL PROTECTED]
True, I did not think of that.  But it can at least be defined for most  
URI schemes to check for ://, in the case of HTTP, FTP, etc.

We're talking about the *built-in* functions here, right?
Anyway, is there any other URI scheme besides for mailto: that doesn't use  
://?  mailto isn't something you can open really, for read at least.   
If it's for built-in, then only the most common protocols would be defined  
I imagine.  The ones I can think of that you can read from/stream in use  
://, so I don't see why the methods for those protocols can't be defined  
with ://.  Maybe I'm missing something here though.. which does happen a  
lot ;)

Also, I don't know much about rules with regex yet, but could you do
something like...
multi sub open ($u of Str where /protocol(file)/, [EMAIL PROTECTED]) 
returns
Handle {...}
Where  protocol(file)  expands to  file:// 
Yes, but it's probably easier to just use a hash: %protocolfile.
Easier or more efficient?


Re: -X's auto-(un)quoting?

2005-04-22 Thread Matt
On Fri, 22 Apr 2005 21:31:03 -0400, Larry Wall [EMAIL PROTECTED] wrote:
given open 'mailto:[EMAIL PROTECTED]' {
^say(...);
^close or fail;
}
That almost makes sense, given that $^a is like $_.  It also points  
vaguely
upward toward some antecedent.  I could maybe get used to that, if I
tried real hard for a long time.  Almost makes we wish we could rename
$_ to $^ though.  Hmm...

I think ^ makes the most sense.  I like how it points up.  Like it's  
saying HEY! THE TOPIC IS UP THERE!

Though, it IS still a bit odd. It seems more like a modifier on the  
function, than a reference to the topic.

What about . for each level up you want to go?
instead of 1.say, 2.say, 3.say
you use .say, ..say, ...say
(Ok, I'm just kidding.. really!)


Re: -X's auto-(un)quoting?

2005-04-22 Thread Mark Reed
 Anyway, is there any other URI scheme besides for mailto: that doesn't use
 ://? 
 
 It¹s optional for news:; news:comp.lang.perl is a valid URI for accessing that
 Usenet newsgroup via whatever your default news server is.
 
 There aren¹t any slashes in the aim: scheme (not part of the IANA standard,
 but widely supported for accessing AOL-compatible IM clients from web
 browsers).
 
 There are no slashes in tel: (telephone numbers), though I don¹t know what you
 could do with those from Perl. :)
 
 And I¹m sure there are others.  The syntax after the colon is pretty much
 arbitrarily determined by the scheme prefix, so a global constraint on it is a
 bad idea.
 
 -Mark



Re: -X's auto-(un)quoting?

2005-04-22 Thread Larry Wall
On Fri, Apr 22, 2005 at 09:09:21PM +0200, Juerd wrote:
: Matt skribis 2005-04-22 14:44 (-0400):
:  We're talking about the *built-in* functions here, right?
: 
: I don't know.
: 
:  Anyway, is there any other URI scheme besides for mailto: that doesn't use  
:  ://?
: 
: I don't know, but if you want to find this out,
: http://www.iana.org/assignments/uri-schemes is probably a good starting
: point.
: 
:  mailto isn't something you can open really, for read at least.   
: 
: No, but writing to it ought to simplify things :)
: 
: given open 'mailto:[EMAIL PROTECTED]' {
: .say(q0:to.
: Subject: Useful mailto open 
: User-Agent: Perl 6
: In-Reply-To: [EMAIL PROTECTED]
: 
: Hello, world!
: .
: );
: .close or fail;
: }

I should point out that we're still contemplating breaking .foo() so it
no longer means $_.foo().  I wish there were more keys on my keyboard...

I know it's a bit counter-cultural, but at the moment I'm wondering
if we can make this work instead:

given open 'mailto:[EMAIL PROTECTED]' {
_say(...);
_close or fail;
}

We do, after all, have better ways of declaring private methods and
functions now. so maybe we don't need to reserve _ for that anymore.
And it would save two characters over $_.foo().  But recovering C
programmers will scream, and probably prefer _.foo(), even if it only
saves one character.  Maybe it's time to raid Latin-1 for the next
closest thing to a dot, middle dot:

given open 'mailto:[EMAIL PROTECTED]' {
·say(...);
·close or fail;
}

But I'm sure some will argue that's too subtle.  (Hi, @LarryDamian.)

Well, hey, as long as we're looking at Latin-1, we could use superscripts
to indicate nested topic defaults.

given open 'mailto:[EMAIL PROTECTED]' {
say¹(...);
close¹ or fail;
}

Then foo² would be $OUTER::_.foo(), foo³ would be $OUTER::OUTER::_.foo().

Or we go back to .foo always meaning $_.foo and use ¹.foo to call the
first invocant, ².foo to call the second, ³.foo to call the third.
Interestingly, 1.foo, 2.foo, 3.foo etc. would work as ASCII workarounds
if we didn't autobox literal numbers.  Though that would put a crimp
in the Rubyish

3.times:{ say It's true! }

Okay, that's kinda nuts.  How 'bout we change ! to ¬ and then we can
say:

given open 'mailto:[EMAIL PROTECTED]' {
!say(...);
!close or fail;
}

Sigh.  We could also take ` away from user-defined literals and say

given open 'mailto:[EMAIL PROTECTED]' {
`say(...);
`close or fail;
}

But I rather like ` for user-defined literals.  I suppose bare ^
is also available:

given open 'mailto:[EMAIL PROTECTED]' {
^say(...);
^close or fail;
}

That almost makes sense, given that $^a is like $_.  It also points vaguely
upward toward some antecedent.  I could maybe get used to that, if I
tried real hard for a long time.  Almost makes we wish we could rename
$_ to $^ though.  Hmm...

:  If it's for built-in, then only the most common protocols would be defined  
:  I imagine.
: 
: No, if it's built in, we should stick to the spec and interpret every
: ^\w+: (roughly - see RFCs for syntax specifics) as a scheme.

Yes, especially the c: scheme.  :-)

Larry


Re: -X's auto-(un)quoting?

2005-04-22 Thread Matt
On Fri, 22 Apr 2005 15:09:21 -0400, Juerd [EMAIL PROTECTED] wrote:
Matt skribis 2005-04-22 14:44 (-0400):
mailto isn't something you can open really, for read at least.
No, but writing to it ought to simplify things :)
given open 'mailto:[EMAIL PROTECTED]' {
.say(q0:to.
Subject: Useful mailto open
User-Agent: Perl 6
In-Reply-To: [EMAIL PROTECTED]
   Hello, world!
.
);
.close or fail;
}
Good point, I didn't think of that :)  That would be awesome if you could  
do that in perl6 without needing any extra libraries.

What about ftp?
given open 'ftp://user:[EMAIL PROTECTED]:port' {
.say(q0:USER username
PASS password
);
.close or fail;
}
Though I'm not sure exactly how the FTP protocol works :)


Re: -X's auto-(un)quoting?

2005-04-22 Thread Mark A. Biggar
Larry Wall wrote:
I should point out that we're still contemplating breaking .foo() so it
no longer means $_.foo().  I wish there were more keys on my keyboard...
I know it's a bit counter-cultural, but at the moment I'm wondering
if we can make this work instead:
given open 'mailto:[EMAIL PROTECTED]' {
_say(...);
_close or fail;
}
We do, after all, have better ways of declaring private methods and
functions now. so maybe we don't need to reserve _ for that anymore.
And it would save two characters over $_.foo().  But recovering C
I kind of like that, but see below.
programmers will scream, and probably prefer _.foo(), even if it only
saves one character.  Maybe it's time to raid Latin-1 for the next
closest thing to a dot, middle dot:
given open 'mailto:[EMAIL PROTECTED]' {
·say(...);
·close or fail;
}
But I'm sure some will argue that's too subtle.  (Hi, @LarryDamian.)
I agree, too subtle.
Well, hey, as long as we're looking at Latin-1, we could use superscripts
to indicate nested topic defaults.
given open 'mailto:[EMAIL PROTECTED]' {
say¹(...);
close¹ or fail;
}
Then foo² would be $OUTER::_.foo(), foo³ would be $OUTER::OUTER::_.foo().
Or we go back to .foo always meaning $_.foo and use ¹.foo to call the
first invocant, ².foo to call the second, ³.foo to call the third.
Interestingly, 1.foo, 2.foo, 3.foo etc. would work as ASCII workarounds
if we didn't autobox literal numbers.  
Given I like _.foo(), we can get around the autobox problem by using 
_2.foo(), _3.foo, etc.  Even though those are legal(?) variable names 
I've never seen them used in code anywhere.

But I rather like ` for user-defined literals.  I suppose bare ^
is also available:
given open 'mailto:[EMAIL PROTECTED]' {
^say(...);
^close or fail;
}
This kind of works also.  And it would allow ^2.foo(), ^3.foo(), etc. or 
even ^^.foo(), ^^^.foo(), etc (nah!).

That almost makes sense, given that $^a is like $_.  It also points vaguely
upward toward some antecedent.  I could maybe get used to that, if I
tried real hard for a long time.  Almost makes we wish we could rename
$_ to $^ though.  Hmm...
Too late, maybe.
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]


Re: -X's auto-(un)quoting?

2005-04-22 Thread Larry Wall
On Fri, Apr 22, 2005 at 11:28:06AM +0200, Juerd wrote:
: Which brings me to the following: can open please use the same kind of
: $file, so that open $filehandle just checks $filehandle's mode and
: returns $filehandle again? That way, every library function that accepts
: a filename automatically also accepts an open filehandle, which has a
: thousand and one benefits.

You speak of open as if it must be a single function.  We're now
living in the age of MMD, so what you're asking for is a no-brainer.
If we decided to we could even do MMD with constraints:

multi sub open ($u of Str where /^file:/, [EMAIL PROTECTED]) returns Handle 
{...}
multi sub open ($u of Str where /^http:/, [EMAIL PROTECTED]) returns Handle 
{...}
multi sub open ($u of Str where /^ftp:/, [EMAIL PROTECTED]) returns Handle 
{...}
multi sub open ($u of Str where /^mailto:/, [EMAIL PROTECTED]) returns 
Handle {...}
...

Though that would potentially be problematic if you wanted to open
a file whose name started with http:, so we'd probably want to
give that suite of multis a different name.  Call it io() maybe, if
we can unify the Handle and IO abstractions.  As I've said before,
I kinda like the IO::All module, except for how it overloads  and .
But Perl 6 has == and == that can do that instead, which just happen
to be called pipes, strange coincidence.  :-)

Presumably you can write a slurp like this:

my $page == io(http://www.wall.org/~larry;);

Larry


Re: -X's auto-(un)quoting?

2005-04-22 Thread Matt
On Fri, 22 Apr 2005 11:42:10 -0400, Larry Wall [EMAIL PROTECTED] wrote:
You speak of open as if it must be a single function.  We're now
living in the age of MMD, so what you're asking for is a no-brainer.
If we decided to we could even do MMD with constraints:
multi sub open ($u of Str where /^file:/, [EMAIL PROTECTED]) returns Handle  
{...}
multi sub open ($u of Str where /^http:/, [EMAIL PROTECTED]) returns Handle  
{...}
multi sub open ($u of Str where /^ftp:/, [EMAIL PROTECTED]) returns Handle {...}
multi sub open ($u of Str where /^mailto:/, [EMAIL PROTECTED]) returns Handle  
{...}
...

Though that would potentially be problematic if you wanted to open
a file whose name started with http:, so we'd probably want to
give that suite of multis a different name.  Call it io() maybe, if
we can unify the Handle and IO abstractions.  As I've said before,
I kinda like the IO::All module, except for how it overloads  and .
But Perl 6 has == and == that can do that instead, which just happen
to be called pipes, strange coincidence.  :-)
Well why can't you define the functions like so:
	multi sub open ($u of Str where /^file:\/\//, [EMAIL PROTECTED]) returns Handle {...}
	multi sub open ($u of Str where /^http:\/\//, [EMAIL PROTECTED]) returns Handle {...}
	multi sub open ($u of Str where /^ftp:\/\//, [EMAIL PROTECTED]) returns Handle {...}
	multi sub open ($u of Str where /^mailto:\/\//, [EMAIL PROTECTED]) returns Handle  
{...}

Also, I don't know much about rules with regex yet, but could you do  
something like...

	multi sub open ($u of Str where /protocol(file)/, [EMAIL PROTECTED]) returns  
Handle {...}

Where  protocol(file)  expands to  file:// 




Re: -X's auto-(un)quoting?

2005-04-22 Thread Juerd
Matt skribis 2005-04-22 14:20 (-0400):
 Well why can't you define the functions like so:

Because a URI scheme ends in :. It http: followed by anything other than
// should fail because it is invalid, not fall back to file handling.
IFF you're handling URIs.

   multi sub open ($u of Str where /^mailto:\/\//, [EMAIL PROTECTED]) 
 returns 
   Handle  {...}

Well, it's mailto:[EMAIL PROTECTED], not mailto://[EMAIL PROTECTED]

 Also, I don't know much about rules with regex yet, but could you do  
 something like...
   multi sub open ($u of Str where /protocol(file)/, [EMAIL PROTECTED]) 
 returns  
 Handle {...}
 Where  protocol(file)  expands to  file:// 

Yes, but it's probably easier to just use a hash: %protocolfile.


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


Re: -X's auto-(un)quoting?

2005-04-22 Thread Juerd
Matt skribis 2005-04-22 14:44 (-0400):
 We're talking about the *built-in* functions here, right?

I don't know.

 Anyway, is there any other URI scheme besides for mailto: that doesn't use  
 ://?

I don't know, but if you want to find this out,
http://www.iana.org/assignments/uri-schemes is probably a good starting
point.

 mailto isn't something you can open really, for read at least.   

No, but writing to it ought to simplify things :)

given open 'mailto:[EMAIL PROTECTED]' {
.say(q0:to.
Subject: Useful mailto open 
User-Agent: Perl 6
In-Reply-To: [EMAIL PROTECTED]

Hello, world!
.
);
.close or fail;
}

 If it's for built-in, then only the most common protocols would be defined  
 I imagine.

No, if it's built in, we should stick to the spec and interpret every
^\w+: (roughly - see RFCs for syntax specifics) as a scheme.

 Also, I don't know much about rules with regex yet, but could you do
 something like...
 multi sub open ($u of Str where /protocol(file)/, [EMAIL PROTECTED]) 
  returns
 Handle {...}
 Where  protocol(file)  expands to  file:// 
 Yes, but it's probably easier to just use a hash: %protocolfile.
 Easier or more efficient?

Yes.


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


Re: -X's auto-(un)quoting?

2005-04-22 Thread Juerd
Larry Wall skribis 2005-04-22  8:42 (-0700):
 multi sub open ($u of Str where /^http:/, [EMAIL PROTECTED]) returns 
 Handle {...}
 Though that would potentially be problematic if you wanted to open
 a file whose name started with http:

open ./http://...;;
open file://$CWD/http://...;;

:)

In fact, I'm a big proponent of using URIs instead of filenames where
possible. It can even provide a more portable way of saying
\\sambaserver\share, in smb://sambaserver/share, which can be translated
to whatever the system supports, possibly failing because it's just not
supported.

 I kinda like the IO::All module, except for how it overloads  and .
 my $page == io(http://www.wall.org/~larry;);

IO used in this way denies that there's non-stream-based IO too.
Waiting for a certain wire to get shorted is input too, as is writing
directly to graphic memory a form of output.


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


Re: -X's auto-(un)quoting?

2005-04-22 Thread Larry Wall
On Fri, Apr 22, 2005 at 05:53:48PM +0200, Juerd wrote:
:  I kinda like the IO::All module, except for how it overloads  and .
:  my $page == io(http://www.wall.org/~larry;);
: 
: IO used in this way denies that there's non-stream-based IO too.

How so?  Where's the xor?

: Waiting for a certain wire to get shorted is input too, as is writing
: directly to graphic memory a form of output.

I don't see how an IO is prevented from being used like any other
handle.  The handle type is there so MMD can pick out particular
behaviors for == and syswrite().  And different subtypes of handles
can pick out different behaviors.  Even the OS can keep track of
the types of file descriptors that are just integers as far as the
user is concerned.

Larry


Re: -X's auto-(un)quoting?

2005-04-22 Thread Juerd
Larry Wall skribis 2005-04-22  9:47 (-0700):
 :  my $page == io(http://www.wall.org/~larry;);
 : IO used in this way denies that there's non-stream-based IO too.
 How so?  Where's the xor?

Good point.


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


Re: -X's auto-(un)quoting?

2005-04-21 Thread Larry Wall
On Thu, Apr 21, 2005 at 10:18:17AM +0200, Michele Dondi wrote:
: Are the -X functions still going to be there? I definitely hope so! 

Certainly.  They're useful, and one of the things people love about Perl.
In fact, we're enhancing them to be stackable, so you can say

if -r -w -x $filename {...}

to and the conditions.  Or maybe there's a better solution to that
now that we have junctions, on the order of

if $filename ~~ -r  -w  -x {...}

Then we also get our or for free.  We'd just say that ~~ binds
the default of -X just as it does m// or s///.

The only fly in the ointment is that this is awfully ambiguous because
-X is a unary operator looking for an argument, and you're not giving
it one.  But it might think the next thing is a sub ref starting with ''.
Ouch.  Not sure where to go with that, other than require space or parens
when ambiguous.

: However, to come to the actual question, it has happened to me to have to 
: do, in perl5 that is:
: 
: perl -lne 's/^//;s/$//;print if -e'
: 
: or (less often)
: 
: perl -lne '$o=$_;s/^//;s/$//;print $o if -e'
: 
: 
: Ok: no much harm done (to my fingertips). But then, talking about 
: huffmanization, could a standard adverb be provided for -X's to the effect 
: of specifying that the passed filename is quoted, say in double (or if 
: sensible in single) quotes: for I find that to be a common filelist 
: format. Ideally, what I'd like to do is
: 
: perl -lne 'print if -e :q'

It seems to me that -e «$_» would handle most of these cases, as long as
whitespace always comes in quoted so that you always end up with one word.
That seems more general than a special option to -X ops.

Larry


Re: -X's auto-(un)quoting?

2005-04-21 Thread Juerd
Larry Wall skribis 2005-04-21  8:54 (-0700):
 if $filename ~~ -r  -w  -x {...}

Just curious - would the following dwym?

if (prefix:-r  prefix:-w  prefix:-x)($filename) { ... }

 It seems to me that -e «$_» would handle most of these cases, as long as
 whitespace always comes in quoted so that you always end up with one word.
 That seems more general than a special option to -X ops.

Wouldn't it be a good option to combine the filetest operators into one
operator? It'd even be historically correct to call that test:

test(:r  :w, $fn);

I still like -r -w $fn much better than the binding and the ~~ things.


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


Re: -X's auto-(un)quoting?

2005-04-21 Thread Larry Wall
On Thu, Apr 21, 2005 at 06:40:54PM +0200, Juerd wrote:
: Larry Wall skribis 2005-04-21  8:54 (-0700):
:  if $filename ~~ -r  -w  -x {...}
: 
: Just curious - would the following dwym?
: 
: if (prefix:-r  prefix:-w  prefix:-x)($filename) { ... }

It might do what you mean.  Personally, I would never mean that if I
could help it.  :-)

:  It seems to me that -e «$_» would handle most of these cases, as long as
:  whitespace always comes in quoted so that you always end up with one word.
:  That seems more general than a special option to -X ops.
: 
: Wouldn't it be a good option to combine the filetest operators into one
: operator? It'd even be historically correct to call that test:
: 
: test(:r  :w, $fn);

Hmm.  I think this works syntactically:

$file ~~ all(:r:w)

: I still like -r -w $fn much better than the binding and the ~~ things.

There's one minor problem with -r -w $file, which is that it evaluates
right-to-left, which is going to surprise some people who think they
want to say

-e -r $file

when they really mean

-r -e $file

But that doesn't really matter much unless you're so much into speed
that you think about falsifying the test without doing a stat().

Now the interesting thing about the ~~ approach is that it naturally
lends itself to

given $file {
when :x {...}
when :r:w   {...}
when :r(0)  {...}
when :u | :g{...}
default:
}

I suppose it's a little bit rude to grab all the pairs for testing
against all the strings, so maybe we have to say

given $file.test {...}
$file.test ~~ :r:w

or maybe

given $file.stat {...}
$file.stat ~~ :r:w

which leaves room for lstat if we need it, though I can't say I'm fond
of the Unix naming scheme here.  If we borrow from IO::All maybe it's just:

given io($file) {...}
io($file) ~~ :r:w

BTW, I'm assuming the $file is either $filename or $filehandle there.

Larry