Re: String interpolation
On Tue, 2004-07-20 at 19:35, Luke Palmer wrote:
> The New Way (tm) to do that would probably be sticking a role onto the
> array object with which you're dealing:
>
> my @foo does separator('//') = (1,2,3,4,5);
> say "[EMAIL PROTECTED]"; # 1//2//3//4//5
Shh, no one's let slip the idea of curried roles yet! I'm not even
certain A12 mentioned parametric roles, let alone first-class roles.
-- c
Re: String interpolation
Alexey Trofimenko writes:
> On Tue, 20 Jul 2004 16:06:40 -0700, Larry Wall <[EMAIL PROTECTED]> wrote:
> >So all of these would require curlies:
> >
> >{foo()}
> >[EMAIL PROTECTED]
> >...
>
> ah.. how poorly.. and how sufficient!.. But it's.. it's just not quite
> like in perl5.. But I can adopt myself. :) I doubt about "@arr" disabling,
> but {} interpolator is cool!
This doesn't quite feel right to me. I was really a big fan of the good
ol' Perl 6 days where you could interpolate as in Perl 5, and method
calls required parentheses. I understand why Larry wanted to take out
the parentheses, though... or rather why I'd want to take out the
parentheses if I were him. It's so that people would stop thinking of
$foo.bar
as a method call, and more as an attribute. Or just more abstractly --
less procedurally -- in general. This I'm all for.
But then making them interpolate without parens get's a little to
"loose" for my tastes. Perl's then come to the point of doing too much
for me, and I want it to just sit down and shut up.
I admit there's a certain interest to Larry's new idea. I've been
looking for more distinction between $, @, and % in Perl 6, since they
start to become mostly irrelavent. In the new proposal:
my @a = (1,2,3,4,5);
my $a = @a;
say "@a"; # @a
say "$a"; # 1 2 3 4 5 (perhaps?)
But I'll admit that I'm much more a fan of $() and @() than I am of {}.
Form.pm would get very angry at this decision indeed.
On the other hand, this is another step unifying strings and regexes. I
can say pretty confidently that that's a Good Thing.
On the mutant growth hand, it's just too weird. Come on, just be
conservative (or liberal, depending on whether you're talking culturally
or syntactically)! It was pretty good before. With $() and @(), it's
better than before.
> (hm.. looks like Perl6 will not require special HTML templating packages
> in 90% cases.. qq[ ] would be enough for me almost
> always)
>
> some questions:
>
> 1) is "@a[1][2]{'a'}ÂbÂ" interpolateable?
I should hope that Larry hasn't gone completely insane (or should I say
"more insane" ;-). That ought to work.
> and what about "@a[1]('arg')[3]"?
That probably wouldn't.
> 2) what's the default separator for list interpolation?
> "{1,2,3}" eq "123" or
> "{1,2,3}" eq "1 2 3" ?
I definitely liked space as in Perl 5. It was the simplest thing that
you could pick: perfectly clear where the elements are.
> and is there any way to redefine it, as assigment to perl5 @" does? I
> can't figure to which object or class that property could belong, so maybe
> there should be just lexically scoped pragma...
The New Way (tm) to do that would probably be sticking a role onto the
array object with which you're dealing:
my @foo does separator('//') = (1,2,3,4,5);
say "[EMAIL PROTECTED]"; # 1//2//3//4//5
Re: String interpolation
On Tue, 20 Jul 2004 16:06:40 -0700, Larry Wall <[EMAIL PROTECTED]> wrote:
Actually, I've been rethinking this whole mess since last week, and
am seriously considering cranking up the Ruby-o-meter here just a tad.
At the moment I'm inclined to say that the *only* interpolators in
double quotes are:
\n, \t etc.
$foo
@foo[$i]
%foo{$k}
{EXPR}
where the last provides a list context to EXPR. So all of these
would require curlies:
{foo()}
[EMAIL PROTECTED]
{%foo}
{$foo.bar}
{Dog.wag}
{.count}
{~localtime}
[EMAIL PROTECTED]
[EMAIL PROTECTED] '.'}
{$x.as "%10.5d"}
Note that this not only fixes the Perl 6 "% in sprintf" issue, but
also the Perl 5 "@ in email address" issue. It also generalizes the
notion that curlies (almost) always indicate a closure everywhere.
On the other hand, it undoes my stated A12 policy that $x.foo can be
used anywhere $foo can. On the gripping hand, it enables "{.foo}"
where we would have had a lot of "$_.foo", and I think that's an
improvement in readability, at least for people who believe in topics.
ah.. how poorly.. and how sufficient!.. But it's.. it's just not quite
like in perl5.. But I can adopt myself. :) I doubt about "@arr" disabling,
but {} interpolator is cool!
(hm.. looks like Perl6 will not require special HTML templating packages
in 90% cases.. qq[ ] would be enough for me almost
always)
some questions:
1) is "@a[1][2]{'a'}ÂbÂ" interpolateable? and what about "@a[1]('arg')[3]"?
2) what's the default separator for list interpolation?
"{1,2,3}" eq "123" or
"{1,2,3}" eq "1 2 3" ?
and is there any way to redefine it, as assigment to perl5 @" does? I
can't figure to which object or class that property could belong, so maybe
there should be just lexically scoped pragma...
Re: String interpolation
Larry wrote:
Actually, I've been rethinking this whole mess since last week, and
am seriously considering cranking up the Ruby-o-meter here just a tad.
At the moment I'm inclined to say that the *only* interpolators in
double quotes are:
\n, \t etc.
$foo
@foo[$i]
%foo{$k}
{EXPR}
where the last provides a list context to EXPR. So all of these
would require curlies:
{foo()}
[EMAIL PROTECTED]
{%foo}
{$foo.bar}
{Dog.wag}
{.count}
{~localtime}
[EMAIL PROTECTED]
[EMAIL PROTECTED] '.'}
{$x.as "%10.5d"}
So what about:
$foo[$i]
$foo{$k}
???
And would slices interpolate?
I can't say I'm keen on making {...} special in strings. I felt that the
$(...) and @(...) were a much cleaner and more general solution. The prospect
of backslashing every opening brace in every interpolated string is not one I
relish.
Damian
Re: This week's summary
On Tue, 20 Jul 2004 19:15:49 +0200, Juerd <[EMAIL PROTECTED]> wrote:
The Perl 6 Summarizer skribis 2004-07-20 14:46 (+0100):
Another subthread discussed interpolation in strings. Larry'schanged
his mind so that "$file.ext" is now interpreted as
"$object.method". You
need to do "${file}.ext" or ""$( $file ).ext"". Or maybe
"$ÂfileÂ.ext"
by analogy with "%fooÂbarÂ". James Mastros pointed out that "." is
rather ambiguous in a literal string; sometimes a full stop is just
a
full stop.
My preference is "$file\.ext". Clear, light and ascii.
Juerd
That's my preference too. But what if we have (perl5) "${n}th occurence" ?
"$n\th" won't work because of \t special meaning...
I think, better if . would be interpreted as method call only after
\$, \@, \% or \&, so
" ...leading dots?.. hm.."
would not require \ before dots, but
" text ~#~$obj.method.method2~#~ text"
would be interpreted as it should.
I think, real period will be used more often than .topicsMethod
interpolating , and "$(.topicsMethod)" or "$_.topicsMethod" look nice
enough, so there's no need to add special behavior to . not preceded by
sigilled expression..
ah, one more problem. perl5-style "${var}.NotAMethod" could save us in
some case, but what if you need to interpolate "$var.method.NotAMethod" ?
should it be "${var.method}.NotAMethod" ?.. or
"$($var.method).NotAMethod" is only solution?
Re: String interpolation
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> Actually, I've been rethinking this whole mess since last week, and
LW> am seriously considering cranking up the Ruby-o-meter here just a tad.
LW> At the moment I'm inclined to say that the *only* interpolators in
LW> double quotes are:
LW> \n, \t etc.
LW> $foo
LW> @foo[$i]
LW> %foo{$k}
LW> {EXPR}
LW> where the last provides a list context to EXPR. So all of these
LW> would require curlies:
LW> {foo()}
LW> [EMAIL PROTECTED]
LW> {%foo}
LW> {$foo.bar}
LW> {Dog.wag}
LW> {.count}
LW> {~localtime}
LW> [EMAIL PROTECTED]
LW> [EMAIL PROTECTED] '.'}
LW> {$x.as "%10.5d"}
and how do you force scalar context without a scalar() or $() wrapper
around the expression in {}? hard to say whether scalar or list context
is more popular and so would get the huffman prize. i liked @() and $()
for both context control and interpolation with context. it would do all
the above but allow $($foo) instead of {$($foo)} and that saves 2 chars
right there. maybe you could leave {} for list and have $() for scalar
but that is inconsistant and bletcherous too.
so whatever you do, make it symmetrical regarding context. even in perl5
the @{[]} and ${\EXPR} tricks are both list context which is annoying
(not that i use those tricks. i want the p6 style i mention above).
LW> Note that this not only fixes the Perl 6 "% in sprintf" issue, but
LW> also the Perl 5 "@ in email address" issue. It also generalizes the
LW> notion that curlies (almost) always indicate a closure everywhere.
LW> On the other hand, it undoes my stated A12 policy that $x.foo can be
LW> used anywhere $foo can. On the gripping hand, it enables "{.foo}"
LW> where we would have had a lot of "$_.foo", and I think that's an
LW> improvement in readability, at least for people who believe in topics.
so does @() as that is not possible in an email address AFAIK. and that
isn't a closure IMO as it is just an expression with no possibility for
arguments (unless you come up with a way for that! :).
i don't think "$foo.bar" should be a method call. it is too easy to
accidentally write and i bet many will fall into that trap. also it may
generate a very odd runtime (since it is not a method call with a
signature or declaration, it can't (easily?) be checked at compile time)
message that may be hard to actually tie back to the string in question.
so i would say, make interpolating method calls a little harder because
it won't be done as often as simpler stuff (huffman) and it should be
marked off as something completely different than simple variable
interpolation.
so method calls would need the $() or @() wrappers as do all expressions
beyond simple scalar value lookup. that means $foo, @foo[0], $foo[0],
%foo{'bar'} and $foo{'bar'} all interpolate and only their variants
(longer index/key expressions) do as well.
related question: given a ref to a scalar like $foo = \$bar, what is
interpolated in these?
"$foo" # similar to ref interpolation in p5?
"$($foo)" # similar to ref interpolation in p5 as this is
# just the scalar context op
# or does this do a dereference as p5 would do?
"${$foo)" # deref and interpolate that value
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs http://jobs.perl.org
Re: String interpolation
On Tue, Jul 20, 2004 at 06:28:11PM -0400, Aaron Sherman wrote:
: > My preference is "$file\.ext". Clear, light and ascii.
:
: That's fine as far as it goes, but how do you say what, in Perl 5, I
: would use this for:
:
: "${foo}n"
:
: I like the ${} syntax, but I'm a shell guy from my early days... long
: before I touched Perl. If ${} is going to go away, then it seems like
: the best route is one of:
:
: * The pythonish "%sn" % ($foo) sprintf operator, something other
: than % though. Might even be -> with appropriate layers of sugar
: * "$($file)n"
: * "$file\bn" \b is word-break in regexp, so it makes sense to me
: here mnemonically. Could even have "$\b$money\bM is a lot" which
: would force the lone $ to be literal in the same way as
: "\$$money\bM is a lot" would. Kinda fun.
Those are all pretty bletcherous.
Actually, I've been rethinking this whole mess since last week, and
am seriously considering cranking up the Ruby-o-meter here just a tad.
At the moment I'm inclined to say that the *only* interpolators in
double quotes are:
\n, \t etc.
$foo
@foo[$i]
%foo{$k}
{EXPR}
where the last provides a list context to EXPR. So all of these
would require curlies:
{foo()}
[EMAIL PROTECTED]
{%foo}
{$foo.bar}
{Dog.wag}
{.count}
{~localtime}
[EMAIL PROTECTED]
[EMAIL PROTECTED] '.'}
{$x.as "%10.5d"}
Note that this not only fixes the Perl 6 "% in sprintf" issue, but
also the Perl 5 "@ in email address" issue. It also generalizes the
notion that curlies (almost) always indicate a closure everywhere.
On the other hand, it undoes my stated A12 policy that $x.foo can be
used anywhere $foo can. On the gripping hand, it enables "{.foo}"
where we would have had a lot of "$_.foo", and I think that's an
improvement in readability, at least for people who believe in topics.
Larry
String interpolation
On Tue, 2004-07-20 at 13:15, Juerd wrote:
> The Perl 6 Summarizer skribis 2004-07-20 14:46 (+0100):
Wasn't there an actual thread to respond to for this? I always feel odd
turning the summary into a thread on what it's summarizing.
> My preference is "$file\.ext". Clear, light and ascii.
That's fine as far as it goes, but how do you say what, in Perl 5, I
would use this for:
"${foo}n"
I like the ${} syntax, but I'm a shell guy from my early days... long
before I touched Perl. If ${} is going to go away, then it seems like
the best route is one of:
* The pythonish "%sn" % ($foo) sprintf operator, something other
than % though. Might even be -> with appropriate layers of sugar
* "$($file)n"
* "$file\bn" \b is word-break in regexp, so it makes sense to me
here mnemonically. Could even have "$\b$money\bM is a lot" which
would force the lone $ to be literal in the same way as
"\$$money\bM is a lot" would. Kinda fun.
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Perl Toolsmith
http://www.ajs.com/~ajs/resume.html
Re: This week's summary
The Perl 6 Summarizer skribis 2004-07-20 14:46 (+0100):
> Another subthread discussed interpolation in strings. Larry's changed
> his mind so that "$file.ext" is now interpreted as "$object.method". You
> need to do "${file}.ext" or ""$( $file ).ext"". Or maybe "$«file».ext"
> by analogy with "%foo«bar»". James Mastros pointed out that "." is
> rather ambiguous in a literal string; sometimes a full stop is just a
> full stop.
My preference is "$file\.ext". Clear, light and ascii.
Juerd
Re: This week's summary
--- The Perl 6 Summarizer <[EMAIL PROTECTED]> wrote: > Okay, so the interview was on Tuesday 13th of July. > It went well; I'm going to be a maths teacher. "As usual, we begin with maths-geometry: In Mathematics last week, one Pythagoras suggested there might be a relationship between the sides of a triangle and its hypotenuse. Zeno continued to close on his destination, but once again only got halfway there. http://xrl.us/chjj (Squares) http://xrl.us/chjk (Zeno in mid-flight) As we all know, time flies like an arrow, but fruit flies like a banana. If you found this mathematical summary helpful, please consider paying your tuition you ungrateful little bastards." Congratulations, Piers! The fate of a generation rests on your shoulders. =Austin
This week's summary
The Perl 6 Summary for the week ending 2004-07-18
Following last week's bizarrely dated summary (I misplaced a day) we're
back with the correct week ending date, but I'm ashamed to admit that
I've slipped to writing on a Tuesday again. My head hangs in shame and I
am filled with the direst remorse.
It will probably happen again though; life's like that.
Pie-thon!
Anyone would think that the possibility of not even being able to run
the Piethon benchmark (let alone getting a pie in the face for running
it too slowly) weighs heavily on Dan.
The bulk of the week's traffic related to getting to the point where we
can at least run all the tests.
Python::Bytecode, the module that parses, well, python bytecode, shot up
in version numbers; I think it reached 2.7 by the end of the week.
Dan released a Piethon translator, a tool that uses Python::Bytecode
translate python to parrot. So has Leo. Dan's is on his website (see the
link below, you'll find Leo's in languages/python/pie-thon.pl).
http://xrl.us/chh9 -- Parrot runs a python lambda
http://xrl.us/chia -- Notes on pie-thon.pl
http://xrl.us/chib -- Namespaces for builtins
http://xrl.us/chic -- Dan's translator
Semi-stack code
In a quest for speed when emulating python's stack manipulation ops, Dan
outlined a plan for manipulating a pseudo stack using some of Parrot's
PMC register (18-29, with P31 used for overflow). Leo wasn't convinced
it was needed.
http://xrl.us/chid
"string_to_num" precision
Leo's got some problems with the precision of the "string_to_num"
function found in string.c. He doctored things to use "atof", but Dan's
not so keen on that idea because "atof" doesn't have standard behaviour
across platforms. He recommended grabbing Perl 5's string to num code
(which he thought we'd already done). Nicholas Clark wasn't convinced
that this was a good idea; he reckoned that Perl 5's code wasn't good
enough. I think Nicholas convinced Dan that "atof" is actually the right
thing to use (with a little preprocessing to deal with C99's "atof"
being incompatible with C89's -- Parrot expects C89 behaviour).
http://xrl.us/chie
GMP Licensing
Armin Obersteiner reported his investigations into the licensing
requirements of the GMP maths library. It appears that the FSF's 'GPL
Compliance Engineer' reckons we won't need to include the GMP's source
code with binary distributions. We just have to make it available from
the same source as the distribution. Which is handy.
http://xrl.us/chif
Parrot configuration -- a small perl task
Leo asked for volunteers to fix up Configure.pl in order to make it less
dependent on the host Perl's configuration. Brent Royal-Gordon provided
a teeny-tiny patch that's actually shorter than Leo's description of the
problem.
http://xrl.us/chig
Meanwhile, in perl6-language
Scalar subscripting
Remember Guatam Gopalakrishnan's question about subscripting scalars?
Discussion continued. One Piers Cawley (who he?) suggested that it
should be possible to specify a "postcircumfix:[] is rw" method in the
String class to make string subscripting behave in a helpful fashion. He
also suggested pulling this (and other similar behaviours) out into a
Sequence trait. Juerd thought the proposed method name was a little
verbose compared to Ruby's syntax for doing the same thing and showed
off some rather pretty Ruby metaphors.
Another subthread discussed interpolation in strings. Larry's changed
his mind so that "$file.ext" is now interpreted as "$object.method". You
need to do "${file}.ext" or ""$( $file ).ext"". Or maybe "$«file».ext"
by analogy with "%foo«bar»". James Mastros pointed out that "." is
rather ambiguous in a literal string; sometimes a full stop is just a
full stop.
http://xrl.us/chih
Pushing lazy lists
This thread continues to resemble the lists it is nominally discussing:
Infinitely long and possibly endless.
http://xrl.us/chii
Perl 6 and Parrot Essentials, 2nd Edition
Leo pointed us at an O'Reilly press release announcing that the second
edition of *Perl 6 and Parrot Essentials* is available. Huzzah! Let joy
be unconfined.
http://xrl.us/chij
Rules to match abbreviations
Hans Ginzel wondered wondered about adding something to the rules system
to easily match specified abbreviations of a string. Luke Palmer came up
with a (pretty ugly) solution which he then wrapped very neatly in a
rule.
http://xrl.us/chik
Enhancing "open"
There's a good deal of mileage to be had talking about how to improve
the "open" function it seems.
Larry continues to come up with new and interesting ways of designing
the language in such a way that almost every decision about how to do
something can be deferred. Speaki
Re: Why do users need FileHandles?
On Sun, 18 Jul 2004, Andrew Shitov wrote:
> DW> my $text is TextFile("/tmp/bar");
> DW> $text = "hello"; # writes, truncates
> DW> $text ~= ", world\n"; # appends
>
> DW> $text.print "again\n"; # for old-times sake
>
> Anyhow we still need $text.flush() or $text.close() methods.
^^
Not necessarily if lexically scoped, just as in (recent enough) perl5...
Michele
--
>A question out of curiousity: who is this Green of Green's functions?
>Is he the same person of Green's theorem? :)
Yes. He was also an early environmentalist; hence the current
phrases "green" this and "green" that...
- David C. Ullrich on sci.math, thread "Who is Green?"
Re: push with lazy lists
On Mon, 19 Jul 2004, Jonadab the Unsightly One wrote: > > If I extend the natural numbers N with Inf to a new set NI (N with > > Inf) > > The problem is, NI is not a group with respect to addition for any > definition of addition of which I am aware. Translated from mathese In other words, or more briefly, and in many different contexts, it is well known that "Inf" can't be fully arithmetized... Michele -- > As you see, we have to conclude that either Cantor's "proofs" are > worthless wastes of ink, Or we can conclude that your posts are worthless waste of web space. - "Theorist" in sci.math, "Re: Cantor Paradox :-)" (slightly edited)
