Re: can a method name contain a funny character?

[yary]

Thanks for the in-depth analysis. My misunderstanding was about what an
identifier considers a number; I have no well-thought-out ideas on the
subject of what an identifier ought to be.

Having the docs mention that "number" means only characters with a Unicode
Property GeneralCategory of Nd might have prevented me from looking through
the NumericTypes for a pattern. With more experimenting, I might have
noticed that De was the one that always worked, since De has a one-to-one
correspondence with Nd...

-y

Re: can a method name contain a funny character?

[Larry Wall]

On Fri, May 20, 2016 at 09:39:30AM -0400, yary wrote:
: On Tue, Apr 12, 2016 at 6:12 PM, Brandon Allbery 
: wrote:
: > I was explaining why some "symbols" are acceptable to the parser. Which
: one
: > is more appropriate is not my call,
: 
: I was thinking about what exactly are valid identifiers in Perl6/rakudo's
: implementation. The docs 
: say:
: 
: An identifier is a primitive name, and must start with an alphabetic
: character (or an underscore), followed by zero or more word characters
: (alphabetic, underscore or number). You can also embed dashes - or single
: quotes ' in the middle, but not two in a row.

At this point, "number" means only characters with a GeneralCategory
of Nd.  We could talk about generalizing that, but there are potential
issues.  We can't simply extend it to No characters, because then

pi²

would misparse as a 3-character identifier.

: Experimenting with some of the numeric codes from Wikipedia
: , some of the numeric
: codes seem inconsistent-

Note that, even if we used this table, we could not distinguish ² from ② and 
such.

: > my $_६೬ퟨ = ६೬ퟨ # "De" Devanagari, Kannada, Mathematical. "De" is all
: good.
: 666

That's fine, those work because of the Nd general property, so they're 
equivalent
to 0..9 as far as we're concerned.

: > my $x六 = 6 #  "Nu" Han number 6
: 6
: >  say 六
: ===SORRY!=== ...

Note that 六 works in identifiers by virtue of being not numeric at all,
but by being in general category Lo, that is, it's a "letter other",
so considered alphabetic.

: > say ௰  # "Nu" Tamil number 10
: 10
: > my $x௰ = 5
: ===SORRY!=== Error ...

Excluded because it's No, not Nd.

: > say ① + 3 # "Di" 1 in typographic context has value 1
: 4
: > my $b① = 44 "Di" 1 not valid in identifier
: ===SORRY!=== Error ...

① is indistinguishable from superscripts, even by "Di", and falls into
the No general category, so excluded.

: Some numeric codepoints are recognized as such, yet Rakudo isn't allowing
: them in identifiers. Especially confounding is the treatment of the "Han
: number 6" and "Tamil number 10", both of which are unicode "Nu" numeric.
: The Tamil is recognized as a number on its own but not as an identifier;
: the Han is allowed in an identifier but isn't recognized as a number!

We currently rely only on GeneralCategory.  I don't believe we use
NumericType anywhere in parsing Perl 6.

: Is there some deeper rule at work here- which could be added to the
: documentation? Or are these bugs?

Not a bug, but potentially negotiable.  It simply comes down to Nd vs
No at the moment.  One could argue that we could notice superscripts
as a separate category and treat them differently, but there are two
arguments against that.

The first is that we'd like to keep the basic identifier rules fairly
simple.  We're already pushing the state of the art here, and I don't
see much benefit in making the rules more arcane that they are.

The second argument is that we should probably reserve syntax for the
user here.  Once we get slangs fully hooked up, we can easily let users
define identifiers to include ①  and such.  But it's just as likely,
perhaps more likely, that the user will want to use ①  for a postfix,
just like we currently treat superscripts as powers.  We can't guess
(well, we *could* guess, but can't know) which way the user will want to
use these, so the conservative approach is to make neither of them work,
and let the user take an additive approach, rather than forcing them to
use a subtractive approach if we guessed wrong.

Larry

Re: can a method name contain a funny character?

[yary]

To be clear, I expect that "number" in "followed by zero or more word
characters (alphabetic, underscore or number)" means "if Unicode thinks
it's numeric, you can use it in an identifier after the first character."

I don't expect that every numeric codepoint in Unicode must evaluate to
number in the Perl6 settings. We can have Numeric::Roman,
Numeric::Counting-Rod, Numeric::Euler etc. for those, if someone cares
enough to write & use them.

Re: can a method name contain a funny character?

[yary]

On Tue, Apr 12, 2016 at 6:12 PM, Brandon Allbery 
wrote:
> I was explaining why some "symbols" are acceptable to the parser. Which
one
> is more appropriate is not my call,

I was thinking about what exactly are valid identifiers in Perl6/rakudo's
implementation. The docs 
say:

An identifier is a primitive name, and must start with an alphabetic
character (or an underscore), followed by zero or more word characters
(alphabetic, underscore or number). You can also embed dashes - or single
quotes ' in the middle, but not two in a row.


Experimenting with some of the numeric codes from Wikipedia
, some of the numeric
codes seem inconsistent-

> my $_६೬ퟨ = ६೬ퟨ # "De" Devanagari, Kannada, Mathematical. "De" is all
good.
666

> my $x六 = 6 #  "Nu" Han number 6
6
>  say 六
===SORRY!=== ...
> say ௰  # "Nu" Tamil number 10
10
> my $x௰ = 5
===SORRY!=== Error ...

> say ① + 3 # "Di" 1 in typographic context has value 1
4
> my $b① = 44 "Di" 1 not valid in identifier
===SORRY!=== Error ...

Some numeric codepoints are recognized as such, yet Rakudo isn't allowing
them in identifiers. Especially confounding is the treatment of the "Han
number 6" and "Tamil number 10", both of which are unicode "Nu" numeric.
The Tamil is recognized as a number on its own but not as an identifier;
the Han is allowed in an identifier but isn't recognized as a number!

Is there some deeper rule at work here- which could be added to the
documentation? Or are these bugs?

-y

[perl6/specs] 33eaff: Update Supply introduction and method docs for ser...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: 33eaffeb784e1f2b61511b727ef614615df6bca8
  
https://github.com/perl6/specs/commit/33eaffeb784e1f2b61511b727ef614615df6bca8
  Author: skids <b...@abrij.org>
  Date:   2016-02-25 (Thu, 25 Feb 2016)

  Changed paths:
M S17-concurrency.pod

  Log Message:
  ---
  Update Supply introduction and method docs for serial supplies

   Also some Channel clarifications.


  Commit: cc534c403199b0804fe05bd5cb88676142a878a1
  
https://github.com/perl6/specs/commit/cc534c403199b0804fe05bd5cb88676142a878a1
  Author: skids <b...@abrij.org>
  Date:   2016-02-26 (Fri, 26 Feb 2016)

  Changed paths:
M S17-concurrency.pod

  Log Message:
  ---
  A start on design doc for react/supply blocks and whenever clauses

  This will need quite more work.


Compare: https://github.com/perl6/specs/compare/b10af0c10726...cc534c403199

[perl6/specs] 627f2a: Fix - vs . method call typo in S17

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: 627f2a8ad12039b31159b88e4f4a50f45c7e6845
  
https://github.com/perl6/specs/commit/627f2a8ad12039b31159b88e4f4a50f45c7e6845
  Author: Rob Hoelz r...@hoelz.ro
  Date:   2014-12-24 (Wed, 24 Dec 2014)

  Changed paths:
M S17-concurrency.pod

  Log Message:
  ---
  Fix - vs . method call typo in S17

[perl6/specs] e15acb: Re-purpose the method ^foo(...) { ... } syntax.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: e15acbc12ed5c800c3c905faecb450c28bf16535
  
https://github.com/perl6/specs/commit/e15acbc12ed5c800c3c905faecb450c28bf16535
  Author: Jonathan Worthington jn...@jnthn.net
  Date:   2014-12-17 (Wed, 17 Dec 2014)

  Changed paths:
M S12-objects.pod

  Log Message:
  ---
  Re-purpose the method ^foo(...) { ... } syntax.

The existing design of it was out of line with the way Perl 6 evolved
since then, and also not especially useful. This takes the syntax and
enables its use for per-type meta-behavior specialization. This, as a
special case, allows attaching extra metadata to the meta-object,
which captures some aspect of what the syntax was originally specified
to do. However, it maintains the distinction between objects and their
meta-objects more strongly, which also fits better with the overall
Perl 6 design.

[perl6/specs] 8c901d: Refer to .content method for Pod blocks rather tha...

[GitHub]

  Branch: refs/heads/S26
  Home:   https://github.com/perl6/specs
  Commit: 8c901dcd5254f07ed76c8363cf3a71c4dbe68c50
  
https://github.com/perl6/specs/commit/8c901dcd5254f07ed76c8363cf3a71c4dbe68c50
  Author: Rob Hoelz r...@hoelz.ro
  Date:   2014-07-15 (Tue, 15 Jul 2014)

  Changed paths:
M S26-documentation.pod

  Log Message:
  ---
  Refer to .content method for Pod blocks rather than .contents

[perl6/specs] f143d1: Supply.(zip|merge) can be called as class method

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: f143d1a0644a28e1bd63aeb990f2f95f2ea33f47
  
https://github.com/perl6/specs/commit/f143d1a0644a28e1bd63aeb990f2f95f2ea33f47
  Author: Elizabeth Mattijsen l...@dijkmat.nl
  Date:   2014-04-20 (Sun, 20 Apr 2014)

  Changed paths:
M S17-concurrency.pod

  Log Message:
  ---
  Supply.(zip|merge) can be called as class method

[perl6/specs] 379579: [S05] Reintroduce the .ast method.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: 3795799fb83bd4b68eaa5bfeab4db2fd575519d0
  
https://github.com/perl6/specs/commit/3795799fb83bd4b68eaa5bfeab4db2fd575519d0
  Author: lue rnd...@gmail.com
  Date:   2014-03-12 (Wed, 12 Mar 2014)

  Changed paths:
M S05-regex.pod

  Log Message:
  ---
  [S05] Reintroduce the .ast method.

Every good language has a few synonyms anyway :) .

[perl6/specs] 24373d: Rename .ast method to .made

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: 24373dc4ddedc05b6ddac603e03343931c720b4c
  
https://github.com/perl6/specs/commit/24373dc4ddedc05b6ddac603e03343931c720b4c
  Author: Elizabeth Mattijsen l...@dijkmat.nl
  Date:   2014-02-03 (Mon, 03 Feb 2014)

  Changed paths:
M S02-bits.pod
M S05-regex.pod

  Log Message:
  ---
  Rename .ast method to .made

This makes much more sense when paired with make.  It also makes the generic
examples of make that jnthn++ used in his

  http://jnthn.net/papers/2014-fosdem-perl6-today.pdf

(slide #24 and following) much more sensible to naive, or even experienced
Perl 6 users.  Perhaps the .ast method should be kept as a synonym for .made,
and may even have a check for AST-nodeness added, to give it additional
implicit documentational value in the Perl 6 internals.

Please note that this has bugged me since the Rakudo and NQP Internals workshop
last September.  It came back to me in full force after seeing jnthn++'s talk.

[perl6/specs] ae7cf3: Define .narrow method to narrow numeric types

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: ae7cf355db859aa8782533ce7cd25378b219fd57
  
https://github.com/perl6/specs/commit/ae7cf355db859aa8782533ce7cd25378b219fd57
  Author: Larry Wall la...@wall.org
  Date:   2013-12-28 (Sat, 28 Dec 2013)

  Changed paths:
M S32-setting-library/Numeric.pod

  Log Message:
  ---
  Define .narrow method to narrow numeric types

Can narrow either Rat or Num to Int, for instance.
Resolves #47.

[perl6/specs] 29e1f7: Change use of .elems on Set/Bag/Mix to new method ...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: 29e1f757937ef0d15dc0c57bf7bd3b7ea5363504
  
https://github.com/perl6/specs/commit/29e1f757937ef0d15dc0c57bf7bd3b7ea5363504
  Author: Elizabeth Mattijsen l...@dijkmat.nl
  Date:   2013-10-03 (Thu, 03 Oct 2013)

  Changed paths:
M S32-setting-library/Containers.pod

  Log Message:
  ---
  Change use of .elems on Set/Bag/Mix to new method .total

[perl6/specs] 41296c: [S12]: bless is a method, not a function

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: 41296cb4ea8296100848dd8c742e34148314d514
  
https://github.com/perl6/specs/commit/41296cb4ea8296100848dd8c742e34148314d514
  Author: Moritz Lenz mor...@faui2k3.org
  Date:   2013-08-25 (Sun, 25 Aug 2013)

  Changed paths:
M S12-objects.pod

  Log Message:
  ---
  [S12]: bless is a method, not a function

[perl6/specs] 0cca60: round method produces a Real, not always Int

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: 0cca600925867743b3b7c5126335145f89090bb9
  
https://github.com/perl6/specs/commit/0cca600925867743b3b7c5126335145f89090bb9
  Author: Brent Laabs bsla...@gmail.com
  Date:   2013-06-23 (Sun, 23 Jun 2013)

  Changed paths:
M S32-setting-library/Numeric.pod

  Log Message:
  ---
  round method produces a Real, not always Int
provided a better description of what the specced algorithm actually does

[perl6/specs] b49be3: Remove mention of .exists method from example, rep...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: b49be302000f0c1bfab96c70126d13d2483f867e
  
https://github.com/perl6/specs/commit/b49be302000f0c1bfab96c70126d13d2483f867e
  Author: Elizabeth Mattijsen l...@dijkmat.nl
  Date:   2013-06-20 (Thu, 20 Jun 2013)

  Changed paths:
M S11-modules.pod

  Log Message:
  ---
  Remove mention of .exists method from example, replace by :exists adverb

[perl6/specs] 01c9f4: Added some identical method based examples, seemed...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: 01c9f446e782d6fdb40567aae1aeeeaf0de0b807
  
https://github.com/perl6/specs/commit/01c9f446e782d6fdb40567aae1aeeeaf0de0b807
  Author: Elizabeth Mattijsen l...@dijkmat.nl
  Date:   2013-06-15 (Sat, 15 Jun 2013)

  Changed paths:
M S32-setting-library/Containers.pod

  Log Message:
  ---
  Added some identical method based examples, seemed appropriate

[perl6/specs] 5faf89: [S02] Small clarification about method .tree

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: 5faf8960fd051cbefbaf07ae51366d3cab5da3c4
  
https://github.com/perl6/specs/commit/5faf8960fd051cbefbaf07ae51366d3cab5da3c4
  Author: lue rnd...@gmail.com
  Date:   2013-06-10 (Mon, 10 Jun 2013)

  Changed paths:
M S02-bits.pod

  Log Message:
  ---
  [S02] Small clarification about method .tree

Make it clear that the phrase level-sensitive map refers to the
specific Cmap function/method, as opposed to some general concept of a
map.

[perl6/specs] 18c244: Replace mention of now defunct .file method by de-...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: 18c24443c4f65cd58f74bef9f153e068a19beab4
  
https://github.com/perl6/specs/commit/18c24443c4f65cd58f74bef9f153e068a19beab4
  Author: Elizabeth Mattijsen l...@dijkmat.nl
  Date:   2013-04-09 (Tue, 09 Apr 2013)

  Changed paths:
M S03-operators.pod

  Log Message:
  ---
  Replace mention of now defunct .file method by de-facto .path

[perl6/specs] b1c338: add combinations method

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: b1c33865fd5d2da6935f2eea01a2279a149aa68f
  
https://github.com/perl6/specs/commit/b1c33865fd5d2da6935f2eea01a2279a149aa68f
  Author: Larry Wall la...@wall.org
  Date:   2013-02-16 (Sat, 16 Feb 2013)

  Changed paths:
M S32-setting-library/Containers.pod

  Log Message:
  ---
  add combinations method

Re: The .trans method and Least Surprise

[Carl Mäsak]

yary ():
 Speaking as a non-p6-coder proposal sounds good to me though the
 spec raises some other questions.

The tr/// quote-like operator now also has a method form called
 trans(). Its argument is a list of pairs. You can use anything
 that produces a pair list:

 $str.trans( %mapping.pairs );

 Does Perl 6 guarantee the order in which pairs are returned from a
 hash? If not, then the following code won't always return the same
 thing:

 my %mapping = 'a' = 'x', 'x' = 'b'; say 'ax'.trans(%mapping);

Perl 6 does not guarantee any particular order in which pairs are
returned from a hash. However, this is a non-issue with .trans, since
.trans doesn't care about the order.

Not sure how clear it is from the spec, but .trans traverses things in
*one* pass. That's the idea of it. So there's no conflict in the above
example. 'a' goes to 'x' and 'x' goes to 'b', regardless of pair
ordering.

See 
http://perl6advent.wordpress.com/2010/12/21/day-21-transliteration-and-beyond/
for deeper delvings into this.

Even if I didn't see reasons why .trans shouldn't care about hash key
ordering on the grounds of what it is in Perl 6, I would still be
against it on the grounds of it being based on tr/// in Perl 5, which
is on-pass and doesn't care about the ordering of characters on the
left.

 It might say 'bb' or 'xb', depending on how the pairs are returned.
 That might be considered a programmer's error, but it seems
 less-than-optimal that these two lines have the same result in my
 somewhat dated Rakudo install:

 say 'ax'.trans(a = x, x = b)
 xb
 say 'ax'.trans(x = b, a = x)
 xb

 - even if it is completely in accord with spec.

No. As above.

Perl 5 agrees:

$ perl -wle '$_ = ax; tr/ax/xb/; print'
xb
$ perl -wle '$_ = ax; tr/xa/bx/; print'
xb

 And since mapping is a hash, it prevents a series of transl{ations
 iterations} with the same from in a single call.

And that's a feature.

If you want a series of translations, make a series of .trans calls.
(Unless my proposal goes through, in which case you should make a
series of .translate calls.)

// Carl

The .trans method and Least Surprise

[Carl Mäsak]

Something's bothering me about the .trans method. This email lists a
proposal to split its semantics into two methods.

I'm not yet convinced myself about this proposal. It's quite late in
the game to make spec changes of established methods, and the change
will break some downstream application code, some of which I wrote. So
if the advantages don't come shining through, I will withdraw my
proposal. But I thought I would make a case for it and see what people
think of it.

Here's the .trans spec:

 http://perlcabal.org/syn/S05.html#Transliteration

Summary of the spec: .trans does what tr/// does (in Perl 5, and Perl
6). .trans also does a bunch of cool stuff with strings and regexes
and Longest-Token Matching that tr/// never did.

My proposal is to split away the cool stuff with strings and regexes
and LTM into its own method.

For purposes of concreteness, I will call this proposed method
.translate -- name proposals are allowed in the thread and on the
#perl6 channel, but in order to reduce bikeshedding, proposals without
a rationale will be ignored. Also note that the discussion is not
primarily about the name, but about the split itself.

Here are my reasons for the split:

* The spec literally goes from saying that the tr/// operator has a
method form, to overloading this method form with features that are
not in tr///. The method is showing signs of lack of cohesion.

* I use the more advanced features frequently, and they're great for
parallel, one-pass substitution of substrings. They're an improvement
over Perl 5's corresponding features. I don't want them to go away,
just to separate them into their own method.

* Linguistically, trans*literation* (which is what Ctr stands for)
is about replacing individual characters. Substituting bigger chunks
is a kind of translation.

* Over the years, I've seen people struggling with the API of .trans,
which is for all intents and purposes two separate APIs: one involving
pairs of strings, and one involving pairs of Positional (spec says
Array). Something about the whole thing violates Least Surprise. This
whole email was prompted by my having to check the spec for the
umpteenth time and realizing that the API simply doesn't vibe with me.
Splitting up the two separate APIs into two methods would help.

* The more advanced parts of the current API -- the ones that allow
the right hand sides of pairs to be regexes or closures -- could be
migrated out along with the pairs-of-Positional API. Then the .trans
method would be left to handle *only* the things that tr/// handles,
and the .translate method could do the cool stuff.

* .trans could then have specially optimized code which does one-char
substitution efficiently. Though we're not there yet, because of the
cool stuff that I propose to move out into .translate, the plans for
an efficient implementation of .trans involve somehow generating a
grammar on-the-fly and then running it on the string to be
substituted. This seems like extreme overkill for tr///.

Have these things been bothering any of you too? Does the split make
sense? Would it help us to simplify the API and make people Less
Surprised by it? Are the projected wins of the spec change worth the
upsetting of the ecosystem?

Hopefully,
// Carl

Re: The .trans method and Least Surprise

[yary]

Speaking as a non-p6-coder proposal sounds good to me though the
spec raises some other questions.

The tr/// quote-like operator now also has a method form called
 trans(). Its argument is a list of pairs. You can use anything
 that produces a pair list:

 $str.trans( %mapping.pairs );

Does Perl 6 guarantee the order in which pairs are returned from a
hash? If not, then the following code won't always return the same
thing:

my %mapping = 'a' = 'x', 'x' = 'b'; say 'ax'.trans(%mapping);

It might say 'bb' or 'xb', depending on how the pairs are returned.
That might be considered a programmer's error, but it seems
less-than-optimal that these two lines have the same result in my
somewhat dated Rakudo install:

 say 'ax'.trans(a = x, x = b)
xb
 say 'ax'.trans(x = b, a = x)
xb

- even if it is completely in accord with spec.

And since mapping is a hash, it prevents a series of transl{ations
iterations} with the same from in a single call.
trans('A..J'='0..9', 'a..z'='A..Z', 'A..J'='zyxjihcba');
- which is a contrived example that could be rewritten to avoid the
clash, but it shows the idea.

So if you're going to alter the spec, I suggest changing the method
from accepting a hash of pairs, to accepting an array of pairs.

I still really like the idea of passing 'from' = 'to' as a pair, and
think even 'subst' should accept a pair because it looks good in the
source!

[perl6/specs] 578e3c: [S04] un-spec method-level PRE/POST

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: 578e3cbf3189098e7e854d6222905218d7e67ebc
  
https://github.com/perl6/specs/commit/578e3cbf3189098e7e854d6222905218d7e67ebc
  Author: Carl Masak cma...@gmail.com
  Date:   2012-03-11 (Sun, 11 Mar 2012)

  Changed paths:
M S04-control.pod

  Log Message:
  ---
  [S04] un-spec method-level PRE/POST

The intent was to extend block-level PRE/POST to something that could
do Eiffel-style Design-by-Contract assertions. This is an intriguing
idea, but not in the way the spec outlined it. See
http://www.nntp.perl.org/group/perl.perl6.language/2012/03/msg34803.html
for details.

[perl6/specs] 315449: spec method form of make

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: 3154497284681b416b68b174be028a97fd9c7b67
  
https://github.com/perl6/specs/commit/3154497284681b416b68b174be028a97fd9c7b67
  Author: Moritz Lenz mor...@faui2k3.org
  Date:   2012-02-03 (Fri, 03 Feb 2012)

  Changed paths:
M S05-regex.pod

  Log Message:
  ---
  spec method form of make

the sub form just looks up whatever $/ it finds, which makes
it unnecessary hard to work with multiple match objects at once,
for example when doing regex matches in action methods

[perl6/specs] 8a9969: [S06] avoid indirect method call syntax

[noreply]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs

  Commit: 8a99698d298576ce3ea9405c7c9af1aebd8fbf0c
  
https://github.com/perl6/specs/commit/8a99698d298576ce3ea9405c7c9af1aebd8fbf0c
  Author: Moritz Lenz mor...@faui2k3.org
  Date:   2011-12-27 (Tue, 27 Dec 2011)

  Changed paths:
M S06-routines.pod

  Log Message:
  ---
  [S06] avoid indirect method call syntax

It is unrelated to the topic, and seem to confuse readers. Me too.

[perl6/specs] e1c674: Add conjugate method (for RT 76602)

[noreply]

Branch: refs/heads/master
Home:   https://github.com/perl6/specs

Commit: e1c674c451ea3cd2c07355b96ffca02d02423d60

https://github.com/perl6/specs/commit/e1c674c451ea3cd2c07355b96ffca02d02423d60
Author: Dave Whipp dwh...@google.com
Date:   2011-03-02 (Wed, 02 Mar 2011)

Changed paths:
  M S32-setting-library/Numeric.pod

Log Message:
---
Add conjugate method (for RT 76602)

Method 'Bool' not found for invocant of class 'Integer'

[Nathaniel]

OK: I get this message when running a .pir file from an embedded
parrot interpreter, but not when I actually call parrot from a command
line.  My guess is that there is perhaps a .pbc file missing from the
area where I have set up a runtime directory structure mimicking the
rakudo release, but I've tried copying everything over and I can't
seem to find what is present in the rakudo directory but not in the
one for my executable.  Is there some c method I can call to point a
parrot interpreter at a particular runtime directory -- like the same
one as rakudo/perl6 itself uses?

[perl6/specs] 61e2e1: copy-paste issues with new roll method

[noreply]

Branch: refs/heads/master
Home:   http://github.com/perl6/specs

Commit: 61e2e1a1f54bb0fbefbdd932d95f28f3df2a172e

http://github.com/perl6/specs/commit/61e2e1a1f54bb0fbefbdd932d95f28f3df2a172e
Author: TimToady la...@wall.org
Date:   2010-09-16 (Thu, 16 Sep 2010)

Changed paths:
  M S32-setting-library/Containers.pod

Log Message:
---
copy-paste issues with new roll method

jkpeters_37++ points out a problem in the new specs for .roll, which
are now revised for (I hope) more clarity.

Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another

[Michael Zedeler]

On 2010-07-31 20:23, Carl Mäsak wrote:

* Today we discovered that it's possible to break encapsulation by
detaching a method from an object of one class, and calling that
method on an object of another class. Which means that breaking the
encapsulation of a foreign class is as easy as creating a custom class
with all of the same private attributes, and with a method to print
(or otherwise reveal) them.

* It is my feeling that such encapsulation-breakage shouldn't be
allowed. Do you agree, p6l?
   
I don't really agree. The way OOP is implemented in perl 5 allows 
breaking encapsulation on many different levels, but I believe this has 
turned out to be a strength, since it allows you to use in those (very 
rare?) cases where it is needed.


When I found that all objects in perl 6 had fields, I was kind of put 
off, since it looked to Java-ish. What saves the spirit of perl is that 
people are still free to hack away (and then there are such roles as 
postcircumflex that reintroduces the very terse syntax, perl 5 is known 
for, avoiding the dot-hell of Java).


I believe we have a much larger task at hand, which is to write 
documentation that educates newcomers to use the right tools for the 
right job. I'd never recommend monkeypatching to a rookie programmer (or 
those silly .* and .+ method invocators) and I believe we owe people 
outside the perl community to explain the /intent/ behind the different 
constructs.


Regards,

Michael.

Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another

[Carl Mäsak]

jnthn++ points out in meatspace that the invocant parameter has a
constraint (by spec but not in Rakudo), which will carry over to the
new class. Which means that only objects of child classes will
signature-bind anyway.

// Carl

Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another

[Moritz Lenz]

Carl Mäsak wrote:
 * It is my feeling that such encapsulation-breakage shouldn't be
 allowed. Do you agree, p6l?

Time may proof me wrong, but I think it's not such a big issue.

Note that encapsulation can be broken in many ways already, wither with
MONKEY_TYPING or by using introspection techniques (which aren't fully
specced yet, but they *will* exist. In case of doubt you can just parse
.perl output).

 * If it isn't allowed, which of the two steps is disallowed?
 *Detaching* a method containing references to private accessor slots
 (thereby extending the syntactic restriction of no private accessors
 outside of the class block), or *attaching* an anonymous method to an
 object belonging to a different class than the one from which it was
 detached (thereby by necessity having to complicate anonymous methods
 somewhat)?

There's a third possiblity - $!foo being bound to the $!foo attribute of
the lexically enclosing class at compile-time. So that re-attaching
methods make them still refer to the old attribute. Not sure if it's a
good idea, just food for thought.

Cheeers,
Moritz
-- 
Moritz Lenz
http://perlgeek.de/ |  http://perl-6.de/ | http://sudokugarden.de/

Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another

[Carl Mäsak]

Carl (), Moritz ():
 * If it isn't allowed, which of the two steps is disallowed?
 *Detaching* a method containing references to private accessor slots
 (thereby extending the syntactic restriction of no private accessors
 outside of the class block), or *attaching* an anonymous method to an
 object belonging to a different class than the one from which it was
 detached (thereby by necessity having to complicate anonymous methods
 somewhat)?

 There's a third possiblity - $!foo being bound to the $!foo attribute of
 the lexically enclosing class at compile-time. So that re-attaching
 methods make them still refer to the old attribute. Not sure if it's a
 good idea, just food for thought.

That's indeed what Stefan proposed as well, and what I currently
believe to be the right way of looking at this. The fact that you
don't mention an error condition in connection to the accessing of the
old attribute makes me realize yet another thing:

class Parent { has $!a; method foo { say $!a } }
class Child is Parent { has $!a }

my $child = Child.new( :a(42), Parent{ :a(5) } );
my $parent-foo = Parent.^can('foo');
$child.$parent-foo(); # works, prints 5\n

Or, in words, just because one detaches/re-attaches a method doesn't
automatically mean that private attribute accesses result in an error.
Specifically, they don't in child classes.

// Carl

rounding method adverbs

[Darren Duncan]

Martin D Kealey said (in the a..b thread):
 So then, a cmp ส้ is always defined, but users can change the
 definition.

 I take the opposite approach; it's always undefined (read, unthrown
 exception) unless the user tells us how they want it treated. That can be a
 command-line switch if necessary.

 To paraphrase Dante, the road to hell is paved with Reasonable Defaults.
 Or in programming terms, your reasonable default is the cause of my ugly
 work-around.

That might be fair.

But if we're going to do that, then I'd like to go a step further and require 
some other operators have mandatory config arguments for users to explicitly 
state the semantics they want, but that once again a lexical pragma can declare 
this at a higher level.


Specifically, I think there should be a configuration for any numeric operations 
that might do rounding, where users specify the rounding method employed.  For 
example, the Int-resulting division and modulo operators should require 
specifying how to round on an uneven division.


I can think of at least 9 rounding methods to choose from off the top of my 
head: up (ceiling), down (floor), to-zero (truncate), to-infinity, half-up 
(common), half-down, half-to-zero, half-to-infinity, and half-to-even 
(statistics, banking, etc).  There are probably more, so this should be extensible.


The point here is that there are multiple distinct expectations on what is a 
reasonable default way to do numeric rounding, and it would be a lot more clear 
for everyone reading code if these semantics were spelled out.  Just because 
such as default is stated in the Perl 6 manual doesn't mean it won't constantly 
trip people up all the same.


In particular, common programming languages are often split between down/floor 
and to-zero/truncate as their semantics, and I believe even Perl 5 and Perl 6 
differ on the issue.


Having these options provided also supports some other common tasks.  For 
example, the up/ceiling option would be common, if the task is to figure out how 
many containers we need to hold our widgets, or how many rows in which to 
display multi-column data.


For example:

  $num_boxes_needed = $num_widgets div $box_capacity :round(Up)

Similarly, explicitly stated rounding semantics are useful for non-integer 
operations such as currency or statistics or science.


Also useful when we want to emulate other languages in Perl 6 elegantly and 
even-handedly.


Now, of course, some rounding methods may be more efficient than others on 
particular hardware, but that's just something that should be documented, or 
alternately an explicit named rounding method of don't care could be provided, 
for users who don't care about exact portable semantics, and the implementation 
can decide what is fastest.  I suggest using the whatever mnemonic for this:


  $a = $b div $c :round(*)

... though for those people, probably they'd do it at the file level.

-- Darren Duncan

Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another

[Carl Mäsak]

Here's a case where a bug report stumped me and made me feel I'm
missing something:

 http://rt.perl.org/rt3/Ticket/Display.html?id=69260

I'll give a somewhat summarized version of the above page, which
gradually turns into a set of questions and not enough answers:

* It has been decided that attribute slots of the type $!foo are only
allowed *syntactically* within the class block that declares them.
(The exception to this, I guess, is the 'trusts' directive.) But this
means that something like this anonymous method

my $reveal-foo = method { say $!foo }

isn't allowed. I think that's good, because it would provide a very
easy way to break encapsulation of an object; just call
$object.$reveal-foo() on it.

* Today we discovered that it's possible to break encapsulation by
detaching a method from an object of one class, and calling that
method on an object of another class. Which means that breaking the
encapsulation of a foreign class is as easy as creating a custom class
with all of the same private attributes, and with a method to print
(or otherwise reveal) them.

* It is my feeling that such encapsulation-breakage shouldn't be
allowed. Do you agree, p6l?

* If it isn't allowed, which of the two steps is disallowed?
*Detaching* a method containing references to private accessor slots
(thereby extending the syntactic restriction of no private accessors
outside of the class block), or *attaching* an anonymous method to an
object belonging to a different class than the one from which it was
detached (thereby by necessity having to complicate anonymous methods
somewhat)?

I only see those three options:

a. Allow this form of encapsulation breakage.
b. Disallow detaching of certain methods.
c. Disallow attaching of certain anonymous methods.

I must confess I don't particularly like either option. I'm by no
means an OO expert. It would be interesting to hear your views on
this.

// Carl

Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another

[Brandon S Allbery KF8NH]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/31/10 14:23 , Carl Mäsak wrote:
 a. Allow this form of encapsulation breakage.
 b. Disallow detaching of certain methods.
 c. Disallow attaching of certain anonymous methods.
 
 I must confess I don't particularly like either option. I'm by no
 means an OO expert. It would be interesting to hear your views on
 this.

The whole concept of detaching and attaching methods seems suspect to me; in
particular, attaching a method from a class not declared to be related reeks
of monkey patching.  As such, I'd only allow it when monkey patching is enabled.

- -- 
brandon s. allbery [linux,solaris,freebsd,perl]  allb...@kf8nh.com
system administrator  [openafs,heimdal,too many hats]  allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon university  KF8NH
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxUbRAACgkQIn7hlCsL25URzACfeQwHqlQWs4IL6RdSCkkI1inr
BasAoM0LyLl19dylqoOcMjCfk3kvC9j3
=FyAF
-END PGP SIGNATURE-

Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another

[Stefan O'Rear]

On Sat, Jul 31, 2010 at 08:23:29PM +0200, Carl Mäsak wrote:
 * It has been decided that attribute slots of the type $!foo are only
 allowed *syntactically* within the class block that declares them.
 (The exception to this, I guess, is the 'trusts' directive.) But this
 means that something like this anonymous method
 
 my $reveal-foo = method { say $!foo }
 
 isn't allowed. I think that's good, because it would provide a very
 easy way to break encapsulation of an object; just call
 $object.$reveal-foo() on it.

There is no $!foo.  There is only $!Class::foo, and $!foo is a lexically
scoped alias to it.  This is necessary to allow privacy from your children
to work:

class Class {
has $!foo;  # the mere existance of $!foo is an implementation detail
}

class SubClass is Class {
has $!foo;  # hey why doesn't this work?
}

So $reveal-foo can't be defined because $!foo isn't even in scope.

 * Today we discovered that it's possible to break encapsulation by
 detaching a method from an object of one class, and calling that
 method on an object of another class. Which means that breaking the
 encapsulation of a foreign class is as easy as creating a custom class
 with all of the same private attributes, and with a method to print
 (or otherwise reveal) them.

Calling such methods should fail, because the $!OtherClass:: attributes
don't exist even if the shortnames are the same.

 * It is my feeling that such encapsulation-breakage shouldn't be
 allowed. Do you agree, p6l?

It's not.

 * If it isn't allowed, which of the two steps is disallowed?
 *Detaching* a method containing references to private accessor slots
 (thereby extending the syntactic restriction of no private accessors
 outside of the class block), or *attaching* an anonymous method to an
 object belonging to a different class than the one from which it was
 detached (thereby by necessity having to complicate anonymous methods
 somewhat)?
 
 I only see those three options:
 
 a. Allow this form of encapsulation breakage.
 b. Disallow detaching of certain methods.
 c. Disallow attaching of certain anonymous methods.
 
 I must confess I don't particularly like either option. I'm by no
 means an OO expert. It would be interesting to hear your views on
 this.

Perl philosophy has always been it's not that I have a shotgun, you just
weren't invited, so stay out of my living room.  I don't see any reason for
Perl 6 to break with this - encapsulation should be about helping the
programmer, not helping the sysadmin maintain system security.

-sorear


signature.asc
Description: Digital signature

Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another

[Stefan O'Rear]

On Sat, Jul 31, 2010 at 02:36:02PM -0400, Brandon S Allbery KF8NH wrote:
 On 7/31/10 14:23 , Carl Mäsak wrote:
  a. Allow this form of encapsulation breakage.
  b. Disallow detaching of certain methods.
  c. Disallow attaching of certain anonymous methods.
  
  I must confess I don't particularly like either option. I'm by no
  means an OO expert. It would be interesting to hear your views on
  this.
 
 The whole concept of detaching and attaching methods seems suspect to me; in
 particular, attaching a method from a class not declared to be related reeks
 of monkey patching.  As such, I'd only allow it when monkey patching is 
 enabled.

Methods are just functions.

$object.$method(@args)

is simply sugar for

$method($object, @args)

so disallowing it is not quite that simple.

-sorear


signature.asc
Description: Digital signature

Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another

[Brandon S Allbery KF8NH]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/31/10 14:38 , Stefan O'Rear wrote:
 On Sat, Jul 31, 2010 at 02:36:02PM -0400, Brandon S Allbery KF8NH wrote:
 The whole concept of detaching and attaching methods seems suspect to me; in
 particular, attaching a method from a class not declared to be related reeks
 of monkey patching.  As such, I'd only allow it when monkey patching is 
 enabled.
 
 Methods are just functions.
 
 $object.$method(@args)
 
 is simply sugar for
 
 $method($object, @args)
 
 so disallowing it is not quite that simple.

That would seem to make it worse (type conformability on the first
positional parameter; does declaring a method not implicitly declare the
type of its positional parameter to be the class that declared it, or a
subclass thereof?) --- but I think you addressed that in your other response.

- -- 
brandon s. allbery [linux,solaris,freebsd,perl]  allb...@kf8nh.com
system administrator  [openafs,heimdal,too many hats]  allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon university  KF8NH
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEUEARECAAYFAkxUbtAACgkQIn7hlCsL25WOkwCgvq2SevYoVtGWSio0q7lVDxWy
Qt8AmM8FijA51vxGjylUwuCq1+zpF9k=
=XroU
-END PGP SIGNATURE-

Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another

[Carl Mäsak]

Carl (), sorear ():
 * It has been decided that attribute slots of the type $!foo are only
 allowed *syntactically* within the class block that declares them.
 (The exception to this, I guess, is the 'trusts' directive.) But this
 means that something like this anonymous method

     my $reveal-foo = method { say $!foo }

 isn't allowed. I think that's good, because it would provide a very
 easy way to break encapsulation of an object; just call
 $object.$reveal-foo() on it.

 There is no $!foo.  There is only $!Class::foo, and $!foo is a lexically
 scoped alias to it.  This is necessary to allow privacy from your children
 to work:

 class Class {
    has $!foo;  # the mere existance of $!foo is an implementation detail
 }

 class SubClass is Class {
    has $!foo;  # hey why doesn't this work?
 }

 So $reveal-foo can't be defined because $!foo isn't even in scope.

Thanks, that's an excellent way to explain this. It also provides the
answer to this whole thread:

class A {
has $!x;
}

class B {
has $!x;
method foo { say $!x } # really 'say $!B::x'
}

my $b-foo = B.^can(foo);
A.new( :x(42) ).$b-foo(); # doesn't work, can't access $!B::x from A

This solution is a fourth one that I didn't see, and the first one that I like:

d. Disallow illegally accessing a private attribute slot that isn't yours.

It also incidentally answers a random thought I had today after
posting my original email: Hey, jnthn talked about implementing
attribute accesses as array accesses rather than hash accesses -- how
the heck will that work if methods can be detached and re-attached to
objects of a different class? With $!foo really meaning
$!MyClass::foo it makes a lot more sense.

// Carl

Mixing in to method objects

[Matthew Walton]

As I understand it, in Perl 6 a method of a class, as indeed all
similar things like a sub or a regex, is represented by an object. If
it's an object, I should be able to mix a role into it, right?
Something like:

role Fancy {
  has $.something is rw;
}

sub a {  }

a does Fancy;
a.something = 56;
say a.something;
a();

And so forth. Now, Rakudo's got a whole load of bugs I'm tripping over
trying to do things like this, but I thought I'd check to see if it's
supposed to be possible, and if it isn't, why not.

Also syntactically, is there or should there be a way to do it which
doesn't involve having to haul out the a afterwards - so can the
'does' or maybe a 'but' be attached to the definition itself?

As for why I want to do this, I've got something in mind which would
be potentially much nicer if some methods can carry a load of extra
data around with them - which seems like an excellent use for a mixin,
especially as I could then smartmatch against it in order to pick out
the relevant methods from the .^methods list.

Matthew

Re: [perl #62528] Match.keys method returns nothing.

[Moritz Lenz]

Since afaict this is not specced, I'll hand that over to p6l.

Eric Hodges (via RT) wrote:
 use v6;
 
 rule test {test};
 
 test ~~ /test/;
 say '$/.keys = ', $/.keys.perl;
 say '%($/).keys = ', %($/).keys.perl;
 
 # outputs
 # $/.keys = []
 # %($/).keys = [test]

 
 Same could be said for .values and .kv
 
 It would be very DWIM for it to act like a hash in these cases by default.

Actually I think it would DWIM more in the general case if Match.keys
(and .kv, .pairs, .values etc) would give a list of the array and hash
part, so $/.keys would be  @($/).keys, %($/).keys.
Your suggestion would be just a degenerate case of that.

Any thoughts on that?

Cheers,
Moritz

Re: [perl #62528] Match.keys method returns nothing.

[Jon Lang]

Moritz Lenz wrote:
 Since afaict this is not specced, I'll hand that over to p6l.

 Eric Hodges (via RT) wrote:
 use v6;

 rule test {test};

 test ~~ /test/;
 say '$/.keys = ', $/.keys.perl;
 say '%($/).keys = ', %($/).keys.perl;

 # outputs
 # $/.keys = []
 # %($/).keys = [test]


 Same could be said for .values and .kv

 It would be very DWIM for it to act like a hash in these cases by default.

 Actually I think it would DWIM more in the general case if Match.keys
 (and .kv, .pairs, .values etc) would give a list of the array and hash
 part, so $/.keys would be  @($/).keys, %($/).keys.
 Your suggestion would be just a degenerate case of that.

 Any thoughts on that?

Take it one step more general: IIRC, Match returns a Capture of the
matches found.  What happens if you apply .keys, .values, etc.
directly to a Capture object?  I'm thinking that it should return a
multidimensional array: e.g., (@$capture; %$capture).«keys.

-- 
Jonathan Dataweaver Lang

Re: [PATCH] Add .trim method

[Brandon S. Allbery KF8NH]

On 2009 Jan 12, at 15:17, Ovid wrote:



בָּרוּךְ שֵׁם כְּבוֹד מַלְכוּתוֹ  
לְעוֹלָם וָעֶד.


If you can't see that in your client, that's Hebrew from http://www.i18nguy.com/unicode/shma.html 
 and means Hear O Israel, the Lord is our God, the Lord is One.


Actually that's the response: blessed be the name of the glory of His  
kingdom for ever and ever (and your guess is as good as anyone else's  
as to the actual meaning of that :)


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH

Re: [PATCH] Add .trim method

[Ovid]

- Original Message 

 From: Ovid publiustemp-perl6interna...@yahoo.com

  This patch implements the .trim() method for strings.
 
 Now that I'm reading S29, I see there is no .trim() method there.  I got that 
 because it was referenced in pugs in the cookbook (not in tests, though) and 
 I 
 was trying to get the examples to run.  Bummer :(

Sorry for constant spamming, but now that I've put disparate pieces together, I 
see what's going on here.  I'll stop soon, but I am *sick* of rewriting the 
trim() function over and over :)

There are no tests because it's not in the spec.  If there's a spec, I know 
where to write the tests and will happily commit tests for them to Pugs and 
I'll submit a new patch against any-str.pir and t/spectest.data to get them to 
pass.
 

http://tinyurl.com/4xjnh, a mailing list thread where Larry wrote:

: (Replying to p6l instead of p6c as requested.) 
: 
: On Mon, Apr 04, 2005 at 10:39:16AM -0700, Larry Wall wrote: 
:  (Now that builtins are just functions out in * space, we can probably 
:  afford to throw a few more convenience functions out there for common 
:  operations like word splitting and whitespace trimming.  (Specific 
:  proposals to p6l please.)) 

So even though it's not in the spec, it seems like something Larry is not 
entirely opposed to (or wasn't back in 2005).  So here's my proposal (copied to 
p6l):

  =item trim

  our Str multi Str::trim ( Str $string )

  Removes leading and trailing whitespace from a string.

  =cut

I could optionally make the following work:

  $string.trim(:leading0);
  $string.trim(:trailing0);

Setting leading or trailing to false (they default to true) would result in 
either leading or trailing whitespace not being trimmed.  Setting both to false 
would be a no-op.

Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog- http://use.perl.org/~Ovid/journal/
Twitter  - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6

Re: [PATCH] Add .trim method

[Carl Mäsak]

Ovid ():
  =item trim

  our Str multi Str::trim ( Str $string )

  Removes leading and trailing whitespace from a string.

  =cut

 I could optionally make the following work:

  $string.trim(:leading0);
  $string.trim(:trailing0);

 Setting leading or trailing to false (they default to true) would result in 
 either leading or trailing whitespace not being trimmed.  Setting both to 
 false would be a no-op.

Unless someone protests loudly, I can add this to S29, and I (or
someone else with tuits) can implement it in Rakudo.

// Carl

Re: [PATCH] Add .trim method

[Ovid]

- Original Message 


   =item trim
 
   our Str multi Str::trim ( Str $string )
 
   Removes leading and trailing whitespace from a string.
 
   =cut
 
  I could optionally make the following work:
 
   $string.trim(:leading0);
   $string.trim(:trailing0);
 
  Setting leading or trailing to false (they default to true) would result in 
 either leading or trailing whitespace not being trimmed.  Setting both to 
 false 
 would be a no-op.
 
 Unless someone protests loudly, I can add this to S29, and I (or
 someone else with tuits) can implement it in Rakudo.

I've already submitted a patch for Rakudo which implements this for the trivial 
$string.trim and trim($string) case.  The optional :leading and :trailing 
parameters aren't there.

I'm happy to finish the work according to whatever spec is agreed upon. I want 
this badly enough that it's important to me :)

 
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog- http://use.perl.org/~Ovid/journal/
Twitter  - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6

Re: [PATCH] Add .trim method

[Ovid]

- Original Message 


   I could optionally make the following work:
  
$string.trim(:leading0);
$string.trim(:trailing0);

Alternatively, those could be ltrim() and rtrim().  If you need to dynamically 
determine what you're going to trim, you'd couldn't just set variables to do 
it, though. You'd have to figure out which methods to call.  Or all could be 
allowed and $string.trim(:leading0) could all $string.rtrim internally.

 
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog- http://use.perl.org/~Ovid/journal/
Twitter  - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6

Re: [PATCH] Add .trim method

[Aristotle Pagaltzis]

* Ovid publiustemp-perl6langua...@yahoo.com [2009-01-12 16:05]:
 Or all could be allowed and $string.trim(:leading0) could all
 $string.rtrim internally.

++

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: [PATCH] Add .trim method

[Jonathan Worthington]

Aristotle Pagaltzis wrote:

* Ovid publiustemp-perl6langua...@yahoo.com [2009-01-12 16:05]:
  

Or all could be allowed and $string.trim(:leading0) could all
$string.rtrim internally.



++

  

Note you can write it :!leading too. :-)

Jonathan

Re: [PATCH] Add .trim method

[Larry Wall]

On Mon, Jan 12, 2009 at 05:04:50AM -0800, Ovid wrote:
: ...the trivial $string.trim and trim($string) case.

Hmm, I'd think .trim should work like .chomp, and return the trimmed
string without changing the original.  You'd use $str.=trim to do it
in place.

Can't say I really like the negated options though.  They smell funny.

Larry

Re: [PATCH] Add .trim method

[Jonathan Worthington]

Ovid wrote:

- Original Message 

  
In the pir, doesn't the s = self line copy self, thus ensuring that I'm changing s and not self?  

No, it's binding.


Or do I need s = clone self (or however it's written).

  

Yeah, but also note that substr would return a copy...


Can't say I really like the negated options though.  They smell funny.



Agreed, but ltrim and rtrim will disappoint Israelis and dyslexics alike.  
Suggestions welcome as I can't think of anything better.

  
The .Net framework calls 'em TrimStart and TrimEnd (and has a Trim that 
does both). So maybe trim_start and trim_end if we wanted to take that 
lead...


Jonathan

Re: [PATCH] Add .trim method

[Carl Mäsak]

Jonathan (), Ovid (), Larry ():
 Can't say I really like the negated options though.  They smell funny.

 Agreed, but ltrim and rtrim will disappoint Israelis and dyslexics alike.
  Suggestions welcome as I can't think of anything better.

 The .Net framework calls 'em TrimStart and TrimEnd (and has a Trim that does
 both). So maybe trim_start and trim_end if we wanted to take that lead...

How about .trim(:start) and .trim(:end)?

// Carl

Re: [PATCH] Add .trim method

[Geoffrey Broadwell]

On Mon, 2009-01-12 at 07:01 -0800, Ovid wrote:
 - Original Message 
 
 
I could optionally make the following work:
   
 $string.trim(:leading0);
 $string.trim(:trailing0);
 
 Alternatively, those could be ltrim() and rtrim().  If you need to 
 dynamically determine what you're going to trim, you'd couldn't just set 
 variables to do it, though. You'd have to figure out which methods to call.  
 Or all could be allowed and $string.trim(:leading0) could all $string.rtrim 
 internally.

When I saw your proposed syntax above, instead of reading don't trim
leading/trailing whitespace, I read change the definition of
'whitespace' to 'codepoint 0' for leading/trailing.

That of course raises the question of how one *would* properly override
trim's concept of whitespace 


-'f

Re: [PATCH] Add .trim method

[Ovid]

- Original Message 


  Agreed, but ltrim and rtrim will disappoint Israelis and dyslexics alike.
   Suggestions welcome as I can't think of anything better.
 
  The .Net framework calls 'em TrimStart and TrimEnd (and has a Trim that does
  both). So maybe trim_start and trim_end if we wanted to take that lead...
 
 How about .trim(:start) and .trim(:end)?

So if:

1.  No params, trim all
2.  :start or :end, only trim that bit (not a negated option :)
3.  If both, goto 1

 
Sound good?

Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog- http://use.perl.org/~Ovid/journal/
Twitter  - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6

Re: [PATCH] Add .trim method

[Ovid]

- Original Message 

 From: Geoffrey Broadwell ge...@broadwell.org

 When I saw your proposed syntax above, instead of reading don't trim
 leading/trailing whitespace, I read change the definition of
 'whitespace' to 'codepoint 0' for leading/trailing.
 
 That of course raises the question of how one *would* properly override
 trim's concept of whitespace 

Change your locale to one with a different concept of whitespace (are there 
any?)


Otherwise, would this be trying to stuff too much into one function?

Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog- http://use.perl.org/~Ovid/journal/
Twitter  - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6

Re: [PATCH] Add .trim method

[Larry Wall]

On Mon, Jan 12, 2009 at 09:33:32AM -0800, Geoffrey Broadwell wrote:
: That of course raises the question of how one *would* properly override
: trim's concept of whitespace 

Well, given that .trim is essentially just .comb(/\S.*\S/), which in
turn is really just m:g/(\S.*\S)/, I don't see much need for alternate
trimmings.

Larry

Re: [PATCH] Add .trim method

[Andy Colson]

Larry Wall wrote:

On Mon, Jan 12, 2009 at 05:04:50AM -0800, Ovid wrote:
: ...the trivial $string.trim and trim($string) case.

Hmm, I'd think .trim should work like .chomp, and return the trimmed
string without changing the original.  You'd use $str.=trim to do it
in place.

Can't say I really like the negated options though.  They smell funny.

Larry


I'm +1 on adding a trim, I do a lot of csv import (with trimming) in perl 5.

On a side note, between modifying the original and returning a fixed 
string, which one would we expect to be faster?  And I assume either 
would be faster than the regex method of trimming?


-Andy

Re: [PATCH] Add .trim method

[Aristotle Pagaltzis]

* Ovid publiustemp-perl6langua...@yahoo.com [2009-01-12 18:40]:
 1.  No params, trim all
 2.  :start or :end, only trim that bit (not a negated option :)
 3.  If both, goto 1

Also `:!start` to imply `:end` unless `:!end` (which in turn
implies `:start` unless `:!end`)?

I’d like not to have to type `.trim(:start)` when I could just do
`.ltrim` though.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: [PATCH] Add .trim method

[Mark J. Reed]

On Mon, Jan 12, 2009 at 2:50 PM, Aristotle Pagaltzis pagalt...@gmx.de wrote:
 I'd like not to have to type `.trim(:start)` when I could just do
 `.ltrim` though.

As long as we gloss .ltrim as leading trim rather than left trim.
Then the other end could be .ttrim for trailing?

We really ought to avoid using left and right to refer to the
beginning and end of text strings.


-- 
Mark J. Reed markjr...@gmail.com

Re: [PATCH] Add .trim method

[Ovid]

- Original Message 


 Also `:!start` to imply `:end` unless `:!end` (which in turn
 implies `:start` unless `:!end`)?
 
 I’d like not to have to type `.trim(:start)` when I could just do
 `.ltrim` though.

So what would .ltrim do with this?



בָּרוּךְ שֵׁם כְּבוֹד מַלְכוּתוֹ לְעוֹלָם וָעֶד.

If you can't see that in your client, that's Hebrew from 
http://www.i18nguy.com/unicode/shma.html and means Hear O Israel, the Lord is 
our God, the Lord is One.

Since that's RTL (Right To Left) text, should ltrim remove the leading or 
trailing whitespace?

I like Jonathan's trim_start and trim_end.

Side note:  I'm implementing the tests now, but only for bog-standard .trim.  I 
won't do the rest until we settle this.

So far I only have one failing test:

  is_deeply(trim(()), (), trim on empty list);

Results in:

  not ok 10 - trim on empty list
  # have: 
  # want: []

Note that this output is from my locally hacked version of Test.pm which is 
kind enough to tell you what the failure is.  I'll submit a patch for that 
later.

Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog- http://use.perl.org/~Ovid/journal/
Twitter  - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6

Re: [PATCH] Add .trim method

[Aristotle Pagaltzis]

* Aristotle Pagaltzis pagalt...@gmx.de [2009-01-12 20:55]:
 Also `:!start` to imply `:end` unless `:!end` (which in turn
 implies `:start` unless `:!end`)?

Ugh, forget this, I was having a blank moment.

Actually that makes me wonder now whether it’s actually a good
idea at all to make the function parametrisable at all. Even
`.ltrim.rtrim` is shorter and easier than `.trim(:start,:end)`!
Plus if there are separate `.ltrim` and `.rtrim` functions it
would be better to implement `.trim` by calling them rather than
vice versa, so it wouldn’t even be less efficient two make two
calls rather than a parametrised one.

And if anyone really needs to be able to decide the trimming
based on flags, they can do that themselves with `.ltrim`/
`.rtrim` with rather little code anyway.

So I question the usefulness of parametrisation here.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: [PATCH] Add .trim method

[Aristotle Pagaltzis]

* Ovid publiustemp-perl6langua...@yahoo.com [2009-01-12 21:20]:
 Since that's RTL (Right To Left) text, should ltrim remove the
 leading or trailing whitespace?

 I like Jonathan's trim_start and trim_end.

Let me ask you first: does a string that runs Right-to-Left start
at the left and end at the right or start at the right and end at
the left?

Now to answer your question, *I* know where the *left* side is in
a string that runs from right to left: it’s at the *left*, same
as if the string ran from the left to the right, because left is
at the *left*.

:-)

I mean, if the the meaning of “left” was inverted by
“right-to-left”, in which it is contained, then what does the
latter even mean? (OK, we’re on a Perl 6 list so I guess the
answer is it’s a juction… :-) )

Clearly one of us has an inversed sense of which pair of terms is
ambiguous, and I don’t think it’s me… ;-)

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: [PATCH] Add .trim method

[Larry Wall]

On Mon, Jan 12, 2009 at 09:18:03PM +0100, Aristotle Pagaltzis wrote:
: Plus if there are separate `.ltrim` and `.rtrim` functions it
: would be better to implement `.trim` by calling them rather than
: vice versa, so it wouldn’t even be less efficient two make two
: calls rather than a parametrised one.

Depends on your string implementation if they're non-destructive,
since they potentially have to copy the middle of the string twice if
your implementation can't support one string pointing into the middle
of another.  And again, I think .trim should be non-destructive,
and .=trim should be the destructive version.

Larry

Re: [PATCH] Add .trim method

[Austin Hastings]

Aristotle Pagaltzis wrote:

Actually that makes me wonder now whether it’s actually a good
idea at all to make the function parametrisable at all. Even
`.ltrim.rtrim` is shorter and easier than `.trim(:start,:end)`!
  


How about .trim(:l, :r) with both as the default? And if the rtl crowd 
makes a furor, we can add :a/:o or :ת/:א or something.



So I question the usefulness of parametrisation here.
  


Useful for doing infrequent things. IMO, left and right trimming are 
infrequent compared to the frequency of basic input editing.


=Austin

Re: [PATCH] Add .trim method

[Ovid]

- Original Message 

 From: Aristotle Pagaltzis pagalt...@gmx.de

  I like Jonathan's trim_start and trim_end.
 
 Let me ask you first: does a string that runs Right-to-Left start
 at the left and end at the right or start at the right and end at
 the left?
 
 Now to answer your question, *I* know where the *left* side is in
 a string that runs from right to left: it’s at the *left*, same
 as if the string ran from the left to the right, because left is
 at the *left*.
 
 :-)

I see your point, but it complicates the internals of the trim method because 
then I have to detect if a string is RTL and reverse it, then unreverse it when 
done (or something conceptually similar).

I'd rather not toss in said complications for a problem space I don't know very 
well.

On the other hand, this is a core feature, not a quick CPAN jobbie, so it's 
important to get it RIGHT or it will be LEFT out.  (I kill me.  I really do :)

 
Beers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog- http://use.perl.org/~Ovid/journal/
Twitter  - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6

Re: [PATCH] Add .trim method

[Aristotle Pagaltzis]

* Larry Wall la...@wall.org [2009-01-12 21:55]:
 * Aristotle Pagaltzis pagalt...@gmx.de [2009-01-12 21:20]:
  Plus if there are separate `.ltrim` and `.rtrim` functions it
  would be better to implement `.trim` by calling them rather
  than vice versa, so it wouldn’t even be less efficient two
  make two calls rather than a parametrised one.

 Depends on your string implementation if they're
 non-destructive, since they potentially have to copy the middle
 of the string twice if your implementation can't support one
 string pointing into the middle of another. And again, I think
 .trim should be non-destructive, and .=trim should be the
 destructive version.

Sure, but that doesn’t affect my point: if `.trim` is implemented
as calling `.ltrim` + `.rtrim`, as I assumed, then all ways of
trimming a string at both ends will be equally efficient or
inefficient depending on whether or not the implementation
supports offsetted strings.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: [PATCH] Add .trim method

[Aristotle Pagaltzis]

* Ovid publiustemp-perl6langua...@yahoo.com [2009-01-12 22:05]:
 I see your point

And now I see yours. I was visualising the memory layout of a
string, wherein a right-to-left string gets displayed from the
right end of it’s in-memory representation so “left” and “right”
are absolutes in that picture. But of course RTL reverses the
relation of left/right in memory and left/right on screen.

I think a week’s worth of wolf sleep is catching up to me, sorry.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: [PATCH] Add .trim method

[Aristotle Pagaltzis]

* Austin Hastings austin_hasti...@yahoo.com [2009-01-12 22:00]:
 How about .trim(:l, :r) with both as the default?

Liveable.

 And if the rtl crowd makes a furor, we can add :a/:o or :ת/:א
 or something.

*grin*

Maybe :h and :t (head/tail).

 Useful for doing infrequent things. IMO, left and right
 trimming are  infrequent compared to the frequency of basic
 input editing.

Good point, rings true.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: [PATCH] Add .trim method

[Ovid]

- Original Message 

 From: Aristotle Pagaltzis pagalt...@gmx.de

 * Austin Hastings [2009-01-12 22:00]:
  How about .trim(:l, :r) with both as the default?
 
 Liveable.

I've just committed the pugs tests for trim.  However, it's just 'trim' with no 
left/right, leading/trailing, Catholic/Protestant implementation.  I'll submit 
a patch for trim with the spectest data updated and work on the rest after the 
dust settles.

 
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog- http://use.perl.org/~Ovid/journal/
Twitter  - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6

Re: [PATCH] Add .trim method

[Ovid]

- Original Message 

 From: jesse je...@fsck.com
 
 On Mon, Jan 12, 2009 at 07:01:25AM -0800, Ovid wrote:
 I could optionally make the following work:

  $string.trim(:leading0);
  $string.trim(:trailing0);
  
  Alternatively, those could be ltrim() and rtrim().  
 
 'left' and 'right' are probably not the right names for functions which
 trim leading and/or trailing space, since their meanings get somewhat
 ambiguous if a language renders right-to-left instead of left-to-right
 or vice-versa

Um, er.  Damn.  Now I'm wondering how my leading and trailing trimming 
works with Hebrew.  How are the strings implemented internally?

And then there are languages such as Manchu and Uygher which can be written 
vertically.  http://www.omniglot.com/writing/direction.htm

 
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog- http://use.perl.org/~Ovid/journal/
Twitter  - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6

Re: [PATCH] Add .trim method

[Gianni Ceccarelli]

On 2009-01-12 Ovid publiustemp-perl6interna...@yahoo.com wrote:
 Um, er.  Damn.  Now I'm wondering how my leading and trailing
 trimming works with Hebrew.  How are the strings implemented
 internally?

RTL (and bidi) languages are written in strings so that the character
order is the logical, reading, order. That is, the character nearer
to the beginning of the string is the first one to be read by a human
reader (so, such character would be displayed on the right for a RTL
language, on the left for a LTR language, at the top for a TTB language)

Short answer: your implementation is right :)

-- 
Dakkar - Mobilis in mobile
GPG public key fingerprint = A071 E618 DD2C 5901 9574
 6FE2 40EA 9883 7519 3F88
key id = 0x75193F88

You possess a mind not merely twisted, but actually sprained.


signature.asc
Description: PGP signature

Re: [PATCH] Add .trim method

[Jonathan Scott Duff]

On Mon, Jan 12, 2009 at 9:01 AM, Ovid
publiustemp-perl6langua...@yahoo.comwrote:

 - Original Message 


I could optionally make the following work:
   
 $string.trim(:leading0);
 $string.trim(:trailing0);

 Alternatively, those could be ltrim() and rtrim().  If you need to
 dynamically determine what you're going to trim, you'd couldn't just set
 variables to do it, though. You'd have to figure out which methods to call.
  Or all could be allowed and $string.trim(:leading0) could all
 $string.rtrim internally.


If I were going to have ltrim() and rtrim(), I'd implement them in terms of
trim() rather than the other way around.

-Scott
-- 
Jonathan Scott Duff
perlpi...@gmail.com

Re: [PATCH] Add .trim method

[Ovid]

- Original Message 

 From: Larry Wall la...@wall.org

 On Mon, Jan 12, 2009 at 05:04:50AM -0800, Ovid wrote:
 : ...the trivial $string.trim and trim($string) case.
 
 Hmm, I'd think .trim should work like .chomp, and return the trimmed
 string without changing the original.  You'd use $str.=trim to do it
 in place.

In the pir, doesn't the s = self line copy self, thus ensuring that I'm 
changing s and not self?  Or do I need s = clone self (or however it's 
written).

 Can't say I really like the negated options though.  They smell funny.

Agreed, but ltrim and rtrim will disappoint Israelis and dyslexics alike.  
Suggestions welcome as I can't think of anything better.

 
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog- http://use.perl.org/~Ovid/journal/
Twitter  - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6

Re: [PATCH] Add .trim method

[Dave Whipp]

Ovid wrote:


 $string.trim(:leading0);
 $string.trim(:trailing0);

 Setting leading or trailing to false (they default to true) would
 result in either leading or trailing whitespace not being trimmed


Alternatively, those could be ltrim() and rtrim().  If you need to dynamically 
determine what you're going to trim, you'd couldn't just set variables to do it, 
though. You'd have to figure out which methods to call.  Or all could be allowed and 
$string.trim(:leading0) could all $string.rtrim internally.


I like having the options, I think. If the default value of :trailing 
was /ws*/, then someone could change it to /ws*\#\N*/ to chomp 
trailing line comments. (Assuming they don't simply redefine the ws token)

Re: [PATCH] Add .trim method

[jesse]

On Mon, Jan 12, 2009 at 07:01:25AM -0800, Ovid wrote:
I could optionally make the following work:
   
 $string.trim(:leading0);
 $string.trim(:trailing0);
 
 Alternatively, those could be ltrim() and rtrim().  

'left' and 'right' are probably not the right names for functions which
trim leading and/or trailing space, since their meanings get somewhat
ambiguous if a language renders right-to-left instead of left-to-right
or vice-versa

-jesse

Re: [PATCH] Add .trim method

[Andy Lester]

On Jan 12, 2009, at 11:27 AM, Carl Mäsak wrote:


How about .trim(:start) and .trim(:end)?



And .trim(:both) for orthogonality.

--
Andy Lester = a...@petdance.com = www.petdance.com = AIM:petdance

Re: [PATCH] Add .trim method

[Moritz Lenz]

Carl Mäsak wrote:
 Jonathan (), Ovid (), Larry ():
 Can't say I really like the negated options though.  They smell funny.

 Agreed, but ltrim and rtrim will disappoint Israelis and dyslexics alike.
  Suggestions welcome as I can't think of anything better.

 The .Net framework calls 'em TrimStart and TrimEnd (and has a Trim that does
 both). So maybe trim_start and trim_end if we wanted to take that lead...
 
 How about .trim(:start) and .trim(:end)?

That would be my favourite:

our Str multi method trim (Str $string:, :start = True, :end = True)

So $str.=trim would trim both start and end, and if you want only one,
you can say $str.=trim(:!end);.

Cheers,
Moritz

Re: [PATCH] Add .trim method

[Larry Wall]

On Mon, Jan 12, 2009 at 06:36:55PM +0100, Moritz Lenz wrote:
: Carl Mäsak wrote:
:  Jonathan (), Ovid (), Larry ():
:  Can't say I really like the negated options though.  They smell funny.
: 
:  Agreed, but ltrim and rtrim will disappoint Israelis and dyslexics alike.
:   Suggestions welcome as I can't think of anything better.
: 
:  The .Net framework calls 'em TrimStart and TrimEnd (and has a Trim that 
does
:  both). So maybe trim_start and trim_end if we wanted to take that lead...
:  
:  How about .trim(:start) and .trim(:end)?
: 
: That would be my favourite:
: 
: our Str multi method trim (Str $string:, :start = True, :end = True)

Er, that would make .trim(:start) also default :end to True...

Well, except it won't parse either.  For at least two reasons. :)

: So $str.=trim would trim both start and end, and if you want only one,
: you can say $str.=trim(:!end);.

HEY!  Don't ignore my nose.  At least, not this time. :)

Switches should almost never default to true.  It's more like:

our Str multi method trim (Str $string:
:$start = False,
:$end = False,
:$both = not $start || $end)

or really, since start/end really mean startonly/endonly:

our Str multi method trim (Str $string:
:start($start_only) = False,
:end($end_only) = False)
{
my $do_start = not $end_only;
my $do_end = not $start_only;
...
}

I really shouldn't be participating in the bikeshedding though...

Larry

Re: [PATCH] Add .trim method

[jason switzer]

On Mon, Jan 12, 2009 at 9:07 AM, jesse je...@fsck.com wrote:


 'left' and 'right' are probably not the right names for functions which
 trim leading and/or trailing space, since their meanings get somewhat
 ambiguous if a language renders right-to-left instead of left-to-right
 or vice-versa


I'm in favor of using the proposed syntax, but I will agree with lwall that
it seems like overkill to have the specialized trims. .trim should be
non-destructive and .=trim should be destructive (these seems intuitive).

Some languages run in the direction of left-to-right, some in the direction
right-to-left (some even top-to-bottom). No matter what language you speak
or which direction your native language reads, left is the same for everyone
as well as right.

If we wanted to simplify matters, use :left, :right and :both. Those have
the same meaning everywhere.

If we wanted language dependent version, use :leading, :trailing, and :both.
That will require each implementation properly handle the language
variations.

By the way, good work on this. Everyone loves useful string functions.

-Jason s1n Switzer

Trimming; left or start? (was: Re: [PATCH] Add .trim method)

[Timothy S. Nelson]

	Can I make a suggestion?  From my point of view, it'd be nice if the 
trim method supported:


-   left/right (leftmost/rightmost part of the string; language-independent)
-   start/end (start and end of string; could be leading/trailing instead)
-   both

How would that work?

:)


-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am   |
-

BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- 
PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y-

-END GEEK CODE BLOCK-

Re: [PATCH] Add .trim method

[Ovid]

- Original Message 

 From: jason switzer jswit...@gmail.com

 If we wanted language dependent version, use :leading, :trailing, and :both.
 That will require each implementation properly handle the language
 variations.
 
I think :start and :end are my favorites.  Huffman++ (maybe :begin and :end for 
consistency?).

Still raises the question of what to do with arrays of hashes of arrays with 
@array  .= trim;

I can't trim keys of pairs because they're used as unique identifiers in hashes 
and conflicts will occur.  So recursive trimming needs have a special case for 
keys or it needs to not be allowed (and thus fail with AoHoA and similar 
complex data structures).

 By the way, good work on this. Everyone loves useful string functions.

Thanks.  It's been lots of fun :)

 
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog- http://use.perl.org/~Ovid/journal/
Twitter  - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6

Re: [PATCH] Add .trim method

[jason switzer]

On Mon, Jan 12, 2009 at 6:26 PM, Ovid
publiustemp-perl6langua...@yahoo.comwrote:

 - Original Message 

  From: jason switzer jswit...@gmail.com

  If we wanted language dependent version, use :leading, :trailing, and
 :both.
  That will require each implementation properly handle the language
  variations.

 I think :start and :end are my favorites.  Huffman++ (maybe :begin and :end
 for consistency?).


My best advise is to keep it consistant. .chomp makes references to chomping
from the end, not the trailing. .substr makes reference to start. I think
that's better to just find terminology that has already been agreed upon and
keep abusing it.

new method question

[Xiao Yafeng]

There are no barewords in Perl 6, but it seems new method is an exception:

class Dog {

has $name;
method bark () {
say $name;
}
}
my $p = Dog.new($name = 'boo');
  $p.bark;#error!
my $p = Dog.new( name = 'boo');
  $p.bark#say boo

more confused:

class Dog {

has @names;
method bark () {
say @names;
}
}
my $p = Dog.new(names = 'boo');
  $p.bark;#nothing but passed.

So, how set array attribute of a class by new method?

Re: new method question

[John M. Dlugosz]

Moritz Lenz moritz-at-casella.verplant.org |Perl 6| wrote:

Attributes need to have a twigil, so it would be
  has $.name

  


The syntax
   has $name;
with no twigil is legal according to S12.  Perhaps the original poster 
(Xiao Yafeng) might like to read 
http://www.dlugosz.com/Perl6/web/class-declarators.html.


--John

Re: syntax question: method close is export ()

[Larry Wall]

On Tue, Aug 05, 2008 at 05:43:57PM +0800, Audrey Tang wrote:
 John M. Dlugosz 提到:
 Does that mean that traits can come before the signature?  Or should it 
 be corrected to
 method close () is export { ... }

 It's a simple typo.  Thanks, fixed in r14572.

The strange thing is that we might have to support that order if we want
to allow user-defined operators in the signature, since

sub infix:foo
($x, $y, :$z = $x foo $y bar 1)
is equiv(infix:baz)
{...}

would not know the precedence soon enough to know whether foo is tighter
or looser than bar.  Whereas

sub infix:foo
is equiv(infix:baz)
($x, $y, :$z = $x foo $y bar 1)
{...}

could presumably attach that information in a timely fashion to the
definition of the foo operator.  'Course, there are workarounds in the
current scheme of things:

sub infix:foo
is equiv(infix:baz)
is sig(:($x, $y, :$z = $x foo $y bar 1))
{...}

sub infix:foo
($x, $y, :$z = infix:foo($x, $y) bar 1)
is equiv(infix:baz)
{...}

but I'm inclined to simplify in the direction of saying the signature
syntax is just a trait variant so the order doesn't matter.  The one
remaining question I see is whether it's possible to declare a sub
with the name is:

sub is is foo {...}

and if so, whether it's possible to have an anonymous sub with traits
and no signature:

sub is foo {...}

I suspect we should bias it towards the first case on the grounds that
you can write the latter with an explicit missing sig sig as

sub ([EMAIL PROTECTED] is rw) is foo {...}

Though, of course, we could solve it the other direction with an
explicit I am not a sub name sub name.  Not sure which side least
suprise works on, but the fact that we already have a representation
for no sig seems to say we don't need an explicitly anonymous name.
But maybe such a name would be more generally useful, which would
make it a wash.  One obvious candidate for a null name:

sub () is foo {...}

is of course not possible.  I suppose we could nudge things in a
direction that

sub  is foo {...}

would work, since that'd be much like

state $ = do { I am a fake START block }

But if we allow sub foo then people will wonder what sub @foo means...

Larry

Re: syntax question: method close is export ()

[Audrey Tang]

John M. Dlugosz 提到:
Does that mean that traits can come before the signature?  Or should it 
be corrected to

method close () is export { ... }


It's a simple typo.  Thanks, fixed in r14572.

Cheers,
Audrey

syntax question: method close is export ()

[John M. Dlugosz]

Does that mean that traits can come before the signature?  Or should it be 
corrected to

method close () is export { ... }

?

Re: method hiding (or not) in derived classes

[TSa]

HaloO,

John M. Dlugosz wrote:

Perl 6 has a concept of a candidate list.  The candidate list are
those that could handle the call, typically inherited methods and
multi variations.


Candidate set would be a better term. It is a subset of all long names
of a multi in a lexical scope.



It seems that multi variations, at least with respect to the
semicolon parameters, compare the actual type and drop out of the
list if any don't match.


I'm not sure what you are asking. But if a candidate is applicable
it competes with the other candidates for specificity. That is what
the semicolons are for. And even if a candidate is voted out it still
can vote out others.



What about ordinary methods (and ordinary parameters of multis)?
Does the candidate list hold every method name that matches, or does
it do simpler parameter matching based on number of arguments,
required named arguments, etc.?


There is hopefully a complete specification what constitutes
applicability. There can hardly be differing simpler versions.
In other words there is only one subtype relation that is used
whenever a binding takes place.



If that is the case, then a derived method might not hide a base
class method if the parameter list is seriously incompatible.


That is a natural and welcome consequence of type based dispatch.
Classes are for implementation sharing, not for transitive typing.


 More
interestingly, left-to-right ordering of multiply-inherited base
classes will be checked for applicability rather than  arbitrarily
taking the leftmost.


Indeed, I would hope that order of inheritance doesn't matter.


Regards, TSa.
--

The unavoidable price of reliability is simplicity
  -- C.A.R. Hoare

Re: method hiding (or not) in derived classes

[John M. Dlugosz]

TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:


Candidate set would be a better term. It is a subset of all long names
of a multi in a lexical scope.

List, not set, because it is ordered.  nextsame/nextwith/etc. are 
described as invoking the next candidate on the list.  Therefore, there 
is a list.






What about ordinary methods (and ordinary parameters of multis)?
Does the candidate list hold every method name that matches, or does
it do simpler parameter matching based on number of arguments,
required named arguments, etc.?


There is hopefully a complete specification what constitutes
applicability. There can hardly be differing simpler versions.
In other words there is only one subtype relation that is used
whenever a binding takes place.


I have no idea what you said.





If that is the case, then a derived method might not hide a base
class method if the parameter list is seriously incompatible.


That is a natural and welcome consequence of type based dispatch.
Classes are for implementation sharing, not for transitive typing.


I'm talking about non-multi's here.



 More
interestingly, left-to-right ordering of multiply-inherited base
classes will be checked for applicability rather than  arbitrarily
taking the leftmost.


Indeed, I would hope that order of inheritance doesn't matter.

Sounds more role-like, now that you mention it.





Regards, TSa.

Re: method hiding (or not) in derived classes

[Larry Wall]

On Sat, Apr 19, 2008 at 08:00:07AM -, John M. Dlugosz wrote:
: Perl 6 has a concept of a candidate list.  The candidate list are those 
that could handle the call, typically inherited methods and multi variations.  
: 
: It seems that multi variations, at least with respect to the semicolon 
parameters, compare the actual type and drop out of the list if any don't match.

When you drop those candidates that can never match is mostly a
matter of optimization, I suspect.

: What about ordinary methods (and ordinary parameters of multis)?  Does the 
candidate list hold every method name that matches, or does it do simpler 
parameter matching based on number of arguments, required named arguments, etc.?

For those parameters, it matters only whether they can be bound when the
candidate is called.  The parameters need not be considered at all when
generating the candidate list (but see optimization above--though
perhaps this view is oversimplified if we have to do tie determination,
since ties are supposed to fail before the final call, and we'd have
to weed out non-bindable sigs before declaring a tie).

: If that is the case, then a derived method might not hide a base class method 
if the parameter list is seriously incompatible.  More interestingly, 
left-to-right ordering of multiply-inherited base classes will be checked for 
applicability rather than  arbitrarily taking the leftmost.

only methods use only short name, and methods, like subs, default to
only.  And as it is currently specced, the class is dispatched on
the short name before any any of its multis, and long names are not
considered until the class is dispatched to.  The invariant is that
single dispatch is always under the control of the invocant's object
system, while multiple dispatch never is.  In my mind the policy
distinction is clarified by considered what happens if a foreign
language defines some of the classes.  Under single dispatch the
language that defined the object gets the dispatch.  Under multiple
dispatch, all objects are treated as Perl objects with Perl types,
and the type system gets to decide which candidate to call.  It is
important to be able to look at a call and determine which kind of
call is being made; this is why we give single dispatch a syntax that
is distinct from multiple dispatch.

So if you use multi method declarations within a class, they appear
only to be a single method from outside the class, because that is all
the foreign language interface can support.  You can only use multi
methods within a class if the language supports the concept, and Perl
6 only supports it out the scope of the current class.  Basically,
multi methods are just treated as multi subs inside a class, except
the invocant is predecided and doesn't make any difference to the
dispatch within the class.

Larry

Re: method hiding (or not) in derived classes

[TSa]

HaloO,

John M. Dlugosz wrote:

TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:


Candidate set would be a better term. It is a subset of all long names
of a multi in a lexical scope.

List, not set, because it is ordered.  nextsame/nextwith/etc. are 
described as invoking the next candidate on the list.  Therefore, there 
is a list.


Hmm, the term candidate should be after the applicability check and
before specificity check. The latter results in a partially ordered
list of targets. If there's more than one most specific target, we
have an ambiguity error. As a consequence there might not be a unique
next method on the target list and a nextsame might fail. I agree
that the synopsis conflate these details into the term candidate list.
But I hope you are more rigorous.




What about ordinary methods (and ordinary parameters of multis)?
Does the candidate list hold every method name that matches, or does
it do simpler parameter matching based on number of arguments,
required named arguments, etc.?


There is hopefully a complete specification what constitutes
applicability. There can hardly be differing simpler versions.
In other words there is only one subtype relation that is used
whenever a binding takes place.


I have no idea what you said.


OK, here's my vision of dispatch. First there's a syntactic distinction
between MMD and class dispatch.

  $obj.meth(|$args);
  meth $obj: |$args;

These pull out the candidate set from $obj. Everything else
collects the candidate set from a namespace scan. Next, all candidates
are checked to allow a binding of $obj and |$args. The ones that
fail are dropped. If the candidate set is now empty we have a failure. 
The remaining set is now sorted into a list of sets by applying the

subtype relation in the dispatch relevant parameter positions. If the
first element of that list is a set with a single element we have a
successful dispatch. Otherwise there's an ambiguity error. The .? avoids
the no target error, .+ avoids the ambiguity error and .* never fails.
I would leave the order in which sets of targets are called unspecified.
If one needs more control the .WALK method can be used. If class
dispatch fails because there's no applicable method then a MMD is
attempted.

I guess the answer to your question concerning hiding a method in a
derived class depends on the set of candidates the $obj.HOW comes up
with in the first step. If it delivers superclass methods and subclass
methods fail the applicability test then the dispatch goes to a
superclass method that can handle the dispatch. Would you favor a
type error then?



If that is the case, then a derived method might not hide a base
class method if the parameter list is seriously incompatible.


That is a natural and welcome consequence of type based dispatch.
Classes are for implementation sharing, not for transitive typing.


I'm talking about non-multi's here.


Me too. As stated above the candidate set is up to the class that
created the object. If this class can prevent the failover to MMD
I don't know.


Regards, TSa.
--

The unavoidable price of reliability is simplicity
  -- C.A.R. Hoare

method hiding (or not) in derived classes

[John M. Dlugosz]

Perl 6 has a concept of a candidate list.  The candidate list are those that 
could handle the call, typically inherited methods and multi variations.  

It seems that multi variations, at least with respect to the semicolon 
parameters, compare the actual type and drop out of the list if any don't match.

What about ordinary methods (and ordinary parameters of multis)?  Does the 
candidate list hold every method name that matches, or does it do simpler 
parameter matching based on number of arguments, required named arguments, etc.?

If that is the case, then a derived method might not hide a base class method 
if the parameter list is seriously incompatible.  More interestingly, 
left-to-right ordering of multiply-inherited base classes will be checked for 
applicability rather than  arbitrarily taking the leftmost.

--John

Re: multi method dispatching of optional arguments (further refined)

[Larry Wall]

On Mon, Sep 04, 2006 at 10:52:35PM -0700, Trey Harris wrote:
: In a message dated Tue, 5 Sep 2006, Ph. Marek writes:
: I now had a look at http://dev.perl.org/perl6/doc/design/syn/S06.html 
: but didn't find what I meant. Sorry if I'm just dumb and don't 
: understand you (or S06); I'll try to explain what I mean.
: 
: I don't think you're dumb; the Synopses just require that you intuit 
: certain things from each other, from examples in other Synopses, and so on 
: in a Perlish sort of way; what you're looking for is not spelled out 
: explicitly.  It can be found by noticing how you specify subtypes, along 
: with noticing that subtypes can be specified as parameter types.  There's 
: also an example showing explicitly what you want in S12.
: 
: In Perl5 this looks like
: 
:  sub SomeThing
:  {
:my($a, $b)[EMAIL PROTECTED];
: 
:return b+2 if ($a == 4);
:return a+1 if ($b == 3);
:return a*b;
:  }
: [...]
: What I am asking is whether there will be some multimethod dispatch 
: depending
: on the *value*, not the *type*, of parameters.
: Perl6 could possibly do something with given; but matching on multiple
: variables seems to be verbose, too.
: I'm looking for something in the way of
: 
:  sub SomeThing(Num $a, Num $b) where $a==4 is $b+2;
:  sub SomeThing(Num $a, Num $b) where $b==3 is $a+1;
:  sub SomeThing(Num $a, Num $b) { return $a * $b }
: 
: It's just
: 
:multi sub SomeThing(Num $a where {$^a == 4}, Num $b) { $b + 2  }
:multi sub SomeThing(Num $a, Num $b where {$^b == 3}) { $a + 1  }
:multi sub SomeThing(Num $a, Num $b)  { $a * $b }
: 
: but without specifying the signature multiple times (or maybe we should, 
: since
: it's MMD). Now
: 
: Yes, the signatures are different--the first two multis specify subtypes 
: as their signatures, the last specifies a canonical type.

Every scalar value is a one-element subset of its type, so you can just write:

   multi sub SomeThing(Num 4, Num $b)  { $b + 2  }
   multi sub SomeThing(Num $a, Num 3)  { $a + 1  }
   multi sub SomeThing(Num $a, Num $b) { $a * $b }

or even just

   multi sub SomeThing(4, Num $b)  { $b + 2  }
   multi sub SomeThing(Num $a, 3)  { $a + 1  }
   multi sub SomeThing(Num $a, Num $b) { $a * $b }

Though 3 and 4 are arguably going to match against Int rather than Num...

Larry

Re: but semantics (was Re: Naming the method form of s///)

[Larry Wall]

On Mon, Sep 04, 2006 at 08:54:02PM +0200, TSa wrote:
: But are assignment ops allowed as initializer?
: 
:   my $z = $p but= { .y = 17 };

Why not?  It's only the first = that's potentially special.  (And it's
only for non-my, since my's = is an ordinary assignment at normal
run time.)  I don't see much syntactic difference between your example and

state $z = $p += 17;

The fact that both of them modify $p in passing is unrelated to the
eventual use of the value to initialize something else.

Larry

Re: but semantics (was Re: Naming the method form of s///)

[Larry Wall]

On Mon, Sep 11, 2006 at 11:12:00AM -0700, Larry Wall wrote:
: On Mon, Sep 04, 2006 at 08:54:02PM +0200, TSa wrote:
: : But are assignment ops allowed as initializer?
: : 
: :   my $z = $p but= { .y = 17 };
: 
: Why not?  It's only the first = that's potentially special.  (And it's
: only for non-my, since my's = is an ordinary assignment at normal
: run time.)  I don't see much syntactic difference between your example and
: 
: state $z = $p += 17;
: 
: The fact that both of them modify $p in passing is unrelated to the
: eventual use of the value to initialize something else.

Well, okay, I should clarify that.  The meaning of $p += 17 is
unrelated.  However, the declarator before the = does control when
and how often that expression is evaluated.

Larry

Re: multi method dispatching of optional arguments (further refined)

[Ph. Marek]

On Tuesday 05 September 2006 07:52, Trey Harris wrote:
 I don't think you're dumb; the Synopses just require that you intuit
 certain things from each other, from examples in other Synopses, and so on
 in a Perlish sort of way; what you're looking for is not spelled out
 explicitly.  It can be found by noticing how you specify subtypes, along
 with noticing that subtypes can be specified as parameter types.  There's
 also an example showing explicitly what you want in S12.
Ok, I'll try to dive through the documentation before asking questions.

 It's just

 multi sub SomeThing(Num $a where {$^a == 4}, Num $b) { $b + 2  }
 multi sub SomeThing(Num $a, Num $b where {$^b == 3}) { $a + 1  }
 multi sub SomeThing(Num $a, Num $b)  { $a * $b }

 Yes, the signatures are different--the first two multis specify subtypes
 as their signatures, the last specifies a canonical type.
Thank you *very* much! That clears it up.


Regards,

Phil

Re: multi method dispatching of optional arguments (further refined)

[Ruud H.G. van Tol]

Ph. Marek schreef:


 [Haskell]
 SomeThing a b
  | a = 4 : b+2
  | b = 3 : a+1
  | otherwise : a*b

 In Perl5 this looks like
 
 sub SomeThing
 {
   my($a, $b)[EMAIL PROTECTED];
 
   return b+2 if ($a == 4);
   return a+1 if ($b == 3);
   return a*b;
 }


Or like:

  sub SomeThing
  {
alias my ($p, $q) = @_ ;

$p == 4 ? $q + 2 :
$q == 3 ? $p + 1 :
  $p * $q ;
  }

-- 
Groet, Ruud

Re: multi method dispatching of optional arguments (further refined)

[Audrey Tang]

2006/9/4, Ph. Marek [EMAIL PROTECTED]:

On Sunday 03 September 2006 14:25, Mark Stosberg wrote:
 Luke Palmer wrote:
  On 9/3/06, Mark Stosberg [EMAIL PROTECTED] wrote:
  Note that the variant /with/ the parameter can be considered an exact
  match, but but the variant /without/ it cannot be considered an exact
  match.
Excuse me for getting into this thread with only minor knowledge about perl6,
but will there be MMD based on the *value* of parameters? Like Haskell has.


Why, yes, see the various Unpacking sections in S06, as well as where
type constraints.  We're st^H^Hadapting as much as we can. :-)

Audrey

Re: but semantics (was Re: Naming the method form of s///)

[TSa]

HaloO,

Trey Harris wrote:
I do not think that Cbut should mutate its LHS, regardless what its 
RHS is.


I strongly agree. We have the mutating version

  $p but= { .y = 17 };

which is just one char longer and nicely blends as a meta operator.
But are assignment ops allowed as initializer?

  my $z = $p but= { .y = 17 };

Regards,
--