Is there going to be a Perl 6 equivalent to $ARGV (the current filename
for the ARGV filehandle)?

This is something I wanted to use in an example in the Learning Perl 6
filehandles chapter:

http://www.learningperl6.com/Chapters/11.filehandles.html

: Is there going to be a Perl 6 equivalent to $ARGV (the current filename
: for the ARGV filehandle)?

Hmm, well, we did away with unsigiled filehandles, and renamed @ARGV
to @*ARGS, so $*ARGS is presumably the magical filehandle, which means
it can't really serve as the filename at the same time.  So assuming
that any filehandle knows the name of its file (if available), it'd
probably be available via a method like $ARGS.name or some such.

Larry

In article <20070501174030.GA7...@wall.org>, Larry Wall

$ARGS.name seems reasonable enough, and the method could be very handle
for other things that use filehandles too. However, until it shows up
in a synopsis, I'll assume you're just thinking aloud rather than
making a decision. :)

=HI!
To avoid any uncertainty: the subject is a parody for similar
discussion on perl6-internals@ about Parrot.

=FOREWORD
What I want to say is that after N years of developing Perl 6 we do
not have a practical (P in Perl stands for Practical) tool which can
work in real life.

Even worse: today there is no way to speed up the interpreter - it is
good for parsing the language but is very slow for real applications.
(mod_pugs is not the case while there is no command-line tool).

=EXPLANATION
We have Pugs to play with. We have no tool to run with.

Current Pugs have options to compile the programme into several
intermediate languages, for example PIR:

You can
    pugs -CPIR helloworld.pl > helloworld.pir

But you cannot later do this:
    pugs -BPIR helloworld.pir

Standalone parrot does not help.

=WHAT IS TO BE DONE
What is nedded is a very simple step: complete the Pugs compiler so
that it could provide good PASM (PIR). Going this way we will achieve
the main goal: it will be possible to use hi-speed applications
written in Perl 6 today. No care the language itself is not fully
standardized.

It will change the status of 'conception' and 'project'
to 'utilizing' and 'using'.

=CUT
A bit of fun is that three years ago the situation was better: language
was more poor, the tools for more pure. In April of 2004 I made
a toy server with demos of how real Perl 6 works on a web-server. There
was a bit of examples with comments in Russian that were written on
real Perl 6 of that day, compiled into Parrot bytecode (.pbc) and run
on Apache under Parrot virtual machine. I cannot do the same with
today's instrumentary (or maybe I do not know how to?).

Thank you for understanding :-)

--
Andrew Shitov
______________________________________________________________________
a...@shitov.ru | http://www.shitov.ru

chromatic schrieb:

And to attract contributors, you have to have a convincing vision.
I'm not sure, if the (current) Perl6 specs are convincing enough to
attract the developers out there.
Sure there are a lot of great ideas. But imho Perl6 still has quite some
deficiencies, that are criticized very often for Perl5.

<digressing>

I'm only a distant observer of the Perl6 design process, so I might not
be in the position to criticize Perl6.
On the other hand, a distant view might be insightful.
This is not intended to be a provocation.
But I also think that there is a great opportunity to make _big_ changes
to Perl to be even more competitive.
But maybe Perl6 is probably too far defined to encounter big changes in
some critical aspects.

As Ruby and Python are getting more and more attraction [1][2] I think
they do something right, that Perl doesn't.
What I think where both (especially Python) do better is in readable code.

What makes Perl hard to read is the excessive use of special characters
(/\W/).
In my opinion, reducing the use of those characters would make Perl a
lot easier to read and also easier to write.
Global variables with cryptic names, that no beginner can make any sense
of by reading it. And after not working with "$<" for some months I
can't remember it either, although I've got quite some Perl experience.

Additionally I'm not a friend of sigils: Typing them is relatively
painful, for reading there is no advantage if you use an editor with
decent syntax highlighting and the code looks more cryptic. The answer
in Perl6 are twigils, great... One step backwards in my optinion.
Most programming languages
/C(++|#)?|Java(Script)?|Python|Ruby|Groovy/... don't need them. The only
obvious advantage of using sigils is variable interpolation in strings.
But that could easily be done only in strings without the need to put a
$ in front of each and every variable name in the rest of the code.

I would also like semicolons to be optional. There are far more cases of
single line statements than multiline statements. So you would save
quite some characters, when the semicolon would be optional and you
could concatenate multiline statements with e.g. a backslash.

Some say that there are too much operators in Perl(6). I partially
agree. I don't like the implicit type casting forced by the operators
(== int / eq string). That's harder to learn and remember. Harder to
read also.
I really like the Python way of doing it: Set the variables type on the
assignment and remember it. The (fewer) operators now work according to
the type of the operands. No implicit (and error prone) type casting.
That way seems to be the best compromise of easiness and type safety.

I could continue on that, but I've already written too much...

[1] http://radar.oreilly.com/archives/2007/05/state_of_the_co_6.html
[2] http://www.google.com/trends?q=perl%2C+python+-snake%2C+ruby

</digressing>

People not only want code that _is_ sexy, but they also want it to
_look_ sexy.

--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: streawkc...@jabber.i-pobox.net

I think they are ;-)

I don't think that there is space for the changes you are implying in
the following paragraphs. Small changes are acceptable, of course.

Right ;-)

I disagree: The make it look ugly, but not hard to read.

Well, most of them are gone or renamed to more readable ones in p6.

Then you shouldn't program in perl. Really.

Most people don't ;-).

Well, if you like the python way, feel free to code in python.
Perhaps some day it will be possible to mix them:

use python;
# Write python code here

Don't get me wrong, there's nothing bad in writing some critics, but
yours is impossible to realize in Perl 6, and therefore are it's hard to
call it constructive.

Cheers,
Moritz

--
Moritz Lenz
http://moritz.faui2k3.org/ |  http://perl-6.de/

Moritz Lenz schrieb:

Even if it's "only" ugly: To what advantage? I don't think ugliness is a
good characteristic of a programming language.

I hope so. I could only find the counterparts for __PACKAGE__ etc. in
S02. I didn't find the one for e.g. $<.

Reason? I still haven't seen a good justification for sigils.
To allow arrays and scalars and subs to have the same name (besides the
sigil) although they have different content? No good idea I think.
I also can't remember that I ever named a variable like a "reserved
word" or operator. And even if I could, I'd consider it to be bad style.

Oh, really? Source? :)
I think they were invented to allow easier parsing and not easier coding.
E.g. in JavaScript, Python, Ruby and Groovy they are optional or even
don't exist. As I said, there are much more cases where you wouldn't
need them but have to write them than vice versa.
Optional semicolons save keystrokes, eye pain and stupid syntactic
errors. And if you still like them, you could just use them, which is
the definition of "optional".

Oh, if I didn't like Perl, why should I care about posting my ideas here?
Perl has stolen the largest part of the language from other languages.
Why not do so again by adopting good ideas.

Admittedly I'm much too late and I didn't expect applause for my critics
-- but at least I hoped to get a discussion based on arguments.

 > and therefore are it's hard to call it constructive.

Unfortunately I already thought this. Even if everyone agreed that
sigils (or forced semicolons, or tons of operators, ...) are more bad
than good (and this seems like persuading the pope to allow homosexual
muslims to marry with priests) the design process is probably too far to
introduce such dramatic changes.
Sadly.

--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: streawkc...@jabber.i-pobox.net