Hey, all.
This whole discussion on using . instead of -> made me think a lot about
the Perl 6 language. Actually, this was the more recent of many
religious wars happening on perl6-language about choosing this or that
way of doing something. I remember many others like using my or using
dynamic variables, using strict or no strict by default and the same
with warnings, everything/nothing should be an object, etc.
Well, every one of these discussions is actually very important, since
the outcome of this will be the syntax of Perl, and the syntax defines
much of how we feel the language. Of course we cannot judge a language
by its syntax, we have to see the features and flexibility it offers
(its internals), but usually the syntax is the first thing of the
language we get in touch with, it's our first impression of the
language, and a non-pleasant syntax can make one resist to learn a
language. I really can say that because syntax made me resist to
languages like Python, Ruby and Pascal, while it attracted me so much to
Perl and C.
Of course, when you see the language at a whole, you see the features
and the flexibility it offers, what made me see how C and Java are
inflexible and how Perl and Python are flexible languages. But we have
to admit that syntax has a strong importance in the first contact with
the language.
That's why I think perl6-language should change its course. I know this
can sound a bit too strong, but please consider my points:
First of all. Perl 6 will be flexible in its internals. We sure can say
that, because we know Perl 5 very much to know what is good about it and
what is not. We know it enough to say that tying is a good thing, and so
is overloading. They both provide a very good level of transparency to
the language. You can access any object through variables (and we hope
in Perl 6 we'll be able to access them as filehandles, regexps, strings,
etc). You can access any sub as an operation, by overloading that
operation to that object. Nothing can be more transparent than that. We
know, however, that Perl 5 has a rather weak implementation of both
tying and overloading. Tying is too slow, and is rather cumbersome on XS
level. Overloading isn't even documented in XS level, and there are some
operations missing, there are some flaws in it. Well, I see
perl6-internals is working hard on fixing some of this flaws while also
adding a never seen level of flexibility, in areas including adding new
opearators to the language, adding support for multiple encodings,
pluggable regexp engines, and other levels of indirection to provide
maximum transparency to the language.
Second point. IIRC, the parser and bytecode generator of Perl 6 are to
be flexible and extendable. If I understand this correctly, it would be
possible, for example, to write another parser/generator for another
completely different language, for example Python or Java, and make it
generate bytecode for the Perl interpreter, that would use the powerful
flexibility of Perl's guts. Also, if I understand correctly the
flexibility and extendability of Perl 6's parser and generator, I would
say it would be possible to make changes and additions to the syntax it
implements by dealing with a well-defined and very clear API.
For example, I would expect to be possible in Perl 6 to add a brand new
operator to the language by only defining some sub, object, or whatever
that defines the behaviour of the operator, and then registering the
operator using an exported function of the parser, but -- this is
important -- without needing to know of any internal details about the
parser except for its exported API.
Also, I would expect to be possible to change the default scope of
variables just by adding some hooks to the parser and to the bytecode
generator. Also, here I expect to learn only about the exported API of
the parser and the exported API of the generator. I really don't care if
they are implemented with a descending tree or with a bottom-up
approache or in a xyyzy bar way, I would expect to have a clean API that
would allow me to add hooks to them independently of their
implementation.
And I would also expect, that I could change `.' to be the operator that
accesses methods in objects, like `$obj.method(@params)', instead of
using `->'. Also, I could change `~' to do concatenation, and change
many other operators to do whatever I want with them, all by using the
exported APIs of the parser/generator. I would also expect to be able to
change the language to accept variables without [$@%], and although this
would probably mean deep changes in the languages, yes, I would expect
to do this without having to write a new parser, but only by using the
API of the parser/generator.
And my last expectation (if I'm not expecting too much...) is that all
these changes would be independent of each other. For example, I could
make the change to accept variables without prefixing them with [$@%],
then I could change `.' to access objects' methods, then I could change
the default scope of variables to lexical, and whatever order I did
these operations, it would all work as expected, it would DWIM.
Well, if all my expectations about the parser will become reality (and I
hope they will, I'd work real hard for it), then I think the core of the
language should be quite different than what is being proposed now.
Since I began learning Perl, I read always that TIMTOWTDI in Perl, and
that is important, because the way that pleases one usually isn't the
way that pleases another one. And that's why there are so many wars in
perl6-language, because people cannot agree on the best way to do
something, because the best way for any one of them is different.
Well, if Perl 6 will be able to tailor itself to any way, why should we
bother choosing one of them and throwing all others away? We could,
instead, have a minimalistic language, with only the basics, and provide
several little modules that would allow us to have the language as we
want it to be.
Think of it, Perl 5 is actually a little like this, with `use strict'
mostly. Strictness changes the parser behaviour to disallow variables
not explicitly declared. Of course, that doesn't change the language so
much, but the principle is the same.
I think the core language of Perl 6 should have the minimal necessary to
do something useful, only the barest. Then, by loading modules (syntax
modules), anyone could tell the language how she would like it to be.
For example, scope. The bare language could have the Perl 5 behaviour of
making everything dynamic. There already is the `strict' module. There
could be a module that makes everything lexically-scoped by default. And
there could be a module that requires every variable to be explicitly
declared, and also requires strong-typing to all variables. These are
four different ways of writing code, and every one of them would have
its use, at least for me. Everything dynamic is great for one-liners.
Strictness is good for writing modules. Everything lexically-scoped by
default would be good for small modules where I want everything `my'ed
without having to write it explicitly. And forcing strong-typed
variables would be something loved by people that want to migrate to
Perl from Java or integrate Perl code with code of another strong-typed
language. The four have very different uses, all of them valid ones. And
these four are actually limitted by my mind, by what I think about
scope. Another person could have different ideas or needs of scoping
behaviour, and then there would be more ways of handling it.
Another thing is personal taste. You can't have everybody liking the
same things. For example, I think most people like having `.' to access
methods, but I don't. Yes! You can force me to use it! But this is
against the TIMTOWTDI spirit of Perl! Perl should be about allowing
people to do what they want the way they want, not about forcing them to
do it the way some decided would be the best.
And I'm not saying here that Perl should stay Perl, but I'm saying that
there should be more than one way to write Perl and _one_ of them should
be Perl 5 syntax.
Many may be thinking: that would make Perl no standard language, in that
there would be many different unrelated languages, and no standard Perl.
That's not true. Consider an example of a language that is built this
way: TeX. TeX is built of a set of primitives, above which are built a
set of macros. The macros are what ultimately make the syntax of the
language, because they are what you have to write in the TeX code to do
whatever it has to do. It's even possible to change the special symbols,
like \, { and }, by using \catcode. Several different sets of macros are
built above TeX, for example, Plain TeX, LaTeX and eTeX. And that makes
TeX no less standard a language, actually, it makes it a more popular
language, since it can be tailored to the use it's needed. LaTeX is
great for writing papers and articles, but Plain TeX can be better if
you have a structure that doesn't fit LaTeX, for example. LaTeX still
supports document classes and packages, to further customize it to the
user's needs.
My last comments are on what I suppose would be the minimal Perl that
would be loaded by default. Actually, I recall many people asking to
export `tinyperl', or better, different perls in different
granularities, for different tasks. Well, I think the minimal Perl
should be something like `tinyperl'. It should be useful for something.
The moment you have a language that can't do anything useful by itself
before loading external modules you don't want to use it anymore.
I would propose that the core language should be useful for doing the
thing that Perl was built to do: process strings easily, manage lists of
items, and deal with files. No objects here. This may seem like Perl 4
and, yes, I think this should be Perl 4 with some details cleaned up.
I'm not proposing using Perl 4 syntax, but actually taking what Perl 4
can do, and taking a subset of the proposed Perl 6 syntax that allows
only this bare minimum. For example, no filehandles as they were in Perl
4, i.e., barewords, as filehandles will be objects. Oh, I said no
objects before. I meant no way of defining and accessing methods of
objects, i.e., no namespaces, and no -> syntax. That would have to be
loaded. I also think that regexps, in this level, should be POSIX, or
very close to it, without extensions (extensions are everything with
(?...)). That could be loaded up after too. And, of course, the minimal
language should have a way to extend itself, i.e., `use'.
Now, the other question is about which syntax modules would be included
in the distro. I would say every syntax module that is particularly well
debugged and, mainly, well-documented, should go in, doesn't matter if
someone finds it useful or not. The idea is not for we to find is
useful, it's that someone may find it useful, and may decide to use it
for some purpose.
I would also propose a namespace, like `syntax::' for syntax modules.
For example, `syntax::scope::lexical' could be the module that makes all
variables lexical by default, and `syntax::objects::dot' could be the
module that allows using `.' to call methods on an object. Yes, this
would lead to big preambles on Perl source code, with several lines of
`use syntax::...'. Well, tell me of one language that doesn't require
several lines of preambles in somewhat complex programs. And also, for
simple and day-to-day scripts, the base language without syntax changes
could be used. Most system administration jobs and also filters that
take data from several text files and write data to other text files
would indeed be written without any of these modules. Or with them, if
the person who wrote them felt like using them.
Also, having the language being built by several syntax modules would
actually assure the parser is designed the right way, with a sufficient
API for external modules to change or extend the language.
Well, this is what I had to say about these language issues. Please,
don't flame on me because of this. It's only my opinion, and I think
many people think different than this (actually, my opinion is all based
on this fact). I also don't expect it to be accepted or agreed by all, I
only wanted to share my thoughts about it, so that maybe someone can see
the subject on a different, new point of view.
- Branden
