Re: The trouble with awesome
On Sat, May 26, 2012 at 6:34 PM, Nicholas Clark wrote: > On Fri, May 25, 2012 at 08:44:30AM -0500, B. Estrade wrote: > > > Realistically, that's not going to happen. The internals of the Perl 5 > interpreter are not flexible enough to implement a lot of the features > that > Perl 6 has that Perl 5 does not. > > Nicholas Clark > > * Or Python 2 to Python 3, as far as I can tell as an outsider. > why can't we write a brand new perl5 interpreter or a better one based on parrot VM if perl6's strength more than perl5 is just internals of the interpreter? it seems Gcc community had a similar discussion about mess of internal. http://gcc.gnu.org/ml/gcc/2012-03/msg00263.html
Re: The trouble with awesome
On Mon, May 28, 2012 at 03:38:48PM +0800, Xiao Yafeng wrote: > On Sat, May 26, 2012 at 6:34 PM, Nicholas Clark wrote: > > > On Fri, May 25, 2012 at 08:44:30AM -0500, B. Estrade wrote: > > > > > > Realistically, that's not going to happen. The internals of the Perl 5 > > interpreter are not flexible enough to implement a lot of the features > > that > > Perl 6 has that Perl 5 does not. > > > > Nicholas Clark > > > > * Or Python 2 to Python 3, as far as I can tell as an outsider. > > > > > why can't we write a brand new perl5 interpreter or a better one based on > parrot VM if perl6's strength more than perl5 is just internals of the > interpreter? That's what Ponie is/was, right? I think there is a major disconnect with providing a standard interpreter versus providing implementations of language "versions". It's less about making /usr/bin/perl (Perl 5) work on Parrot and more about providing a /usr/bin/perl6 on every machine and a chicken in every pot. In otherwords, people are more tied to the actual binary program called 'perl' than anything else. It's not about "Perl 5" vs "Perl 6", it's about either getting 'perl' as Perl 6ish as possible or introducing a new utility in /usr/bin (hence my earlier suggestion of a name change or reference imlementation/one_true_implementation^tm). How man awks or greps come on a standard system these days? More than one. I would not be against seeing various perls - eperl, zperl, 6perl, qperl, rperl, c++perl, jerl, etc. The way out is to quantify how well /usr/bin/perl "implements" the Perl 6 formalization - the level to which this is true would define how far Perl 5 is from "being" Perl 6 compliant. Of course, this would be a non-Parrot implementation. There is nothing saying Perl 6 "compliant" interpreters have to be written in Parrot; Parrot just provides an abstraction layer that allows there to be a cleaner separation between the compiler/interpreter and some of the complex things that need to be done to enable the features of Perl 6. Just throwing more out there as an "outsider", but someone who really wants very badly to have a reason and simple way to start using it for stuff. cheers, Brett > > it seems Gcc community had a similar discussion about mess of internal. > http://gcc.gnu.org/ml/gcc/2012-03/msg00263.html
Re: The trouble with awesome
> There are a lot of programmers who know several programming languages already, > and who don't want to read a whole page on how to print 'Hello World', 5 > pages on > if-statements and while-loops and another 10 pages explaining lists and > iteration. However experienced a programmer may be, there are certain minimum levels of knowledge one needs to get into a new language. What class of language is it? Machine code, assembler, compiler, interpreter, executed from source, like Java? (Obviously, we know that, but for the few sentences it takes to explain it, it might as well be stated anyway for newcomers.) A couple of paragraphs can explain where it might be expected to run, and what's required to start using it. That's the purpose of "Hello, world" programs; not to babble inane greetings, but to show simply to run something in the language. Even there, Perl 6 is unusually rich in options; interactive mode, command line, argument, and stand-alone executable. Each step requires slightly more input, so that's the order I would introduce them. When introducing a programming language, as opposed to teaching programming from scratch, it should not be necessary to explain what a variable is, or why decision statements are required. The reader's questions are more in the nature of "what's a valid variable name" or "how are blocks bounded"? Without the basics of of statement syntax, variable name rules, block structure, how decisions are delimited, and how to iterate, how does one interpret more complex concepts? Certainly, they can be explained by reference to some previous standard; "The rules for are exactly the same as in Perl 5, except when . These rules are .". That allows the Perl maven to skip forward enlightened, and the beginner to keep learning. Learning's a process of building on previous foundations, and so is programming. Somebody creating simple tabulations may never need the techniques of the compiler writer, but the compiler creator had to learn the rules for variable names. > But much more is needed. Please help us with it. Specifying the problem was meant to be the first step. I wanted to get the discussion going, (but not the bikeshedding about the language name). For the author of Perl 6 documentation, the problem is knowing the language well enough to see the logical stages to extend basic concepts and introduce new ones. Where are the rings of the onion? For example, double " and single ' quotes are pretty much essential from the start; when do the alternative forms begin to be necessary? I see at least 3 levels of complexity, demanding increasing levels of sophistication; basic computation on streams of structured I/O, manipulation of unstructured data, like text, and "higher order" work, like program-creating programs, compilers, &c. Does this seem like a reasonable taxonomy, or are other groupings a better fit?
Re: The trouble with awesome
On Sat, May 26, 2012 at 05:34:18AM +0530, Siddhant Saraf wrote: > Rakud[o] is not _the_ reference implementation of Perl 6. Actually, there is > no reference implementation for Perl 6. There never will be. Whoever wants > to make a perl6 implementation is free to do so. Just follow the spec and > you get to label your compiler as a Perl6 implementation. yay ! Just a very minor technical nit (to help preserve clarity): Perl 6 is anything that passes the test suite, which is not necessarily the same as the specification. See Synopsis 1. (Yes, this means the synopses can also contain bugs, and we can and do file bug reports on the synopses themselves.) Pm
