Re: Unifying invocant and topic naming syntax
ralph wrote:
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!
You're confusing brevity of declaration with brevity of use.
Declarations should always be relatively verbose.
Why do you think your estimate of Perl 6
usage of "it" is so much lower than is
true for the standard Perl 5 functions?
Because I don't believe many people write subroutines that
default to $_ or that rely on some particular value of $_.
In Perl 5, relying on $_ is fraught with peril, since its
global nature means you have to be wary of what happens to
it in any nested calls as well.
We ought not make that peril any easier to fall into in
Perl 6. Making $_ lexical goes a long way towards that.
Making (limited) circumvention of that lexicality depend on
a verbose and explicit syntax will help too.
Btw, can I just confirm that one can't do:
sub f ($a = ) { ... }
or
sub f (;$_ = ) { ... }
where is the upscope it and $_
is the sub's topic.
I seriously doubt it but, as always, that's up to Larry.
If it were allowed, the syntaxes might be something like:
sub f ($a = $CALLER::_) { ... }
sub f (;$_ = $CALLER::_) { ... }
Naturally, I see this as another symptom
of the way upscope "it" is being treated
as a second class citizen,
No. It's just not being treated as a parameter.
Because it isn't one.
and that this is leading things in the wrong direction.
Actually, I'm very happy with the direction it's being led.
Besides, what's wrong with:
$foo = sub { print $_ } is given($_);
Compared with
$foo = sub { print $^_ };
The answer is brevity, or lack thereof.
But, even if $^_ *were* synonymous with $_, it
still wouldn't do what you want. The placeholder
in:
$foo = sub { print $^_ };
makes the closure equivalent to:
$foo = sub ($_) { print $_ };
which expects the topic to be passed as the argument of the
subroutine, *not* "inherited" out-of-band from the caller's
scope.
If you're proposing that there be some special exemption for
$^_ so that it (a) doesn't placehold a parameter and (b)
aliases the caller's topic instead, then I'm vehemently opposed,
since it makes $^_ a kind of *anti*-placeholder.
Introducing that kind of inconsistency would be playing straight
into Simon's hands! ;-)
Why bother with currying?
You mean placeholders. Currying is something else entirely.
Why bother with the "it" concept? None of these are necessary.
They simplify code generation, but their more
general feature is enabling brevity.
Of usage, yes, but not necessarily of declaration.
Damian
Re: Primitive Vs Object types
Mark J. Reed wrote:
Attributes are class-specific for a variable (okay, class instance
specific, if you do Evil Things with multiple copies of a single base
class in different legs of the inheritance tree and override the
default behaviour of the engine) and not queryable at runtime without
really nasty parrot assembly code.
You won't be able to query attributes at run-time? Even within
the class? I rather like the ability to loop through
the attributes of an object with something like this Perl5 code:
foreach my $attr (qw(foo bar baz))
{
print "$attr: $this->{$attr}\n";
}
You will. But they won't be entries of a hash. They'll be
separate variables and associated accessor methods.
So maybe something like this:
foreach my $attr (qw(foo bar baz))
{
print "$attr: $self.$attr()\n";
}
Damian
Re: Primitive Vs Object types
Luke Palmer wrote:
Could you just look through the lexical scope of the object?
for $this.MY.kv -> $k, $v {
print "$k: $v\n"
}
Or would you look through the class's lexical scope and apply it to
the object?
for keys $this.class.MY {
print "$_: $this.MY{$_}\n"
}
I think one of those two is possible. (Providing the .class method
exists and DWIMs)
I'm not sure either of those works, exactly. The scope of attributes isn't
precisely lexical in nature. Perhaps instead of a C method, an object
would have a (private!) C method, allowing something like:
for $this.HAS -> $attr {
print "$attr.key(): $attr.value()\n"
}
Or maybe not. ;-)
Damian
Re: Superpositions and laziness
Nicholas Clark wrote: We're looking for a word that tersely expresses > has_no_side_effects_and_can_safely_have_its_results_cached_based_on_parameter_types_ > and_values_and_calling_context ? And to people in the perl5 know, Memoize is the module that implements this, hence why people who know of how and what Memoize can do favour that name. Except that it's not necessarily obvious to everyone else? cacheable is rather long and sufficiently made up that my copy of ispell doesn't recognise it. But at least all English speakers can agree how to spell words that don't end in i[zs]e (or end ou?r or [cs]e :-) Except, of course, that many (near-)English speakers would be tempted to spell your suggestion "cachable". Hence I suspect that "cached" might be better. Then we will only have to contend with those few remaining Romantic poets who will want to write it "cachéd". ;-) Damian
Re: Superpositions and laziness
Paul Johnson wrote: Part of the reason I would prefer something like "pure" over something like "cached" is because it describes the function rather than telling the compiler how to deal with it. That feels better to me. It's working at a higher level. Maybe the end result is the same, or maybe there are other optimisations which can be made with "pure" functions. It's a way of nailing down the contract on the function rather than specifying implementation details. I can certainly see your point, but to me this is disquieteningly reminiscent of the horror that is C in C++ methods. Because, if you're serious about C meaning "pure" in the mathematical sense, then C subs can't access globals or C, can't have C parameters, and call non-C subroutines. One of the reasons I like C is because it does specify exactly the way the subroutine is to behave (i.e. be called the first time, and not called every subsequent time the same arguments are supplied). So I can do nasty^H^H^H^H^Hhandy things like giving the sub side-effects, in the sure knowledge that they won't be invoked more than once. With C I can never be sure what optimizations the compiler is or isn't going to make, or even whether those optimzations will be the same from platform to platform [*]. So I can never be sure what the precise behaviour of my sub will be. :-( Damian [*] I can easily imagine architectures under which re-calling a particular pure function is actually faster than retrieving a previously cached result.
Re: FMTWYENTK about := ( :-)
Arcadi wrote:
this is not a description or definition of something. It is just set
of questions and confusions that I have when I encounter words like
"variable" , "name" , "alias", "assign" in perl . In the form of
explanation. But actually these are questions .
These are answers. In the form of answers. ;-)
perl have 3 *mostly* independent concepts
i) variable-names ( live in namespaces )
2) actually variables or *containers* live in perl memori at
compile-time-phase .
Or run-time (e.g. lexicals, anonymous variables)
3) values live everywere and are the MOSTIMPORTANTTHING.
That is a philosophical position. I could also argue that
values are the LEASTIMPORTANTTHING: that they are merely
trivial "special cases" of the abstractions embodied by
the variables. I could also argue that even variables are
UNIMPORTANTTHINGS; that only the relationships between
variables, as represented by the algorithm, matter.
All just philosophical positions. ;-)
Variable is the following 3-level thing
1) name | '$a'
||
|V
2) container| (.)
||
|V
3) value| some number e.g., 5
Yes. This is a deep understanding. Excellent.
names are strings that can be chosen according to some
restrictions.
Though, in Perl, those restrictions aren't terribly restrictive. Here, for example,
is a variable whose name is (phonetically):
NEWLINE-NEWLINE-ALLO-ALLO-SPACE-the-SPACE-sky-SPACE-is-TAB-falling-BANG-BANG-BANG
and yet it is perfectly legal in Perl:
*{'
«» the sky is falling!!!'} = \[0]->[0];
while (${'
«» the sky is falling!!!'}<10) {
print ${'
«» the sky is falling!!!'}, "\n";
${'
«» the sky is falling!!!'}++;
}
Names *live* in *namespace* . that is, perl keep some
tables ( aka as namespaces ) that list known variable-names. and each
name refer to a container. the type of namespace: global, package,
lexical and so on defines the *scope* of variable-name, life-circle of
variable-name and so on ( but everything for variable-name ).
Another deep insight. Well done.
special modifiers "my" "our" help to place the variable-name in the desired
"variable-namespace".
container is mystical intermediate between value and variable
name.
Mystical? I'd have said that the container is the *least* mystical
part of the symbiosis. It's the only tangible piece of the puzzle.
Its a wheels and sticks inside the clock . we don't see it but it
is necessary to "de-mystify" - how the clock *knows* what time is it.
In perl variable may have properties . Actually containers have.
And values may have them too.
value is actual data - the 0's and 1's that actually run here and
there when program runs.
Not quite. The value is the *interpretation* of the 1's and 0's.
For example, the same bitsequence (say 01010101) may be part of
a (very short) string, or an integer, or a floating point number, or a
reference. And no two of those interpretations will necessarily
represent the same "value.
value is always a scalar - some number,
although it may be a reference ( which is also number ) to some more
elaborate structure ( as in perl is almost always the case even for
references themselves as far as I know, but ???) .
ha, and also, variable ( actually the container ) may be anonymous (
All containers are inherently anonymous. In a sense, a variable is
merely the association of a container and a name.
as most of variables in usual perl program ), in that case it is not
referenced to by some "variable-name" *directly* ; but it is
definitely referenced by something -- otherwize it is dead.
perl variable and values may have properties .
*compile time* properties are attached to *containers*
they are introduced by "is" operator ( actually at run time
containers may already be unneeded , they did all the "semantic"
work and the may go ,
but I am not sure )
Sometimes they can be optimized away; sometimes not.
*run time properties are attached to values ; they are introduced
with "but"; they begin to function at run-time, but perl at compiler
time may well be aware of them ( ??? ) .
Yes, it may be. If the value is a compile-time value such as:
return 0 but true;
then the compiler might well optimize that somehow.
examples :
my $x is constant = 1 ;
our $y = 0 but true ;
* "my" "our" tells where ( and how long and to whom visible ) the
*variable-name* '$x', '$y' lives.
and this create the following structure :
1) name | '$x' ( lives in MY:: namespace )
||
|V
2) container| (.)->props->{ "constant"=>1 , ... }
||
|V
3) value|1->props->{ ... }
1) name | '$x' ( lives in Main:: namespace )
||
|
Re: Superpositions and laziness
On Monday, November 11, 2002, at 02:19 AM, Damian Conway wrote: One of the reasons I like C is because it does specify exactly the way the subroutine is to behave (i.e. be called the first time, and not called every subsequent time the same arguments are supplied). So I can do nasty^H^H^H^H^Hhandy things like giving the sub side-effects, in the sure knowledge that they won't be invoked more than once. With C I can never be sure what optimizations the compiler is or isn't going to make, or even whether those optimzations will be the same from platform to platform [*]. So I can never be sure what the precise behaviour of my sub will be. :-( Amen. The more abstract or metaphorical the name, the more difficult it is to be really sure of what it does. Of the choices, "cached" seems by far the most self-explanatory. If we used "pure", we'd have to teach people what "pure" means, which would be much harder than teaching them what "cached" means. MikeL
Re: Unifying invocant and topic naming syntax
> 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 too.
Sometimes verbosity doesn't matter, but
I don't see how it can ever help. I'd buy
"clarity".
More to the point, the declaration syntax
will not help with avoiding accidents at
the time of call. So what is driving you
guys to deliberately avoid a brief def
syntax?
> > $foo = sub { print $^_ }; # shorthand for
> > $foo = sub { print $_ } is given($_);
> If you're proposing that there be some special
> exemption for $^_ so that it (a) doesn't
> placehold a parameter and (b) aliases the
> caller's topic instead
Well it clearly does placehold something.
In
method f ($self : $a) { ... }
sub f ($a) is given ($line) { ... }
what do you call $self and $line? I am
talking about being able to placehold
these things, whatever you choose to call
them.
> > Why bother with currying?
>
> You mean placeholders.
I meant currying. (I was listing mechanisms
that I believed existed to enable coding
brevity.)
--
ralph
Re: Unifying invocant and topic naming syntax
ralph wrote:
> So what is driving you
guys to deliberately avoid a brief def
syntax?
Can't speak for Larry. But what's driving me is the desire
to balance conciseness with comprehensibility, and to keep the
overall cognitive load manageable.
If you're proposing that there be some special
exemption for $^_ so that it (a) doesn't
placehold a parameter and (b) aliases the
caller's topic instead
Well it clearly does placehold something.
Sure. It's placeholds a parameter named $^_, which
may or may not be equivalent to a parameter named $_
(Larry will need to rule on that bit).
In
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.
I am talking about being able to placehold
these things, whatever you choose to call
them.
You can't placehold the invocant, since placeholders create subroutines,
not methods.
We probably *could* find a notation to placehold the C variable,
but I just can't see the need, when all you have to do now is write
C after the closure.
Why bother with currying?
You mean placeholders.
I meant currying. (I was listing mechanisms
that I believed existed to enable coding
brevity.)
Currying is more about efficiency and algorithmic integrity than
brevity. In fact, I would argue that it explciitly *not* about brevity.
Compare:
$incr = &add.assuming(x=>1);
with:
$incr = { add(1,$^y) };
The currying syntax was (deliberately) chosen to be verbose because
powerful or unusual things should be clearly marked.
Ultimately we're discussing philosophy, which is a waste of time since
we are unlikely to convince each other. I think we should just agree
to disagree here, and let Larry decide.
Damian
Re: Unifying invocant and topic naming syntax
> > 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 placeholders only usable with anonymous
subs, or named subs too?
Switching briefly to currying, can one curry
a method?
--
ralph
