Re: TERN-discuss mailing list finally available
[EMAIL PROTECTED] (Joseph F. Ryan) writes: > Are these people serious? What on earth is the point? I suggest a Tern versus Rindolf shootout. -- An algorithm must be seen to be believed. -- D.E. Knuth
Re: String concatentation operator
[EMAIL PROTECTED] (Smylers) writes: > >... they believed that the + should concatenate the two strings. > > > > Makes perfect sense to me. > > Makes sense in a language where variables are typed It also makes sense in a language where values are typed. They just have to be slightly more strongly typed than just "scalar". But Perl 6 is already going to support INT and STRING built-in types, right? So I see no problem with + doing string concat. I could mention some other languages (or at least, a language (of which I'm becoming considerably more fond as I get to know it (especially having just come back from Japan (excuse the jet lag which takes this approach. -- Sigh. I like to think it's just the Linux people who want to be on the "leading edge" so bad they walk right off the precipice. (Craig E. Groeschel)
Re: String concatentation operator
On Sat, Nov 23, 2002 at 07:34:47PM +, Simon Cozens wrote: >I could mention some other > languages (or at least, a language (of which I'm becoming considerably > more fond as I get to know it (especially having just come back from > Japan (excuse the jet lag which takes this approach. Lisp is Japanese? -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: String concatentation operator
On Sat, Nov 23, 2002 at 07:34:47PM +, Simon Cozens wrote: : [EMAIL PROTECTED] (Smylers) writes: : > >... they believed that the + should concatenate the two strings. : > > : > > Makes perfect sense to me. : > : > Makes sense in a language where variables are typed : : It also makes sense in a language where values are typed. They just : have to be slightly more strongly typed than just "scalar". But Perl 6 : is already going to support INT and STRING built-in types, right? So I : see no problem with + doing string concat. I could mention some other : languages (or at least, a language (of which I'm becoming considerably : more fond as I get to know it (especially having just come back from : Japan (excuse the jet lag which takes this approach. While no assumption is going unquestioned for Perl 6, I do still believe that the decision not to overload + for concatenation is one of the few things I did right in Perl 1. When people look at $a + $b in Perl they don't have to wonder what it means. Addition is such a fundamental operation that it should be kept as clean as possible, both for readability and for optimizability. (The two are not unrelated.) There are several things I like about Ruby, but using + for string concatenation is not one of them. It's another one of those areas where the Principle of Least Astonishment is misapplied. Any language that doesn't occasionally surprise the novice will pay for it by continually surprising the expert. Ruby's scoping rules also fail on this point, in my estimation. Larry
Dynamic scoping (take 2)
First, I'd like to confirm I've understood C and C right: 1. C 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 currently allowed? 2. C is a conditional C; it only restores a variable's value if, on exit from the enclosing block, the block is somehow considered to have "failed". It can be applied to a global or lexical. The above two features are basically sugar for what would otherwise be achieved with paired FIRST/LAST/UNDO blocks. Both must be applied to an existing variable. Next, I want to do a better job of stating a problem I wonder about: Consider "environmental" values such as "screen sizes, graphics contexts, file handles, environment variables, and foreign interface environment handles." [1] Consider a sub One that is going to call a 10 deep stack of subs such that sub Ten needs to access one of these environmental values. How do you pass the data? A. Globals. Bad. Disastrous in threads. B. Passed as args to all intervening subs. Verbose. Sometimes incredibly verbose. C. Aggregate info into objects. But then you still have to do either 1 or 2 above with the object references. And it's a shame to be forced to the object paradigm unnecessarily. D. Use $CALLERS::. Relatively succinct, but definitely error-prone and ugly. Given what I understand of Perl 6 syntax, Parrot, and Perl philosophy, I suspect P6 should, and could fairly easily, provide a good solution to the problem outlined above. Does anyone agree the problem I've outlined is inadequately addressed by $CALLERS::? In previous emails I've suggested: 1. The notion of something like attaching a C property on variables, and picking appropriate defaults for its args (not/ro/rw), to allow the writer of a sub to easily strictly limit what a called sub can access. 2. The notion of args that are explicitly defined in a sub's sig but implicitly passed. This kills most of the verbosity of B above, while, in combination with the previous point, being otherwise just as safe as passing args explicitly all the way down the call stack. [1] http://tinyurl.com/2yhl -- ralph
Re: Dynamic scoping (take 2)
> [temp] > [implicit args] Here's a snippet of conversation on a haskell list about implementation of implicit args : http://tinyurl.com/2ym1 -- ralph
Dynamic scoping
First, I'd like to confirm I've understood C and C right: 1. C 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 currently allowed? 2. C is a conditional C; it only restores a variable's value if, on exit from the enclosing block, the block is somehow considered to have "failed". It can be applied to a global or lexical. The above two features are basically sugar for what would otherwise be achieved with paired FIRST/LAST/UNDO blocks. Both must be applied to an existing variable. Next, I want to do a better job of stating a problem I wonder about: Consider "environmental" values such as "screen sizes, graphics contexts, file handles, environment variables, and foreign interface environment handles." [1] Consider a sub One that is going to call a 10 deep stack of subs such that sub Ten needs to access one of these environmental values. How do you pass the data? A. Globals. Bad. Disastrous in threads. B. Passed as args to all intervening subs. Verbose. Sometimes incredibly verbose. C. Aggregate info into objects. But then you still have to do either 1 or 2 above with the object references. And it's a shame to be forced to the object paradigm unnecessarily. D. Use $CALLERS::. Relatively succinct, but definitely error-prone and ugly. Given what I understand of Perl 6 syntax, Parrot, and Perl philosophy, I believe P6 should, and can fairly easily, provide a good solution to the problem outlined above. Does anyone agree the problem I've outlined is inadequately addressed by $CALLERS::? In previous emails I've suggested: 1. The notion of something like attaching a C property on variables, and picking appropriate defaults for its args (not/ro/rw), to allow the writer of a sub to easily strictly limit what a called sub can access. 2. The notion of args that are explicitly defined in a sub's sig but implicitly passed. This kills most of the verbosity of B above, while, in combination with the previous point, being otherwise just as safe as passing args explicitly all the way down the call stack. [1] http://tinyurl.com/2yhl -- ralph
Re: Dynamic scoping (take 2)
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
# unless it is passed
# to a sub explicitly.
my $foo;# same for $foo
my $baz is yours; # $baz will automatically
$baz = 10; # be passed to /directly/
# called subs that "ask"
# explicitly for $baz.
&waldo($foo);
}
sub waldo ($b ; $baz is yours)
{ print $baz; &emer; }
sub emer (;$baz is yours(no))
{ print $baz; &qux; }
sub qux { ... }
Running this prints '1010'. Here's why:
A property exists that can mark any lexical
as "yours". When a variable is marked yours
it is automatically passed to any directly
called sub (not nested subs) that mentions
it appropriately.
The "automatic" $_ (available without
declaring with a 'my') is marked "yours"
by default.
All other (ie declared) lexicals are, by
default, not yours, hence guaranteed to be
private lexicals unless explicitly passed
to a sub. This is safer than the current
perl 6 design in which use of $CALLER::,
and even builtins and subs that merely
use the topic, might accidentally clobber
one of my lexicals at any time.
Once execution reaches the body of waldo,
there is a new lexical called $baz that is
bound to the lexical with the same name in
the body of the caller.
The C in waldo's sig has two
effects:
1. It requires that any /caller/ has a
variable of the same name marked as
yours or must pass a variable/value
using the named arg syntax for that
arg name;
2. It propogates the marking of $baz as
a yours marked variable for any sub
called from this, the body of waldo.
Once execution reaches the body of emer,
there is a new lexical called $baz that is
bound to the lexical from waldo which is in
turn bound to the lexical within qux.
The '(no)' at the end of the C
means that $baz is private to emer -- it
will not be passed to called subs by the
yours mechanism.
In summary, you mark variables that are
to be automatically passed from sub to
sub with 'is yours' where appropriate.
--
ralph
