Re: Files, Directories, Resources, Operating Systems
Richard Hainsworth wrote in perl.perl6.language : The S16: chown, chmod thread seems to be too unix-focussed. I was more or less thinking that the syscall-related primitives, like chown or chmod, could go in a POSIX namespace. Even in UNIX land nowadays the situation can be much more complex than traditional ownership and modes (a situation not entirely satisfactorily addressed by Perl 5's filetest pragma). Following the general perl6 philosophy, perhaps too there should be an abstract definition for the language that is core and additional modules that are specific to operating systems. Thus when generic software is distributed, it comes with an installer that determines the operating system chooses whether to use IO::Unix, IO::Unix::Gnome, IO::MS::WindowsXP, IO::MS::Vista, IO::Apple, etc. Maybe also IO::Internet::Http, IO::Internet::Ftp? IO (streams) and rights are not naturally related. Maybe you're thinking about filesystems and other content addressing schemes (like URLs). The subject is more complex than it seems at first glance, because you can have, for example, per-volume current working directories. It's quite hard to design something that is abstract enough, but at the same time not totally useless.
Re: [perl #60732] Hash indexes shouldn't work on array refs
Moritz Lenz wrote in perl.perl6.compiler : jerry gay wrote: On Fri, Nov 21, 2008 at 10:43, via RT Moritz Lenz [EMAIL PROTECTED] wrote: # New Ticket Created by Moritz Lenz # Please include the string: [perl #60732] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60732 From #perl6 today: 19:33 moritz_ rakudo: my $x = [ 42 ]; say $x0 19:33 p6eval rakudo 32984: OUTPUT[42] I don't think that should be allowed. the real test is: (8:52:47 PM) [particle]1: rakudo: my $x = [42]; say $x0_but_true; (8:52:49 PM) p6eval: rakudo 32998: OUTPUT[42] (8:53:38 PM) [particle]1: rakudo: my $x = [42]; say $xtrue_but_0; (8:53:40 PM) p6eval: rakudo 32998: OUTPUT[42] (8:53:50 PM) [particle]1: rakudo: my $x = [42]; say $xXXX; (8:53:52 PM) p6eval: rakudo 32998: OUTPUT[42] (8:54:37 PM) [particle]1: rakudo: my $x = ['a', 42]; say $xXXX; (8:54:39 PM) p6eval: rakudo 32998: OUTPUT[a] (8:58:41 PM) [particle]1: rakudo: my $x = ['a', 42]; say $x1.4; (8:58:44 PM) p6eval: rakudo 32998: OUTPUT[42] (8:58:48 PM) [particle]1: rakudo: my $x = ['a', 42]; say $x0.4; (8:58:50 PM) p6eval: rakudo 32998: OUTPUT[a] so, the index is coerced to an integer. is that really wrong? ~jerry IMHO yes, because Perl explicitly distinguishes between arrays and hashes (and it's one of the things we never regretted, I think ;-). Any intermixing between the two would only lead to confusion, especially if somebody writes a class whose objects are both hashe and array. Yes, that leads to confusion. (And confusion leads to anger, and so on) Which is why we removed pseudo-hashes from Perl 5.10. -- The key words SHALT, SHALT NOT, SMITE, and PILLAR OF SALT in this document are to be interpreted as expected. -- RFC 4041
Re: Negative array subscripts
Smylers wrote in perl.perl6.language : Hmmm, a pragma's a bit heavyweight for this; how about being able to set this with a special global variable -- that sure sounds handy ... Actually, in perl 5, $[ *is* a pragma... :) -- Grepping the source is good for the soul. -- the perldebguts manpage
Re: my $key is sensitive;
Brent 'Dax' Royal-Gordon wrote in perl.perl6.language : I would like is sensitive to be defined to mean that any data stored in that variable, at any level of recursion, will be zeroed out as soon as it is garbage collected. Particular implementations can add extra features on top of that--such as stopping the VM from swapping it or even actively encrypting that area of memory--but without a minimum standard there's no point in supporting the feature at all. That really sounds like an unportable feature that should go in a module. On in many modules (Linux::VolatileVariables, etc etc)
Re: my $key is sensitive;
Brent 'Dax' Royal-Gordon wrote in perl.perl6.language : Basically, I'd like to be able to mark a variable as sensitive or secret. This implies that the language should overwrite the memory it uses before deallocating it, and that if possible it should tell the virtual memory system to avoid swapping it out. Moreover, it should probably do so recursively, and to any value that has ever been stored in the variable. (In essence, the *variable* marks all *values* it ever contains as sensitive.) This feature could make Perl 6 a better language for security work than any other I've seen. C and C++ could do this, but only with the programmer's assistance (by calling a wipe function or making sure a destructor is correctly called), and optimizers have been known to helpfully remove such code. Isn't the volatile modifier supposed to avoid this ? Oh, and remark that volatile is quite a high-level construct for a language like C. So, such a sensitive modifier could be added, but its precise meaning would be highly dependent on the underlying implementation. -- The universe (which others call the Library) is composed of an indefinite and perhaps infinite number of hexagonal galleries. -- Borges
no 6;
I just commited into bleadperl a patch that implements this : $ ./perl -e 'no 5' Perls since v5.0.0 too modern--this is v5.9.3, stopped at -e line 1. BEGIN failed--compilation aborted at -e line 1. That is, the exact opposite of the current use VERSION syntax. One of the uses I had in mind for it is to put no 6 at the top of modules or programs that are too tightly bound to Perl 5 that there wouldn't be beneficial to port them to Perl 6. B::* or Safe come to mind. Of course, that would mean that Perl 6 should also recognize and handle the no 6 idiom. That's why I'm cc:ing p6l. Comments ? The patch can be found at http://public.activestate.com/cgi-bin/perlbrowse?patch=25344
Re: should we change [^a-z] to -[a..z] instead of -[a-z]?
Aaron Sherman wrote in perl.perl6.language : A silly question: is there a canonical character set from which we extract these ranges? Are we hard-coding Unicode here, or is there some way for the user to specify the character set for ranges? Perl 5 forces [a-z] (or [i-j] for that matter) to be a range of lowercase alphabetic characters, even on EBCDIC platforms (where it's not).
Re: Synopsis 9 draft 1
On Fri, 3 Sep 2004 11:41:05 +0100, Tim Bunce [EMAIL PROTECTED] wrote: Is there some syntax to express if the struct is packed or needs alignment? (Perhaps that would be needed per element.) Why am I suddenly thinking about unions ?
Re: undo()?
Michele Dondi wrote: I must say I've still not read all apocalypses, and OTOH I suspect that this could be done more or less easily with a custom function (provided that variables will have a method to keep track of their history, or, more reasonably, will be *allowed* to have it), but I wonder if Perl6 may include a builtin undo() function to recover values prior, say, to the last assignement (or push() or, etc. etc.[*]) Difficulties: define history of a function w.r.t. threads; closures; and system side-effects (writing to files, locking them etc.) In other words, if you want a transaction/rollback mechanism, use a suitable transaction library that fits your needs, not a half-baked kludge built into the base language.
Re: simple grammar example
Luke Palmer wrote:
Also, if this is going to be an explanation rather than just a picture,
I suggest you go with Perl's usual versatile power, and store the
operators in a declarative data source.
grammar RPN {
my @operator = + - * / ;
rule input { line* }
rule line { exp? \n }
rule exp :w{ NUM | @operator }
rule NUM { \d+ }
This becomes too weak.
rule exp :w{ NUM | exp exp @binary_operator }
is stronger.
But it involves left-recursion, so it's typically better adapted to
yacc-like parser generators. Probably not to P6 rules...
Re: simple grammar example
Sean O'Rourke wrote: * To really show where P6 rocks, you need to show dynamic features. A simple example might be using a language with keywords kept in variables, allowing you change between e.g. for, while, if, pour, tandis-que, si, etc. Small correction : pour, tant_que, si :)
Re: simple grammar example
Luke Palmer wrote:
That left recursion won't do. I can't remember my transformation rules
well enough to know how to put that in a form suitable for a recursive
descent parser. To be honest, I've never seen an RPN calculator modeled
with a grammar.
Well, the main advantage of an RPM syntax is to avoid the need for a
grammar. The parsing stack and the execution stack are the same.
To be sure, a prefix calculator should be the easiest:
rule exp :w { @operator exp exp | NUM }
Indeed.
With infix operators you need precedences.
Re: Funky «vector» operator
Andy Wardley wrote in perl.perl6.language : I'm so happy! I just found out, totally by accident, that I can type the « and » characters by pressing AltGr + Z and AltGr + X, respectively. Of course this information is almost completely unusable without knowing your OS, your locale, and your keyboard flavour. But thanks anyway, and I'll share mine : with vim, and with the 'digraph' option set, just type Del to get « Del to get » This is probably common knowledge as well.
Re: Compile-time undefined sub detection
Larry Wall wrote in perl.perl6.language : In theory, yes, if you ask it to check in a CHECK block, and if you're willing for the check to assume that no eval or INIT block is going to supply the missing sub before it's actually called, and that no run-time code is going to alias the sub into one of your namespaces where it'll be visible to call, and that no AUTOLOAD in scope will be willing to emulate it. (But then, all that's true of Perl 5 right now as well...) While we're at it. Is there some precise definition of the CHECK/INIT blocks for perl 6 right now ? In perl 5 those blocks are executed at the transition between the compilation and the execution phase *of the main program*. This is convenient for some purposes (the O and B::* modules) and inconvient for others (Attribute::Handlers, etc. etc.). It's not feasible to modify this for Backwards Compatibility Reasons; how will Perl 6 handle this ? is there going to be a CHECK-by-compilation-unit kind of block ?
Re: Compile-time undefined sub detection
Larry Wall wrote in perl.perl6.language :
: In perl 5 those blocks are executed at the
: transition between the compilation and the execution phase *of the main
: program*. This is convenient for some purposes (the O and B::* modules)
: and inconvient for others (Attribute::Handlers, etc. etc.).
Hmm, well, I think it's a problem with Attribute::Handlers only because
that interface binds too late by default. Perl 6 traits will run at
BEGIN time by default. (Though you can define actions at trait time
that don't run till a later phase.) Can you elaborate on the etc. etc.?
Of course :) the main problem is not that CHECK blocks are executed
late (just at the end of the compilation phase); it's that they're
executed too early, notably in some persistent environment, notably
mod_perl (or mod_parrot in the future.) When you have a virtual machine,
you'll end up including modules at run time, because the main
compilation phase becomes less important. Thus CHECK blocks become
worthless, code-reusability-wise.
The link phase is still controlled by the main compilation pulling
in other modules, so CHECK still has the same semantics for the main
program, at least. And for consistency (especially with Perl 5),
a CHECK block from a separately compiled module probably should wait
till end of link time to run. Particularly since we have modules
that specifically create a CHECK knowing it runs at the end of the
main compilation.
But, as I was saying, modules have no control on what the end of the
compilation is; notably, they've no control on whether it's still
finished.
my @x will unitcheck {...}# at UNITCHECK time
your next mission is now to put something like this in Perl 5...
Re: Compile-time undefined sub detection
Larry Wall wrote in perl.perl6.language : Possibly a CHECK block that is compiled after end of main compilation should translate itself to a UNITCHECK. But maybe it should be an error. But it's also possible that CHECK should mean unit check, and there should be an explicit MAINCHECK for delegating checks to the main compilation. In that case, only in the main compilation would CHECK and MAINCHECK mean the same thing. (And since MAINCHECK is explicitly requesting a check at the end of main, a late MAINCHECK should probably be considered an error. (But by that argument, a late CHECK should probably fail under the current naming scheme.)) Anybody got opinions on the naming of these beasts? Certainly *not* renaming CHECK is more compatible with Perl 5. And I kinda got fond of UNITCHECK in the last hour or so. :-) I think I like CHECK and MAINCHECK. (and MAINCHECK being an error after the main compilation phase.) Lots of people who use CHECK (for some value of lots -- let's say, Damian and a few others) actually mean UNITCHECK. MAINCHECK is mainly useful for the O compiler backend, which is part of the perl core anyway, thus without any backward-compatility constraint. (I'd like to have opinions about PAR as well.) So I think changing the meaning of CHECK in Perl 5 is feasible. (and I know it would be welcomed by the mod_perl crowd.)
Re: Compile-time undefined sub detection
Damian Conway wrote in perl.perl6.language : I'd favour UNITCHECK and CHECK, mainly for the greater compatibility with Perl 5 and with software engineering jargon. As far as Perl 5 is concerned, it appears that most people who write CHECK mean UNITCHECK. Including you :) And because MAINCHECK is *ugly*. ;-) I can't disagree. So ugly that, if we go the other way and do change CHECK's behaviour, then the new postlinkage phase should be something else: like POSTLINK or PREINIT or INTEGRATE. But INTEGRATE is even more ugly.
Re: [perl] The Sort Problem
Joe Gottman wrote in perl.perl6.language : This is unrelated to the problem you mentioned, but there is another annoying problem with sort as it is currently defined. If you have an @array and you want to replace it with the sorted version, you have to type @array = sort @array; Besides being long-winded, this causes Perl to make an unnecessary copy of the array. It would be nice calling if sort (or reverse, or other similar functions) in void context resulted in in-place modification of the array that was input. I'd rather not change the behaviour of sort (or other built-ins that may or may not operate in place) depending on the calling context. What to do, for example, when Csort is the last statement of a sub? Besides this, a construction like @x = sort @x could be detected by a suitable optimizer and turned to (internally) an in-place sort. (It appears that Dave Mitchell is working on such an optimization for perl 5.)
Re: Vocabulary
Larry Wall wrote in perl.perl6.language : On Wed, Dec 17, 2003 at 12:11:59AM +, Piers Cawley wrote: : When you say CHECK time, do you mean there'll be a CHECK phase for : code that gets required at run time? Dunno about that. When I say CHECK time I'm primarily referring to the end of the main compilation. Perl 5 appears to ignore CHECK blocks declared at run time, so in the absence of other considerations I suspect Perl 6 might do the same. This has proven to be inconvenient except for a few specialized usages, such as the B::/O compiler framework. There's a need (more or less) for special blocks that can be run at the end of the compilation phase of any arbitrary compilation unit.
Re: %_ - is it available for use?
david nicol wrote:
[EMAIL PROTECTED] perl -le '$_{a}=27; package notmain; print $_{a}'
27
Gosh!
Let's document it! Would it go in perlvar or perlsyn?
It's already documented, in perlvar/Technical Note on the Syntax of Variable Names
(at the end)
Re: Perl6 Daydreams (on topic but frivolous)
Jonathan Scott Duff wrote in perl.perl6.language : My only dream is that by this time next year we have a fully- functional-people-can-use-it-in-production Perl6. It doesn't even have to be 100% complete; I think just 85% would be enough if it were the right 85%. 20% would be enough if it's what it takes to get 80% of the job done ;-)
Re: object initialisers
Nicholas Clark wrote:
class Foo {
...
std::size_t spare = 0
std::size_t allocate = 4096
std::size_t min_readline = 80
and have the compiler know that if I specify a member initialiser in my
my constructor, then that should be used, otherwise to default to using
the value I say. (To avoid the inevitable search/replace if I want to
change that value)
That's actually valid Java syntax (modulo a trailing C;). The default
value can be any expression (as long as it doesn't involve a reference
to the object being constructed, IIRC).
In fact Java provides a notion of instance initialiser, run before
any specific constructor you're invoking, that initialises such fields,
and may run other code.
The details aren't very clear to me, since I haven't written any Java
code since almost two years. I'm sure someone will correct me if I'm
wrong /-/.
Re: P6ML?
Andy Wardley wrote: If my understanding of the design of Perl 6 is correct, the lexer, parser and any other related components will be highly configurable and/or replaceable. The goal is to provide support for little languages by separating Perl the language from perl the interpreter. It will be possible to modify or replace Perl the grammar so that perl the program can parse other languages, including Python, Ruby and presumably, XML. I think that you're a bit mistaken : the goal is to have (a) parrot execute other languages (once compiled to parrot bytecode) and (b) perl's parser able to modify itself at runtime. The fact that Perl's grammar can evolve doesn't mean that the basic entities it operates on will also evolve, and, as a Python string can't be seamlessly mapped to a Perl string, one can't have perl behave as a Python interpreter only by modifying its parser. So instead of writing Perl programs to parse and manipulate XML, it should be possible to modify Perl itself so that it parses the XML directly into some internal form suitable for programmatical manipulation. And moreover XML by itself is not a programming language, so I don't see how it's possible to build a generic interpreter for it. How exactly this will manifest itself, I cannot tell. If you wave hands very fast, bushes might start burning ;-) Nor can I say if this is actually a sensible thing to do or not. But unless my understanding is warped, support for parsing XML and other markup languages could be moved down into the core of the parser internals for Perl 6. I think you're overriding too much the meaning of 'parser' here. Basically I think that perl6's internal parser, even after heavy reconfiguration, will remain an engine to parse context-free languages, with a few improvements. That's very different from a parser for markup languages. (Of course, with a mechanism comparable to perl 5's source filters, one can plug everything. So, as Leon was saying, you can begin to implement a Perl5::XML source filter module right now.)
Re: A proposal on if and else
Brent Dax wrote in perl.perl6.language : Yes, I know this means that we have 'else if' instead of 'elsif', but it's only two more characters and it makes the grammar cleaner. The tokeniser could send two tokens else and if whenever it recognizes the keyword elsif -- so this isn't a problem.
Re: A proposal on if and else
Joseph F. Ryan wrote in perl.perl6.language : If the final design stays the way it is now, there really won't be a lexer. Instead, a perl6 grammar parses the data, and builds up a huge match-object as it, well, matches. This match object is then munged into the optree. Oh, yes, I remember now. Thanks. This means the grammar probably won't be anything resembling simple, since it has to act as both a lexer and a parser at the same time. However, that's not to say your hack couldn't work; in fact, it would be easy to implement during the match-object-munging phase. Indeed. However, it still treats Cif as special syntax, which is the real issue at hand.. I question whether treating Cif as a function rather than as built-in syntax will make the parser any simpler if special block rules keep getting added to simply make it work. I'm in favor of keeping a few special blocks if it makes things easier to implement/design in the long run. Makes sense. Note that I'm not advocating elsif, quite an horrible keyword, that I still mispell as elseif sometimes. But I like hacking on grammars ;-)
Re: L2R/R2L syntax (was Re: Everything is an object.)
Dan Sugalski [EMAIL PROTECTED] wrote: And keyboards, don't forget keyboards. These pesky primitive ones we have now would require a lot of shift-control-alt-meta-cokebottle key sequences... And vt100 consoles ! There are still sysadmins that struggle with a buggy perl script, having rebooted in single user mode, on a production box at 23:15 pm. But this has been already said...
Re: Disappearing code
John Siracusa [EMAIL PROTECTED] wrote: Well, er, don't we need to decide what the subroutine attribute is, so that the compiler will know to honor it and make the code disappear? It doesn't seem like a feature that can be added from userland after the fact (but maybe I'm wrong...) In Perl 5 that could be done from userland, as you say, by using an optree manipulator (optimizer.pm for example). This could even be lexically scoped. [Once the compiler hints are fixed.] I expect Perl 6 to ship with (Parrot::* ?) modules that allow to examine and to modify the compiled form of the programs. Something that probably Java 6 will not have...
Re: Variable Types Vs Value Types
Damian Conway [EMAIL PROTECTED] wrote: There are in fact *two* types associated with any Perl variable: 1. Its storage type (i.e. the type(s) of value it can hold) This is specified before the variable or after an Cof or Creturns. It defaults to Scalar. 2. Its implementation type (i.e. the class that tells it how to act) This is specified after an Cis. It defaults to the type indicated by the variable's sigil. How does it work regarding inheritance and polymorphism ? E.g. consider my @a is Set of Apple; my @b is Basket of Fruit; with Apple isa Fruit, and Basket is a Set. I assume I can use @a or @b where the expected type is: @a @b Set ok ok Set of Fruitok ok Set of Appleok no(?) Basket no ok Basket of Fruit no ok Basket of Apple no no(?) the errors being compile-time or run-time, depends on how much verification the compiler can perform with its input. Reminds me the SetApple C++ templates. And the whole mess that comes with it (when you've got a statically typed language.)
Re: L2R/R2L syntax (was Re: Everything is an object.)
frederic fabbro [EMAIL PROTECTED] wrote: Can one see it as a shell redirection/pipe? This may sound funny, but is the following ok? @b ~ @a ~ @c; # @c = @b = @a; (@b ~ @a) ~ @c; # same order i guess so one can also: @keep ~ grep /good/ ~ @list ~ grep /bad!/ ~ @throw; is this if valid too? @b ~ @a ~ @c; # push @a, @b, @c; or: @b, @c ~ push @a; qw/hello world/ ~ print Just add ^~ and v~ and we've got our own Befunge flavor.
Re: L2R/R2L syntax (was Re: Everything is an object.)
Luke Palmer [EMAIL PROTECTED] wrote: Not necessarily. ~ will necessarily need to be right-associative, while ~ left, however. Not sure if you aren't getting this backwards, but anyway I often find myself confused with right and left. It would be logical to give them the same precedence, except for the opposite associativity thing, where parsers get different results based on their parse method. So different precedences would be good only to ensure that different parsers saw the same thing. Actually I don't think you can define a grammar where two operators have the same precedence but different associativity. Be it a pure BNF grammar, or a classical yacc specification (using the %left and %right declarations).
Re: L2R/R2L syntax (was Re: Everything is an object.)
Nicholas Clark wrote in perl.perl6.language : Actually I don't think you can define a grammar where two operators have the same precedence but different associativity. Be it a pure BNF grammar, or a classical yacc specification (using the %left and %right declarations). But that would mean only perl6 could pass perl6, which isn't much different from the perl5 situation, is it? I meant that if ~ and ~ are going to have the same precedence, you can't parse s ~ t ~ u It's not a well formed phrase of the language (even though this language can't described by a nonambiguous BNF grammar.) In fact, this is different from the Perl 5 situation you're alluding to.
Re: L2R/R2L syntax (was Re: Everything is an object.)
Dave Whipp wrote in perl.perl6.language : But with the different precedence. At last, I can assign from a list without using parentheses: @a = 1, 2, 3; # newbie error @a ~ 1, 2, 3; # would work or : @a ~ 1 ~ 2 ~ 3; or : 1, 2, 3 ~ @a; which would be also written as : 3 ~ 2 ~ 1 ~ @a; shoot me : 3 ~ 2 ~ @a ~ 1; (Aha, Damian's 1st proposal seems to imply that ~ has highest precedence than ~).
Re: Variable Types Vs Value Types
Dan Sugalski [EMAIL PROTECTED] wrote: Like I said, you can always use delegation to subclass an array, or limit yourself to an odd and restrictive subset of behaviour. (Basically just vtable method overriding) Delegation has drawbacks compared to inheritance : you can't use a object that delegates to class Foo where an instance of Foo is expected. Unless Foo and the class that delegates to Foo both inherit from a common (abstract) superclass (ArrayInterface ? Dictionary ?) (Duh, this is just starting to sound like Java.) How do you override vtable methods from within Perl 6 ?
Re: purge: opposite of grep
John Williams wrote in perl.perl6.language : While purge is cute, it certainly is not obvious what it does. Of course neither is grep unless you are an aging unix guru... How about something which is at least obvious to someone who knows what grep is, such as vgrep or grep:v? If you want good'ol Unix flavor, call it vrep. Compare the ed(1) / ex(1) / vi(1) commands (where 're' stands for regular expression, of course) : :g/re/p :v/re/p What would be an idiomatic Perl 6 implementation of such a vrep function ?
Re: UTF-8 and Unicode FAQ, demos
Austin Hastings wrote in perl.perl6.language : What we've got is an encoding problem at the MUA level. Mark Reed says my mailer (Yahoo!) tagged a message containing high-bit characters as US-ASCII. Several people the other day reported on the differences in UTF8 vs. Latin-1 handling among pine, elm, and other mailers. Not only the MUA level. Usually source code is written in a lowest common denominator of ascii, even for languages that allow unicode identifiers (Java) or markup. That's because source code is handled by parsers, documentation extractors, pretty printers, diff(1), patch(1), version control software, and (you said it) various internet clients. That's why some people may still prefer to continue using pure ascii even though then think that unicode operators are cool. (Esp. if they are under the influence of FUD : use PHP ! it's ascii compliant !) Perl6 will do more to address the real technical issues of electronic communication between Americans and French-speakers than anything else. (Primarily because Perl hackers want to talk to each other, but no French-speaker wants to talk to an American ;-) You're Italian, aren't you ?
Re: Character Properties
Dan Sugalski wrote : And, FWIW, emacs is written in C. Granted a much macro-mutated version of C, but C nonetheless. Just like Perl 5 ;-)
Re: What's MY.line?
Chip Salzenberg wrote in perl.perl6.language : In (re?)examining the Apocalypses, I've found something that confuses me a bit. A2 refers to CMY as a pseudopackage and says: __LINE__ becomes MY.line __FILE__MY.file [...] With regard to CMY: 2. What are line and file? Properties? Class variables? (Probably not class variables since CMY is not called a class.) That's the implementation problem ;-) In perl 5, __LINE__, __FILE__ and __PACKAGE__ are replaced at compile-time (in fact, at tokenizing-time) by the appropriate constants. The question is : to which kind of bytecode MY.file (etc.) get compiled ? -- Rafael Garcia-Suarez : http://use.perl.org/~rafael/
Re: $RS paragraph mode going away?
Larry Wall wrote :
Paragraph mode is not going away--it's merely going elsewhere. :-)
: If so, what's the rationale? Another case of you can't do it right
: internationally, so better not to do it at all?
No, it's simply that using a global variable to control something
that should be a filehandle attribute is the wrong way to go about it.
The readline function takes an input filehandle and a line separator and
returns a line. So it makes sense to store the line separator in the
filehandle. OK.
: I'm just looking at the huge number of stanza-based files and
: system-utility output sysadmins deal with every day using C$/ = '', and
: thinking yeah, I could just write a grammar, but it's just a simple regex
: match in paragraph mode...
No problem, you'll just say something like:
$fh = open $filename, :para;
for $fh - $para { ... }
Eventually the Perl 5 folks will get around to implementing such
user-oriented layers in Perl 5, but at the moment they're still working
on the encoding-oriented layers, which is fine.
This seems to be a weird way to specify the line separator.
What if you stack many of them ?
$fh = open $filename, :para:slurp;
$fh = open $filename, :slurp:para;
$fh = open $filename, :para:chunk(8192);
# (assumming that :chunk does the job of $/ = \8192)
or, worse, if you mix them with encoding layers ?
$fh = open $filename, :lineending(\n):crlf;
$fh = open $filename, :crlf:lineending(\n); # will I get \r chars ?
Encoding layers know nothing about end-of-line terminators. I'm under
the impression that encoding layers and user layers have different
semantics : respectively buffer filters and user-space modifiers.
(Another example of a user layer could be :taint to taint/untaint the
data read from the filehandle. That's something that modifies a
filehandle's attribute, but that doesn't affect the way the data is
read/written and encoded.)
Oh, and $\ should become a filehandle attribute too.
$fh = open $filename, :lineending(\n);
$fh = open $filename, :lineending(\n):gzip;
$fh = open $filename, :gzip:lineending(\n); # ???
Re: Backslashes
Larry Wall wrote :
Well, if anything, we're going the other direction, and enriching what
you can do with a backslash in single quotes slightly. But it ought
to be pretty easy to define your own hyperquotes. We might also have
options on quotes like we do on regexen. Then we could tell it what
to interpolate and what not to:
q:bsahfmc/\t $foo array %hash func() $obj.method() { closure }/
'Course, that's pretty klunky.
And that doesn't seem very flexible.
If you're going to specify your quoting rules for your own q//
operators, I think that this should be specified as hints to the very
perl parser.
A simple example : in Cmyq/foo[42]/, you could choose to interpolate
only the array foo, or the array element foo[42].
So maybe we have something like an
immediate subroutine definition:
my sub qa is quote(bsahfmc) {...}
qa/\t $foo array %hash func() $obj.method() { closure }/
Then you could say something like:
my sub q is quote() {...}
'You think I' _ q{'} _ 'm knit-picking!'
to get the behavior you want.
That sounds a bit like my Sub::Quotelike module.
Re: Regex and Matched Delimiters
Michael G Schwern wrote in perl.perl6.language : On Tue, Apr 23, 2002 at 11:11:28PM -0500, Me wrote: Third, I was thinking that having perl 6 regexen have /s on by default would be easy for perl 5 coders to understand; not too hard to get used to; and have no negative effects for existing coders beyond getting used to the change. I'm jumping in the middle of a conversation here, but consider the problem of .* matching newlines by default and greediness. /(foo.*)$/, /(foo.*)$/m and /(foo.*)$/s This is so old-fashioned. when matching against something like foo\nwiffle\nbarfoo\n One matches the last line. One matches the first line. And one matches all three lines. And by the way, there's the semantic unaccuracy of $ matching transparently newlines, combined with the obscure variants \z and \Z. This needs (IMHO) some reshaping. -- Rafael Garcia-Suarez I'll better skip() some releases until it is() ok() to use Test::More without() going insane(). Any more than I already am, that is(). -- Tels in the perl-qa mailing list
Re: // in Perl 5.8?
Brent Dax wrote in perl.perl6.language : I'm working on a preliminary version right now. So far it's been surprisingly easy--touches toke.c, perly.y, opcode.pl, pp.c, and pp_hot.c. (Of course, it's also off an old bleadperl, but I doubt those files change that actively.) Work on a more recent bleadperl and watch t/japh/abigail.t ;-) BTW, so far toke.c hasn't been as bad as I've heard it is. :^) Once you're used to it, it's surprisingly clear. -- Rafael Garcia-Suarez : http://rgarciasuarez.free.fr/
Re: $^a, $^b, and friends
Larry Wall wrote in perl.perl6.language :
Such a grammar switching routine could operate either over a lexical
scope or over the rest of the file. The only restriction is that
one module not clobber the grammar of a different module.
Basically, we're trying to make the opposite mistake of the one
we made with source filters. :-)
I see that. But should it be possible to import grammar rules,
to allow :
use Some::Module::That::Modifies::A::Grammar::Rule;
# continue to parse the perl program with the modified grammar
or even :
{
use Some::Module::That::Modifies::A::Grammar::Rule;
# continue to parse the block with the modified grammar
}
And what about switching to a different or modified tokenizer ?
Re: $^a, $^b, and friends
Dan Sugalski wrote in perl.perl6.language : Don't forget, we already change parsing rules at compile time. Perl's got three (maybe four) different sets of rules as it is: *) Normal perl *) Regexes *) Double-quoted strings *) Single-quoted strings Adding another, or changing those, isn't a big deal. Strictly speaking, the last three are handled by perl 5's tokenizer. An insteresting case of compile-time parsing rules modification is given by prototypes : the perl 5 statement foo 1, 2 is parsed differently if foo() has ($) or () as prototype.
Re: $^a, $^b, and friends
Larry Wall wrote : It's not clear that the lexer is a separate entity any more. Lexers were originally invented as a way of abstracting out part of the grammar so that it could be done in a separate pass, and to simplify the grammar for the poor overworked parser. Indeed. Another benefit of lexers is to allow contextual constructs, like the qq/.../ operator, where the separators can be an arbitrary character. (well, a non-contextual grammar can describe this, if you enumerate all possible separators in separate grammar productions, and you'll end up with a gigantic transition table.) But you can write a grammar for an identifier just about as easily as for an if-then-else. More easily, if we're basing it on regexes. If we're viewing all grammar through the lens of regexes, we're really starting out closer to Lexerland anyway, and generalizing toward parsing, a traditionally weaker area for Perl. And that's an odd weakness for a text processing language. This sounds really cool. The word 'regular' goes more and more unappropriate...
Re: Tree Transformations (was: Perl6 Macros)
Michel J Lambert wrote in perl.perl6.language : Has anyone done any thinking along the lines of how we are implementing the Perl 6 grammer? Simon Cozens did. I don't know the details exactly. Note also that the grammar and the parser are not the difficult part; the perl 5 lexer is very complex (and highly stateful, as opposed as pure-lex lexers). I don't know how much of the complexity of the lexer can be reinserted back into the grammar for perl 6. -- Rafael Garcia-Suarez If strain on the lexer were a design criterion, I blew it long ago. -- Larry Wall, recently
Re: Perl6::Tokeniser
Simon Cozens wrote in perl.perl6.language:
An enhanced version of this (with documentation, no less) is available
from CPAN. I'll be releasing updates to there. There are a few things
I need to fix, but this should be enough to start sensible parser work,
which I intend to in the near future.
Out of curiosity, what kind of parser do you intend to write ? A
Parse::RecDescent one ? Have you an idea about what will be the 'final'
parser for the Perl 6 compiler ? (LALR(1), like Perl 5 ?)
Side-note about whitespace. This is going to be tricky, because of the
DWIMery involved by the end-of-line on some constructs (do{}, IIRC).
IMHO, Perl6::Tokener-toke() should not return whitespace to the parser
(currently it returns (undef)x2, if I understand correctly), but should
trigger some internal state change on \n (or whatever a end-of-line may
be). So, it can insert a fake ';' token after do { ... }\n for the
parser.
--
Rafael Garcia-Suarez
Re: Apoc4: The loop keyword
Melvin Smith wrote in perl6-language:
Besides no one has commented on Steve Fink's (I think it was him) idea
to store the result of the most recently executed conditional in $?. I
kinda like that idea myself. It makes mnemonic sense.
I like the $? idea, and it could probably be optimized away.
And $? should probably be automatically temporarized to the current
block (a bit like $^H in Perl 5) :
if foo() {
if bar() {
# $? is bar() here
frob(); # let's call a function that may contain
# if statements
}
# but $? is foo() here
}
(is temporarized the correct word, now that local() goes away?)
--
Rafael Garcia-Suarez
Re: Apoc4: The loop keyword
On 2002.01.21 18:32 Michael G Schwern wrote:
On Sun, Jan 20, 2002 at 10:58:34PM -0800, Larry Wall wrote:
: while( my $line = FILE ) {
: ...
: }
That still works fine--it's just that $line lives on after the while.
This creeping lexical leakage bothers me. While it might make the
language simpler, the proliferation of left-over lexicals seems
sloppy.
Not really -- you're not going to use a lot of different loop-variables,
aren't you ? But :
while ( my $line = FILE ) { ... }
...
while ( my $line = LIFE ) { ... }
is now probably going to issue some warning (about a lexical masking an
earlier declaration, you know.)
Re: Indenting
Excuse me for dropping this into the discussion, but
this reminds me a proposal made (by me;-) in p5p last month :
define a new prototype () that allows to define quotelike
functions. Example :
sub rot13 () {
my $s = shift; $s =~ tr/A-Za-z/N-ZM-An-zm-A/; return $s;
}
print rot13/uryyb $jbeyq\n/;
# the previous statement being equivalent to print rot13(qq/uryyb
# $jbeyq\n/); if rot13 had a ($) prototype
See the threads:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2001-09/msg01718.html
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2001-09/msg01800.html
Aaron Sherman wrote in perl.perl6.language:
} On Tue, Oct 16, 2001 at 09:30:44AM -0700, David Wheeler wrote:
}
} That's part of the reason that I almost never use here docs, but the
} qq{} operator, instead. No need for a closing newline.
}
} I have not read the RFC, but I do agree that qq is the way to go for
} formatted content. Or, perhaps something like it that in turn
} resembles the s{}{} operator?
}
} qf{^\s+}{ Now is the time
} for all good men...};
}
} eq
}
} sub qf ($pat,$str) {
} $str =~ s/$pat//mg;
} return $str;
} }
} qf('^\s+', qq{ Now is the time
} for all good men...});
}
} eq
}
} qq{Now is the time\nfor all good men...};
}
} That fits with the current trend and gives us a very flexible
} way to deal with just about any sort of formatting.
}
} You would want to allow the usual m{} options after the second
} close, but I think the default behavior should be that of m{}mg
}
} I also think that the above should be abbreviated as:
}
} qf{}{ Now is the time
} for all good men...};
}
} since useful defaults are always good.
--
Rafael Garcia-Suarez
Re: General Feelings on Apoc 3
David M. Lloyd wrote: On Thu, 4 Oct 2001, Michael G Schwern wrote: Backtracking is at the heart of Logic Programming (or Declarative Programming, if you like). This is one of the 3 main programming paradigms (along with procedural and functional). The most popular Declarative language is Prolog. It is great for writing programs that are largely about resource allocation and constraints. There's some links to start you off here: http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?backtracking Sounds like a chess computer. It kind of struck me that this type of concept might be handy for writing parsers directly in Perl without an 'intermediate' parsing language. Or for making it easier to write such an intermediate language. Backtracking is typically not used in parser implementations because it's slow over other predictive techniques. It's needed in a few cases of highly ambiguous languages (e.g. LL-infinite parsers). Another idea : it should be possible to write makefile-like rules with backtracking.
