Re: perl6 requirements
> Language > Miscellaneous language issues > item 1. > Perl is not like other programming languages. Ilya used to say that > Perl isn't a programming language - Perl's grammar is much more like > a natural language than a computer one. Well, $I wonder if anyone except @computers can find it natural to put a f... $dollar_sign in front of every $noun you use. I think we should be glad that Larry likes his 'if's without dots. -Edwin (I like Perl, ...somehow, ...sometimes.) (And yes, I know that 'I' is not a noun but it's a scalar value containing me. BTW I wonder what @I and %I stand for.)
Re: perl6 requirements
Simon Cozens schrieb:
>
> On Tue, Aug 01, 2000 at 01:13:17PM +0200, Edwin Steiner wrote:
> > > Perl isn't a programming language - Perl's grammar is much more like
> > > a natural language than a computer one.
> >
> > Well, $I wonder if anyone except @computers can find it natural to put a
> > f... $dollar_sign in front of every $noun you use.
>
> Grammar != vocabulary.
You're right. Strictly speaking this reduces my posting to
misaimed babbling. :-)
I don't know a lot about CS but since the perl6 community seems to
be concerned about Perl6 being as widely accepted as possible I will
make the following observations. (Risking to repeat something you all
have probably heard 12000 times.)
In my opinion Perl lacks (at least partially) some features which
I consider important for scripting languages:
* elimination of pointers (If I want to spend my time considering how
many dereference operators to use I'll go for ***C++).
I'm aware, however, that switching from variable assignment to
name binding (like in Python or Scheme) is a very fundamental change
and therefore not an issue for perl6 (or is it?).
* no need to declare variables: I think variables should be
lexically scoped by default, without having to think about and write
all those 'my's.
* convenient handling of structured data/records/objects with
attributes: I'm referring to what you can do (for example) with
Python instances: foo.member = bar
I guess I'm not the only one who prefers this to
$$foo{'member'} = $bar (which of course has nothing to do
with $foo{'member'} = $bar).
Maybe Perl is sane and I'm just not getting the point. :-)
-Edwin
Re: perl6 requirements
Tom Christiansen schrieb: [snip] > "Seems" may be the operative term here. Feckless worship of the > false idol of universal popularity will, in attempting to please > everyone, be doomed to please no one. A less proselytist message > would be much useful, perhaps one more along the lines of: "This > is who we are (read: what Perl is). If you like how we are, that's > great--use Perl and be happy. But if you don't like who we are--that > is, *how* we are--then don't use Perl; there are plenty of other > languages for you." [snip] > >I'm aware, however, that switching from variable assignment to > >name binding (like in Python or Scheme) is a very fundamental change > >and therefore not an issue for perl6 (or is it?). > > I wasn't aware that it wasn't an issue. Larry once seriously > contemplated this for perl4++, so why not revisit the notion? I can't help being disoriented about the scope of the discussions which will take place on this list. On the one hand there are such statements as (taken from "Report on the Perl 6 Announcement" on www.perl.com): Can you hint at some of the language changes? Larry said that everything was negotiable. [...]consider any change at all, as long as it could be translated. On the other hand there are the "Perl must remain Perl"-like statements. Although these statements do not contradict each other they open up an enormous space for discussions, which could lead to the following problems: * People refrain from making far reaching (possibly useful) suggestions because they can't imagine them being considered. * The community could waste a lot of time producing suggestions which are discarded at first sight because they would lead Perl in an unwanted direction. Is there any clear notion of the "Perl" part in Perl which should remain its identity? I read thinks like: "perl (the implementation) defines Perl", which is not very helpful because the implementation is going to be rewritten or "the tests define what's Perl", which is also problematic because existing code (including tests) will likely have to be translated to Perl 6 anyway. -Edwin
Re: r29144 - docs/Perl6/Spec
Hello! On Fri, Nov 20, 2009 at 09:39:13AM +0100, pugs-comm...@feather.perl6.nl wrote: > -constant Dog $fido .= new; # okay: a constant Dog object > -constant Dog $fido = Dog.new; # same thing > -constant Dog $fido = $fido.new; # wrong: invalid self-reference > -constant (Dog $fido .= new);# wrong: cannot use .= with parens > +my Dog $fido .= new; # okay: a constant Dog object > +my Dog $fido = Dog.new; # same thing > +my Dog $fido = $fido.new; # wrong: invalid self-reference > +my (Dog $fido .= new);# wrong: cannot use .= inside signature s/constant Dog/Dog/? Or am I missing something? -Edwin
Re: printf-like formatting in interpolated strings
Simon Cozens <[EMAIL PROTECTED]> writes: > it was addressing a problem at too low a level. This could be because I'm a > grouchy old-timer, and I carry over a Perl 5 design principle that says that > changes should be made in as general a way as possible. It's a very good principle, I think. One (tiny) generalization I could think of was to pass everything between the \F and the funny character as an argument to a method call on the value. This method then stringifies the value. The default method just does sprintf or something similar. I see that it would probably be better to pass something like a general "stringification context" to the value, which could contain eg. language info. > Ziggy mentioned earlier today. I think all that needs to happen at this stage > is that we realise that a nicer way to do formatting in strings > would be good, I'm content if this will be revisited (hopefully by someone with better overview than mine). It just should not be ignored. > Unfortunately, it cuts both ways; this is the second post in a row you've > ended with an unnecessary barb. I know I'm no saint as far as that's > concerned, but I also know it doesn't necessary endear people to your point of > view. Look, no barb --> :) -Edwin
Re: Semantics of vector operations
Luke Palmer <[EMAIL PROTECTED]> writes: > @A »+« @B # One-at-a-time > @A «+» @B # Outer product > > Or something. Hmm, then both: > > @A »+ $b > @A «+ $b There is a page you may find inspiring: http://www.ritsumei.ac.jp/~akitaoka/index-e.html Sorry, I could not resist. :) The one-sided operators make sense to me but combining this with both « and » seems hard on the eyes. That being said I really like the general direction that Perl 6 is going and I'm looking forward to using it. You're all doing great work! back to lurking-mode -Edwin
TIMTOWT concat / idea: hypo-operators
Hello! I have some questions about unary _ Is this going to concat $a,$b and $c? $foo = _($a,$b,$c); (One way to save underlines and spaces if you have many operands.) Or would that be: $foo = _@($a,$b,$c); What will these do? $a _=_ ($b,$c); $a ^_= ($b,$c); (WIM in Perl 5: $a .= $b.$c ?) Could there also be *hypo*-operators, i.e. operators which try to *lower* (reduce) the dimensionality of their operands to the lowest common dim. So $foo = 5 +^ (1,2); would set $foo to (5 + 1) + 2 and $foo = $a _^ ($b,$c); $a _=^ ($b,$c); would do the same concats as above respectively? Another application: $sum = 0 +^ @values; Granted: ^ is not the best choice for a meta-operator which lowers something. :) Thanks for your time, -Edwin
TIMTOWT concat / hypo-operators
Hello! Is this going to concat $a,$b and $c? $foo = _($a,$b,$c); (One way to save underlines and spaces.) Or would that be: $foo = _@($a,$b,$c); BTW: what will these do? $a _=_ ($b,$c); $a ^_= ($b,$c); # (better with hypo-operator?, see below) (WIM in Perl 5: $a .= $b.$c ?) Could there also be *hypo*-operators, i.e. operators which try to *lower* (reduce) the dimensionality of their operands to the lowest common dim. So $foo = 5 +^ (1,2); would set $foo to (5 + 1) + 2 and $foo = $a _^ ($b,$c); $a _=^ ($b,$c); would do the same concats as above respectively? Another application: $sum = 0 +^ @values; Granted: ^ is not the best choice for a meta-operator which lowers something. :) -Edwin
Re: TIMTOWT concat / hypo-operators
[EMAIL PROTECTED] (Jeremy Howard) writes:
> Brent Dax wrote:
> > Edwin Steiner:
> > # Could there also be *hypo*-operators, i.e. operators which try to
> > # *lower* (reduce) the dimensionality of their operands to the lowest
> > # common dim. So
[snip]
> > I don't really see the use of hypo-operators.
> >
> Well, it's pretty handy to be able to generalise what join() does for concat
> to any abitrary function. It's covered by:
> http://dev.perl.org/rfc/76.html
> which proposes a new reduce() builtin.
I'd like hypo-operators
a) for the sake of symmetry (imperfect symmetry that is)
b) because they minimize the separation of verb and object
cf. $acc += $_ for (@values);
vs. $acc +=^ @values;
(Well, that's not a hell of an argument, is it? :)
You could of course do more clever and confusing things
with multi-dim. arrays.
Anyway, I realize the need is less than urgent. :)
Maybe Perl 6 is going to be the language to resolve such
"I want it"/"I don't care"-arguments in a friendly way. It should be
feasible to write a module so you can do
{
use Operators::Hypo;
@score +=^ (4,1) *^ @points;
}
lexically, I mean.
What's needed is a parser hook for the operators (which is needed
anyway) and a way to write an extension module which provides
dynamically installable Perl ops which are (almost) as fast as the
builtins (which seems to be in planning).
-Edwin
Re: TIMTOWT concat / hypo-operators
[EMAIL PROTECTED] (Edwin Steiner) writes: > @score +=^ (4,1) *^ @points; Sorry, I completely f...ed up the example. What I was thinking of would be more like: $score +=^ (4,1) ^* @points; So one hypo- and one hyper-operator. Assuming @points is 2-dimensional this would: 1) multiply @points element-wise by the matrix 4 1 1 ... 4 1 1 ... 4 1 1 ... ... ... 2) add the sum of all elements of the resulting matrix to score. -Edwin
printf-like formatting in interpolated strings
Hello!
Recently I was coding Perl 5 and quite often I had to change
interpolated strings or C to C or .
I began to wonder, if qq strings couldn't allow sprintf-like
formatting directly.
I could imagine an \F escape sequence with the following syntax:
:'\F' printf-format-without-% '(' expr ')'
|'\F' printf-format-without-% '{' string '}'
Examples:
"The value in hex is \Fx($value)."
"You currently have \F020d($dollars) on your account."
"Leave some --\Fs60{space for this $interpolates string}--."
I find this syntax reads very well.
eg. "The value in hex is 'format hex $value'."
I like that it doesn't separate format specifier and
data like s?printf. Please note: I don't want to replace s?printf!
Is there something I have missed that would make this impossible or
impractical. Or maybe this feature already exists somewhere and I
don't know it?
best regards,
-Edwin
Re: printf-like formatting in interpolated strings
Edwin Steiner <[EMAIL PROTECTED]> writes:
> "Leave some --\Fs60{space for this $interpolates string}--."
I'm sorry, this should be:
> "Leave some --\F60s{space for this $interpolates string}--."
Re: printf-like formatting in interpolated strings
Luke Palmer <[EMAIL PROTECTED]> writes:
> As far as the syntax, the () and {} don't make a lot of sense with
> regard to the rest of the language. We could either utilize the
> string/numeric context distinction that already exists in {} and []
> for subscripting, or we could always use () in analog to $().
My idea was to make it like the scoped \L{ } of Apocalypse 2.
The \L also says something about formatting and the { } creates a
scope, which "stays" in the interpolated string.
You are right about the (), however, because there should be a
more visible marker (probably a sigil) when the syntax changes from
to .
> I'd like to have that dollar in there somewhere, actually.
>
> "The value in hex is \Fx$( expression )."
The problem is calculated format (I forgot to mention this):
"The value in the chosen format is \F$format$( expression )."
The compiler cannot know, if $format contains the whole format
specifier or just a part (or nothing) so it does not know if it should
take $( expression ) as part of the format or as the formatee ;).
With my proposed syntax the first '(' outside any nesting constructs
would clearly mark the beginning of the formatee.
One option would be to only allow
\\F \{ \}
so this would work and the dollar is there:
"You wanted to see it like that: \F$format\Q{$that}"
"You have \F${digits}d{$cent}."
...which is less than beautiful (should not be common, though).
Also the formatee would always be converted to a string before
formatting (also see conclusion below).
> Or something. That is kinda clunky, though. Maybe just a
> stringification adverb, albeit verbose (but more versatile):
>
> "The value in hex is $( expression where format('x') )"
>
> No, I actually think that should be a property. In fact, one that has
> been discussed before:
>
> "The value in hex is $( expression but formatted('x') )"
>
> That's actually my favorite so far.
So the value should 'carry' its own format...This makes sense in some
cases, in other cases it does not (Though you always could override
with another C.)
The syntax is clean, but even longer than with sprintf:
"The value in hex is $( expression but formatted('x') )"
"The value in hex is $( sprintf '%x',expression )"
Why not allow both (\F with {} and C)? If we disallow
interpolated formats on the \F it introduces minimal complexity into
the parser and compiler. The only price to pay would be the \F
itself.
Disallowing interpolated formats on \F has the additional advantage of
making the {} unnecessary in the most common cases (also removing the
'force to string').
The best of both worlds:
sub foo(int $x,int $y)
{
# print "fooing $x with $y\n" if $debug;
# change it to hex format temporarily
print "fooing \Fx$x with \Fx$y\n" if $debug;
}
$msg = "The value of \$y is $( $y but formatted($chosen_format || '0d') )."
-Edwin
Re: printf-like formatting in interpolated strings
Edwin Steiner <[EMAIL PROTECTED]> writes:
> Disallowing interpolated formats on \F has the additional advantage of
> making the {} unnecessary in the most common cases (also removing the
> 'force to string').
As an afterthought: This suggests getting rid of the {} entirely.
The rule could be like:
\\F
so
"The value in hex is \Fx$value."
"The value in hex is \Fx%lookup{$key}."
"The value in hex is \Fx$(calculate($x,5))."
would both be ok. For more complex formatting you use C or
C.
I really like that. (It's perlish, too, don't you think?)
-Edwin
Re: printf-like formatting in interpolated strings
Edwin Steiner <[EMAIL PROTECTED]> writes:
> The rule could be like:
>
> \\F
After-afterthought:
We know: Everything between the \F and the next funny character is the
format specifier. This allows extensions to the printf-specifiers:
(These extension and more could also be used in C.)
rule format_specifier {
('-' | ' ') ? ? ('.' )? ?
|
? ? ('.' )? ?
}
rule fill_character {
'-' |
}
rule fill_character_no_minus {
> ( <[EMAIL PROTECTED] ]> | )
}
(Hope I got that right.)
If there is no specified, just do the alignment and
filling on the value (which is converted to string before that).
Examples:
$x = 3;
" \F6$x" --> 3
" \F-6$x" --> 3
" \F06$x" --> 03
" \F*6$x" --> *3
" \F-*6$x" --> 3*
" \F\$6$x" --> $3 (yes, it's ugly)
" \F\-6$x" --> -3
" \F -6$x" --> -3 (looks better without the backslash, I think)
" \F--6$x" --> 3-
"\F*20$()" eq ('*' x 20)(don't want to propose special syntax instead of $())
Another possible extension: If there is a specified,
followed by an 'x' and , interpret it as x
and don't expect the :
"\F*x20" eq ('*' x 20)
...quite irregular though.
-Edwin
Re: printf-like formatting in interpolated strings
Austin Hastings <[EMAIL PROTECTED]> writes: > Now, if you want to talk about the cool amazing formatting syntax > you've conceived for sprintf replacement, that's fine. But I'm getting > that warm cozeny feeling that this is burning unnecessary listmips. Well, it's a bike shed. But it is a bike shed people use all the time. The world cannot be run by nuclear scientists alone. If you don't think it's worth talking about such things, install a mail filter which deletes all mails not containing the word 'paradigm'. -Edwin
Re: printf-like formatting in interpolated strings
Simon Cozens <[EMAIL PROTECTED]> writes: > % grep printf cvs/modules/**/*pm | wc -l > 15 > % grep -v printf cvs/modules/**/*pm | wc -l > 15360 > > Well, 0.1% agreed, anyway. Could also mean the current printf syntax is not too popular. Reusable code is also less likely to use it than the day-to-day code one writes anew each time (being annoyed about printf). There should be guidelines about what postings are appreciated on perl6-language. I'd happily obey them. dev.perl.org says Description: This list is for discussing user-visible changes to the language. It's somewhat unnerving to post on topic and (hopefully) politely and get a cold (less on topic) reply from someone with "warm feelings". On the other hand the sharks might miss the occasional bite... regards -Edwin
