Re: r31755 -[S05] specifiy that .parse can invoke other subrules than TOP by name
Note that I sent a patch to that effect to p6c Jun 2 in a mail titled
support of parsing from a non TOP rule
that has not been applied. It still works. Attached below. Testable by :
use Test; grammar A { token hi { hi } }; ok A.parse( 'hi',
:rulehi) eq 'hi', Grammar.parse: :rulesomerule
On Sun, Jul 18, 2010 at 10:40 PM, pugs-comm...@feather.perl6.nl wrote:
Author: moritz
Date: 2010-07-18 22:40:18 +0200 (Sun, 18 Jul 2010)
New Revision: 31755
Modified:
docs/Perl6/Spec/S05-regex.pod
Log:
[S05] specifiy that .parse can invoke other subrules than TOP by name
Modified: docs/Perl6/Spec/S05-regex.pod
===
--- docs/Perl6/Spec/S05-regex.pod 2010-07-18 15:13:40 UTC (rev 31754)
+++ docs/Perl6/Spec/S05-regex.pod 2010-07-18 20:40:18 UTC (rev 31755)
@@ -3943,7 +3943,10 @@
All grammar objects are derived from CCursor, so every grammar object's
value embodies the current state of the current match. This new grammar
object is then passed as the invocant to the CTOP method (regex, token,
-or rule) of CMyGrammar. Grammar objects are considered immutable, so
+or rule) of CMyGrammar. The default rule name to call can be overridden
with
+the C:rule named argument of the Cparse method.
+
+Grammar objects are considered immutable, so
every match returns a different match state, and multiple match states may
exist simultaneously. Each such match state is considered a hypothesis on
how the pattern will eventually match. A backtrackable choice in pattern
--
cognominal stef
parrot-parse_with_rule.2010-06-02.patch
Description: Binary data
optional rules cluttering parse trees
When doing an analyse of a sample parse tree, I note that it is
cluttered by the reduction of optional subrules
to generate a zero length parse subtree. That is, rules with a '?'
quantifier matching zero time.
Suppressing such matching rules from the parse tree would make it
easier to read.
Additionnally, the actions associated with such a quantified rule
matching once would not necessitate a trailing [0].
my $twigil := $twigil ?? ~$twigil[0] !! '';
would read
my $twigil := $twigil ?? ~$twigil !! '';
To substantiate my claim of the omnipresence of arrays of length 0 for
optional subrules,
I analyse the parse tree generated by the following program...
sub a ( |$c ($a, $b)) { say $c }
a(1,2);
my $a;
say $a+4*3
..using this one liner
perl -ne '/\(\w+)\.*size:(\d+)/ and ++$a[$2] and !$2 $r{$1}++ ;
END { $,=, ; print $i++ . : $_\n for @a; print $_ : $r{$_}\n
for sort keys %r }'
..with these results
0 : 49
1 : 9
2 : 1
3 :
4 : 1
arglist : 3
colonpair : 6
default_value : 3
morename : 6
post_constraint : 2
semilist : 1
signature : 1
statement_mod_cond : 5
statement_mod_loop : 5
trait : 5
twigil : 6
type_constraint : 3
typename : 3
It means that most arrays, 49 of them, in the parse tree are of zero
length. When counting rules generating these arrays, we see that most
of them are used in the Perl 6 grammar with a '?' quantifier.
perl -ne '/\(\w+)\/ and $i++; END { print $i }' prg.parsed
162
Counting 162 reductions, that means that more than one fourth of them
are spurious.
When analyzing the rules that have generated 0-length arrays, we
easily understand they are not specific
to the sample program. For example, in normal programs, most
statements have indeed no optional modifiers and many variables don't
have twigils.
--
cognominal stef
Re: How to define a new value type?
On Tue, Sep 16, 2008 at 6:11 AM, Patrick R. Michaud [EMAIL PROTECTED] wrote: On Mon, Sep 15, 2008 at 10:09:41PM -0500, John M. Dlugosz wrote: Darren Duncan darren-at-darrenduncan.net |Perl 6| wrote: So, how does one get an object to pretend to be a value type for purposes of assignment? I have been under the impression that value types are supposed to define immutable objects, or at least objects that pretend to be immutable; any operators on them would produce new objects rather than mutating existing ones. [...] I agree. A value type is immutable, where the identity is keyed to the value. Making a value type that can mutate can cause confusion. I'm now thinking that the normal = you write should always give reference assignment semantics. In the case of value types, assuming they are indeed immutable, it does not matter whether they have value or reference assignment semantics, since the same value will give the same identity, regardless of memory (or in-register) representation. [...] I think I can accept this reasoning for now, although it has some strong implications for managing array elements and binding operations (especially given Parrot's model of them). But we'll come up with something, and thanks. Pm I don't understand how = differs with that semantic from := I would expect that = would make a copy (clone?) of the object. For a mutable object, I don't know if that copy should be immediate or deffered by a mechanism of copy on write. Probably that behavior could depend on a trait of the class that implements to be copied object. -- cognominal stef
yada yada yada in regex
what is the equivalent convention for yadayadayada in regex. Cuz ...
is alread meaningful in regex. Should I use ... or {...} ?
Should the first be predefined?
I want something that is a placeholder that parses but fails if
someone pastes it. In other words the equivalent of
a sub yada yada yada
--
cognominal stef
Re: type sigils redux, and new unary ^ operator
Larry Wall a écrit :
| On Wed, Nov 23, 2005 at 07:10:39PM +0100, Juerd wrote:
| : Ruud H.G. van Tol skribis 2005-11-23 19:03 (+0100):
| : Doesn't ^5 encourage [EMAIL PROTECTED] too much?
| : Can you explain when that creates a problem?
| :
| : It's not about problems in execution, it's about expression.
| :
| : [EMAIL PROTECTED] returns the *number of elements*, not the index of the
last
| : element plus one. It should not be used for index math.
| :
| : There are cases where we should write @foo.last + 1, even though the
| : result will in almost all cases be the same as [EMAIL PROTECTED], and there
are
| : cases where we should write @foo - 1, even though the result will be the
| : same as that of @foo.last.
| :
| : That almost all arrays range from 0..i is no reason to write bad code.
| :
| : Maybe someone doing
| :for ([EMAIL PROTECTED])-$i { say @foo[$i] }
| :
| : That should be ^(@foo.last + 1), or not using ^ at all. I'd prefer the
| : latter.
|
| I don't think that's a big problem. Formal arrays are allowed to view
| all incoming array parameters as 0-based even if created elsewhere as
| non-0-based arrays. Forcing everyone to use the same circumlocutions
| because someone somewhere *might* use a non-0-based view of their
| arrays is just falling back into one of those magical action at a
| distance traps, I think. A non-0-based view is fine in a particular
| lexical scope, but it shouldn't leak out.
|
| Which means you can use [EMAIL PROTECTED] and know it's right in your lexical
| scope.
What about array with holes as supported by Parrot?
Does .elems return the number of elements with or without
the holes?
Does iterating over the array iterates over the holes as well?
That would sound inefficient to do that over a mostly empty array.
Related question, Is there a way to get a list of iterators
that iterate only over the non-holey parts of an array?
--
cognominal stef
|
| Larry
|
Re: What's the latest on Iterators?
Larry Wall a écrit :
| On Fri, Nov 11, 2005 at 08:42:44AM -0500, Joe Gottman wrote:
| : Do functions like map and grep, which in Perl5 return lists, return
| : Iterators in Perl6?
|
| A list may contain iterators. Lists don't eagerly flatten in Perl 6.
|
| : Can an Iterator be passed to a function (like map and grep again)
| : that requires a list as an input?
|
| Certainly. You can pass as many iterators as you like. The range object
| is your prototypical iterator, and you can say:
|
| @results = grep {...} 0..9, 20..29, 40..49;
|
| The list that grep is returning can also function as an iterator, so
| @results isn't necessarily all there after the statement executes.
|
How can Perl6 can consistently cope with side effects if it is not
specified when evaluation is lazy or strict? Is there a trait to say
that a function (here the grepping predicat) does not have
side-effect or is also really functional (so as to permit various
optimizations)?
Ate they pragma to say, from here every function that will be defined will
by default functional or every parameter evaluation will be lazy:
use fun;
use lazy;
sub foo {$a } { ... } # functional and lazy
sub notfunctional($a) isnot fun {...) # can we unset a default attribute?
no fun; # use strict has another meaning btw.
...
use fun, lazy; # also can we do use bundling?
More generally I am worried of the mix of lazy and strict behavior in
the presence of all sorts of side effects that would happen in a random
order depending of the parameter evaluation order.
btw, for strict functions, is the left to right evaluation of
parameters guaranteed?
|
| Larry
|
--
cognominal stef
Re: Mr. Clean vs. Perl 6
On Thu, Jun 30, 2005 at 06:17:14AM -, David Formosa (aka ? the Platypus) wrote: On Thu, 30 Jun 2005 05:17:56 +0300, Yuval Kogman [EMAIL PROTECTED] wrote: [...] I gave Perl 6 to Mr. Clean, and he said that if type inferrence was formalized, and used always, except that it's usually used for performance, and with a lexical pragma can be used to enforce types. I like facist programming when it can help me, so I would like to see something like his proposal. no autocoerce;; my $y =3D 'blah'; my Int $x =3D $y; # compile time type error This scheme is not perfect.. Maybe someone has an idea? I would prefur this to be written. use strict types; I suspect there will be many ways to do types stricture/inference in Perl6. I expect that type modules will influence PIL generation so that people will have to choose the structures they want at a given place: use Types::some-type-sheme or even use Types::Functional::some-sub-type-sheme If such a typing mode gives us an haskell with some Perl6 concrete syntax we eventually could port the whole Haskell environment as Perl6. docs/notes/recursive_polymorphism_and_type_inference is a start in that direction. The best we can hope is that PIL generarion will eventually be written in Perl6. I hope Perl6 will eventually become more expressive than Haskell for handling type problems. So Perl6 could become the playground of type theory searchers. I have a dream... At any given place, be able to choose between the power of functional programming or the convenience of imperative programming. both while keeping Perl6 nice syntax. -- cognominal stef
trait and properties thru getter/setters
There is syntax to define trait and properties but is there an API? my $b = eval '$a but true'; # setting a true property # API to do it without an eval? A trait setter probably does not make sense but for the implementer because it should not be set at run time. Incidentally, in a interactive environment it would be cool to access the documentation of variables and functions using properties. Say doc and udoc respectively for the full and one line version. -- cognominal stef
Re: trait and properties thru getter/setters
On Fri, May 13, 2005 at 06:37:50PM +, [EMAIL PROTECTED] wrote: There is syntax to define trait and properties but is there an API? my $b = eval '$a but true'; # setting a true property # API to do it without an eval? I don't understand why you think you need the eval here? My question is more generic than my example. I may not know at compile time what is the value/trait name and its value. A trait setter probably does not make sense but for the implementer because it should not be set at run time. Incidentally, in a interactive environment it would be cool to access the documentation of variables and functions using properties. Say doc and udoc respectively for the full and one line version. -- Mark Biggar -- cognominal stef
Re: trait and properties thru getter/setters
On Fri, May 13, 2005 at 12:31:09PM -0700, Larry Wall wrote: On Fri, May 13, 2005 at 12:26:22PM -0700, Brent 'Dax' Royal-Gordon wrote: : Well, the value's pretty easy--just pass in a variable: : : my $b = $a is foo($bar); As we currently have it, that is not legal syntax. is may only be applied to declarations. You must use does or but to mixin things at run-time (where this includes the compiler's run-time bits). And what about the getter part of my question? :) Larry -- cognominal stef
Re: Blocks, continuations and eval()
Hi, I am making a presentation about Perl6 this week end. My point will be: the next generation of applicative languages will be scripting languages because they have come of age. Alternatives don't cut it anymore. Indeed C and C++ are memory allocation nightmare; Java and C# don't have read-eval loop, a necessary condition for rapid learning and development. Functional languages like haskell or ocaml are very powerful but needs massive wetware reconfiguration to get used to the syntax and semantic. So I will make do a presentation of Perl6 and Parrot features to make my point about upcoming scripting languages. I have a few questions inspired by my recently acquired knowledge about functional languages. Perl6 being the ultimate syncretist language, I wonder if some functional features will make it into Perl6. I know we already got currying. A very nice feature of Haskell and *ml is the possibility to define complex datastructures types and the control flow that manipulate these structures: constructors and pattern matching. With these languages, in a very deep sense, control flow is pattern matching. Can we expect Perl6 to propose something similar? If yes, could be the matching part folded into the rule syntax? Rules are about identifying structures in parsed strings and acting accordingly. Partern matching is about identify typed structures and acting accordingly. There is a similarity there. Also we may want to match both at the structural level and at the string level. Or is this asking too much of rules, that have already swallowed both lexing and parsing. The notion of data type become very useful in Perl6 for people who want it. In fact, Perl6 is a mix of dynamic and static types (bindings). I think type theory handles type inference in this kind of langage with something called dependant type. Though I have to go thru ATTaPl to get it. Perl, like many scripting language is very lax and, when needed, converts implicitely values within expressions. This is nice, but I think that makes type inference impossible. Type inference is good because it allows to generate very efficient/strict code with very little type annotations. Can we expect in a distance feature a pragmatic mode convention to control automatic type conversions if any and the type inference scheme chosen when/if implemented? -- cognominal stef
Re: Blocks, continuations and eval()
On Fri, Apr 22, 2005 at 08:13:58PM +0200, Stéphane Payrard wrote:
On Fri, Apr 22, 2005 at 09:32:55AM -0700, Larry Wall wrote:
Thank you for your detailled answer. I still don't get what you mean
by [] pattern matching arguments.
Do you mean smart pattern matching on composite values?
A lot of features are making it into Perl 6 that have historically been
associated with functional programming. Off the top of my head:
...
[] pattern matching arguments
Thx to people on #perl6, I got it. It is a form of pattern matching
on arguments. It is described in S06 in under the headers Unpacking
hash parameters, Unpacking array parameters.
sub quicksort ([$pivot, [EMAIL PROTECTED], ?$reverse, ?$inplace) {
...
}
So if we mix that with typing, we will end with full fledged unification?
--
cognominal stef
scoping functions as list operators?
Giving scoping functions the status of list operators would allow to drop parentheses when not used in conjunction with initializer so one could write: my $a, $b, $c; instead of my ($a, $b, $c); Most people use scoping functions as the top most function of the corresponding statement AST so that should not bite unsuspecting people. Probably many more people that don't use stricture are currently caught by the current convention that obliges to parenthesize when multiple variables are declared. In a sense, so many people have been bitten by surprising precedence, that they cargo-cult parentheses as the list operator. In my detestation of gratuitous parenthesses, I would additionally propose a low precedence assignement operator if I could find a good sign for it. my $a, $b, $c := 1..3 ; # too bad := is already taken. # set? I don't think so. my $a, $b, $c set 1..3 ; # alphabetic like and, or, xor? # and what precedence relative to them? -- stef
Re: scoping functions as list operators?
On Fri, Feb 25, 2005 at 03:56:06AM +0100, Stéphane Payrard wrote: Giving scoping functions the status of list operators would allow to drop parentheses when not used in conjunction with initializer so one could write: my $a, $b, $c; instead of my ($a, $b, $c); Too bad that in English there is no plural for my. In French it would work fine mon $a; # French for Cmy, singular # Cmes as a list operator mes $a, $b, $c; # French for Cmy, plural -- stef
Re: How are types related to classes and roles?
On Thu, Feb 24, 2005 at 09:42:30AM -0800, Larry Wall wrote: Anyway, I don't profess to have thought deeply about type inferencing. But I do know that I don't want to turn Perl 6 into ML just yet... Larry Speaking of ML, it appears to me that Perl6 rules are a mechanism that can act very much like ML variant pattern matching. What I fail to see in Perl6 is the equivalent of ML variant constructors. Perhaps, you don't want to turn Perl 6 into ML just yet. :) But if it comes for almost free... -- stef
Re: scoping functions as list operators?
On Thu, Feb 24, 2005 at 11:09:24PM -0500, Uri Guttman wrote: SP == Stéphane Payrard [EMAIL PROTECTED] writes: SP On Fri, Feb 25, 2005 at 03:56:06AM +0100, Stéphane Payrard wrote: Giving scoping functions the status of list operators would allow to drop parentheses when not used in conjunction with initializer so one could write: my $a, $b, $c; instead of my ($a, $b, $c); SP Too bad that in English there is no plural for my. SP In French it would work fine SP mon $a; # French for Cmy, singular SP # Cmes as a list operator SP mes $a, $b, $c; # French for Cmy, plural well, our is a form of a plural my but it is not a plural of the things that are mine/ours but rather the group owning it (which is the namespace). so we can try: all, mine, these, those, them and the brooklynese variants: dese, dose, dem. :) southern variant: y'all or yall. maybe yall is expanded as yall mine! yall $a, $b, $c = 1 .. 3 ; larry? uri PS if this gets in, i will stop being so bigoted against southern accents! :) -- You have got to find a plural form for all the kind of scopes supported by Perl. Ant that gets us half-way because of the = assignement operator precedence which is wrong in your example. -- stef
slight discrepancy between S2 and S7
S2:
my $foo = 42;
say %MY::$foo;# prints 42
S6:
Perl5ish subroutine declarations
...
sub say { print qq{@_\n}; } # args appear in @_
Because Cprint has no final newline, I would expect Csay will have
one. Final newline or not. What is your say?
--
stef
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
On Fri, Dec 03, 2004 at 06:38:42PM -0800, Larry Wall wrote:
On Fri, Dec 03, 2004 at 06:43:05PM +, Herbert Snorrason wrote:
: This whole issue kind of makes me go 'ugh'. One of the things I like
: best about Perl is the amazing simplicity of the input construct.
Hmm.
while () {...}
for .lines {...}
Looks like a wash to me.
This is a neat win, keyboards favorise alphabetic characters that are
less excentred. Moreover, in some non qwerty layout, to make place for
diacritic characters, some non alphabetic characters are less
accessible, shift or alt-gr is necessary to type them.
Having being used to qwerty keyboards, on a french keyboard, I switch
from azerty to qwerty to program in C or Perl because of their heavy
ratio nonalpha/alpha. But most programmers use their native keyboard
layout.
--
stef
Re: This week's summary
On Mon, Jul 26, 2004 at 10:29:15AM -0700, Brent 'Dax' Royal-Gordon wrote: The Perl 6 Summarizer wrote: The infinite thread Pushing onto lazy lists continued to exercise the p6l crowd (or at least, a subset of it). Larry said that if someone wanted to hack surreal numbers into Perl 6.1 then that would be cool. Care to explain what those are, O great math teacher? Disclaimer, I am no math theacher. :) This is a very interesting class of number that can be used to modelize games. It has designed by the _other_ Conway, the one of game of life fame. The expression surreal number was coined by Knuth. For more info, the wikipedia is your friend: http://en.wikipedia.org/wiki/Surreal_number For the full story, read the book Numbers and Games. I have ordered it a few days ago so I can't comment on it. Brent Dax Royal-Gordon [EMAIL PROTECTED] -- stef
Re: more than one modifier
On Fri, Jun 25, 2004 at 03:38:51PM +0200, [EMAIL PROTECTED] wrote: Hello, I have a wish for Perl6. I think it would be nice to have the possibility for more than one modifier after a simple statement. For example: print $a+$b if $a if $b for 1..3; Gerd Pokorra There are two kind of modifiers, loop modifiers and simple test modifiers. It is unpossible to stack loop modifiers without adding conventions denoting the iterators. One could use as many underscores as the depth of the iterator. Countins underscore would not be a problem knowing that a depth of more than three is probably pathologic. Note that this convention could go as well for embedded normal loop without contextualizers. print $_ $__for 'a'.. 'b' for 1..2 would print 1a 1b 2a 2b Consecutive test modifiers can be replaced by a Cor or a Cand, or better by a C|| or C because the alphabetic version looks too much like a modifier. But too much stacking of modifiers is probably not a good idea. My own take would be to support at most two modifiers of different kind per statement That is at most one loop modifier and at most one simple test modifier per statement. But, in previous mails, Larry ruled for at most one modifier. -- stef
Re: Periodic Table of the Operators
Le Thu, May 27, 2004 at 12:34:32AM +0200, le valeureux mongueur Gabriel Ebner a dit: Hello, Mark Lentczner wrote: http://www.ozonehouse.com/mark/blog/code/PeriodicTable.html What's periodic about it? We hope it will be periodically updated. :) Otherwise, _nice_ table. indee.d Gabriel. -- stef
idiom for filling a counting hash
I use over and over this idiom in perl5:
$a{$_}++ for @a;
This is nice and perlish but it gets easily pretty boring
when dealing with many list/arrays and counting hashes.
I thought overloading the += operator
%a += @a;
Probably that operator should be smart enough to be fed with
a mixed list of array and hashes as well:
%a += ( @a, %h); # would mean %a += ( @a, keys %h)
I am not to sure how one can use hyperators, well I meant the
hyped hyperoperators, to juggle with lists and counting hashes.
One may want to feed multiple arrays to a single hash or one
array to multiple hashes. To add some salt to the problem
Multiple can translate to an array of :
my @ary_of_h of Hash; @ary_of_h += @a;
Having real types in Perl6 will allow to slice, dice, splice data
in many nice ways. Damian can even spice that with junctions.
Fear. Fear.
--
stef
Re: C style conditional statements
Le Wed, May 12, 2004 at 02:00:42AM +0200, le valeureux mongueur Pedro Larroy a dit:
Hi
Is there any chance that in perl6 there will be the possibility to write
if/else statements without {}s with the condition at the beginning?
Like
if (condition)
statement;
In order not to break traditional C culture. Is there any technical
reason why it wasn't done in perl5?
In Perl5, variable declaration are an executable statement. Also the
scope of a variable starts from its declaration and ends at the
end of the immediately enclosing block. Things would get
problematic if the branches of an if/else were not scoped.
What would be the meaning of :
if (condition)
my $foo = 'bar';
else
print $foo;
Now about the syntax, it is not clear if the statement before
the 'else' can/must be semicolon terminated.
A similar example of stange meshing of scope and flow of control in
perl5 is:
my $foo = $bar if $buz;
I can't even remember what it supposed to do when it is in a loop
where $bar and $buz change. And I would bet that the exact
semantic is not even documented in most books.
--
stef
Regards.
--
Pedro Larroy Tovar | Linux Network consultant | piotr%member.fsf.org
Software patents are a threat to innovation in Europe please check:
http://www.eurolinux.org/
Re: semantic and implementation of pairs
I have confused assignement and initialisation in my previous mail. Because they are two different operations, there is no problem they have different semantics. A6 described both operations. It described pairs as arguments used to initialize parameters and pairs in assignement. -- stef
semantic and implementation of pairs
My understanding of the semantic of pairs as in A6: A pair in a given scalar context should return its first element coerced to match the said context. This seems to be a prerequisite to use pairs as function arguments. Example with the boolean context: bool $b = a = 10; # $b == 1 But what about CScalar, CRef and Cstring contexts? I expect an object to return a reference to itself in Ref Context. I have trouble to remember if assignation in Scalar context gives a reference to the assigned object, or its size. I expect that assigning a to string gets me a string that can usually get evaluated to return a value equal to the the original one. In the three cases where I assume to have described the nornal semantic, I don't get a behavior compatible with my understanding of pairs used as arguments. To solve that dilemma, can we just say that pairs used as arguments is a special case. Now let's talk about the implementation of perl pairs and lisp pairs as a PMC, assuming pairs as arguments is a special case. We need both the normal pair semantic and the one about arguments as pairs. This mean that the argument as pair is implemented as keyed PMC methods. I propose special methods to avoid that overhead. They are the moral equivalent of the lisp car and cdr in a language with context. These methods would be: (get|set)_first_(integer|number|bool|pmc) (get|set)_second_(integer|number|bool|pmc) Note that they can be used as optimization for array pmcs, Now I run in a second problem that I have already touched on perl6-internal. For storage optimization purposes, I want to avoid as possible to use pmcs for pairs elements. Say I set the key is an int (they can be in Perl6?), I want to avoid to promote it to a PMC. But I must do it if one takes a reference to that key. This happens if someone does a get_first_pmc() or a get_second_pmc(). But sometimes one would just access a pmc to clone it. This does not mean that a reference is really taken and that there is no need to promote the element to a pmc. So we need a clone_first() and a clone_second() to avoid unecessary element promotion. More generally, in pmcs that act as composite containers which elements are not necessarily pmc, we need these cloning methods as well: PMC* clone_pmc_keyed(PMC* key) PMC* clone_pmc_keyed_int(INTVAL key) PMC* clone_pmc_keyed_str(STRING* key) Comments? -- stef
Re: Traits: to renew OO inheritance in a hacker style discussion
On Thu, Feb 12, 2004 at 09:38:47AM -0800, Larry Wall wrote: Yes, that's a very good paper, which is why Perl 6 now has something called Roles, which are intended to degenerate either to Traits or Interfaces. My take on it is that Roles' most important, er, role will be to abstract out the decision to compose or delegate. But we'd like them to function as interfaces when the Role is abstract, and we'd like them to function as Traits when you don't happen to specify any state attributes. But for hiding the delegation decision, you at least have to allow the amount of state that lets you remember the object you're delegating to. Of course, the Traits paper didn't go into traits with state, though it did mention it as a future research topic. We're just doing that future research for them. :-) By the way, we distinguish Traits from traits (which are compile-time properties applied by is. To apply a Role we use does. In a sense, there is no such thing as state. A read-only attribute is a role constituted of one getter method. A write-only attribute is a role constituted of one setter method. A read-write attribute is a role constituted of two methods, one getter and one setter. A noread-nowrite attribute could as well live in a parallel universe. No attributes. It is turtles all the way down. :) More seriously, the mere user of a class has no way to know if he accesses a real attribute or a synthetic one. A synthetic attribute being one that is calculated from real attributes or whose modification affects other attributes. It may interesting to provide syntax to declare the dependancies between attributes even if there is no way to enforce them. Larry
splatting a reference
On Sat, Dec 13, 2003 at 12:12:59PM -0800, Larry Wall wrote: print $ref it doesn't do what you want, but print $ref.as(Array) might work a lot better, though of course print @$ref What is supposed to do the splat operator in this context? My understanding is that when an operator expects something and gets a ref instead, the ref is dereferenced until the expected operand is found. The interpretor barks otherwise. So I expect print *$ref when $ref is ref to an array to be equivalent to print [EMAIL PROTECTED] which in turn should behave like print @$ref because Cprint splats its operands. I don't pretend that Cprint *$ref is very readable, I just ask what it does or if it is at all permitted. -- stef
Re: Vocabulary
A role can also supply one or more attributes. : inheritance (and maybe some other stuff, too). Used with Cdoes. The smalltalk paper you mentionned which talked about roles (under the name of traits) said that roles were stateless. What are the consequences of using stateful roles? A related question. Will getter and setter methods will have the same name as the underlying accessed attributes? -- stef
enums and bitenums
Hi, I don't remember anything about enums and bitenums in the apocalypses. This is probably not very difficult to roll out something using macros but I feel that should belong to the standard language. -- stef
s/// in string context should return the string
s/// in string context should return the string after substituion. It seems obvious to me but I mention it because I can't find it in the apocalypses. -- stef
Re: Next Apocalypse
On Thu, Sep 18, 2003 at 02:12:31PM -0700, chromatic wrote: On Thursday, September 18, 2003, at 12:33 PM, Gordon Henriksen wrote: Ah, shouldn't optimization be automatic? Much preferrable to provide opt-out optimizations instead of opt-in optimizations. No. That's why I tend to opt-out of writing in C and opt-in to writing Perl. Perl (all versions) and Parrot are built around the assumption that just about anything can change at run-time. Optimizing the language for the sake of optimization at the expense of programmer convenience doesn't feel very Perlish to me. With Perl6, few people will compile whole librairies but most will load bytecode. At this late stage there is little place for tunable optimization except JITting or it would defeat the sharing of such code between different intances of Perl6. Nothing will preclude to dynamically extend classes. I note that in Perl6 many optimizations were autoloading for deferring compilation of material until it's really needed. With bytecode, it makes sense (at least optimization-wise) that the programmer decides if his classes will be sealed or some methods to be final because at the user level it is too late to decide. -- stef -- c
Re: Perl and *ML
On Wed, Mar 26, 2003 at 05:40:56PM +0100, Robin Berjon wrote: Dan Sugalski wrote: At 4:47 PM +0100 3/26/03, Robin Berjon wrote: Fast and efficient graphs of all sorts would be very useful. A way to define a complex graph of interlinked arbitrary objects while being reasonable on memory and good with GC would be a definitive big win, especially if it can be lazy. Especially with nice ways to write visitors and easy searches in the graph based on object properties (but I could be asking for too much ;). Probably a bit much, yep. :) I'd be happy with simple graph representation, annotation, and traversal. And for my purposes a DAG is sufficient. Loops are terribly annoying to have to deal with. Efficient annotation and traversal would go a long way, but almost all useful XML representations have loops unfortunately. DAGs wouldn't enough though, most XML tree representations aren't really trees, they're very cyclic. Some automata can treat a stream of events as a B-Tree being visited, but those are rather rare currently. I was under the impression XML was very much a tree, and didn't do loops. Am I missing something here? (I don't, in general, do XML) By loop you mean attributes declared by DTD as IDREFs and pointing to element having the same value for the attribut ID? Like in the example pasted from XML in a nutshell? project project_id=p1 goalDevelop Strategic Plan/goal team_member person=ss078-05-1120/ team_member person=ss987-65-4320/ /project project project_id=p2 goalDeploy Linux/goal team_member person=ss078-05-1120/ team_member person=ss9876-12-3456/ /project employee social_security_label=ss078-05-1120 nameFred Smith/name assignment project_id=p1/ assignment project_id=p2/ /employee employee social_security_label=ss987-65-4320 nameJill Jones/name assignment project_id=p1/ /employee employee social_security_label=ss9876-12-3456 nameSydney Lee/name assignment project_id=p2/ /employee In a way IDREF are similar to symlinks? they cannot create real loops because they are not followed by default by traversal tool juste like find does not follow symlinks by default. -- stef Your impression isn't wrong, it's just that in actual use one needs more information. If you lose the cycles then you could as well just be working on stream of parse events (which is typical in SAX), in which case an in-memory representation is probably not useful. And that's just for basic stuff, if you want to usefully represent ID/IDREFs, QName linking, internal XLinks, etc you're basically pointing from random nodes to other random nodes. Given what you describe plus loops we could take over and do Really Cool Stuff :) -- Robin Berjon [EMAIL PROTECTED] Research Engineer, Expwayhttp://expway.fr/ 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
Re: File operators don't dwim
On Wed, Feb 12, 2003 at 09:17:22AM +0100, Stéphane Payrard wrote:
On Tue, Feb 11, 2003 at 11:42:27PM -0800, Brent Dax wrote:
Stéphane Payrard:
# I was so sure that, in case of success, the file operators
# would return the filename that I wrote the following code to
# print where are the perl interpretors in the PATH. But, in
# case of success, fileops returns 1 not the filename.
#
# local $, = '\n;
# sub mapgrep (@) { my ($fun, @args)=@_; map { {$fun}($_)
# } grep { {$fun}($_) } @args }
# print (mapgrep { -x $_/perl } split /:/, $ENV{PATH}), \n;
#
# Is there a reason why file operators don't dwim?
So you don't have problems with a file name that isn't true, like 0?
Indeed.
Probably my proposition would make more sense in perl6 where the
fileop could return 0 but true in such a case.
May be, it has already proposed and my thought was just a
remembrance. :)
Hem, it would be more correct to say '0' but true. Also my
proposition does (probably) make sense only for fileops that
originally returned a boolean value. Not so sure with these 'but's
that permit to smuggle alternate values of alternate types on the
side.
[snipped]
--
stef
Re: File operators don't dwim
On Tue, Feb 11, 2003 at 11:42:27PM -0800, Brent Dax wrote:
Stéphane Payrard:
# I was so sure that, in case of success, the file operators
# would return the filename that I wrote the following code to
# print where are the perl interpretors in the PATH. But, in
# case of success, fileops returns 1 not the filename.
#
# local $, = '\n;
# sub mapgrep (@) { my ($fun, @args)=@_; map { {$fun}($_)
# } grep { {$fun}($_) } @args }
# print (mapgrep { -x $_/perl } split /:/, $ENV{PATH}), \n;
#
# Is there a reason why file operators don't dwim?
So you don't have problems with a file name that isn't true, like 0?
Indeed.
Probably my proposition would make more sense in perl6 where the
fileop could return 0 but true in such a case.
May be, it has already proposed and my thought was just a
remembrance. :)
[snipped]
--
stef
Re: Arrays vs. Lists
On Fri, Feb 07, 2003 at 02:30:47PM -0500, Mark J. Reed wrote: On 2003-02-07 at 14:26:42, Mark J. Reed wrote: Not really, though. A list can be an lvalue, provided it is a list of lvalues: Note that to avoid the burden of writing an explicit slice, 'undef' is considered as a lvalue in such a context. I see no reason for that behavior to change in perl6: ($a, undef, $b) = (1, 2, 3); # equivalent to ($a,$b) = (1, 3) Note this is only true of undef. You can't stick any literal in its splace. ($a,1,$b) = qw(1,2,3) Can't modify constant item in list assignment at (eval 5)[/usr/lib/perl5/5.8.0/perl5db.pl:17] line 2, at EOF -- stef
newline as statement terminator
In the tradition of Perl concision, I would like newline to be a
statement terminator everywhere it can: that is when
a) the parser expects an operator
_and_ b) we are not in the middle of a parenthesised expression.
Accessorily, it would also help people to switch back and forth
between language that use newline as statement terminator and perl6:
they will not be burn anymore when forgetting a semicolon.
Semicolons are still allowed everywhere as statement terminator
because empty statements are.
So, In the common case, oneliner atomic statements, the proposed rule
means: you can drop the ending semicolon.
BTW: Atomic statement are statement composed of one expression only.
For composite multiline statements, see About the b) rule below.
Multiline atomic statements just have to be broken at the right
place to avoid to break them:
a +
b
is equivalent to
a + b
But
a
+ b
are two statements.
Note that in Perl5, semicolon is not always required as statement
terminator. At the end of a scope, being a closing brace, or the end
of a program, including an explicit eval or an implicit one (perldb
shell).
Note that, for Perl 6, Larry has already opened the path in his fourth apocalypse:
$x = do {
...
} + 1;
is different from
$x = do {
...
}
+ 1;
I just want to make a rule of what Larry made a special case.
About the b) rule.
--
The following code does not parse because of the newlines that are
interpreted as statement terminator.
for
1..10
{ ... }
But
for (
1.. 10
) {
}
is legit.
Smart parser may allow to avoid these otherwise spurious parentheses
.. and make
for
1..10
{ ... }
a legit expression following the rule what could have a meaning should.
The b) rule may not even be necessary with enough parsing state.
The parser could have the following exclusive states:
1) expecting an operator
2) expecting an operand (newline is statement terminator)
The expected operand is an expression that is part of an atomic statement
deemed as atomic.
3) expecting an operand (newline is ignored)
The expected operand is an expression that is directly part of
a composite statement. (as opposed as part of an atomic
statement part of a composite one).
What I mean by deemed as atomic?
When parsing a composite statement, we don't know from the start that
it is so. The following statement:
$a if $b
is deemed atomic until the parse deals with the 'if' token.
My proposition could then be expressed informally:
Newline is interpred as statement terminator when it makes sense.
It does not when :
A) in the middle of an expression when an operand is expected
B) within a parenthesised expression
C) and other cases that would also cause the parsing to return an error
Note: The b/ rule was an undeeded attempt to force C/ into B/.
--
stef
Re: newline as statement terminator
Multiline atomic statements just have to be broken at the right place to avoid to break them: Sorry about my English. Let me reformulate. When folding an atomic statement, it becomes two statements or its meaning is unchanged depending if an operand is expected or not at the position of the folding. a + b is equivalent to a + b But a + b are two statements. -- stef
Re: newline as statement terminator
On Mon, Feb 03, 2003 at 06:11:23PM -0700, Luke Palmer wrote: [snip] See, this is the main, unPerlish thing you're doing. You're enforcing particular styles upon people, something Perl is proud of *not* doing. Let's not forget the often occurence of: $fh = open 'foobar' or die Can't open foobar: $!; An implicit semicolon would cause it to croak there No, that case would not cause the inclusion of an implicit semicolon. I certainly should have discussed such cases. But I have covered them in the blanket statement C) and other cases that would also cause the parsing to return an error because I am confident that the parser can handle them. What I said: My proposition could then be expressed informally: Newline is interpred as statement terminator when it makes sense. It does not when : A) in the middle of an expression when an operand is expected B) within a parenthesised expression C) and other cases that would also cause the parsing to return an error Also, s/or/$(any if unless for while when ...)/ It would be trivial with a grammar munge to implement this (heck, I did it with a source filter in Perl 5). Surely CPAN6 (6PAN/CP6AN/??) will come out with one of these right off the bat, so you could do: use Grammar::ImplicitSemicolon; Or something like that, and be done with it. I am certainly confident that in perl6, everyone will be able to bake his own grammar. I am also confident that the grammar will be good enough that we will not have to do it in the general case Luke -- stef
Re: newline as statement terminator
On Mon, Feb 03, 2003 at 08:19:29PM -0500, Miko O'Sullivan wrote: On Tue, 4 Feb 2003, [iso-8859-1] Stéphane Payrard wrote: In the tradition of Perl concision, I would like newline to be a statement terminator everywhere it can: that is when a) the parser expects an operator _and_ b) we are not in the middle of a parenthesised expression. I don't mean to be abrupt here, especially seeing as how this list has been so patient with some of my ideas but... PLEASE NO. The rules you suggest for keeping track of when a semicolon is required sound more confusing than the simple rule of end of statement, put semicolon. As Luke Palmer said, in perl6, semicolon is a statement separator not a statement terminator. So there is no such simple rule in Perl but you are free to imposit it on yourself. Perl allows it but it does not requires it. I like to break up my long statements in all sorts of arbitrary places, and adding the worries of when a newline might be significant puts a knot in my stomach just thinking about it (literally). I agree that be obliged to check the next line to see if the newline is or is not a statement terminator is not the nicest thing. On the other hand, if the programmer is correctly indenting the program it should stand out that the next line is part of the courant statement. print --- # must read the next line to # figure out if new line is statement terminator or not if $condition; Here indentation is a mere clue but has no syntactic meaning. [snip] -- stef
Re: arrays, hashes unified indexing syntax impact on future variation s on other collection types
On Thu, Jan 30, 2003 at 09:11:10AM -0800, Damian Conway wrote:
What was the reason again which Larry rejected unifying the syntax for
array
and hash indexing?
Because some things have both, and do different things with each.
And because some built-in redundancy is useful for error checking,
especially on complex nested data structures.
As Piers said, we know whether $a is an array or hash reference when we do:
print $a-{foo};
No we don't. Especially if $a is $0 (i.e. the result of a pattern match).
See Exegesis 5 for details.
Someone correct me when I go astray...
See above. ;-)
Damian
I like very much that a reference can point to an object that has
scalar, array and hash natures at once. With the current (non unified
syntax), we can very elegantly munge any kind of attributed tree: XML,
parsing tree...
In the case of XML. if the node is a leaf, the referenced entity would
be a regular scalar. Otherwise, it would be the multifacetted object
of type (say) TagNd; the scalar would be the tag name, the hash would contain the
key/attribute pairs, the array would contain the sons if any.
Example: suppose that $t is the root node of such a tree obtained by parsing:
a b=c
de/d
f
/a
print $t{a} ;# prints c
print $t[0][1]; # prints f
This tree (simplified) deparsing would be done like that:
sub deparseNd($n) {
return $$n if ref($n) ne 'TagNd'; # returns text of leaf node
return $$n ~
(join '', map { qq|$_=$n{$_} | } keys %$n) ~
~
(join '', deparseNd $_ for @$n) ~ # should I protect for the
# possible autoinstanciation of
# of the sons array @$n (when no son?)
/$$n
}
print deparseNd($t);
Does it make any sense?
Someone correct me where I go astray... :)
Probably there is a more elegant way to concatenate all the chunks.
BTW: Can I write for $t instead of for @$t, same for keys $t?
Will Perl6 smart enough to autodereference when needed?
--
stef
Ordering is not what distinguish array from associative tables
On Wed, Jan 29, 2003 at 09:44:27AM -0500, Aaron Sherman wrote:
Yes, I would expect that. In my opinion there is no difference between
an array and a hash other than the underlying storage and the
type-management of the key. I'm increasingly of the opinion that a)
there should be no @ vs %, there should be no {} vs [], there should be
a keys, values, defined, delete, exists, push, pop, shift, unshift for
every container and foreach shouldn't give a damn.
I think that arrays and associative tables are very different entities
for two reasons:
-type of keys. array keys are integers
-cost of insertion and deletion operations: O(n) and
lower for associative table ( O(1) if you don't care for key ordering,
O(log(n)) if you care for ordering).
This is enough to warrant different syntaxes for arrays and hash.
This is one of the main things that attracted me to Perl, variable names ($a,
@a, %a) were a clear indication of behavior.
Perl6 should also support associative tables with ordered keys.
The default type of associative tables should be hashes.
# hash based associative table metonymically called hash
my %assoctbl1;
# tree based associative tables.
properties should specify the tree algo used and possibly the ordering function.
my %assoctbl2 is redblack;
my %assoctbl3 is ordered( sortfun);
But, that would be a different language, and Perl has hashes and arrays.
So, the most we can do is make them not work too differently.
--
stef
Re: right-to-left pipelines
On (09/12/02 06:00), Stéphane Payrard wrote:
Date: Mon, 9 Dec 2002 06:00:40 +0100
From: Stéphane Payrard [EMAIL PROTECTED]
To: Damian Conway [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED] [EMAIL PROTECTED]
Subject: right-to-left pipelines
I would like perl6 to support left-to-right part/sort/grep pipelines.
Left to right syntax is generally good because it facilitates the flow
of reading.
For these pipelines, the current right to left syntax is due to the emphasis
on the operation over the data operated on, so the operator appears
first. Nevertheless with a long pipeline, data is best factored out in a
variable so having it first is not an impediment.
Tentative syntax:
... is an left-associative operator that has the same precedence as .
argexpr...listop indirop
would be equivalent to
listop indirop argexpr
I am wrong about the precedence, the operator should just looser than
list operator and certainly looser than comma to avoid to use
parentheses around argexpr
(argexpr)...listop indirop # parenthese necessary if ... too tight
example:
@data = [ very_long_data_expression ]
(@foo, @bar) := @data...grep { $_ 0 }...sort { $^b = $^a }...part [/foo/, /bar/];
To go left to right all the way, we could have:
@data...grep { $_ 0 } ...sort...@result
Or even
@data...grep { $_ 0 } [EMAIL PROTECTED]@result2 ... grep { % 2}... @result3;
--
stef
Re: ( .... ) vs { .... }
On (22/09/02 10:37), Me wrote:
From: Me [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: ( ) vs { }
Date: Sun, 22 Sep 2002 10:37:59 -0500
In several forms of courier, and some other text fonts
I view code in, I find it hard to visually distinguish the
pattern element:
( ... )
from:
{ ... }
What about replacing the former syntax with:
? ...
If you can't distinguish braces and parentheses (or quotes and
backquotes in some other fonts), you are in deep trouble in many
languages including perl5 BTW. Languages should not bend themselves
(like with trigraph in C) for such particular cases. We have a
paucity of characters to start with, so don't add more constraints.
Good enough fonts are availaible anyway.
--
ralph
Re: dLoo releases peer-to-peer programming language
- Original Message - From: Dan Sugalski [EMAIL PROTECTED] To: Nathan Torkington [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, July 11, 2001 6:59 PM Subject: Re: dLoo releases peer-to-peer programming language At 10:16 AM 7/11/2001 -0600, Nathan Torkington wrote: nile writes, Today, dLoo released the complete architecture of an extensible peer-to-peer programming language. And I thought NFS was the security hole from hell... Unless there's a lot of very clever (research-level, Hi we're from IBM's Watson Labs, would you like a very highly-paid job level) stuff going on under the hood that is completely and totally glossed over in all the PR gook, this system is slightly less secure than putting your IP address and root password in big letters in a 30-second Superbowl commercial. (Though I may be wrong--it's possible I'm underestimating the danger) We must learn from java that initially failed to be sold as the language for embedded devices and was integrated as a browser (and in a browser) as an afterthought with an incredible success. But security was built-in from the start because these embedded devices were intended to be connected possibly on an insecure network: Internet. The lesson to be drawn is consistent with Dan sayings: it is an excellent way to spread a product as a browser or better as a plug-in but the security model must be thought ab initio. Sun and Gosling have learnt that, among many other things, with their unsuccessful and long-defunct Network extensible Windows system: NeWS. Absence of security model is alsso probably the reason why perl did not trhive in this biotop (the browsers themselves , not the servers who feeded the browsers). The module Safe is nice though but that is an afterthought . As a result it could not be made totally secure. -- stef Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: dLoo releases peer-to-peer programming language
- Original Message - From: Cameron Laird [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, July 11, 2001 8:43 PM Subject: Re: dLoo releases peer-to-peer programming language From [EMAIL PROTECTED] Wed Jul 11 13:35:23 2001 . . . The lesson to be drawn is consistent with Dan sayings: it is an excellent way to spread a product as a browser or better as a plug-in but the security model must be thought ab initio. Sun and Gosling have learnt that, among many other things, with their unsuccessful and long-defunct Network extensible Windows system: NeWS. Absence of security model is alsso probably the reason why perl did not trhive in this biotop (the browsers themselves , not the servers who feeded the browsers). The module Safe is nice though but that is an afterthought . As a result it could not be made totally secure. . . . Maybe. In '94-95, Perl was painful to embed; moreover, it lacked a popular way to construct dancing bears, which seemed to be at the heart of the first hundred thousand client- side Java demonstrations. At this point, I'm unconvinced that anything that happened during the Era of Browser Wars had to do with a sophisti- cated appreciation of security, by anyone, in any direction. I agree that dancing bears was what made java a success in a then dull browser world but its long-lasting success well beyond the browser biotop is due in great part to its security model. Pursuing my biologic metaphor spreading is necessary, but it is not enough. A security model for a software entity in the promiscuous Internet world is akin to an healthy immune system for a biological organism. -- stef
