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