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',
:rule) eq 'hi', "Grammar.parse: :rule"
On Sun, Jul 18, 2010 at 10:40 PM, 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 C, 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 C method (regex, token,
> -or rule) of C. Grammar objects are considered immutable, so
> +or rule) of C. The default rule name to call can be overridden
> with
> +the C<:rule> named argument of the C 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 := $ ?? ~$[0] !! '';
would read
my $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
values of undef and JavaScript
In Perl5, the meaning of the undef value is overloaded. It can mean either the value an uninitialized variable or it may indeed mean a genuine undefined value. Perl5 is biased toward the first meaning: in string context, the value behaves as an empty string; In integer and float context, it respectively behaves as 0 and 0.0. In other words, the uninitialized variable is considered initialized with a nice defaut value. In Perl6, for typed primitive variables, the problem disappear : the variables will be explicitely initialized with the appropriate value. But the behavior does not change for untyped variables. In JavaScript, using an uninitialized value is considered an error. Used in string context, it brings "undefined" and in integer and float context, it brings NAN, not a number. Neither can be considered as a nice default value. Unitialized values are probably not a best practice for long programs, but they are very nice for short ones which Perl6 still want to support. Now suppose, I want Perl6 to operate nicely with a Parrot based JavaScript implementation. I want to write short programs with uninitialized values to call JavaScript libraries. I would like my Perl uninitialized values to behave in JavaScript like in Perl5 : brings appropriate defaults values depending on context. This is possible because the PMC will not change its behavior in the Parrot based javascript world. In a non Parrot, non Pugs, based Javascript, I will be out of luck. Good, there has to be some advantages to choose Parrot over the board. On the other hand, I also want to be able to initialize a Perl6 scalar value with a genuine undef value so that it behaves as such in the JavaScript world. As far a Perl6 is concerned, we only need a new convention to distinghish between an unitialized value and a genuine undefined one. I borrow the convention from the JavaScript world, but I don't mind another. defined $a # true still means not undef or not uninitialized $a == undef # true would mean a genuine undef At the Parrot level, it would mean using a PerlUndef PMC and a PerlUninitialized one. A second related problem: should such PMCs be singletons or not? Singletons would allow to save memory. But they are objects where we can shove attributes. Maybe they should be singletons and becomes new different objects the first time an attribute is shoved in them. This behavior is different than simply morphing a pmc. Finally, a third related problem: what about missing slot in arrays? What sort of undef should they be? -- 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
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: 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
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: Blocks, continuations and eval()
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 -- 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: 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
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: Possible syntax for code as comment
On Sun, Jan 09, 2005 at 06:31:24AM -0600, Luke Blanshard wrote: > David Storrs wrote: > >Out of curiosity, why are we all spelling 'subject' without a 'c'? > >Or is 'subjet' a word I'm not familiar with? (Honest question.) > > I assume it's a spelling error on the part of the original poster. > French for "subject" is "sujet" (IIRC), and "subjet" looks like a cross > between the two. > > Luke > I know how to spell "subject" in English. That was a typo. But certainly, it did not trigger an alarm in my mind. When needed, I can think and write in (broken) Englisn. But somehow my French sometimes partly takes over. French for "subject" is "sujet" and it has the same meanings as in English. Once, the Sun-King Louis XIV, asked for a "bon mot". He was answered "Mais sire, vous n'êtes pas sujet". That gives in English: "But Majesty, you are not a subject". It is pretty rare that a pun can survive translation. -- stef
Re: Possible syntax for code as comment
On Fri, Jan 07, 2005 at 09:55:39PM +0100, Juerd wrote: > Stéphane Payrard skribis 2005-01-07 21:23 (+0100): > > > my $s := $subjet; > > > my $c := $complement; > > That's what I wanted to avoid. > > Why? Do you expect to use lots of one letter aliases? > > I think it's one of the most effective ways to kill readability. > > > Juerd > The clearly expressed motivation was the Huffman principle. So I certainly did not imply to use _lots_ of _one_letter_ aliases. The aliases get to be shorter when they are few and heavily used. In other words, when some vars heavily used in some portion of code, it is a win to locally alias them with shorter names. Because they are few it easy to remember what they denote. The particular optimal lengths of these aliases vary on case by case and is also admittedly a question of taste. Independantly of aliasing, they are global conventions for the use of short names, $i or $j is likely to denote an index. Perl helps further by the use sigil hopefully made consistant in Perl6. Too long names very often result in folded lines, less code visible in a screenful. As a result important structural properties of a program often become invisible. Anyway the particular length of variables names was not the subject of my mail, but a good syntax for aliasing name in signatures. -- stef
Possible syntax for code as comment
On Fri, Jan 07, 2005 at 10:28:32AM -0800, Larry Wall wrote:
> On Thu, Jan 06, 2005 at 11:07:47PM +0100, Stéphane Payrard wrote:
> : To get an huffmanized name and a clear one, I would like some support
> syntax:
> :
> : sub canon( $subjet as $s , $complement as $c ) {
> : # code with lots of $s and $s
> : }
>
> Aliasing can currently be done with the binding operator:
>
> sub canon( $subjet, $complement ) {
> my $s := $subjet;
> my $c := $complement;
> # code with lots of $s and $c
> }
That's what I wanted to avoid.
>
> : # or without type annotation
> : sub canon( Expr $subjet as $s , Expr $complement as $c) { }
>
> If we put syntactic relief into the signature, it'd probably work the
> other way around, where the descriptive parameter name is the optional thing:
>
> sub canon( Expr $s is named, Expr $c is named) { }
>
> That way the sigil is on the variable, and not on the parameter name that
> you'd use in a named call:
>
> canon( subjet => $mysub, complement => $mycomp );
> canon( :subjet($mysub) :complement($mycomp) );
I suppose you meant
canon( :subjet($mysub), :complement($mycomp) );
>
> We could conceivably allow a declarational notation like:
>
> sub canon( subjet => Expr $s, complement => Expr $c) { }
I keep forgeting about pairs as named arguments and focused only on
subs signature syntax and omitted the call syntax. Subs are defined
once, but usually called many times, so this call syntax matters even
much. It is great that, in calling code, one can use the pair syntax
to remind the reader what argument is what for a given sub but then
use the positional notation:
...
canon :subjet($mysub) :complement($mycomp);
canon $mysub2, $mycomp2;
canon $mysub3, $mycomp3;
...
btw, are the parentheses mandatory in the alternative pair syntax? If
the value is simple to write, I would like to drop the parentheses:
canon :subjet $mysub, :complement $mycomp;
This would happen if a key with colon bind very tightly.
I love Perl6 syntax. Larry, you should post more sample code so that
people get familiar with that syntax. It is easier to learn by example
than by reading manuals. I loved Perl4 syntax but it got ugly with
the introduction of references in Perl5. It is about time that Perl
stops getting a bad rap about being write-only.
--
stef
thoughts about types, and possible syntax for code as comment
I expect Perl6 to be a language with a mix of dynamically typed and
statically typed variables. In a purely statically typed language like
OCAML, you generally don't need to declare the type of variables
when it can be inferred. So one can benefit from the speed of static
typing (no type info must be handled at run-time) without the chaff of
often redundant type annotations. This has a price though, when
running into a typing problem, the compiler often gives cryptic errors.
But things are probably more complex in Perl6 with a mixed
static/dynamic type system.
Given the complexity of type inference that makes it indecidable in
many complex case, will it be possible in Perl6 to omit some type
annotation in some declarations and expect the compile to infer the
types at compile time? Probably, this will not be supported in
the early versions of Perl6, but is this something even possible?
With ou without help from the programmer with some sort of pragma?
In many cases, and especially when omitting type annotations, the
programmer need a long and descriptive name for parameters. This
is ackward when the said parameters are heavily used.
The long descriptive name is useful for the declaration but goes
against the Huffman principle.
# with type annotation, it is obvious what $xp is
sub canon( Expr $xp ) { }
# ...not anymore
sub canon( $xp ) { }
# ... so one would use a longer name
sub canon( $expr ) { }
# But sometimes the parameter name conveys more info than restating
# the type; that often means even longer names
sub canon( $subjet, $complement ) { }
sub canon( Expr $subjet, Expr $complement ) { }
To get an huffmanized name and a clear one, I would like some support syntax:
sub canon( $subjet as $s , $complement as $c ) {
# code with lots of $s and $s
}
# or without type annotation
sub canon( Expr $subjet as $s , Expr $complement as $c) { }
One could even drop the sigil in the short form with the signature:
sub canon( $subjet as s , $complement as c ) { }
sub canon( Expr $subjet as s , Expr $complement as c) { }
I could not stress enough the value of code as comment. It cannot fall
so much in touch with reality as code evolve than pure comment always
does. Worse, the ratio code/comment can be such that one cannot get
much real meat in a screenful.
I cross post to perl6-compiler because the question about type
inference in a language which a mix of static/dynamic type is very
much a implementation feasability question. Probably after going thru
"Types and programming langauge" by Benjamin C. Pierce and learning
about OCAML implementation, I will have a better grasp on type
inference.
--
stef
spaces for alignement
On Sun, Dec 19, 2004 at 06:44:33PM -0800, chromatic wrote: > On Sun, 2004-12-19 at 20:25 -0600, Rod Adams wrote: > > [snipped] > > > > $x = 4; > > $y = 7; > > $z = 12; > > $r = 4543; > > $q = 121; > > > > With a fixed width font, like all code editors use, all the =' like up, > > and I can quickly scan the var names to get to the one I want to change > > at that moment. > > If you align the equals signs yourself with spaces, you can use variable > names of different lengths (and possibly improved meaningfulness in > actual factual code) too. > > I'm only half-joking. Vertical alignment makes a dramatic difference to > readability. > > -- c > Speaking of alignement, my understanding is that the .[] operator, allows spacing while [] does not: $a = @shortnm.[0 ]; $b = @longername .[42]; -- 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 C has no final newline, I would expect C 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 C or a C, or better by a C<||> or 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: A12: on inheriting wrappers
On Fri, Apr 30, 2004 at 11:14:55AM +0200, Aldo Calpini wrote:
> let's suppose I want to build a class that keeps track of the objects it
> creates.
>
> let's suppose that I want this class to be the base for a variety of
> classes.
>
> let's suppose that I decide, rather than fiddling with the default
> constructor, to wrap it up.
>
> something like:
>
> class Animal {
> our @.zoo;
> &new.wrap( {
> my @results = call();
> push(@.zoo, @results[0]);
> return @results;
> } );
> }
> class Lion is Animal { ... }
> class Tiger is Animal { ... }
> class Panther is Animal { ... }
>
> my $simba = Lion.new();
> my $shere_khan = Tiger.new();
> my $bagheera = Panther.new();
>
> my @all = @Animal::zoo;
> # @all should contain ($simba, $shere_khan, $bagheera);
>
> will the above code work as expected, or is there something I've
> overlooked?
Perl6 seems already to have plenty of mechanisms like delegation
to dynamically change the behavior of a class. So, probably,
wrappers is a mechanism more adapted to extend method behavior at
run-time by entities that don't have access to the internals of a
class.
Comments?
--
stef
>
> cheers,
> Aldo
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 C, C and C 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 C splats its operands. I don't pretend that C 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 C. 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"? Develop Strategic Plan Deploy Linux Fred Smith Jill Jones Sydney Lee 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
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: 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 <>)/ > > 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
> > 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
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: 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:
e
f
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?)
"
}
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
right-to-left pipelines
[snipped]
> so it's easy to build up more complex right-to-left pipelines, like:
>
> (@foo, @bar) :=
> part [/foo/, /bar/],
> sort { $^b <=> $^a }
> grep { $_ > 0 }
> @data;
>
>
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
example:
@data = [ very_long_data_expression ]
(@foo, @bar) := @data...grep { $_ > 0 }...sort { $^b <=> $^a }...part [/foo/, /bar/];
Also, I am not necessarily advocating that operators like :=
could be flipped to become := with flipped operands:
@data...grep { $_ > 0 }...sort { $^b <=> $^a }...part [/foo/, /bar/] =: (@foo,
@bar)
I am just advocating to examine the idea. :)
I certainly see an imediate problem with the current conventions:
=~ and ~= are two different beasts, not one beast and its flipped version.
__
stef
Re: [RFC] Perl6 Operator List, Take 5
On (02/11/02 11:18), Philippe 'BooK' Bruhat wrote: > Date: Sat, 2 Nov 2002 11:18:22 +0100 (CET) > From: Philippe 'BooK' Bruhat <[EMAIL PROTECTED]> > To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > Subject: Re: [RFC] Perl6 Operator List, Take 5 > > On Thu, 31 Oct 2002, Damian Conway wrote: > > > Larry mused: > > > > > Of course, Real Mathematicians will want [1..10) and (1..10] instead. > > > > > > > Forgive me but is this syntax really necessary. > > Does it buy us enough over +1 and -1? > > And for what it's worth, Real Mathematicians do not use open intervals for > integers! BooK, we are not talking topology here even if we are free to borrow syntax from anywhere for notational convenience and mnemonic value. But here, this will buy us not much, will confuse editors like vi or emacs; Also the notation itself is not even universally adopted. In French schools, we were writing [1..10[ for the [1..10). I find the French notation more mnemonic because it shows clearly that the right bracket is "porous". -- stef > > (Sorry for the late post, but p6l is always 200 messages ahead of me) > > -- > Philippe "BooK" Bruhat > > One lesson learned is never enough. >(Moral from Groo The Wanderer #104 (Epic)) > >
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: "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
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 >
