actually unsafe to do so.
I'm pleased to note that you made my point for me.
Sure, you can sneak in under the covers of the JVM and compromise the
immutability of its final data. But you do have to sneak in. And when
you do, and things go belly up in interesting ways, or worse continue
to run
John M. Dlugosz wrote:
Carl Mäsak cmasak-at-gmail.com |Perl 6| wrote:
Pm ():
In Rakudo's case, we just haven't implemented read-only traits
on variables yet.
Goodie. I guessed as much.
But yes, I expect that it will be caught as
a compile-time error.
Carl Mäsak wrote:
What is the point of marking things readonly if you can turn it off?
There are many possible reasons, I think.
* The code that declares the variable readonly might not be available
to you (compiled to bytecode, fetched by RCP etc),
* or it might be available but used
A better fitting solution wouldn't focus on classic
MMD, but simply Dispatch, where type- and value-based
dispatching are two of many kinds of dispatching supported.
I've always liked the sound of Linda's tuple spaces
and view that as a nice generalized dispatch approach.
Procedure calls are
given baz(@args) { return $_ when defined }
given baz(@args) { return $_ when $_ 0 }
Sweet.
Shouldn't the latter example be:
given baz(@args) { return $_ if $_ 0 }
In general, if a Cwhen condition clause contains
a C$_, chances are good that it's a mistake, right?
If a pipe
How would one most nicely code what I'll call
a lazy pipeline, such that the first result
from the final element of the pipeline can
appear as soon as the first result has been
processed from the intervening elements?
--
ralph
).
Oh. Now I understand C- rather differently!
The left-to-right flow/assignment viewpoint
had worked for me as an (incorrect) way to
interpret C- when used with Cfor et al.
So, I guess I'm suggesting a binary C- that
really is a left-to-right flow/assignment op
so that:
@data
- grep { $_ 0
push (/foo/ @foo ||
/bar/ @bar ||
/zap/ @zap), $_ for @source;
Presumably, to avoid run time errors, that
would need to be something like:
push (/foo/ @foo ||
/bar/ @bar ||
/zap/ @zap ||
@void), $_ for @source;
But perhaps...
( @foo,
Michael said:
I worry that Cclassify sounds too much like
something class-related
'Classify' also seems wrong if some items are
thrown away. I like 'part':
(@foo,@bar) := part { ... } @source;
Headed off in another direction, having a sub
distribute its results like this reminds me
Dynamic scoping (take 2)
... a system of implicit argument passing ...
Larry pointed out [an error about threads]
The system of implicit argument passing was
intended to eliminate the need to use globals.
I was wrong about threads but that doesn't
change my view that globals are mostly evil.
I'm sorry, but I gotta get back on the
no-global grail trail for at least one
more post.
The granularity [of currying] can be
controlled on a sub-by-sub or on a
class-by-class basis.
If one could do something like this:
{
my $src = 'oldname1';
my $dest = 'newname1';
use
Thanks for the clear answers.
Larry:
I think that currying should be extended to
handle any caller-instituted defaulting.
Argh. So obvious! (So of course I missed it.)
Basically, the parameter list of the subroutine
is already providing a limited namespace to be
shared by caller and
Larry's earlier response means this 'yours'
idea is history, but for closure, yes, this
seems to be headed in the right direction,
at least in theory. It may have even been
practical to implement it thru the standard
property mechanism.
so these two are equivalent ???
{
my $x is yours ;
my
you propose a mechanism of passing [vars]
between desired subroutins by default
through all the dynamical chain of sub
calls connecting them.
There's more, or rather, less to it than that.
The same mechanism also includes a clean way
to pass it, something that needs to be done.
And a way to
I like more shared instead of yours
But that's because that's the way you are
thinking about the problem/solution.
I'm just talking about a very local trick
of having autoargs instead of explicitly
passing args in parens. The fact that this
ends up creating an elegant alternative to
dangerous
Warning: I just watched The Wizard Of Oz
for the first time tonight.
$x is yours
tells that $x is aliased to variable in
some secret scope symbol table that
( the table ) is shared between caller
and callee
The secret place is MyYourca, a Subterranean
island. People think it's an old,
First, I'd like to confirm I've understood
Ctemp and Clet right:
1. Ctemp dynamically scopes changes to a
variable's value to the enclosing block.
It does not dynamically scope the name.
The variable can obviously be a global.
It can also make sense if it is lexical.
Is the latter
[temp]
[implicit args]
Here's a snippet of conversation on a
haskell list about implementation of
implicit args : http://tinyurl.com/2ym1
--
ralph
In summary, I am proposing that one marks
variables that are to be automatically
passed from sub to sub with 'is yours'
where appropriate.
An example of what I'm suggesting follows.
Code with brief comments first then explanation.
{
my $_; # $_ can't be touched
'-' means the topic gets set and is
private to the block (ignoring aliasing effects):
$_ = 1; for @foo - $_ { $_ = 2 }; print; # 1
It seems to me that a logical conclusion would be
that a blank arg list after a '-' would mean the
topic remains private (and is set to undef).
Perhaps having bare
Are you suggesting this?
if($error) {
use visible 'croak';
require Carp;
import Carp: 'croak';
croak($error);
}
No - that would be pointless as well as error-prone.
My idea of visible is that it would make a lexically scoped thing
accessible to an inner dynamic scope at
$_ = 1; mumble { $_ = 2 }; print;
will print 1 or 2?
Least surprise, visually, is obviously 2.
This would be true if bare blocks (even
those passed as args) just pick up from
the surrounding lexical context. And if
that were true, mumble presumably could
not do anything about this
don't understand when one could do the
'is given($_)' and not do the ($_ = $_).
Any time that the caller's topic isn't
supposed to be explicitly passed as an
argument, but is still used within the
subroutine.
[example]
And, yes, I could make it an optional
argument, but them I have
$_ # current topic
$__ # outer topic
$___ # outer outer topic
[not sufficiently visibly distinct]
[too much anyway]
Agreed.
Returning to the topic of binding/copying
from a caller to a callee, what about using
square brackets to mark implicit args thus:
c) the ability to break lexical scope
Well, I could argue that c) already exists
in the form of passing parameters in parens.
Of course, that doesn't feel like breaking
anything.
So instead I'll argue that the word break
is perhaps prejudicially perjorative.
I'd say, to steer away from being
inheriting a caller's topic isn't going to be
that common a thing that it needs such a short
name, is it?
15% of the perl 5 builtins do so.
I have suggested that, in some extreme
scenarios such as short scripts, perhaps
as many as 50% of subs might do so. But
then again I probably ate a lot
Elements of this shared vocabulary might be
called 'locals' or 'yours'.
I like the 'yours' idea from the point of
view of the callee:
my $inherited = your $_;
I like that syntax, but I'm uncomfortable
with an underlying principle, which is that
one can reach in to the caller's
# I'm uncomfortable [that]
# one can reach in to the caller's lexical
# context from any place in a callee's body.
We need that capability if we're going to
have lexically-scoped exports:
I think I was a bit careless in how I worded
that.
My problem is not that one reaches in to the
# I am thinking one should have to predeclare
# in a sub's preamble that such a trick will
# be going on.
#
# Thus something like:
#
# sub foo [bar] { ... }
#
# is (part of what is) required to be allowed
# to create a bar sub in the context of the
# caller of foo.
So how does
Larry:
sub bar(; $foo = topicmumble) {...}
Damian:
topic [would be] Cundef.
I assumed topicmumble implied an 'is given'.
I don't see why it couldn't.
Damian:
Hm. Given that the topic is in some sense
a property of the lexical scope of the subroutine
body, this might be a
my sub foo ($_ = $_)
to just propagate the outer $_ inward.
That only works when $_ can somehow be
shoe-horned into the parameter list.
Whereas:
my sub foo is given($_)
works for *any* parameter list.
Other than the placeholder situation, I
don't understand when one
My complete knowledge comes from
archive.develooper.com/perl6-language...
(search for superpositions).
I find google (rather than develooper's
archive/search) the best tool for most
searching of p6lang. Unfortunately even
google only goes back so far, and doesn't
search punctuation.
Perl 6's
access caller's topic is an unrestricted
licence to commit action at a distance.
Right.
Perhaps:
o There's a property that controls what subs
can do with a lexical variable. I'll call
it Yours.
o By default, in the main package, topics are
set to Yours(rw); other lexicals are set
You're confusing brevity of declaration
with brevity of use.
One needs sufficient brevity of both call
and declaration syntax if the mechanism's
brevity is to be of use in short scripts.
Making (limited) circumvention of [$_'s
lexicality] depend on a verbose and
explicit syntax will help
method f ($self : $a) { ... }
sub f ($a) is given ($line) { ... }
what do you call $self
The invocant.
and $line?
A lexical variable that happens to be
bound to the caller's topic.
The invokit perhaps?
placeholders create subroutines, not methods.
Oh.
Are
In the hope this saves Allison time, and/or
clarifies things for me, I'll attempt some
answers.
In your article at perl.com you describes
various ways and situations when perl
creates a topic and this is described as
perl making the following binding on my behalf:
$_ := $some_var ; *1
Damian:
[it will be passed to about 5% of subs,
regardless of whether the context is your
10 line scripts or my large modules]
If the syntax for passing it to a sub
remains as verbose as it currently is,
you are probably right that it won't
be used to achieve brevity! I think it's
a pity
Will there be some shorter-hand way to say these?
[list comprehensions]
(bb clarified that this is about hash slicing.)
From A2:
RFC 201: Hash Slicing
...Concise list comprehensions will require
some other syntax within the subscript...
And
There are many ways we could
After all, there's gotta be some advantage to
being the Fearless Leader...
Larry
Thousands will cry for the blood of the Perl 6
design team. As Leader, you can draw their ire.
Because you are Fearless, you won't mind...
--
ralph
people on the list who can't be bothered to read
the documentation for their own keyboard IO system.
Most of this discussion seems to focus on keyboarding.
But that's of little consequence. This will always be
spotted before it does much harm and will affect just
one person and their software
(naming) the invocant of a method involves
something very like (naming) the topic
Generally, there's no conceptual link...
other than
The similarity is that both are implicit
parameters
which was my point.
Almost the entirety of what I see as relevant
in the context of deciding
the outside and makes
it the topic.
On its own this was no big deal, but it got
me thinking.
The key thing I realized was that (naming)
the invocant of a method involves something
very like (naming) the topic of a method,
and ultimately a sub and other constructs.
Thus it seems that whatever
%a ^:union[op] %b
%a :foo[op]:bar %b
I think that any operators over 10 characters should
be banished, and replaced with functions.
I'd agree with that. In fact probably anything over 4,
and even 4 is seriously pushing it.
I'll clarify that I am talking here about using
On Thu, 31 Oct 2002, Me wrote:
: That's one reason why I suggested control of this sort
: of thing should be a property of the operation, not of
: the operands.
I think that by and large, the operator knows whether it wants to
do union or intersection. When you're doing +, it's obviously
So despite the beauty of
a [+] b
I think it cannot survive in its current form. It overloads square
brackets too heavily.
What about using colon thus:
a [:+] b
or other character after the opening bracket, so long as that
character is not valid as the initial character of a
hash ^[op] hash
...
array ^[op] scalar
ie, generally:
term ^[op] term
what to do if a, b in a ^[op] b have different length
what to do if %a, %b in %a ^[op] %b have not the same set of keys
what to do in %a ^[op] a
[what to do] resolved by hash property :
I'd expect adverbs
: I wonder if we can possibly get the Rubyesque leaving out of
: endpoints by saying something like 1..!10.
:
: Similarly: 1 .. 10 == 2..9
There's also an issue of what (1..10) - 1 would or should
mean, if anything. Does it mean (1..9)? Does 1 + (1..10)
mean (2..10)?
And what
And that's also why we need a different way of returning from the
innermost block (or any labelled block). last almost works, except
it's specific to loops, at least in Perl 5 semantics. I keep thinking
of ret as a little return, but that's mostly a placeholder in
my mind. I've got a lot
Somebody fairly recently recommended some decent fixed-width
typefaces.
I think it may have been MJD, but I can't find the reference right now
(could be at work).
Michael Schwern recently suggested Monaco,
Neep or, if you can find them, Mishawaka or ProFont.
I investigated and found this link
I've looked before for discussion of the rationale behind
introducing attr/has and failed to find it. I noticed you
mention Zurich, so perhaps this decision followed from
discussion in living color (as against b+w).
Anyhow, what was deemed wrong with using my/our?
And...
class Zap {
my
Nothing the matter with our for class attributes since they're
already stored in the package if we follow Perl 5's lead. But using
my for instance attributes is problematic if we allow a class to
be reopened:
class Blurfl {
my $.foo;
}
...
class Blurfl is continued {
Problem:
You want to use delegation (rather than inheritance)
to add some capabilities of one class or object to
another class or object.
Solution:
Use a PROXY block:
class MyClass {
PROXY {
attr $left_front_wheel is Wheel;
attr $right_front_wheel is Wheel;
to me /mnemonically/ which is which. Even if
you can tell which is a brace and which a paren, you
are still left wondering what each does when you're
learning this new stuff. I mean, which one of these is
executing some code to return a boolean assertion,
and which one a string value
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:
? ...
?
--
ralph
Backtracking syntax includes:
:, ::, :::, commit, cut
I like the way the ':' looks in patterns. But I noticed I have
several niggles about a number of other aspects of the
above syntax. All the niggles are minor, individually, but
they added up to enough that I thought I'd see what the
[EMAIL PROTECTED] (Me) writes:
1. It's nice how the ':', '::', and ':::' progression indicates
progressively wider scope. But I would be surprised if
newbies don't say to themselves, now just how wide a
scope am I backtracking when there's three colons?.
Why would newbies be writing
I'm talking about just in the same namespace, how
do we keep rules from messing with file-scoped
(or any-scoped, for that matter) lexicals or globals.
How do we get rule- or closure-scoped lexicals
that are put into $0?
How about something like the following rework of
the
I may be missing your point, but based on my somewhat
fuzzy understanding:
Oh. Duh. Why don't we have such a mechanism for matches?
m/ my $date := date /
is ambiguous to the eyes. But I think it's necessary to have a
lexical
scoping mechanism for matches
The above would at least have
[run time control of assignment behavior when array contains pairs]
How much have I misunderstood things from a mechanisms
available point of view (as against a practical / nice way to
do things) when I suggest something along the lines of:
my sub op:= (*@list : %adverbs) {
...
Damian Conway wrote:
And is the is/but distinction still around?
Oh, yes.
Could someone please reference where this decision was
made. I do not find any information describing the distinction.
The following May 2001 post was related. Poke around the
thread it was in, especially posts
$roundor7 = rx /roundascii+[17]/
That is: the union of the two character classes.
Thank you; that wasn't in A5, E5 or S5. Will there be foo-bar as
well?
From A5:
The outer ... also naturally serves as a container
for any extra syntax we decide to come up with for
Current p6 rx syntax aiui regarding embedded code:
/
#1 do (may include an explicit fail):
{ code }
#2 do with implicit 'or fail'
( code )
#3 interp lit:
$( { code } )
#4 interp as rx:
{ code }
/
This feels cryptic. Do we need abbreviated syntax for
: Would something like these DWIM?
:
: # match pat1 _ pat2 and capture pat2 match:
: / pat1 { ($foo) = / pat2 / } /
Yes
So a match in a closure starts where the outer match
was. Simple enough.
Will:
# match pat1 _ pat2 _ pat3 and capture pat2 match:
/ pat1 { ($foo) = /
I'm basically sold on Damian's conclusions. On the other
hand the 'otherwise' clause still feels to me like a CAPITALS
block.
So, as a tweak, I suggest:
while condition() {
...
}
NONE {
...
}
--
ralph
/pat/i m:i/pat/ or /?i:pat/ or even m?i:pat ???
Why lose the modifier-following-final-delimiter
syntax? Is this to avoid a parsing issue, or
because it's linguistically odd to have a modifier
at the end?
/^pat$/m /^^pat$$/
What's the mnemonic here? It feels the wrong
way round --
Larry said:
I haven't decided yet whether matches embedded in
[a regex embedded] closure should automatically pick
up where the outer match is, or whether there should
be some explicit match op to mean that, much like \G
only better. I'm thinking when the current topic is a
match state, we
: I'd expect . to match newlines by default. For a . that
: didn't match newlines, I'd expect to need to use [^\n].
But . has never matched newlines by default, not even in grep.
Perhaps. But:
First, I would have thought you *can't* make . match newlines
in grep, period. If so, then when
: I'd expect . to match newlines by default.
I forgot, fourth, this simplifies the rule for . -- it
would become period matches any char, period.
Fifth, it makes the writing of match anything but
newline into an explicit [^\n], which I consider a
good thing.
Of course, all this is minor
when matching against something like foo\nwiffle\nbarfoo\n
/(foo.*)$/ # matches the last line
/(foo[^\n]*)$/ # assuming perl 6 meaning of $, end of string
/(foo.*)$/m # matches the first line
/(foo[^\n]*)$$/ # assuming perl 6 meaning of $$, end of line
or
/(foo.*?)$$/
Very nice (but, I assume you meant {$foo data})!
I didn't mean that (even if I should have).
Aiui, Mike's final suggestion was that parens end up
doing all the (ops data) tricks, and braces are used
purely to do code insertions. (I really liked that idea.)
So:
Perl 5Perl6
(data)
Let me see if I understand the final version of your (Mike's)
suggestions
and where it appears to be headed:
Backwards compatibility:
perl5 extended syntax still works in perl6 if one happens to use it.
Forward conversion:
Automatic conversion of relevant perl5 regex syntax to perl6 is simple
often be used
to contradict a built-in or compile time property. If he is right
about the dominant case being a contradiction, 'but' works
better for me than anything else I can think of, including 'now'
(explained below).
-
Even if usage to contradict a built-in or compile time property
[2c. What about ( data) or (ops data) normally means non-capturing,
($2 data) captures into $2, ($foo data) captures into $foo?]
which is cool where being explicit simplifies things, but
ain't where implicit is simpler. So, maybe add an op ('$'?)
or switch that makes parens capturing by
The following syntaxes have been seen:
foo()
.foo()
..foo() ## rejected because .. is different binary op
class.foo()
FooClass.foo()
::foo()
Package::foo()
$foo()
$_.foo()
With a nod to Piers, and with apologes if this is silly in
the context of Perl 6 syntax, what about:
But suppose you want all .foo to refer to self and not
to the current topic.
What about
given (self) { }
Also, what about
use invocant;
resulting in all method bodies in scope getting an implied
surrounding given (self) { }.
And what about 'me' or 'i' instead of 'self
Non-yet-thrown exceptions must be a useful concept.
This is a bullet point from a list in Apo4 introducing
coverage of exception handling. Was Larry talking
about an exception object that hasn't yet been thrown?
Did he refer to this issue again anywhere else in the Apo?
--me
could type:
LAST: {
or
last: {
--me
clean up code that frees some
resources. If you inherit from that method, and do not
inherit the LAST block, then you've got a leak. This is
obviously a mild example.
--me
and the code
is not. One can optionally not inherit the conditions
(at least preconditions, from another post I just read).
And one can optionally inherit the code (by calling it).
Right?
Btw, are you going to have an equivalent of super?
--me
[final, private]
I detest what these modifiers have done to me
in the past. They seem very unperlish to me.
worth it, but it seems
worth mentioning.).
--me
A quarter-baked idea:
How about punting by using nan (all lowercase)
as a boolean logic not-a-number, leaving NaN
for someone to (later) create an IEEE style
tristate not-a-number.
Later:
$foo == NaN; # NaN literal is not same as nan literal
use NaN;
NaN(expr);
What about if the symbol doesn't exist in the caller's scope
and the caller is not in the process of being compiled? Can
the new symbol be ignored since there obviously isn't any
code in the caller's scope referring to a lexical with that
name?
No. Because some other
If the dispatcher is drop-in replacable, what does its
interface look like?
I'm thinking this is either deep in mop territory, or a probably quite
straightforward set of decisions about dispatch tables, depending
on how you look at things.
I found just one relevant occurence of 'mop' in
Dan, I don't immediately see how per object/class dispatch
control helps to make multimethods pluggable. Perhaps a
multimethod (a set of methods) is a class/object? Is there
a general mop for dispatch?
More generally:
Yes. Ordinary subroutine overloading (like that offered by C++)
certainly
utterly different
in other common languages. And I never did find 'multimethods'
appealing either.)
Even if the dispatcher is the heart of multimethods, perhaps it
would be nice if it were convenient to replace the dispatcher
in whole or part. Kinda reminds me of the story of the old mop.
In a nutshell, you are viewing:
foo if bar;
as two statements rather than one, right?
Personally, I think it's more natural to view the above as one
statement, so any my anywhere in one element of it does not
apply to other elements of it.
use strict 'recursive';
If this is not yet done and is deemed a good idea, I'd add that it
seems to me to be equally applicable to perl 5.
Further, considering the more general
[pragma] 'recursive';
I can imagine pragma adverbs / attributes.
I searched p5p and p6all for things like
into derived sub-structures?
In other words, isn't there a more general problem of how to provide
MD access and what to do with the currently one dimensional operations
like:
for (@foo) {
when @foo is multi-dimensional?
Jeremy Howard wrote RFCs that I think relate to this and pointed
me to J (APL
What I was suggesting was to consider broadening what the
$foo : bar style postfix sub syntax allows/assists bar to do,
so that bars can be used to set properties OR do other stuff.
What's the practical utility of this?
1. Simplification for perl 6 implementation. I would expect it to
Me:
[$foo is bar] can change the value of $foo.
Damian:
Yes. For example:
my $foo is persistent;
Could you explain this further please?
Me:
$foo : bar baz is roughly equivalent to baz(bar($foo))
Damian:
Err. No. That would
of these:
$foo : bar baz qux
instead of
qux(baz(bar($foo)))
I realize this isn't particularly appealing, but bare with me
a little longer.
So, in:
$foo : bar
bar in this context is not a property, but instead a more
general post or similar (alluding to the notion that it is
a bit like a postfix sub
For what it's worth, I like it.
So do I, actually... it's sort of growing on me.
Me too. (I think it (~ for concat, ^ for negation) is just fine.)
The clash with =~ is disappointing though.
Now if Larry had the cahones to change the =~ operator...
(I find the notion of a short infix word
discontiguous slice
subsets across joined arrays) to be a powerful yet
simple general purpose algebra for creating
normalized tabular datastructures. This has nothing
to do with dbs, even less to do with SQL, and
everything to do with general purpose programming
expressiveness.
OK. No more from me
the end user is going to be able to
redefine the syntax anyway,
Yes. But if the syntax for arrays and db data are to
be simultaneously the same and as ideal as possible,
then either the core array syntax needs to be relatively
ideal for relational db data, or one needs to redefine
the array
, what do you
suggest IS a good fit?
array (or hash, you don't seem to care)
Records have named fields so one dimension is like a hash.
Get started now - Perl 5's..
...arrays are one dimensional.
tie and overload support should be more than sufficient.
Aiui, overload won't get me past
Sam, I don't think we're on the same wavelength.
So a direct response seems pointless.
Larry himself said:
while allowing multidimensional arrays to distinguish
between [this and that] in a manner more conducive to
database programming
Ok, I did s/numerical/database/, but what's
modeling of the whole database
Doesn't seem like it's hard to do.
With MD arrays, you are all but there anyway:
Table:
A 2d array.
Whatever is introduced to more directly support
handling MD arrays could very plausibly help in
more directly supporting handling of single
pick both rows from both arrays.
Seems simple to me. Perhaps you meant the concrete
method and/or syntax to achieve the join, or to reference
the two arrays, or to reference the result table. But thinking
of concrete details like that is way premature.
For one thing, if Simon and Sam are anyone
(The intent is that) Perl 6 will be a better general purpose
programming language for building application specific
sub-languages.
I'm interested in how far Perl 6 could go in providing support
for a high-level expressive syntax sub-language for dealing
with relational data. To the extent the
1 - 100 of 122 matches
Mail list logo
