[svn:perl6-synopsis] r12875 - doc/trunk/design/syn

[larry]

Author: larry
Date: Mon Oct  9 00:22:24 2006
New Revision: 12875

Modified:
   doc/trunk/design/syn/S05.pod

Log:
P5's s[pat][repl] syntax is dead, now use s[pat] = "repl"


Modified: doc/trunk/design/syn/S05.pod
==
--- doc/trunk/design/syn/S05.pod(original)
+++ doc/trunk/design/syn/S05.podMon Oct  9 00:22:24 2006
@@ -14,9 +14,9 @@
Maintainer: Patrick Michaud <[EMAIL PROTECTED]> and
Larry Wall <[EMAIL PROTECTED]>
Date: 24 Jun 2002
-   Last Modified: 4 Oct 2006
+   Last Modified: 8 Oct 2006
Number: 5
-   Version: 35
+   Version: 36
 
 This document summarizes Apocalypse 5, which is about the new regex
 syntax.  We now try to call them I rather than "regular
@@ -88,10 +88,18 @@
 
  s/pattern/{ doit() }/
 
+or:
+
+ s[pattern] = doit()
+
 Instead of C say:
 
  s/pattern/{ eval doit() }/
 
+or:
+
+ s[pattern] = eval doit()
+
 =item *
 
 Modifiers are now placed as adverbs at the I of a match/substitution:
@@ -2876,15 +2884,71 @@
 the longest one wins.  In the case of two identical sequences the
 first in order wins.
 
+=back
+
+=head1 Substitution
+
 There are also method forms of C and C:
 
- $str.match(//);
- $str.subst(//, "replacement");
- $str.subst(//, {"replacement"});
- $str.=subst(//, "replacement");
- $str.=subst(//, {"replacement"});
+ $str.match(/pat/);
+ $str.subst(/pat/, "replacement");
+ $str.subst(/pat/, {"replacement"});
+ $str.=subst(/pat/, "replacement");
+ $str.=subst(/pat/, {"replacement"});
 
-=back
+There is no syntactic sugar here, so in order to get deferred
+evaluation of the replacement you must put it into a closure.  The
+syntactic sugar is provided only by the quotelike forms.  First there
+is the standard "triple quote" form:
+
+s/pattern/replacement/
+
+Only non-bracket characters may be used for the "triple quote".  The
+right side is always evaluated as if it were a double-quoted string
+regardless of the quote chosen.
+
+As with Perl 5, a bracketing form is also supported, but unlike Perl 5,
+Perl 6 uses the brackets I around the pattern.  The replacement
+is then specified as if it were an ordinary item assignment, with ordinary
+quoting rules.  To pick your own quotes on the right just use one of the C
+forms.  The substitution above is equivalent to:
+
+s[pattern] = "replacement"
+
+or
+
+s[pattern] = qq[replacement]
+
+This is not a normal assigment, since the right side is evaluated each
+time the substitution matches (much like the pseudo-assignment to declarators
+can happen at strange times).  It is therefore treated as a "thunk", that is,
+as if it has implicit curlies around it.  In fact, it makes no sense at
+all to say
+
+s[pattern] = { doit }
+
+because that would try to substitute a closure into the string.
+
+Any scalar assignment operator may be used; the substitution macro
+knows how to turn
+
+$target ~~ s:g [pattern] op= expr
+
+into something like:
+
+$target.subst(rx:g [pattern], { $() op expr })
+
+So, for example, you can multiply every dollar amount by 2 with:
+
+s:g [\$ <( \d+ )>] *= 2
+
+(Of course, the optimizer is free to do something faster than an actual
+method call.)
+
+You'll note from the last example that substitutions only happen on
+the "official" string result of the match, that is, the C<$()> value.
+(Here we captured C<$()> using the C<< <(...)> >> pair; otherwise we
+would have had to use lookbehind to match the C<$>.)
 
 =head1 Positional matching, fixed width types
 

Re: class interface of roles

[TSa]

HaloO,

Stevan Little wrote:

I think that maybe we need to seperate the concept of roles as types
and roles as partial classes, they seem to me to be in conflict with
one another. And even they are not in conflict with one another, I
worry they will bloat the complexity of roles usage.


The bloat aside I believe it is essential to have roles as the key
players of the type system. I propose to handle the typeish aspect of
roles as described in the paper I linked to: there should be a trait
'is augmented' that is applicable to a role and to methods in a role.
In such a method a call to next METHOD should invoke the class's method.
Alternatively we could make the method combination behavior the default
and have a class method trait 'is disambig' or 'is override' for the
case where the class needs to have the final word.

Note that the superclass interface of roles should be mostly inferred
from the usage of next METHOD. As such it is a useful guidance for
error reports in the class composition process.



My experiences thus far with roles in Moose have been that they can be
a really powerful means of reuse. I point you towards Yuval Kogman's
latest work on Class::Workflow, which is basically a loose set of
roles which can be composed into a highly customizable workflow
system. This is where I see the real power of roles coming into play.


Is this a set of free mixins or are they dependent on the class to
provide a certain interface to fully achieve the means of the roles?
I also consider roles a powerful tool but I believe that the type
system should play a role in the composition process that goes beyond
simple checking of name clashes.


Regards,
--

Re: class interface of roles

[TSa]

HaloO,

Jonathan Lang wrote:

TSa wrote:
 > Dispatch depends on a partial ordering of roles.

Could someone please give me an example to illustrate what is meant by
"partial ordering" here?


In addition to Matt Fowles explanation I would like to
give the following example lattice build from the roles

  role A { has $.x }
  role B { has $.y }
  role C { has $.z }

There can be the four union combined roles A|B, A|C, B|C
and A|B|C which complete the type lattice:

 Any={}
/  |  \
   /   |   \
  /|\
 / | \
/  |  \
  A={x}  B={y}  C={z}
   | \/ \/ |
   |  \  /   \  /  |
   |   \/ \/   |
   |   /\ /\   |
   |  /  \   /  \  |
   | /\ /\ |
 A|B={x,y} A|C={x,z} B|C={y,z}
\  |  /
 \ | /
  \|/
   \   |   /
\  |  /
A|B|C={x,y,z}

Note that A = (A|B) & (A|C) is the intersection type of A|B and A|C.
Note further that A|B is a subtype of A and B written A|B <: A and
A|B <: B and so on. Usually the A|B|C is called Bottom or some such.
I think it is the Whatever type of Perl6. It is the glb (greatest lower
bound) of A, B and C. In a larger lattice this type gets larger as well.
Any is the trivial supertype of all types.

This lattice can then be used for type checks and specificity
comparisons in dispatch. BTW, such a lattice can be calculated lazily
from any set of packages. In pure MMD the selected target has to be
the most specific in all dispatch relevant positions.

Regards,
--

Re: class interface of roles

[TSa]

HaloO,

TSa wrote:

Note that the superclass interface of roles should be mostly inferred
from the usage of next METHOD. As such it is a useful guidance for
error reports in the class composition process.


Actually 'next METHOD' doesn't catch all superclass interface issues.
There is the simple case of calling e.g. accessor methods on super
which should result in the requirement to provide them. So I still
propose a super keyword that in roles means the object as seen from
the uncomposed class.


Regards,
--

Re: class interface of roles

[TSa]

HaloO,

Stevan Little wrote:

I do not think method combination should be the default for role
composition, it would defeat the composeability of roles because you
would never have conflicts.


I don't get that. The type system would give compile time errors.
The current spec means that in case of a "conflicting" method the
class version simply overrides the role version. That is there is
simple, short or long name based "conflict" checking with priority
to the class.



 > I see that quite different: roles are the primary carrier of type
 > information!

Well yes, they do seem to have taken on this role ;).


If it is not roles that carry type information then the Perl6 type
system is as of now completely unspecced. Even with roles I miss
some clear statements about their theoretical background.



However, roles
as originally envisioned in the Traits paper are not related to the
type system, but instead related to class/object system. In fact the
Trait paper gave it's examples in Smalltalk, which is not a strongly
typed language (unless you count the idea that *everything* is an
object and therefore that is their type).


Remember the paper did not include state for traits and thus nicely
avoided several typing issues particularly in SmallTalk that is based
on single inheritance and dispatch along these lines.



I think we need to be careful in how we associate roles with the type
system and how we assocaite them with the object system. I worry that
they will end up with conflicting needs and responsibilities and roles
will end up being too complex to be truely useful.


My current understanding is that properly typed roles can obliviate
the need of the things described in theory.pod and directly go with
F-bounded polymorphism as the theoretical model of the type system.
It e.g. is strong enough to model Haskell type classes. Note that there
are free mixins that pose no requirements on the class in the theory
as described in the article.



 > Dispatch depends on a partial ordering of roles.

Type based dispatch does (MMD), but class based method dispatch
doesn't need it at all.


I strongly agree. The two hierarchies should be separated. The
only interweaving that occurs is the class composition process.
And this process should IMHO be directed by the type system and
provide for method combination when the correct typing of the role
requires it. Typical examples that need method combination are
equality checking, sorting support and generic container types.

There seems to be another connection from the class hierarchy to
the role hierarchy that is that a class has a role of the same
name so that class names can be used where a type is expected or
however this is supposed to work. In the end there shall be some
mixing of class and type based dispatch or some kind of embedding
of the class dispatch into type dispatch.



The whole fact that dispatching requires roles to be partially ordered
actually tells me that maybe roles should not be so hinged to the type
system since roles are meant to be unordered.


But how else do we define a subtype relation if not through a role
type lattice?



Possiblely we should be seeing roles as a way of *implementing* the
types, and not as a core component of the type system itself?


Hmm, again what is the type system then? All indications from the
Synopsis and this list go for roles taking over the responsibility
of key player in the type department. E.g. type parameters also go
with roles not with classes.


Regards,
--

Re: class interface of roles

[TSa]

HaloO,

TSa wrote:

Note that A = (A|B) & (A|C) is the intersection type of A|B and A|C.
Note further that A|B is a subtype of A and B written A|B <: A and
A|B <: B and so on. Usually the A|B|C is called Bottom or some such.
I think it is the Whatever type of Perl6. It is the glb (greatest lower
bound) of A, B and C. In a larger lattice this type gets larger as well.
Any is the trivial supertype of all types.


Damn it! I always puzzle glb and lub (least upper bound). So it should
read lub there. This is because the intension set gets larger even
though a subtype is formed. Note that the extension set "the instances"
becomes smaller! In a limiting case the Whatever type has got no
instances at all :)

Sorry,
--

[svn:perl6-synopsis] r12933 - doc/trunk/design/syn

[larry]

Author: larry
Date: Mon Oct  9 08:34:36 2006
New Revision: 12933

Modified:
   doc/trunk/design/syn/S02.pod
   doc/trunk/design/syn/S05.pod

Log:
Quote and regex adverbs may now take only parentheses as brackets.


Modified: doc/trunk/design/syn/S02.pod
==
--- doc/trunk/design/syn/S02.pod(original)
+++ doc/trunk/design/syn/S02.podMon Oct  9 08:34:36 2006
@@ -12,9 +12,9 @@
 
   Maintainer: Larry Wall <[EMAIL PROTECTED]>
   Date: 10 Aug 2004
-  Last Modified: 8 Oct 2006
+  Last Modified: 9 Oct 2006
   Number: 2
-  Version: 75
+  Version: 76
 
 This document summarizes Apocalypse 2, which covers small-scale
 lexical items and typological issues.  (These Synopses also contain
@@ -1476,17 +1476,17 @@
 There is now a generalized adverbial form of Pair notation.  The
 following table shows the correspondence to the "fatarrow" notation:
 
-Fat arrow  Adverbial pair
-=  ==
+Fat arrow  Adverbial pair  Paren form
+=  ==  ==
 a => 1 :a
 a => 0 :!a
 a => 0 :a(0)
 a => $x:a($x)
-a => 'foo' :a
-a =>  :a
-a => «$foo @bar»   :a«$foo @bar»
-a => {...} :a{...}
-a => [...] :a[...]
+a => 'foo' :a :a()
+a =>  :a :a()
+a => «$foo @bar»   :a«$foo @bar»   :a(«$foo @bar»)
+a => {...} :a{...} :a({...})
+a => [...] :a[...] :a([...])
 a => $a:$a
 a => @a:@a
 a => %a:%a
@@ -1518,7 +1518,12 @@
 If that's not intended, you must use whitespace between the adverb and
 the opening bracket.  The syntax of individual adverbs is the same
 everywhere in Perl 6.  There are no exceptions based on whether an
-argument is wanted or not.  Except as noted above, the parser always
+argument is wanted or not.  (There is a minor exception for quote and
+regex adverbs, which accept I parentheses as their bracketing
+operator, and ignore other brackets, which must be placed in parens
+if desired.  See "Paren form" in the table above.)
+
+Except as noted above, the parser always
 looks for the brackets.  Despite not indicating a true subscript,
 the brackets are similarly parsed as postfix operators.  As postfixes
 the brackets may be separated from their initial C<:foo> with either
@@ -1566,7 +1571,7 @@
 
 quote qx = 'qq:x';  # equivalent to P5's qx//
 quote qTO = 'qq:x:w:to';# qq:x:w:to//
-quote circumfix:<❰ ❱> = q:code { .quoteharder };  # or some such...
+quote circumfix:<❰ ❱> = q:code{ .quoteharder };  # or some such...
 
 In particular, all these forms disable the lookahead for an adverbial argument,
 as if there were a space after the keyword.  So although
@@ -1594,10 +1599,8 @@
 
 q:n[stuff]
 
-is not so fine, if the user intended "stuff" to be the string rather
-than an argument to C<:n>.  Basically, you'll be fine if you just
-never use parens for quote delimiters, and always put a space after
-your adverbs.
+also happens to work because quote adverbs only all the paren form of
+bracketed adverbs.
 
 If this is all too much of a hardship, you can define your own quote
 adverbs and operators as standard macros.  The main difference is that,
@@ -1609,8 +1612,8 @@
 
 macro qn { 'q:n' }
 
-does I disable the subsequent search for an argument to C<:n>.  To
-get the equivalent, you need to add a space:
+does I disable the subsequent search for a parenthesized argument
+to C<:n>.  To get the equivalent, you need to add a space:
 
 macro qn { 'q:n ' }
 

Modified: doc/trunk/design/syn/S05.pod
==
--- doc/trunk/design/syn/S05.pod(original)
+++ doc/trunk/design/syn/S05.podMon Oct  9 08:34:36 2006
@@ -14,9 +14,9 @@
Maintainer: Patrick Michaud <[EMAIL PROTECTED]> and
Larry Wall <[EMAIL PROTECTED]>
Date: 24 Jun 2002
-   Last Modified: 8 Oct 2006
+   Last Modified: 9 Oct 2006
Number: 5
-   Version: 36
+   Version: 37
 
 This document summarizes Apocalypse 5, which is about the new regex
 syntax.  We now try to call them I rather than "regular
@@ -108,8 +108,8 @@
 
 Every modifier must start with its own colon.  The delimiter must be
 separated from the final modifier by whitespace if it would otherwise be taken
-as an argument to the preceding modifier (which is true for any
-bracketing character).
+as an argument to the preceding modifier (which is true if and only if
+the next character is a left parenthesis.)
 
 =item *
 
@@ -180,7 +180,7 @@
 
 But in the case of
 
- m:s {(a|\*) (b|\+)}
+ m:s{(a|\*) (b|\+)}
 
 or equivalently,
 
@@ -257,7 +257,7 @@
 which is almost the same as:
 
  $_.pos = 0;
- s:c [ () = (\N+) $$] [$0 => $1] for 1..4;
+ s:c[ () = (\N+) $$] = "$0 =

[svn:perl6-synopsis] r12936 - doc/trunk/design/syn

[larry]

Author: larry
Date: Mon Oct  9 08:44:59 2006
New Revision: 12936

Modified:
   doc/trunk/design/syn/S02.pod

Log:
bleah, typo from ENOCAFFEINE


Modified: doc/trunk/design/syn/S02.pod
==
--- doc/trunk/design/syn/S02.pod(original)
+++ doc/trunk/design/syn/S02.podMon Oct  9 08:44:59 2006
@@ -1599,7 +1599,7 @@
 
 q:n[stuff]
 
-also happens to work because quote adverbs only all the paren form of
+also happens to work because quote adverbs only allow the paren form of
 bracketed adverbs.
 
 If this is all too much of a hardship, you can define your own quote

Bytes make no sense on text strings

[Juerd]

I don't understand why having :bytes for things like s/// would be a
good thing.

A Str doesn't have bytes, just like how a Buf doesn't have characters.

To get bytes out of a Str, you need an encoding. There will be an
internal encoding, but exposing it in this way is probably just asking
for a lot of trouble: inconsistent (invalid) data that internals rely
on, and the inability to switch the internal encoding later. Or, for
example, to keep things 8bit encoded as an optimization until something
demands more than that. 

As I understand it, a Str is a unicode string, not a UTF-8 string.

I propose that using :bytes on a text string throws an exception.
-- 
korajn salutojn,

  juerd waalboer:  perl hacker  <[EMAIL PROTECTED]>  
  convolution: ict solutions and consultancy <[EMAIL PROTECTED]>

Ik vertrouw stemcomputers niet.
Zie .

Re: Bytes make no sense on text strings

[Larry Wall]

On Mon, Oct 09, 2006 at 11:40:09PM +0200, Juerd wrote:
: I don't understand why having :bytes for things like s/// would be a
: good thing.
: 
: A Str doesn't have bytes, just like how a Buf doesn't have characters.
: 
: To get bytes out of a Str, you need an encoding. There will be an
: internal encoding, but exposing it in this way is probably just asking
: for a lot of trouble: inconsistent (invalid) data that internals rely
: on, and the inability to switch the internal encoding later. Or, for
: example, to keep things 8bit encoded as an optimization until something
: demands more than that. 
: 
: As I understand it, a Str is a unicode string, not a UTF-8 string.

A string object is allowed to present multiple interfaces at different
abstraction levels.  If a string object allows multiple abstraction levels
it is part of the object's job in life to keep those abstraction levels
in sync with each other.  This is one of the reasons it's Very Important
that string positions be considered opaque abstractions and not numbers.

: I propose that using :bytes on a text string throws an exception.

It will if the string in question doesn't support the bytes abstraction
level, which might well be most of them.

Larry