Re: Synchronized / Thread syntax in Perl 6
On Tue, May 30, 2006 at 03:41:06PM -0600, John Drago wrote:
I asked this via the Google Groups interface a few weeks ago, but I'm not
sure if it made it here.
I am asking again in case the question never made it onto the list.
Has the syntax for synchronized/threaded @things been worked out?
For example:
class Foo is synchronized {
...
}
I don't like the name synchronized -- it implies that multiple things are
happening at the same time, as in synchronized swiming, which is exactly the
opposite of what should be implied. Serialized would be a nice name,
except it implies serializing to a serial format, like disk. Locked is
the best name I can think of, and it frankly isn't that good -- it's so
vauge as to be able to mean almost anything.
(Also, of course, all those /z/ names should have a s/z/s/ version, for
those who speak a z-impared dialect of English.)
-=- James Mastros
Re: A rule by any other name...
On Tue, May 09, 2006 at 04:51:17PM -0700, Allison Randal wrote: I'm comfortable with the semantic distinction between 'rule' as thingy inside a grammar and 'regex' as thingy outside a grammar. But, I think we can find a better name than 'regex'. [...] Maybe 'match' is a better keyword. Can I suggest we keep match meaning thing you get when you run a thingy against a string, and make matcher be the thingy that gets run? 100% agree with you, Allison; thanks for putting words to doesn't feel right. -=- James Mastros
Re: using the newer collection types - Interval
On Sat, May 06, 2006 at 01:41:41PM -0700, Darren Duncan wrote: Some people may confuse it with a Range, but I don't think so since a Range progresses in discrete increments, while an Interval would be continuous. A range listifies to a (potentially) finite list of discrete elements, but it compares as a range. 1.1 should ~~ 1..2; pugs thinking that's false is a bug, not a feature. Of course, that doesn't mean implementing range in a subset of perl6 without it isn't interesting, and possibly useful for bootstrapping. -=- James Mastros
Re: backtick units (Was: File.seek() interface)
Wolverian wrote:
On Thu, Jul 07, 2005 at 05:58:53PM -0700, Larry Wall wrote:
$fh.pos = $fh.pos + 10`lines
I'm sorry if this has been discussed, but is the ` going to be in
Perl 6? I like it. :)
I was hoping it was going to be in the standard library, but non-core.
Using it for manipulating .pos, OTOH, would seem to make it core, which
I suppose is probably worth it.
How does it work, though?
sub *infix:` (Num $amount, Unit $class) { $class.new($amount) }
Or so?
Now I'm tempted to make it a generic infix .new.
(args)`Class;
The problem with it is that somehow we have to get 5`m / 30`s to work,
even though m is an operator, which AFAIK means it needs to be a macro,
or the moral equivalent (is parsed).
Also, having every unit be a like-named class would very much crowd the
root of the namespace.
-=- James Mastros
theorbtwo
Re: Idea for making @, %, $ optional
Millsa Erlas wrote: I have thought of an interesting idea that may allow Perl 6 to make the $, @, and % optional on many uses of variables. This involves simply extending the function namespace to include all kinds of structures, and thus the function namespace does not require symbols, they are optional. Also, a goal I have tried to follow here is to implement this feature without affecting the existing usage grammar and rules of the Perl 6 language at all. This is a good goal i believe, my intention is just for this to be an additional extension to Perl 6, not change its existing grammar and parsing rules at all, just expand upon it. Perl 6 is a great language and I like what has done so far. This is not an attempt to change what has already been defined, but rather provide an additional usage. In that case, you should be looking into how to make it a pragmata, rather then pushing the idea on perl6-language. It shouldn't be too hard -- a matter of using the equivalent of perl5's UNIVERSAL::AUTOLOAD, and the OUTER:: scope. -=- James Mastros, theorbtwo
Re: single element lists
Larry Wall wrote: : If yes, then (1)[0] means the same as 1.[0] and 1.[0][0][0]. If no, : (1)[0] is a runtime error just like 1.[0] -- i.e. unable to find the : matching .[] multisub under Int or its superclasses. Maybe we should just let someone poke a Subscriptable role into some class or other to determine the behavior if they care. Why is this a role, rather then just implementing postcircumfix:«[ ]»(Whatever $self: Int $index) ? (I'd hope the error message is a bit more newbie-friendly, but that's the only special-casing I see it needing...) -=- James Mastros
Re: identity tests and comparing two references
Larry Wall wrote: On Fri, Apr 01, 2005 at 08:39:52AM -0700, Luke Palmer wrote: : I'm pretty sure that =:= does what you want. If you have two scalar : references, you might have to spell it like this: : : $$x =:= $$y Unnecessary, I think. I want $x =:= @y to tell me whether the reference in $x is to the same array as @y. $x = 42; $a = \$x but false; $b = \$y but blue; $a =:= $b ??? If it's true, then the =:= operator is pretty useless -- two things that are =:= to each-other can have very different semantics. If it's not, then there needs to be some other way to tell. $$a =:= $$b feels sane to me. So does $a == $b. I generally don't like it when things half-smudge important differences. Either there should be no difference between a reference and a referent, or there should be. We shouldn't try to hide important truths. (This is why I don't like CGI.pm's HTML generation, for example -- it makes you feel like you don't need to know HTML, when you do.) -=- James Mastros
Re: Units on numbers [was Re: S28ish]
Craig DeForest wrote: Yet another point: there are plenty of non-obvious reductions that people worry about, such as N m - J (energy) but m N - m N (torque); but it's probably not worth worrying about such things: if the coder knows that s/he wants a torque, s/he should be able to ask for reduction to a particular form [e.g. 'units( $val, $template )' should exist and return $val in whatever units $template has, if possible.] Oh, and don't underestimate the usefulness of doing things in non-base-ten mixed units, and useful fractions: my height is 5`ft+(6+1/4)`in, not 66.25`in, thank you. In any case, I'd love something like this, and I suspect many other people would as well... but remember, again, extensibility is key. C $d=22`AWG; $a=pi*($d/2)**2; print $a`mm**2. qm; # buying wire in Germany doesn't work very well if there is no way to specify insane units like AWG. 25`USD*1.06+5`EUR can't be computed at all without extensibility, because the conversion rate from USD to EUR doesn't stay static over time. For that matter, monetary conversions are going to take some effort to get right, though they will be very useful if they are gotten right, because going through a common intermediary isn't correct. You won't get the same results converting USD to EUR to JPY as you will from converting USD to JPY. (OTOH, if you want to convert from DEM to FRF, you /must/ convert to EUR in the middle, or you will get the wrong result. Of course, neither the DEM nor the FRF have existed in several years, so it probably isn't that important...) -=- James Mastros, Who certainly looks forward to this.
Re: eval (was Re: New S29 draft up)
Larry Wall wrote: On Fri, Mar 18, 2005 at 10:28:18AM -0500, Aaron Sherman wrote: : Thus: : : eval read :file(foo); : : There you have it. The problem being that it will now report errors in some random temporary string rather than at some line number in a file. Not good. Orthogonality strikes again. ...unless read returns a Str but source(foo). -=- James Mastros
Re: Auto My?
Luke Palmer wrote: James Mastros writes: Does this imply that it's now possible to type Cmy @foo[23] = 42;, and declare @foo? In the current perl, this doesn't work -- it's a syntax error. It'd certainly make many constructs easier. That looks weird to me. But as Rod points out, it can be useful with hashes. Yes, that's the primary case I was thinking of. I was trying to find a smaller example. OTOH, I realize now you can do that with zip in P6, in which case you do have a mention of the whole variable to stick a my on -- Cmy %foo = zip(@keys, @values); I think Cmy [EMAIL PROTECTED] = @values; reads better though, even though looking at it literally, you're attempting to lexicalize an element. -=- James Mastros, theorbtwo
Re: Auto My?
Juerd wrote: Just typing my before the first use of a variable isn't hard, and it makes things much clearer for both the programmer and the machine. Does this imply that it's now possible to type Cmy @foo[23] = 42;, and declare @foo? In the current perl, this doesn't work -- it's a syntax error. It'd certainly make many constructs easier. -=- James Mastros
Re: Angle quotes and pointy brackets
Larry Wall wrote: I'm ready to propose a Great Angle Bracket Renaming. Hajleuja! Praise the Larry!* It looks wonderful, and just fixed half about half the things I was worried about having to do when programming perl6. (Not that hard -- I can't think of any more at the moment, but I'm sure they're there somewhere.) -=- James Mastros *I think I just broke two or three commandments.
Re: Angle quotes and pointy brackets
Austin Hastings wrote:
Larry Wall wrote:
* We get the cute, clean and rather more typeable
$varkey1key2[3]key3
No more or less typeable for me, or anyone else who can remap their
keyboard. I'm presuming there's something costly about {} on non-US
keyboards, but how much does it cost? and do those non-US perl hacks use
remapping already?
German keyboard, for example:
{ -- right alt, and the 7 key
[ -- right alt, and the 8 key
] -- right alt, and the 9 key
} -- right alt, and the 0 key
German keyboard under xfree86 but not windows:
« -- right alt, z (Well, the key that's z on an American keyboard).
» -- right alt, x
Those are /really/ hard to type, esp }, which comes up a /lot/ in perl,
weather 5 or 6, which is a big reason that I use the American keymap,
which is a constant annoyance to my girlfriend, who uses the British
keymap. (We're an American and a Brit, living in Germany.)
The problem with {} for a hash dereference operator is not it's
typeablility, but rather it's autoquoting behavior from perl5. In
perl5, the contents of {foo} are a string -- except when they aren't.
Quick:
$wheel-{roll} = 3;
$wheel-{shift} = 4;
In perl5, the first is a literal, the second shifts from @_. Whoops.
In perl6, the contents of {} is an expression. The first is an error
unless a function named roll is available (or a method on the topic?).
The second is good old shift (on the topic now).
OTOH, $wheel.roll and $wheel.shift are both literals. (The dot
there is optional.) (Until a little bit ago, that was $wheel.roll
or $wheel.«roll». (Note that I had to switch keyboard layouts again to
type that.))
-=- James Mastros
Re: Angle quotes and pointy brackets
Larry Wall wrote:
On Fri, Nov 26, 2004 at 07:32:58AM +0300, Alexey Trofimenko wrote:
: ah, I forget, how could I do qx'echo $VAR' in Perl6? something like
: qx:noparse 'echo $VAR' ?
I think we need two more adverbs that add the special features of qx and qw,
so that you could write that:
q:x/echo $VAR/
where ordinary qx/$cmd/ is short for
qq:x/$cmd/
I think I'd like that much better if we consider execution and
word-splitting to be the primary operations, and interpolation and
noninterpolation the adverbial modifiers then the other way around,
making that qx:q/echo $VAR/ or qx:qq/$cmd/. OTOH, I expect backticks to
be rare enough that I wouldn't mind writing
use Spawn 'spawn';
spawn :capture :wait ($cmd);
spawn :capture :wait ('echo $VAR');
Much more clear, saves ` for other things, and allows for easy
specification of the many adverbs of spawn (weather it returns the
return status, the PID/FH set object, or output, if it waits right
there, or runs in the background (and makes the return value lazy), if
it replaces the current process (exec)...
Likewise a qw/a b/ is short for
q:w/a b/
qw:q/a b/
$fromvar = 'foo bar';
qw:qq/a something with spaces b $fromvar/
# ?? -- slightly OT, but is that a, 'something', with, 'spaces',
# b, 'foo bar', or... um, what? Is qw smart enough to allow
# internal quotes? Does splitting take place before or after
# interpolation if it's interpolating?
: I notice that in Perl6 thoose funny « and » could be much more common
: than other paired brackets. And some people likes how they look, but
: nobody likes fact that there's no (and won't!) be a consistent way to type
: them in different applications, wether it's hard or easy.
:
: But to swap «» with [] or {} could be real shock for major part of
: people..
: We also have another ascii pair, and . maybe they could be better than
: « and » ?:) i'm not that farseeing, but isn't problem of distinguishing
: as a bracket and as an comparison operator no harder than distinguishing
: as bracket and as part of heredoc?..
It would get very confusing visually, even if the computer could sort it out:
We could force whitespace disambugation, possibly -- require that ...
bracketing have whitespace on the outside and none on the inside. But
that's ugly.
But there are some things that would be completely ambiguous:
%hashfoobar
Bracketing operator.
%hashfoobaz()
Very long bracket operator, which quite likely has a syntax error
directly after it.
: or maybe even we could see consistant to go after + + and alike, and
: make old and written as + and + (and then lt and gt suddenly could
: become ~ and ~ :)
I think people would rise up and slay us if we did that. We're already
getting sufficiently risen up and slain over Perl 6.
Could be worse. They could rise from the grave and eat us!
Well, yes, but sometimes the weights change over time, so it doesn't
hurt (much) to reevaluate occasionally. But in this case, I think I
still prefer to attach the exotic characters to the exotic behaviors,
and leave the angles with their customary uses.
...of which they have plenty already. Backtick has exactly one, and not
an often-used one at that... I'm fine with axing it. Of course, there
are a lot more people in the world then just me.
If you're a White Russian I suppose the yolk is on me.
In Russia, the yokes throw you!
-=- James Mastros,
theorbtwo
Re: Lexing requires execution (was Re: Will _anything_ be able to truly parse and understand perl?)
Randal L. Schwartz wrote: All the handwaving in the world won't fix this. As long as we have dual-natured characters like /, and user-defined prototypes, Perl cannot be lexed without also parsing, and therefore without also running BEGIN blocks. And user-defined prototypes that change when the argument list of a function ends, that is. If we forced the argument list for all functions to have parens (including empty parens for argument less functions), then we'd be OK, I'm fairly certain. For that matter, if we stick to declaration syntax for declarations, and not BEGIN blocks and reflection, then we're OK -- you have to do some execution, but of a minilanguage that can't express concepts that you wouldn't be OK running... though you do still have to descend through require/use, and thus have to have the files being required or used (or at least a description of their declarations). -=- James Mastros, theorbtwo
Re: anonimity
Larry Wall wrote: On Sat, Nov 06, 2004 at 10:37:39PM +0100, Juerd wrote: : Larry Wall skribis 2004-11-06 13:32 (-0800): : Easy, just one of : my $named := anonymous(); : my @named := anonymous(); : my %named := anonymous(); : my named := anonymous(); : my ::named := anonymous(); : : That's a lexical name. Are they used in error messages? (Can they be?) Generally not, unless we make aliasing smart enough to latch onto the first name and add it as a property to the anonymous object if it doesn't already have one. It would seem, then, that the answer is there's some property of thingies that gives the name that error messages will use to refer to them. (I want to thank the man who made thingy the proper technical term, BTW.) So what's it called? -=- James Mastros
Re: What Requires Core Support (app packaging)
Nicholas Clark wrote: On Tue, Sep 07, 2004 at 06:07:24PM +0200, James Mastros wrote: 4. The single-file, platform dependent, machine language executable (realexe). Which parrot can already do. (Or at least could, but I don't think that anyone's been checking on it recently) Er, right -- I'd meant to say that there, but I must have lost it when I decided my verbiage was horrible and rewrote it. (There's a reason I don't post often.) Mostly, though, they require fairly minimal support from the core. Only 1 requires Cperl support, and that support is very minimal. The and as you say all this really isn't about perl 6 the language. Exactly -- most of this sort of thing is about perl's standard library, which I think is a discussion for much, much later, and a discussion (one that, for the most part, is finished) for perl6-language (the part of the list that should be renamed to parrot). -=- James Mastros
Re: What Requires Core Support (app packaging)
John Siracusa wrote: 1. The special dir of files (SDoF). Ignoring, for now, the argument for a standard way to do this, all the core needs to do to bootstrap an entire ecosystem of app packagers is support some standard starting point. Maybe it's a file names main.pl inside a *.pmx dir, or whatever. But there needs to be something, otherwise every SDoF system will have to bootstrap itself using some executable other than perl (e.g. PAR/parl) I think that's much less elegant. We can, and I think should, write a one-paragraph documentation, one-screenful implementation of this that's in perl core: As a special case, if the filename argument to perl is a directory, and the directory contains a file named main.pl, then the directory is prepended to @*INC, and main.pl is run. 2. The single-file, packaged version of the SDoF (SDoF Package). Too boostrap this, the core needs to know what to make of such a file. Maybe nothing needs to be done if a #! line and some plain old perl code at the start of the file is sufficient. But something tells me that a bit more is needed to unzip/untar/whatever the rest of the stuff in the package file before execution. Trying to inline pure perl unzip/untar at the header of each SDoF Package file doesn't seem elegant to me, but it could be technically possible to bootstrap that way using only the perl 6 executable. We can support this in several ways. We can say that core perl also supports the above if the file is a gzipped tar file, and contains a main.pl (including adding the archive to @*INC). We can ship a script with perl, and have the user use the #! mechinisim to run it, with the actual file being specified to be a #! line, ending with some combination of CR and LF, then a tarball. This is probably a lot more work for perl core, but would be quite nice. 3. The single-file, platform independent, non-source executable (P6exe). This is bytecode or some other platform neutral representation of the SDoF. I just don't see how to do this at all without core support. Parrot supports this well enough that it will be hard for perl6 to mess it up. Parrot, indeed, already supports... 4. The single-file, platform dependent, machine language executable (realexe). This is a plain old executable, that does not particularly indicate it was generated by a scripting language. It requires no odd handing vs a normal executable for the target platform, because it /is/ a normal executable for the target platform. It may be staticly or dynamicly linked to the necessary libraries. Based on the little I know of JAR, the three features listed above seem to extend a bit beyond JAR in both directions, and each either require or should have some amount of core support, even if only to bootstrap community implementations. Mostly, though, they require fairly minimal support from the core. Only 1 requires Cperl support, and that support is very minimal. The others require standard-library support, but all the major bits are things that should already be in the standard library (because a front-end to C6PAN should come with, and that means extracting some sort of .tar.gz files -- calling out to external utilities doesn't cut it too often). -=- James Mastros PS -- Unreatedly, why, oh why, do people insist on an apostrophe in 80's and postfix:'th? It's 80s and postfix:th!
Re: String interpolation
David Green wrote: I was also going to say something tongue-in-cheek about Unicode quotation marks, but curly-quotes could actually be quite useful. Reasons not to use them as anything but synonyms for normal double quotes: 1) They look too much like each-other. 2) They look too much like normal quotes. 3) Some editors will give you one when you want the other. - David ³wondering how likely curly-quotes are to come out right² Green 4) Many people think they're in Latin-1, but they aren't, they're only in Microsoft's perversion of Latin-1. -=- James Mastros
xx and re-running
Recently on perlmonks, at http://perlmonks.org/index.pl?node_id=375255,
someone (DWS, actually) brought up the common error of expecting x (in
particular, listy x, which is xx in perl6) to not create aliases. What
he was doing in particular, I don't have any expectation of making it
work, but what about the also-common problem of C @randoms = (int rand
100) xx 100 ? In perl5, this picks one random integer between 0 and
99, and copies it 100 times -- not what was intended. The best way to
do this is C my @randoms = map {int rand 100} 0..100; , which is
rather yucky -- conceptually, you aren't trying to transform one list
into another. OTOH, C my @randoms; push @randoms, int rand 100 for
0..100 is even yuckier.
Perhaps if the LHS of a xx operator is a closure, it should run the
closure each time around... or perhaps there should be an xxx operator.
(Both suggestions from BrowserUk's reply,
http://perlmonks.org/index.pl?node_id=375344). The former raises the
question of what you do if you really want to repeat a coderef, and the
later raises the possibly of being blocked (really), and starts to
become confusing -- the difference between x and xx is sensical -- the
former repeats one thing, the later many... but what's the reasoning for
xxx, other then that it's like xx? How will users be able to remember
which is which?
-=- James Mastros,
theorbtwo
Re: scalar subscripting
Larry Wall wrote:
I suppose another approach is simply to declare that dot is always a
metacharacter in double quotes, and you have to use \. for a literal
dot, just as in regexen. That approach would let us interpolate
things like .foo without a variable on the left. That could cause
a great deal of cultural confusion in the short term, however.
[...]
Ouch. I'm thinking we allow $foo.bar in both strings and regexen, but
not .bar in either case. Gotta use $_.bar inside strings and regexen.
(Or $(.bar) would work too.) Possibly we even complain about /.bar/
and force them to write /. bar/.
Please, think of Csay This is a sentence. This is another
sentence.;. Dots with whitespace or end-of-string after them should
just be literal dots in qq strings. Dots should always be literals in
q() strings, of course. And dots are /already/ metacharacters in
regex^Wrules; forcing a space after the dot isn't giving the power of
formatting to the user; it's forcing formatting upon them that they
don't want. (I don't remember if there's an adverb to treat spaces as
literals, but if not, there should be.)
I think method calls in strings should be Foo's bar is $($foo.bar).,
plain and simple. Dot is too useful here already. @{[...]} needed to
be replaced with something easier to type, and with clearer (and
cleaner) semantics. We did that; $(...) is far better. Not requiring a
set off for method calls is Huffman coding the wrong direction, unless
you can find one that won't disturb useful things that you'd want in
double-quotes -- which includes patterns common in any natural language,
which includes even the literal versions of / (which I can't type
easily at the moment).
-=- James Mastros
Re: Yadda yadda yadda some more
Austin Hastings wrote:
So, how wrong is this:
class VerticalYadda
{
extends Yadda;
multi method coerce:as($what) {
say Coercing VerticalYadda to ~ ($what as Str);
next METHOD;
}
}
sub *\U{VERTICAL ELLIPSIS}()
{
return new VerticalYadda;
}
=Austin
macro \N{VERTICAL ELLIPSIS} :parsed«term» {
return '...';
}
Re: Yadda yadda yadda some more
Luke Palmer wrote:
Aaron Sherman writes:
Ok, so in the case of:
my int $i = ...;
we should apply Cconvert:as(..., ::int) and fail at run-time,
correct? There's nothing wrong with TRYING to do the conversion, just as
there should not be anything wrong with:
my int $i = 4;
which has some pretty simple semantics in Perl.
Right. Though, constant folding at CHECK time might be able to tell when
you're *going* to do an invalid conversion and complain about it right
then.
In the case of ..., give it type error semantics. That is, any
expression involving ... gets type Except instead of reporting
at the end of the statement, just suppress the errors and move on.
Huh? Um, no, your ideas as to what happens don't give the desired
semantics for ..., and don't make other desired semantics fall out
naturally.
The basic semantic for ... is that use of it gives an error at runtime,
when the code has been hit. Unless a pragmata changes things, it
should not be possible to trigger an error from use of ... without the
code being actually run.
Thus, I propose the following: A convert routine should be able to tell
if it's being run at runtime or compile time, and do a fail with reason
matching :i/not yet/ or :i/too early/, to defer the conversion until
runtime.
This gives the desired semantics for ... -- an error at runtime, not
compile time. It also allows for desired semantics elsewhere. Say I
have two classes, Net::IP::Addr and Net::HostName. It should be
possible to convert a Net::HostName to a Net::IP::Addr, but that
conversion should not happen until runtime (because I may be keeping
around the bytecode for a long time, and the hostname-IP mapping may be
different by then).
(Note: Aaron Sherman's syntax above doesn't match A12#Overloading. Was
the syntax changed, or is he wrong?)
multi sub *coerce:as (Net::HostName $name, Net::IP::Addr ::to) {
fail 'Too early to convert hostname to IP address' if
(we_are_in_compile_time);
$name.lookup;
}
(Yes, I know those parens around the condition of the if are optional --
even in perl5. I like them.)
What I don't know is how to write Cwe_are_in_compile_time. A property
of the object that Ccaller gives?
I don't really like using fail with regex matching here, but we need to
be able to return a real undef (we don't mind converting early, but the
correct conversion is to undef -- C0 as bool), should be able to
really fail (it's not a valid conversion, and waiting won't help
anything -- Csqrt(-1) as Real).
BTW, since that example above isn't the hottest, imagine defining a
conversion from a hostname to a DNS lookup, that saves the expiry time,
and defining a second coercion from that to an IP address, that reruns
the lookup if the TTL has expired. The first coercion should take place
at compile time, the second not until runtime.
-=- James Mastros
Re: Dereferencing Syntax (Was: Outer product considered useful)
Larry Wall wrote: Yes, * was originally a no-op in list context, but I think now we can use it to deref a list that would otherwise not interpolate itself. It maps better onto how a C programmer thinks, and if in scalar context it also happens to defer the signature checking to use the interpolated values, that's just an extra bonus. No! Please, God, no! I like perl, in no small part, because references are less confusing then pointers. Pointers, in no small part, are confusing because * means both this is a pointer (as in int*), and give me the thingy at (as in chr=*str). It seems like this is creating the same confusion. $foo = 0...;# take ref to an infinite range @bar = $foo;# puts in the iterator as a reference say @bar.elems; # prints 1 @bar = *$foo; # puts in 0... say @bar.elems; # prints Inf @bar = **$foo; # throws exception: Please install a lot more memory I hope that Perl will be intelegent enough to notice that the range is infinite, and say attempt to flatten infinite list rather then ENOMEM here. Also, how does the use of *$foo differ from @$foo here? Is the later going away? (I'd think that horrible, for the same reason as above: C is confusing because it's not always clear what you get when you *.) By the way, I like say, but wonder if we're going to become a horrible mix of APL and PHP. At least we don't have a Unicode alias for say (yet, why do I suspect we're about to get a unary » operator for it? Perhaps I'm just pessimistic this morning.) -=- James Mastros
Re: z ip
Mark J. Reed wrote: One obvious reason for reaching out to unicode characters is the restricted number of non-alphanumeric characters in ASCII. But why do infix operators have to be non-alphanumeric? They don't - but they do have to look like operators. Thanks to the multiplication symbol, lowercase 'x' looks like an operator to many people. Most alphanumerics don't. The rule is that, since the infix operator space and the sub-without-parens space intermix, and the subs namespace is very user-extensible, we shouldn't create places where they're likely to intersect and surprise the user. This is primarily in non-aphenumerics. Also, users expect operators to look more or less like the ones they know, which are funny symbols. x and xx is a bit of a corner case -- I think it's a bit far, perhaps, but OTOH, x does look like the operator people use for this, and if we already have x (and we do), xx is reasonable. I think the ¥(yen) suggestion is great, especially since it does indeed look like a zipper. Still, I would very much like an ASCII infix alternative for zip(). I propose z as the ASCII alternative for the infix zip operator (either broken bar or yen). With some imagination, it is a good candidate for representing interleaving. Besides that, zip() starts with a z so it is easy to remember even if you don't think it looks like something that zips. I think if we go with ¥ for the Unicode operator, the logical choice for an ASCII equivalent would be Y. You could read it as Spanish and, if you like. :) I like ¥ for the zip operator. It looks like a zipper, it's a funny symbol, it's latin-1, and it's typeable on my keyboard (altgr-shift-z, German xfree86 keyboard). Japanese users used to having problems with ¥ vs \ may be confused by that, but I think it's livable. I don't think it needs an ASCII equivlient, though -- it isn't /that/ useful, and it already has an ASCII equivalent: the zip() function. Let Y be used by user subs, or as a user operator; it's too likely to confuse.
Re: Latin-1-characters
Karl Brodowsky wrote: Mark J. Reed wrote: The UTF-8 encoding is not so attractive in locales that make heavy use of characters which require several bytes to encode therein, or relatively little use of characters in the ASCII range; utf-8 is fine for languages like German, Polish, Norwegian, Spanish, French,... which have = 90% of the text with ASCII-7-bit-characters. Add perl to that list, by the way. I rather strongly suspect that most perl code will consist mostly of 7-bit characters. (Even perl code written by traditional-Chinese-speakers (and I pick on traditional Chinese only because it has a very large character repituar -- one of the reasons there's a simplified variant).) but that's why there are other encoding schemes like SCSU which get you Unicode compatibility while not taking up much more space than the locale's native charset. These make sense for languages like Japanese, Korean, Chinese etc, where you need more than one byte per character anyway. But Russian, Greek, Hebrew, Arabic, Armenian and Georgian would work fine with one byte per character. But the kinds of of encoding that I can think of both make this two bytes per character. So for these I see file sizes doubled. Or do I miss something? Yes. You're missing the fact that SCSU is a very good encoding of Unicode. http://www.unicode.org/reports/tr6/#Examples In general, SCSU is one byte per character, except when switching between half-blocks (that is, 0x7f contiguous characters), which take one additional byte -- except switching between a single half-block and ASCII. Thus, most of your second list of languages take one byte per character for most code, and two bytes for encoding « and ». Hebrew, Greek and Arabic take one additional byte (for the whole file) to encode what half-block that the non-ASCII characters fall into. (Arabic and Cyrillic are in default blocks.) The first list of languages is hard to predict -- it changes depending on how often you change between the different Japanese alphabets (and pseudoalphabet), for example. Their example Japanese input compresses to about 1.5 bytes per character. (Note that SCSU is really an encoding, if it claims to be or not.) Anyway, it will be necessary to specify the encoding of unicode in some way, which could possibly allow even to specify even some non-unicode-charsets. By the way, there is (should be) nothing that is encodable in a non-Unicode character set that is not encodable in (any encoding of) Unicode. That's where the uni bit comes from. If there is, it's means that Unicode is not fulfilling it's design goals. IMHO the OS should provide a standard way to specify such a charset as a file attribute, but usually it does not and it won't in the future, unless the file comes through the network and has a Mime-Header. I think the answer is multi-fold. 0) Auto-detect the encoding in the compiler, if a U+FFEF signature, or a #! signature, is found at the beginning of the input. (If there is a FFEF signature, it should get thrown away after it is recognized. It may be possible to recoginze on package or module as well, and possibly even on #.) 1) Beleive what the underling FS/OS/transport tells us. (This is likely to be a constant for many OSes, possibly selectable at the compiler's compile-time. It's the encoding on the end of the content-type for HTTP and other MIME-based transports.) 2) Support a use encoding 'foo' similar to that in recent perl5s: It states the encoding that the file it appears in is written in. (the higher-numbered sources of encoding information override the former ones.)
Re: Compile-time undefined sub detection
Larry Wall wrote: And how would it differ from END? You can't predict when the last time a module is going to get used... Unless we support an explicit unload action on modules. This seems highly useful for long-running processes. (I don't think making them DODable is useful, since there's no way to tell if a future eval STRING (or equiv) might be useful.) -=- James Mastros
Re: Partially Memoized Functions
On 12/10/2002 5:46 PM, Smylers wrote: OK. There was something on MJD's QOTW recently where using the current Perl 5 Memoize module slowed code down -- that gave me the impression that caching had the potential. It does. In fact, all caching has that potential. Specificly, if the time to look up somthing in the cache is greater then the time to recompute it, caching is a loose. Additionaly, if the hit rate (probablity; 0..1) times the time to recompute the datum is less then the time to look up the result in the cache, it's a loss for that datum. MJD has a set of presentation slides on this at http://perl.plover.com/yak/memoize-quant/ -- Quantitative Analysis of Memoization. -=- James Mastros PS -- This is getting offtopic, even for p6l.
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
On 12/12/2002 5:50 AM, Aaron Crane wrote: Damian Conway writes: There's no need for special methods or (gods forbid) more operators. Just: $obj1.id == $obj2.id That's what the universal Cid method is *for*. How universal are universal methods? That is, can a programmer override .id() in a user-defined class? If so, simply comparing .id for numeric equality isn't a good enough way of comparing object identity. I'd say that you can override .id, but if you do, you deserve what you get. That is to say, if your .id method lies, and somebody tests that two objects are the same with .id, you should be sure that you're prepared to accept all the complications of answering the way you do. Also, it's likely that .id will be implemented with a single Parrot opcode, so you'll loose a lot of efficency by overriding it. Another question. Consider the integer 17. There are two plausible representations for it -- one boxed, and one unboxed. There might also be several distinct boxed 17s that aren't object-identical. My question is whether all of those should have the same .id(). Here's my basic defintion of ID: Two things should have the same ID if-and-only-if they will behave exactly the same, now and forevermore. Thus, there should be one ID for all constants of the same value, which is different from all constants of different value. (This is probably unimplementable if we gaurntee IDs are of some constant length.) Two objects should only have the same ID if they are aliases of each-other: they always have the same instance values, and the same value (but) properties. Promotable, but unpromoted, Ints should have different IDs, because they may at some point, have different values. Any unconsidered cases? That is, should the programmer be allowed to determine whether two apparently-identical numbers have the same representation, or should .id() fudge the issue by pretending that all representations of a number of a given type are identical. Some of both. Not all constants of the same number neccessarly have the same reprensentation in PBC -- to whit, a constant float in different compilation units will get different slots in the constant table, but are really identical. The same is true of constant strings. (Constant integers are inlined, and thus this doesn't apply to them -- they really are identical.) -=- James Mastros
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
(This is a reply to a mail accidently sent to me personaly instead of the list. Buddha, care to resend your other mail? I havn't quoted it in total.) On 12/12/2002 9:43 AM, Buddha Buck wrote: James Mastros wrote: Here's my basic defintion of ID: Two things should have the same ID if-and-only-if they will behave exactly the same, now and forevermore. If I wrote the Perl6 code correctly (and no guarantees that I hit this moving target), then once created, a Complex object cannot be modified and is indistinguishable by behavior from any other Complex object with the same value: Is it reasonable to have $a.id == $b.id? No, as you can still change the properties of the objects independently. If you can't even do that, then yes. -=- James Mastros
Re: Comparing Object Identity (was: Re: Stringification of refere nces (Decision, Please?)) [x-adr][x-bayes]
On 12/12/2002 4:01 PM, Larry Wall wrote:
On Thu, Dec 12, 2002 at 12:40:52PM -0600, Garrett Goebel wrote:
: And what will:
:
: main.*can('foo')
:
: result in?
These days it's Main, not main. And it's a module, not a class,
so probably it fails, unless someone can think of something useful
for it to mean.
It would, logicaly, mean that the class Module has a method foo if
true -- applying can on an object tells you if the class of that object
can do somthing, and Main is an object of class Module... right?
(%Main:: is a hash, but Main (bareword) is an object, no?)
-=- James Mastros
Exists and hypotheticals (Was: Re: Comparing Object Identity)
On 12/12/2002 8:07 PM, Larry Wall wrote:
Ordinarily you'd test for subs with one of
exists Main::foo
Main::foo.exists
I thought that was now spelt exists %Main::{foo} -- that the symbol
tables were now just plain hashes? (And what's the methody syntax for
testing for hashkey existance -- %hash{key}.exists should get the key
element of hash, then run it's exists method, logicly. Is it
%hash.exists('key')?
I suppose one could set up a transactional structure in which can
actually does the side effects hypothetically, with the option of
committing later. Sort of what a try block would like to be when
it grows up...
Or hypothetical variables in a non-regex context...
-=- James Mastros
Re: Comparing Object Identity
On 12/12/2002 5:24 PM, Dan Sugalski wrote:
At 2:17 PM -0800 12/12/02, Michael Lazzaro wrote:
On Thursday, December 12, 2002, at 01:41 PM, Dave Whipp wrote:
I might want to write code such as:
$remembered_id = $obj.id;
... [ time passes ] ...
if $an_object.id == $remembered_id { ... }
I think if you do this, you're probably in a world of hurt. We'd have
to assure that no object id's are *ever* reused -- so mem addresses
are out, since the same address may be used for different things at
different points in time.
There'll definitely be memory address reuse. If .id returns the current
object's memory address, it shouldn't be cached any place, as otherwise
you'll find things going bang with some regularity.
And I'd say (but who asked me -- IMHO, of course) that it should be
perfectly valid to write code like the above. (That IDs should be
unique across a process over all time.) If that'd require that an
object's ID be a combination of the header address and a generation
counter, that's OK. It means a serilization point in the allocator, but
I think we'd need one no matter what (Dan?).
-=- James Mastros
Re: how to code a lazy pipeline?
On 12/10/2002 4:54 AM, Me wrote:
How would one most nicely code what I'll call
a lazy pipeline, such that the first result
from the final element of the pipeline can
appear as soon as the first result has been
processed from the intervening elements?
I belive the short answer is make sure all elements of your pipeline
return a lazy list. Exactly how one does this, and the distinction
between a lazy list and an iterator, I belive is still somwhat up in the
air. (If I'm wrong, please correct me.)
IOW:
foreach (map {$_+1} grep {$_0} @foo but lazy) {
do_somthing_here($_);
die Bye-bye universe! if ($_=42);
}
Will never compute anything after the first 41 element in @foo occours.
(I'm assuming map, grep, and any other list-oriented function that can
get away with it will act lazily when given a lazy-list argument.)
-=- James Mastros
Re: Usage of \[oxdb] (was Re: String Literals, take 2)
On 12/05/2002 12:18 PM, Michael Lazzaro wrote: On Thursday, December 5, 2002, at 02:11 AM, James Mastros wrote: On 12/04/2002 3:21 PM, Larry Wall wrote: \x and \o are then just shortcuts. Can we please also have \0 as a shortcut for \0x0? \0 in addition to \x, meaning the same thing? I think that would get us back to where we were with octal, wouldn't it? I'm not real keen on leading zero meaning anything, personally... :-P You misinterpret. I meant \0 meaning the same as \c[NUL], IE the same as chr(0), a null character. (I suppse I should have said \0x[0].) Which means that the only way to get a string with a literal 0xFF byte in it is with qq:u1[\xFF]? (Larry, I don't know that this has been mentioned before: is that right?) chr:u1(0xFF) might do it too, but we're getting ahead of ourselves. Hmm... does this matter? Sorry. It does, in fact, not matter... momentarly stopped thinking in terms of utf8 encoding being a completly transparent process.
Re: Usage of \[oxdb] (was Re: String Literals, take 2)
On 12/04/2002 3:21 PM, Larry Wall wrote:
On Wed, Dec 04, 2002 at 11:38:35AM -0800, Michael Lazzaro wrote:
: We still need to verify whether we can have, in qq strings:
:
:\033 - octal (p5; deprecated but allowed in p6?)
I think it's disallowed.
Thank the many gods ... or One True God, or Larry, or whatever your
personal preference may be. (So have a merry Christmas, Happy Hanukah,
Kwazy Kwanzaa, a tip-top Tet, and a solemn, dignified Ramadan.)
\0o33 - octal
\0x1b - hex
\0d123 - decimal
\0b1001- binary
\x and \o are then just shortcuts.
Can we please also have \0 as a shortcut for \0x0?
\c[^H], for instance. We can overload the \c notation to our heart's
desire, as long as we don't conflict with its use for named characters:
\c[GREEK CAPITAL LETTER OMEGA WITH PSILI AND PERISPOMENI AND PROSGEGRAMMENI]
Very Cool. (BTW, for those that don't follow Unicode, this means that
everything matching /^[^A-Z ]$/ is fair game for us; Unicode limits
charachter names to that to minimize chicken-and-egg problems. We
/probably/ shouldn't take anything in /^[A-Za-z ]$/, to allow people to
say the much more readable \c[Greek Capital Letter Omega with Pepperoni
and Pineapple].
: There is also the question of what the bracketed format does. Wide
: chars, e.g. for Unicode, seem appropriate only in hex. But it would
: seem useful to allow a bracketed form for the others that prevents
: ambiguities:
:
:\o164 ne \o{16}4
:\d100 ne \d{10}0
:
: Whether that means you can actually specify wide chars in \o, \d, and
: \b or it's just a disambiguification of the Latin-1 case is open to
: question.
There ain't no such thing as a wide character. \xff is exactly
the same character as \x[ff].
Which means that the only way to get a string with a literal 0xFF byte
in it is with qq:u1[\xFF]? (Larry, I don't know that this has been
mentioned before: is that right?) chr:u1(0xFF) might do it too, but
we're getting ahead of ourselves.
Also, an annoying corner case: is \0x1ff eq \0x[1f]f, or is it eq
\0x[1ff]? What about other bases? Is \0x1x eq \0x[1], or is it
eq \0x[1x] (IE illegal). (Now that I put those three questions
together, the only reasonable answer seems to be that the number ends in
the last place it's valid to end if you don't use explicit brackets.)
(BTW, in HTML and XML, numeric character escapes are decimal by default,
you have to add a # for hex. In windows and several other OSes (I
think, I like to play with Unicode but have little actual use for it),
ALT-0nnn is spelt in decimal only. Decimal Unicode ordnals are
fundimently flawed (since blocks are always on nice even hex numbers,
but ugly decimal ones), but useful anyway).
-=- James Mastros
Re: String Literals, take 2
On 12/03/2002 2:27 PM, Michael Lazzaro wrote:
I think we've been gravitating to a language reference, geared
primarily towards intermediate/advanced users. Something much more
rigorous than beginners would be comfortable with (since it defines
things in much greater detail than beginners would need) and written to
assume *no* prior knowledge of Perl5. It will be useful to the
developers -- in that it will describe required P6 behaviors in much
greater detail than the Apocalypses and Exegesis -- but it will be
written for users.
I quite agree... which still means we need more rigor then this document
has. The defintion of a pair and the semantics of \c[ and friends is
important so that users know exactly what \c~ means ('',
Cchr(ord('['-64)) ), and if Cqq◄some words here► will work (no,
those aren't a matched Pi/Pf or Pb/Pe pair, they're just Misc. Shapes
that have no direction information, and we can't do them reasonably
without looking at every character in Unicode visualy -- if somebody
wants to, be my guest!).
Do we want to change shorthand octal literal numbers to 0o123 (I
don't like this, it's hard to read), change octal chars to \c123
(can't do this without getting rid of, or changing, \c for
control-character), get rid of octal chars entirely, or somthing
else? (Baring a good somthing else, I vote for killing octal chars.)
As of Larry's last writings, there will definitely be an octal (it still
has good uses), and it's syntax will definitely be 0o777 -- with an 'o',
not a 'c'. The 'o' is a little hard to read, but the best anyone can
come up with. It has to be lowercase 'o', not uppercase 'O', which
helps *enormously*. :-)
Huh? In that case, somebody should tell Angel Faus; Numeric literals,
take 3 says 0c777, and nobody disented. IIRC, in fact, nobody's
descented to 0c777 since it was first suggested.
(But since I assume you can use \d, \b, \h anywhere you use \o, you
won't have to use octal at all if you don't want to.)
\d is pure speculation on my part. (As is \0 == chr(0).)
In fact, for this, and \o777 vs. whatever, I'm cc-ing perl6-language on
this.
p6l guys and the Design Team, if you havn't been following the
conversation, here's how it goes:
In perl5, octal numbers are specified as 0101 -- with a leading zero,
and octal characters in strings are specified as \0101. In perl6, our
current documentation lists 0c101 as being the new way to write octal
numbers, because it lets people use leading zeros in numbers in an
intuitive way, and 0o101 was decided to be too difficult to read. The
last writing of Larry to address this, as far as I (or anybody else who
I've noticed) knows, says 0o101.
It's generaly been agreed on, I think, that 0c101 is the way to go.
Now, we're working on string literals, and the question is how we write
octal character literals. The current writer of the string literal spec
wants \o101 to be the new way to write what is \101 in perl5 (and
C). I'd prefer this to be \c101, to match up with how the current doc
says octal numerics are written. Unfornatly, \c is taken for
control-characters (ie \c[ eq chr(ord '[' - 64) eq ESC), which is a
more important use of \c.
What do we do, oh great and wonderful design team?
Numeric StringUpsideDownside
--- ----
0101 \101 p5/C compatable Unintutive
0o101 \o101 ConsistentHard to read
0c101 \o101 keeps \c for Inconsistent
control-char
0c101 unsupported Consistentoctal string chars
unsupported
0t101 \t101 Consistentwhat's tab?
Or somthing else?
All choices are bad, which one is best?
-=- James Mastros
Re: ~ for concat / negation (Re: The Perl 6 Emulator)
From: Nathan Wiger [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, June 21, 2001 4:41 PM Subject: ~ for concat / negation (Re: The Perl 6 Emulator) Does anyone else see a problem with =~ ? Plus, it makes the pre-plus-concat that many desire impossible, since =~ is taken. God, yes. I constantly have problems with ~= vs. =~; this is only helped by the fact that =~ is normaly a syntax error. (It isn't when you use a qx//ed regex, which I don't do often.) In summary: 1. I don't like ~ for concat 2. But if it does become concat, then we still shouldn't change ~'s current unary meaning I 100% agree. It's shenanagnins like this that make perl people look like fringe wackos. I still fail to see why . is such an advantage over -. The only real benifit I see is typing ease, and - isn't that hard to type. That's what editor macros are for. It's rather unfornate that we've run out of characters to use for operators, but we've got to deal with it better then flipping around operators willy-nilly. -=- James Mastros
Re: suggested properties of operator results
From: Dave Storrs [EMAIL PROTECTED]
To: Chris Hostetter [EMAIL PROTECTED]
Sent: Sunday, June 10, 2001 9:07 PM
Subject: Re: suggested properties of operator results
On Fri, 8 Jun 2001, Chris Hostetter wrote:
$v2 = VALUE2;
$v1 = (defined VALUE1.valueR ? VALUE1.valueR : VALUE1);
return ($v2-$v1 == abs($v2-$v1)) is valueR($v2);
which ... would cause the following code to mean ... think it
should mean:
if ($foo $bar $baz) { ... }
I'm assuming that you're correct (I see no reason that you wouldn't be; I
just havn't checked it out myself, and am not clear on where valueR is
defined.)
...
1) The do this because it will be more intuitive for beginners
argument comes up a lot, and is pretty appealing at first. However, as
someone (was it tchrist?) pointed out, beginners don't stay beginners for
long, so writing a language for beginners may cost you people when they
grow out of your language.
Which it is indeed. (The feature is a good idea, and tchrist is right.)
It's a lot easier to read, and a lot easyer to write ($a $b $c) then
($a$b) ($b$c). Moreover, when the varables have names longer then a,
b, and c, then it gets rather easy to change only one of several instances
of a varable. (That is, $a$b $b$c into $a$d $b$c).
2) This feature would be very prone to abuse (makes it easier to
obfuscate code), but that isn't a reason to disqualify something either.
Certianly not in perl. Hell, I think sometimes it's a reason /to/ put a
feature in perl.
3) Used for what it is intended for, it seems like a very concise,
expressive way to do multiple relationship tests without needing all those
s and such.
Indeed. (Though, as defined above, this won't work on the string
operations, only the numerics.)
-=- James Mastros
Re: Properties and stricture and capabilities
From: [EMAIL PROTECTED] To: David L. Nicol [EMAIL PROTECTED] Sent: Friday, June 08, 2001 8:01 PM Subject: Re: Properties and stricture and capabilities On Thu, Jun 07, 2001 at 08:24:33PM -0500, David L. Nicol wrote: That would prevent further shoving of anything onto the symbol table without proper authorization as defined by holding the capability. Getting into details about this doesn't make much sense as we don't yet know what the new symbol table interface will look like. I thought Larry had said that it would be a plain hash, with funny- character included in the key. -=- James Mastros
Re: Perl5 Compatibility, take 2 (Re: Perl, the new generation)
From: Michael G Schwern [EMAIL PROTECTED] To: Nathan Wiger [EMAIL PROTECTED] Sent: Friday, May 11, 2001 2:27 PM Subject: Re: Perl5 Compatibility, take 2 (Re: Perl, the new generation) On Fri, May 11, 2001 at 10:56:38AM -0700, Nathan Wiger wrote: 2. Do we want to be able to switch between Perl 5 and Perl 6 in a single file (by using module to dictate P6 and package P5)? I'd say no. Although it would allow for incremental upgrades of legacy modules, the idea of mixing two versions of Perl in a single file makes the short hairs on the back of my neck stand up. It will be extremely confusing. Yes, it will be, and /I/ wouldn't do it if I could avoid it. OTOH, we're already talking about having support for multiple languages (parsers) within one file, and having perl5 being another parser. Put them together, and you get exactly this. -=- James Mastros
Re: Apoc2 - STDIN concerns
From: Larry Wall [EMAIL PROTECTED] To: Eric Roode [EMAIL PROTECTED] Sent: Tuesday, May 08, 2001 11:03 AM Subject: Re: Apoc2 - STDIN concerns Eric Roode writes: : And, while I'm on my soapbox here, I don't get how ... is a vast : improvement over qw :-) Please pardon my hyperbole. I don't loathe qw() so badly that I want to get rid of it. I merely want to put it in the same status as the other general quote operators that also have a non-general pair of standard quote characters. I would feel the same about qq// if there weren't a . Might I suggest, then, that instead of making foo bar a synonym for qwfoo bar, we use it for iterators, and use foo bar (by which I mean the character twice, not the « character -- though probably either should work). That lets us keep foo for somthing iteratorish, which saves special-caseing (I do occasionaly use a qw list with one element), and lets us keep continuity. Anyway, I'm fairly certian that I'll use iterators more then qw lists. -=- James Mastros
Re: Apoc2 - STDIN concerns
From: Michael G Schwern [EMAIL PROTECTED]
To: Nathan Wiger [EMAIL PROTECTED]
Sent: Friday, May 04, 2001 9:46 PM
On Fri, May 04, 2001 at 04:42:07PM -0700, Nathan Wiger wrote:
I'm wondering what this will do?
$thingy = $STDIN;
This seems to have two possibilities:
1. Make a copy of $STDIN
2. Read a line from $STDIN
While perhaps inconsistent, I'd really rather it did #2. Here's the
basic argument... compare how often you dup a filehandle with how
often you read from one. Duping is swamped by several orders of
magnitude. Dup with $fh = $STDIN.copy; (or whatever). $line =
$STDIN.next should still work normally.
Here's what I'd like (in general interators):
1) Using in a scalar context gets the next value. $line = $STDIN;
2a) Using in a unknown-length list context gets all the values. @lines =
$STDIN;
2b) Using in a known-length list context gets enough values. ($line1,
$line2) = $STDIN;
3) Using on the LHS of a = outputs a value (or a bunch of values if RHS is a
list).
4) Using on the RHS of a := copies. $STDOUT := $STDERR;
5) Using with a $() operator won't get. if ($($STDOUT) eq $($STDIN)) {foo}.
(?)
That is, getting without somthing special gets values out of the iterator,
getting
with a := gets the iterator itself (: for inner), and $() derefs it to a
filenameish thing (?).
This leaves free, and I think the use of := agrees with what is planned.
It also avoids the use of a verbose .next (and the dot, which I still don't
like G).
-=- James Mastros
Re: Apoc2 - STDIN concerns
From: Nathan Wiger [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, May 04, 2001 10:02 PM Subject: Re: Apoc2 - STDIN concerns You know, I hear what you're saying, but it really makes the little hairs on my neck stand up. Just imaging trying to teach this: $a = $b;# assignment or readline? It's really spooky. You're changing what = does, indeed what method it calls (copy vs next), based on the contents of the variable. I'd much rather have to do: $a = next $b; I think that = should always be get a value, and := should always be get the thing itself. For normal things, the thing itself and it's value are the same, so := is equivlent to =. Truthfully, I've always liked the 's (and personally don't think we need a qw alternative), so I'd rather we stay with: $a = $b; # same as next $b or $b.next Hey, maybe we can convince Larry... ;-) I'd tend to agree. Especialy that we don't need a qw() alternative. However, I don't think Larry's in a convincable mood -- coughdotcough. -=- James Mastros
Re: Please make last work in grep
From: Alexander Farber (EED) [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, May 02, 2001 5:13 AM Subject: Please make last work in grep Here I am looking for a button with a special name - Delete ... - and there can be only one such button, so I have to interrupt the grep after I find it I'd rather see grep have split-like magic, where it sees the length of the list it is being assigned to, and stops when it has filled the list. So ($a, $b) = grep /!(.*)/, qw(1 4 0 5 !0!0 98 46 !9 !097!0!9080; would stop looking after it had found and returned 0!0 and 9, and never even glance at the 98. Basicly, if you assign to a list of lvalues, @returnlist, it will stop looking after it has found scalar(@returnlist) matches or end-of-input. -=- James Mastros
Re: Tying Overloading
From: Larry Wall [EMAIL PROTECTED] Sent: Monday, April 23, 2001 1:10 PM Subject: Re: Tying Overloading Helgason writes: : I _really_ think dot-syntax would make perl prettier as well as make it : more acceptable to the world of javacsharpbasic droids. Which is some : kind of goal, no? Consider it a given that we'll be using . for dereferencing. (Possibly with - as a synonym, just for Dan. :-) Larry I hate yelling without good reason, but this /is/ good reason. CAN SOMBODY PLEASE TELL ME A _GOOD_ REASON TO SWITCH TO . FOR METHOD CALLS? Reasons I have seen are: 1) Two less keys to press. 2) Looks cleaner. 3) Looks more like other languages. Counterarguments: 1) Produces confusion for perl5 programmers. I think that we should be kinder to perl5 programmers switching to perl6 then to java[script]/vb programmers switching to perl6. (C and C++ shouldn't be an issue; we stole - from C in the first place.) I submit that := is far uglyer and harder to type then -. I don't think that we should change around huge amounts of other things just so we can s/-/./. If we really want an easyer-to-type method call operator, I'd go with \. It's use currently outside of a qq is erronious. It can't interoperlate inside of qq, but nor can any other operator discussed here. It doesn't look much like whitespace (if that's what you mean by looks nice). If you want that, you could go with `, which could produce some ambiguity, both with qx and with ', which looks very similar in many fonts. BTW, I think that considering no-whitespace cases of indirect object is quite silly -- does anybody acatualy use that? This is the first I thought it wasn't a syntax error. -=- James Mastros
Re: YA string concat proposal
From: Jonathan Scott Duff [EMAIL PROTECTED] To: Nathan Wiger [EMAIL PROTECTED] Sent: Tuesday, April 24, 2001 4:08 PM Subject: Re: YA string concat proposal On Tue, Apr 24, 2001 at 01:05:24PM -0700, Nathan Wiger wrote: Under the above plan, maybe this is: $a ca $b; For concat after? I'd rather it be called pp for prepend. :-) I'd rather it be spelled $a =. $b; (or $a=.$b, or $a=./index.html; I don't see how any of those are subject to misparse. $a=.5 would be, of couse, but you can disambugate by $a=. 5 or C$a=.5. It's good that we decided to let Larry design the language, otherwise we'd be mired in muck like this for a long time. Yah. And it looks like we're going to be as it is. It's been said elsewhere on these threads: What does changing to . from - buy us? I can see that . is shorter to type then -, but, say, \ would be just as good. I can't really say changing because . is more standard. It isn't standard to C or perl5. It's possible to misparse . as concat with . as a sepperator on version-strings, but that's more of a problem with using it for method-call. -=- James Mastros
Re: Larry's Apocalypse 1
On Fri, Apr 06, 2001 at 11:17:49AM -0700, Larry Wall wrote: Hence, :+ would be pairwise array addition. Sounds quite reasonable. There will probably be optional modifiers before colon for various reasons. This has the result that we could distinguish an inner:* operator from and outer:* operator. (Labels would be required to have whitespace after the colon, in this scenario.) It also means that every operator has a function name, so you could call inner:*(@a, @b) or @a-inner:*(@b) or some such. Hm. If I assume that s/:/::/, I like it. Otherwise, I really really don't. Why? Because it introduces more namespaces (and probably syntax) when they aren't really neccessary. If you use a ::, and make packages able to define operators straight-up, then you could do, say, $a dB::+ $b. There would be a :infixable attribute on subs, so you could make infix operators with arbitrary names: use Game::DnD 'D'; $hp = 3 D 6; It might even mean that we can have a URL literal type, if we can figure out how to parse it, and if there's any good reason to treat a URL as more than just a string: print $::OUT http://www.wall.org/~larry/index.html; Please, no! A URL isn't a /new/ type of literal, really. Either it's a wierd form of a literal list, or it's a wierd type of file name, so you should open() it. Or it's a self-quoting literal, like Packagename::. If you really want to be able to read from a URL in one line, let yourself do open(foo). But make opening a URL an explicit act. But I really mustn't spill too many half-digested beans here. :-) If you have to, at least do it in the toilet. P.S. Larry's Second Law of Language Redesign: Larry gets the colon. May He (or You) do Good Things with it. -=- James Mastros -- The most beautiful thing we can experience is the mysterious. It is the source of all true art and science. He to whom this emotion is a stranger, who can no longer pause to wonder and stand wrapt in awe, is as good as dead. -=- Albert Einstein AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Perl 5 compatibility (Re: Larry's Apocalypse 1)
OK, there's probably somthing simple I'm missing here, but... 1. Cuse 5 or Cuse 6 (and, in general, Cuse vervect) import the definitions of the language as it existed at that time (more or less), or die if they can't. (Or run through p52p6, or whatever.) Advantage: matches existing precedent. The real perl 5 won't choke on it, and will even give the right error. 2. If the name of the executable (from argv[0] or the beginning of #!) contains "perl.?[56]", then there is an implicit Cuse 5 or Cuse 6. (And why not any other version number? Just don't ship them in core, please!) Advantage: reasonably non-intrusive. 3. Otherwise, assume perl 6. Advantage: we require trivial changes in existing scripts instead of baggage we'll be carrying around forever. If you object to that much change as an admin, feel free -- install perl6 under the name "perl6", symlink perl5 to it, and make a symlink from perl to perl5. (This would work only if we had #2 follow symlinks until it saw a "perl5" or "perl6", which is probably fine). If you don't have symlinks on your system, then get a better system, use a site-policy file, or bite the bullet and change the #! lines. -=- James Mastros -- The most beautiful thing we can experience is the mysterious. It is the source of all true art and science. He to whom this emotion is a stranger, who can no longer pause to wonder and stand wrapt in awe, is as good as dead. -=- Albert Einstein AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Larry's Apocalypse 1
On Thu, Apr 05, 2001 at 06:12:30PM -0400, John Porter wrote: Michael G Schwern wrote: ETOOMAGICAL. Shades of zip/unzip here. On some systems zip and unzip are just hard links to the same binary. It figures out what it supposed to do by what name is called. Very magical. Very bad. Well, the proposed trick for perl would be bad; what zip does isn't. argv[0] is just another arg, afterall. Hmm. I rather fail to see the difference between the zip vs. perl. On the other hand, I don't like it when bzip2 does it either -- you can't symlink bunzip - bunzip2 and bzip - bzip2 and have it do the Right Thing. On the gripping hand, when combined with other mesures, not so bad. -=- James Mastros -- The most beautiful thing we can experience is the mysterious. It is the source of all true art and science. He to whom this emotion is a stranger, who can no longer pause to wonder and stand wrapt in awe, is as good as dead. -=- Albert Einstein AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: What can we optimize (was Re: Schwartzian transforms)
On Wed, Mar 28, 2001 at 03:41:42PM -0800, Hong Zhang wrote: Are we over-optimizing? The Perl is just an interpreter language. Who really needs this kind of optimization for Perl? Even C does not provide this feature. Umm, art thou sure? C can optimize better then we currently do many times, because it doesn't have to worry about side-efects as often because it doesn't have the concept of ties/overriden operators. (It does, and we do, have to worry about aliasing, but that is somthing of a smaller problem.) Just because C doesn't memonize, doesn't mean we shouldn't have that optimization available to us. So many other optimizations that are doable in C aren't in perl. Though Pascal/Ada have distinctions like function/procedure, it does not make them any faster than C. Umm, I don't know Ada, but in Pascal, the only difference is that one returns a value and the other does not (IE like void vs. nonvoid functions in C, or sub vs. function in VB). Just given its ugly name, I hate to see it in the core language. If people really want to optimize Perl, they can write a native compiler for Perl with advanced garbage collector, just like Scheme or Strongtalk compiler? We want to make it as fast as reasonably possible. Writing a native compiler might not be _reasonably_ possible. And an advanced GC will almost certianly be part of perl6; they're orthogonal issues. -=- James Mastros -- The most beautiful thing we can experience is the mysterious. It is the source of all true art and science. He to whom this emotion is a stranger, who can no longer pause to wonder and stand wrapt in awe, is as good as dead. -=- Albert Einstein AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: What can we optimize (was Re: Schwartzian transforms)
On Thu, Mar 29, 2001 at 10:36:48AM -0800, Hong Zhang wrote: I have to say that I agree to disagree. Since it has been so controversal, I just don't think this optimization is a good one. Hmm, we aren't talking sort() specificly anymore. Look at the subject line. G The function in Ada can not have any side effect, i.e. no change to globals. The procedure can have side effect. It gives compilers some more chances for optimizations. For example (pseudo code), function comp(int n, int m) : int; the compiler can safely remember the result of comparison for the same arguments. Ahh, bingo. That's what a number of people (inculding me) are suggesting -- a :functional / :pure / :stateless / :somthingelseIdontrecall attribute attachable to a sub. -=- James Mastros -- The most beautiful thing we can experience is the mysterious. It is the source of all true art and science. He to whom this emotion is a stranger, who can no longer pause to wonder and stand wrapt in awe, is as good as dead. -=- Albert Einstein AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Schwartzian Transform
On Wed, Mar 28, 2001 at 09:38:59AM -0500, John Porter wrote: Mark-Jason Dominus wrote: I have to agree with whoever followed up that this is a really dumb idea. Yahbut... (See last paragraph, below). OK, I'm agreeing with MJD on this one, and it was my idea. There is no easy way to check for statelessness in all cases. In some cases you can -- sin($a) = cos($b) is obviously stateless (if $a and $b aren't magic), because it is composed only of stateless primitives. This runs afoul of the halting problem real quick. Or so I'm told, and I belive it. If the comparison (or key extraction) function is not idempotent, that is a much worse situation than simply one of degraded performance. It means the result of sort() won't be (or at least will not be guaranteed to be) sorted! My intuition says that it will either be sorted, for a simple def of sorted ($s[i] = $s[i+1]), or will take infinite time. (The "take infinite time" is, I assume, the one that made things dump core.) if my_compare(a,b) 0, and my_compare(b,c) 0, then it should also be the case that my_compare(a,c) 0 Hm. We could call that "relative idempotency", I suppose. I'd go with "transitive", since this is a property of the comparator, not the extractor. If you seperate the comparator and the extractor(s), then the comparator must be transitive, and the extractors must be internaly stateless. But, aaui, it is not a question of the comparison function being idempotent, but the key extraction function being so. aaui? Hm. Let's define some terms like "idempotency". These are also my (current) ideas for sub attributes. Stateless: The function neither depends on state, nor modifies it. This makes it a pure (IE mathematical) function. f(a) == f(a), and there is no side-effect. sin() is stateless. This means the function is memonizeable. Internaly stateless: f(a) == f(a), but there might be sideefects that do not effect the return value. printf is internaly stateless (ignoring linenoize vars). This is the essencial property of key extractors. Note that all stateless functions are internaly stateless. Transitive: if my_compare(a,b) 0, and my_compare(b,c) 0, then it should also be the case that my_compare(a,c) 0 I can't define it better then that. (Though there's more to it then that). Note that only the sign of the answer is gaurnteed, so it doesn't even have to be internaly stateless -- but it probably doesn't make sense for it not to be. Give the braindead no head. You might want to change that to "heed". -=- James Mastros -- The most beautiful thing we can experience is the mysterious. It is the source of all true art and science. He to whom this emotion is a stranger, who can no longer pause to wonder and stand wrapt in awe, is as good as dead. -=- Albert Einstein AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Schwartzian transforms
On Wed, Mar 28, 2001 at 11:11:20AM -0500, Dan Sugalski wrote: "Can perl automatically optimize away function and tie calls inside a sort function, and under what circumstances?" Agreed. It doesn't really matter if the functions inside the sort function are idempotent--what matters is whether it's OK for us to go and memoize the things (or whatever else we might choose to do) As far as I can see, this, in essence, gives a few basic cases: 1) The sort function is ill-defined. 2) The sort function is stateless. 3) The sort function is simply internaly stateless. 4) The function is well-defined, but not stateless whatsoever. In case 1, The sort won't work anyway, so we can ignore this case. I'm of the opinion that we should consider 3 to be Just Plain Silly and not worth worring about overmuch. (These would be functions that increment a counter every time they are accessed, for example.) I think that the difference between 43 dosn't matter. We only have things in 4 and not 3 that vary in abs(), but not sign. We're left with 12, and for 1, the sort won't work anyway. So long as we consider 2 Just Plain Silly, we're OK memonizing. -=- James Mastros -- The most beautiful thing we can experience is the mysterious. It is the source of all true art and science. He to whom this emotion is a stranger, who can no longer pause to wonder and stand wrapt in awe, is as good as dead. -=- Albert Einstein AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: What can we optimize (was Re: Schwartzian transforms)
On Wed, Mar 28, 2001 at 04:36:58PM -0500, Dan Sugalski wrote:
With perl, though, this does
potentially unexpected things if $i is tied. Do we still optimize it away?
Do we only do it if we can tell that $i's not tied?
Yep. And in non-trivial cases, the only way to do that might be for $i to
be :simple.
Do we force the
programmer to explicitly note which variables are potentially tied with the
"my Dog $spot" syntax and assume that everything else is fair game?
I'd rather see that things that will never be tied or otherwise magic be
marked as :simple. Code always works, and will be faster with a little
effort.
Can we
even do that in the face of runtime requires, dos, or evals? (Or does that
force a complete reevaluation of the optimized bytecode)
It is a catchable error to remove a behavorial restrictor attribute such as
:simple or :stateless. So let it be spoken, so let it be done.
This isn't any more preverse then the "you can't assign to constants" rule.
-=- James Mastros
--
The most beautiful thing we can experience is the mysterious. It is the
source of all true art and science. He to whom this emotion is a stranger,
who can no longer pause to wonder and stand wrapt in awe, is as good as dead.
-=- Albert Einstein
AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: What can we optimize (was Re: Schwartzian transforms)
On Wed, Mar 28, 2001 at 05:57:30PM -0500, James Mastros wrote: [A bunch of stuff] Oh, and I agree with sombody else on this thread that unless otherwise stated, the sort should always assume statelessness (and thus the ability to cache at will). If it's trivial to see that the sort function isn't stateless (IE it's a named sub that doesn't have the :stateless attribute set), then have an optional warning, because you probably don't want to be using that function, or the function should be marked :stateless. -=- James Mastros -- The most beautiful thing we can experience is the mysterious. It is the source of all true art and science. He to whom this emotion is a stranger, who can no longer pause to wonder and stand wrapt in awe, is as good as dead. -=- Albert Einstein AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Schwartzian Transform
On Mon, Mar 26, 2001 at 03:36:08PM -0500, Dan Sugalski wrote:
The only issue there is whether memoization is appropriate. It could be
argued that it isn't (it certainly isn't with perl 5)
Hm. I don't see a linguistic reason why it isn't with perl5. Unless the
comparisign function as a whole is stable (IE {f(a) = f(b)}, the sort
function is documented as being undefined.
The only way f(a) can not be stable and f(a) = f(b) can be is somthing of
a corner case. In fact, it's a lot of a corner case.
though I for one
wouldn't mind being able to more aggressively assume that data was
semi-constant...
Well, you can. Unless it has magic (and more specificly, scalar get magic).
(Imagine returning tied data from a function loaded in via
do(). Imagine the optimizer. Imagine Dan's brain popping out of his head
and hiding behind the bookcase)
That's a really wierd image. Twisted, even.
-=- James Mastros
--
The most beautiful thing we can experience is the mysterious. It is the
source of all true art and science. He to whom this emotion is a stranger,
who can no longer pause to wonder and stand wrapt in awe, is as good as dead.
-=- Albert Einstein
AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Perl culture, perl readabillity
On Mon, Mar 26, 2001 at 01:11:06PM -0700, Dan Brian wrote:
As for the English influence, you're welcome to identify ways that the
syntax could be extended or tightened to be less so. That's the intent of
the mailing list. But please, no more Latin ... I like positional
dependency. :)
Hmm. I just relized what he's talking about. As an example, most nonsimple
statements (IE past-tense, ones with modal and action verbs, etc) end in the
verb. For example, an english-speaker would say:
I must walk the god. (Subject modal-verb action-verb direct-object.)
A german-speaker would say:
I must the god walk. (Subject modal-verb direct-object action-verb.)
(Yes, I am a dislexic, agnostic insomniac.)
This is exactly analgous to the perl form (english-perl):
sort { f(a) = f(b) } @list; (Action-verb subordanate-verb (adverbal form)
direct-object.) OTOH, for a german-speaker, sort @list {f(a) = f(b)}
would be more natural (Action-verb direct-object subordanate-verb
(infinitive form)). (Note, BTW, that gramaticly, perl statements always
have a implied subject of "Intepreter" [0]. (Also note that in english, the
adverbal form of a verb normaly ends with ly, in german it ends with en, and
in perl is surrounded by curly-braces.))
Hmm, in fact, perl statements are always in command form, which means that
in german, they are always non-simple sentances, and the verb is always at
the end.
OTOH, there are cases where perl is more readable for not
matching a natural language structure. For example, hit $ball
$outfield; is a normal structure: verb indir-obj dir-obj. OTOH,
$ball-hit ($outfield) is indir-obj verb dir-obj, which is just screwy from
an english point of view, but perfectly normal from a perl viewpoint.
Then again, if you think of objects (in the OO sense) as doing things, then
they normaly are the subject, and _not_ the indirect-object (in the english
sense).
(Note, BTW, that both my german and my lingustics aren't so hot.)
-=- James Mastros
--
The most beautiful thing we can experience is the mysterious. It is the
source of all true art and science. He to whom this emotion is a stranger,
who can no longer pause to wonder and stand wrapt in awe, is as good as dead.
-=- Albert Einstein
AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Schwartzian Transform
On Mon, Mar 26, 2001 at 07:31:29PM -0500, Dan Sugalski wrote: At 06:51 PM 3/26/2001 -0500, John Porter wrote: As for :idempotent, I think sort() needs to assume the comparison sub is idempotent, rather than requiring such an attribute explicitly. Assuming idempotency's fine, though I don't know that I'd go so far as to require it. I certainly wouldn't complain, though. I'd think /perl/ should complain if your comparison function isn't idempotent (if warnings on, of course). If nothing else, it's probably an indicator that you should be using that schwartz thang. -=- James Mastros -- The most beautiful thing we can experience is the mysterious. It is the source of all true art and science. He to whom this emotion is a stranger, who can no longer pause to wonder and stand wrapt in awe, is as good as dead. -=- Albert Einstein AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Schwartzian Transform
On Mon, Mar 26, 2001 at 06:31:22PM -0500, Dan Sugalski wrote:
At 04:04 PM 3/26/2001 -0500, James Mastros wrote:
The only way f(a) can not be stable and f(a) = f(b) can be is somthing of
a corner case. In fact, it's a lot of a corner case.
You're ignoring side-effects.
Damm. I hate it when I miss the obvious. It's still a corner case, but not
so ignorable of one.
Well, you can. Unless it has magic (and more specificly, scalar get magic).
Yeah, but figuring out whether data isn't magic is rather tricky.
It shouldn't be, since we have to check for scalar get magic every time we
get the value as a scalar anyway. Figuring out whether it is depenedent on
some other thing which is magic, on the other hand, is really freeking nasty.
Once a
little uncertainty comes in (Say, from AUTOLOADed subs, or from subs whose
contents we don't know at compile time because of runtime requires, or
because we really do have magic data and the potential uncertainty from it
flares out quickly) it really cuts down on what the optimizer can do.
Youch. I tend to forget how "incestuous" perl is (as another message on a
perl6 list said quite some time ago).
I'm definatly with the guys who say we should have a :constant and a
:idempotent attrib for subs, and make them unremovable.
-=- James Mastros
--
The most beautiful thing we can experience is the mysterious. It is the
source of all true art and science. He to whom this emotion is a stranger,
who can no longer pause to wonder and stand wrapt in awe, is as good as dead.
-=- Albert Einstein
AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Schwartzian Transform
On Thu, Mar 22, 2001 at 11:13:47PM -0500, John Porter wrote:
Brent Dax wrote:
Someone else showed a very ugly syntax with an anonymous
hash, and I was out to prove there was a prettier way to do it.
Do we want prettier? Or do we want more useful?
Perl is not exactly known for its pretty syntax.
If you have to explicitly specify both the forward and inverse transforms,
then it isn't very useful -- it's nothing more then map/sort/map. OTOH, if
you only have to specify the forward mapping, it becomes more useful. Thus,
I think the best syntax is
tsort({xform}, {compare}, @list), where the {}s are anon blocks or curried
expressions (same thing) and xform specifies the forward mapping (IE (lc
^_)) and compare specifies the comparator (IE (^_ cmp ^_)).
This would always (do the equiv to) create a LoL in the inner map, sort on
the -[0] elem, and extract the -[1] elem. Thus, it might not be as
effecent as a hand-crafted schwartzian, but will be at least as efficent as
a naieve straight sort (except in pathalogical cases, like tsort((^_),
(^_=^_), @list)).
-=- James Mastros
--
The most beautiful thing we can experience is the mysterious. It is the
source of all true art and science. He to whom this emotion is a stranger,
who can no longer pause to wonder and stand wrapt in awe, is as good as dead.
-=- Albert Einstein
AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Schwartzian Transform
On Tue, Mar 20, 2001 at 11:15:51PM -0500, John Porter wrote:
@s = schwartzian(
{
second_map = sub { $_-[0] },
the_sort= sub { $a-[1] = $b-[1] },
first_map = sub { [ $_, /num:(\d+)/ ] },
},
@t );
Hm. I'd rather see:
schwartzian({/num:(\d+)/}, {^_=^_}, @t), and have perl figure out how to
do the forward and backword mappings. Hmm, I don't see why you couldn't
write that right now. (Other then synthatical shugar -- currying and
getting rid of the need for "sub {}"s.)
Indeed,
map $_-[0], sort {$sort($a-[1], $b-[1])} map [$_, $attrib($_)], @list;
does what I intendeded. (Where ex $sort = sub {$_[0] cmp $_[1]}, and
$attrib = sub {lc $_}.) (Of course, this doesn't always use the optimal
form.)
-=- James Mastros
--
The most beautiful thing we can experience is the mysterious. It is the
source of all true art and science. He to whom this emotion is a stranger,
who can no longer pause to wonder and stand wrapt in awe, is as good as dead.
-=- Albert Einstein
AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
On Wed, Feb 14, 2001 at 10:12:36AM -0300, Branden wrote: David Mitchell wrote: ... the above seems to imply a discussion that you only need to do expensive ref-counting (or whatever) on objects which have a DESTROY method. However, since you dont know in advance what class(es), if any, a thinngy will be blessed as, you always have to ref-count (or whatever technique is Blast. You are absolutly right, Dave. [snip about DESTORY predictablity not being neccessary] You're probably right about that, Branden. Quite nice, but not neccessary. Also, I think it would be valid for the programmer to explicitly say ``I would like to DESTROY this object now'', I'd think that an extension to delete is in order here. Basicly, delete should DESTROY the arg, change it's value to undef, and trigger a GC that will get rid of the arg. If the arg is a ref, it is /not/ derefed, so you'd oft want to use delete $$foo. being used by others. The way I suggest to deal with this is set a flag if the object was already DESTROYed. Then if any other tries to use it, it raises an exception (dies) with a message about ``This object was already DESTROYed.''. I think an ordinary "attempt to dereference undef" will work. -=- James Mastros -- "All I really want is somebody to curl up with and pretend the world is a safe place." AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
On Wed, Feb 14, 2001 at 09:59:31AM -0500, John Porter wrote: James Mastros wrote: I'd think that an extension to delete is in order here. Basicly, delete should DESTROY the arg, change it's value to undef,... Huh? What delete are you thinking of? This is Perl, not C++. Umm, perldoc -f delete? Come to think of it, this doesn't mesh purticularly well with the current meaning of delete. It does, however, with undef. In fact, it /is/ the current meaning of undef, except for the GC part. And perhaps the GC should be explicit or automatic, but not implicit. ...and trigger a GC that will get rid of the arg. No. Perl decides for itself when to do GC. That's almost certianly a mistake. The programmer often /does/ know the expectations of the end-user better then the interpreter. If the programmer can GC when /he/ wants to, he can do so when the pause will have the least effect. Think of a program that you want to run near-realtime most of the time, but where you have a bit of downtime every now and again. A game comes immedetly to mind. Or, for that matter, a program that spawns an external process that might take a lot of memory, so does a GC before spawning it. (Because otherwise the OS will happily page out your garbage, resulting in massive amounts of unneeded IO.) -=- James Mastros -- "All I really want is somebody to curl up with and pretend the world is a safe place." AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
On Wed, Feb 14, 2001 at 01:43:22PM -0300, Branden wrote: As I wrote in the last post, this isn't what I'm talking about. I'm talking about destroying the object before the GC does. Yah, so am I. I'm just saying that after the object is destroyed, don't keep it around. Yeah, what about a nasty module that decides not to call the GC and blow your memory??? That's IMO the best thing about programming in Perl compared to C: not having to keep track of the memory!!! RFC 28!!! Whoh! I never meant to say that Perl shouldn't automaticly do GC as it feels like it. Simply that you should be able to explicitly garbage-collect if you want to. (It's arguable that you should be able to disable automatic GC. In any case, it should be tunable, so disabling it is just an _extreme_ tune.) We must not count on the programmer for almost nothing. Watch your double-negitives. Writing calmly helps. If the programmer can GC when /he/ wants to, he can do so when the pause will have the least effect. I agree the programmer should have how to explicitly call the GC, but that wouldn't be required from him. OK then, we're all in agreement. Think of a program that you want to run near-realtime most of the time, Write C. With no GC below it. Probably, with no OS (or a realtime one) below it. Sorry. Near-realtime is apparently a much more restrictive word then I wanted. but where you have a bit of downtime every now and again. A game comes immedetly to mind. Even if you want to write games in Perl (I would definitely want to), you should use C extensions to do the screen update (at least for speed...), and those would definitely not be constrained to GC pauses. True, but I probably wouldn't for the event loop, and certianly not for the tick function. (At least some of the tick functions.) Call the GC explicitly before, no need to control when *not* to call it for this, as you were suggesting. Serious, man. Not having a implicit GC is not having GC at all! And as Perl should be Perl, it should keep collecting our garbage as we produce it! Sorry. I should have explained my wording more carefuly. I see three different types of triggers: 1) Explicit -- A call to garbage::collect or somesuch. 2) Implicit -- Certian program-execution events implicitly do a GC run when encountered. For example, you could say we do this now -- we garbage-collect every time a scope exits. What I was suggesting above is that when a 1-arg undef is encountered, implicitly GC. 3) Automatic -- Certian runtime events, not directly (or obviously) related to the flow of execution, like when the number of SVs created or the amount of memory allocated since the last GC run exced a certian critical value. (I /think/ a dictionary would agree with me, but I'm not about to get pissy and look them up.) I was saying that we should do 1 and 3, but not 2. -=- James Mastros
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
On Wed, Feb 14, 2001 at 01:25:26PM -0300, Branden wrote: The problem is when objects are shared by many variables. For example: $a = new Object(); $b = $a; ... destroy $a; ## would call $a-DESTROY() ... $b-doSomething();## should die. Note that $b is not undef Hmm? (Assuming destroy() autoderefs.) destory $a would call %$a-DESTORY (assumption of hash for example), and remove %$a from the symbol-table/otherwise make it nonexistant. Then $b-doSomthing() will fail because it's a ref to undef. And there would be another problem when the GC tries to collect the memory used by the object, because it usually calls DESTROY on collected objects. Calling it for this object would mean calling it twice, what is probably a very wrong thing to do. Oh, I rather assumed that there would be a "invalid" marker of some sort. It's neccessary (I think) for a pool, which I assumed. Bad James, bad. -=- James Mastros -- "All I really want is somebody to curl up with and pretend the world is a safe place." AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: End-of-scope actions: Toward a hybrid approach.
On Wed, Feb 14, 2001 at 07:40:26PM -0700, Tony Olekshy wrote: The problem may be that a dynamic always statement means both "no matter what happens" and "not until later". The static finally clause just means "no matter what happened" (the effect is immediate). I'm fond of post, myself. Simply means "subsequent to", literaly (m-w.com, post-, 2a. Yes, I'm anal sometimes.) "Always" makes me say "but when", and "later" seems like the wrong part-of-speech to me. -=- James Mastros -- "All I really want is somebody to curl up with and pretend the world is a safe place." AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Auto-install (was autoloaded...)
On Mon, Feb 12, 2001 at 04:01:31PM -0300, Branden wrote: We'll just have to use something other than RSA most likely. Why? Problems with exporting cryptosystems? If that's it, how does Java/Netscape do it? Nah, it's a pattent issue. Netscape (and other .jar consumers, assumedly) licenced code from RSA. However, it shouldn't be a problem, since RSA's pattent (in the US, anyway, and I don't think they pattented anywhere else) has timed out. -=- James Mastros -- "All I really want is somebody to curl up with and pretend the world is a safe place." AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Auto-install (was autoloaded...)
On Mon, Feb 12, 2001 at 01:03:31PM -0600, Jarkko Hietaniemi wrote: The problem of unpacking, or in other words, installing, or in other words, embedded hardwired paths is hard. Think library paths: both pure Perl libraries *and* shared libraries. True enough. The way Linux package managers work I think we can go with: they rely on stuff being in well-known locations. In the Linux case this is because the packager (in the broad sense of the term) can rely on the target system's distro being "right" for the package. In the case of Perl, we can rely on the parts inside the /usr/lib/perl (or whatever) tree being set up the "right way", and die, or even do the wrong thing, if the admin messed it up. In other words, if there's a place for everything, we just have to put everything in its place. The one rub with that is manpages: they need to be installed in a system-dependent location (with system-dependent names, even) in order for the "man" command to pick them up. My best idea for this is to have some directories (IE man dirs, but it could be useful for other things) have a magical "install" script in them that knows how to do special things with files in that directory (like set up symlinks from the normal man dirs). BTW, this plan would make it painful to do with perl5 setups, since they commonly have odd dir structures. -=- James Mastros -- "All I really want is somebody to curl up with and pretend the world is a safe place." AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Auto-install (was autoloaded...)
On Mon, Feb 12, 2001 at 06:56:47PM -0300, Branden wrote:
James Mastros wrote:
magical "install" script in them that knows how to do special things with
files in that directory (like set up symlinks from the normal man dirs).
That probably should be in Perl's Config.pm, since Perl itself will have to
install its own manpages. Perl should probably also include system-wide
shared libraries location, and other things of this kind.
Yah. In fact, I'm surprised it doesn't already.
I'd rather not have any kind of `script' that would be run on an
installation, to avoid the `Memoize' kind of bug (couldn't find the
reference), in which the install script had something like
Oh, I think you're understanding me wrong -- the par being installed doesn't
get to have an install program, the directory being installed into does.
Thus, for ex, doc/lib could have a script that does pod2man and installs the
manpages.
(It's arguable that the par being installed should get to have an install
script, but it should be highly optional.)
-=- James Mastros
--
"All I really want is somebody to curl up with and pretend the world is a
safe place."
AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: End-of-scope actions: POST blocks.
On Mon, Feb 12, 2001 at 01:58:57PM -0700, Tony Olekshy wrote:
- It does have in-flow presence, so it doesn't suffer from the
problem that "always" has; POST is a statement, not a dangling
clause. That fixes my main complaint with RFC 119. On the
other hand, now there's nothing at the end of the scope to tell
you whether or not have to revisit the whole scope to check if
there are any POST clauses before you advance your mind to the
next statement. Hmm.
You seem to like a /lot/ of context markers for line-of-flow-control. I
think that's somwhat misguided. Perl already has a fair number of
out-of-line control semantics. DESTROY, overloaded operators, and other
CAPITAL subs come to mind. Moreover, I see no need to declare at the
beginning, middle, and end of a block that there's some exception
handling/out of order code going on. If you want to understand a block of
code, reading everything textualy within the curley braces should be a
_minimum_, in which case, the word POST is plenty.
Also, I think that the syntax of exception processing should be minimial,
not only because I'll use it more if it's an extra 5 keystrokes instead of
an extra 15, but because the important things should stand out more --
that's why we support both leading and trailing ifs.
- It does solve the dual free problem. Where RFC 88 says:
try { my $p = P-new; my $q = Q-new; ... }
finally { $p and $p-Done; }
finally { $q and $q-Done; }
the proposed method could say:
my $p = P-new; POST { $p-Done; };
my $q = Q-new; POST { $q-Done; };
I like this MUCH better. Even better (IMHO) would be:
my $p = P-new; POST: $p-Done;
my $q = Q-new; POST: $q-Done;
That only gets rid of one char (the ; after the -Done;s is already optional
as the last statement in a block), but it looks much less crowded to me.
I'd get rid of the caps on POST if I could, but that would be breaking
tradition for naming magical things.
On the other hand, there is no easy way to specify the order
in which $p-Done and $q-Done are invoked, independent of
the order in which $p and $q are constructed. Hmm.
You could always say:
my $p = new P;
my $q;
try {$q = new Q};
POST: $q-Done;
POST: $p-Done;
A little on the messy side, but workable.
- The semantics aren't quite the same as "try"
TMTWTDI.
You could even have
{
my $a = new A; POST: $a-Done;
...;
} catch { f() } finaly { g() };
(In which case, we go with order-encountered: first the POST, then the catch
(if approps), then the finaly. (I don't think there should be a try keyword
neccessary at the top. (Though if present, it should be a warning not to
have any danglers on the end of the block.))
- If the contents of a POST block raises an exception, how
does it affect other POST blocks?
I'd like to poist this rule:
Each POST block is independent. If one raises an exception, it has no
effect on the others (including the value of @@). This is equivlent to
saying that each POST block has an implicit eval {}.
If you want to do somthing if a POST {} block throws, use POSTs inside the
POST, or any of the other try {} catch {} finaly {} things.
In the example above, if $p-Done throws, then $q-Done should
be called, *and* vice versa, *and* unwinding should propagate if
either one threw (or anything else did for that matter, unless
it was caught without the catching throwing).
I don't follow you, neccessarly. Is that what I just said? I'm a little
bit behind in the jargon.
- What about CATCH blocks (what RFC 88 calls "catch" and RFC 119
calls "except")? What exactly is the interaction between these
dynamic POST and CATCH blocks? We will need a detailed semantics,
along the lines of
http://www.avrasoft.com/perl6/rfc88.htm#Unwinding_Semantics
I'd go with a textual FIFO for danglers (what you have proposed, if I read
it correctly, then a LIFO on the in-body ones in order encountered.
BTW, when I say order encountered what I mean is that for this:
for (1, 2) {
POST {print "2\n"} if ($_ == 2);
POST {print "1\n"} if ($_ == 1);
print "$_\n";
}
Will output:
1
2
2
1
because we hit the 1 POST block in order-of-execution first, even though it
was second in textual order.
- What about conditional CATCH blocks? What syntax can we
use that interacts reasonably well with the rest of Perl?
Hm? POST { if (cond) { somthing } }.
CATCH is just shorthand.
- What's the return value? With RFC 88 you can say:
The return value is undef (or empty-list) until you hit a return statement.
If the code dies before returning, then it stays undef/() unless somthing
run after that (IE a CATCH/POST/catch/finaly/whathaveyou) returns. (And if
it does, that blocks all execption processing.)
You can mess with the return arbitrarly if we support return-stack visiblity.
-=- James
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
On Mon, Feb 12, 2001 at 05:33:05PM -0500, Dan Sugalski wrote:
package foo;
use attrs qw(cleanup_sub);
would be nice, but I don't know that he'll go for it. (Though it's the only
way I can think of to avoid AUTOLOAD being considered a potential destructor)
Fiat?
It's pretty hard (for me) to think of when you'd want an AUTOLOADed DESTROY,
since if you create /any/ objects of the class, DESTROY will be called.
"It isn't possible to AUTOLOAD DESTROY." --perlmem(6)
-=- James Mastros
--
"All I really want is somebody to curl up with and pretend the world is a
safe place."
AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Auto-install (was autoloaded...)
You should probably also take a look a Debian's packaging, the .deb.
It consists of an ar archive containing three files: one for the magic
(named debian-binary, containing "2.0"), one for the filesystem image
(filesystem.tar.gz)
On Fri, Feb 09, 2001 at 06:17:34PM -0200, Branden wrote:
| Platform independent | Yes | Yes | Yes |
Yes.
| Available in a wide | Yes | No | Yes |
| range of platforms | | (Win32 +/-, | |
| | | MacOS, VMS) | |
No -- only debian, but that includes several HW archs, and both linux and
the hurd. But source should be portable and abstracted decently.
| Allow platform | Yes | Yes | No |
| dependent deployment | | | |
Yes.
| Supports binary, | Yes | Yes | No |
| source and bytecode | | | (source?) |
Yes. Source format is .dsc (metadata) + .tar.gz (upstream) + .patch.gz
(debian patches). Keeping that would allow for many CPAN packages to be
used unmodified. Not keeping it would allow for single-file distribution.
| Install archive | Yes | Yes | No |
| automatically| | | (manually) |
Yes.
| Uninstall and| Yes | Yes | No |
| upgrade archive | | | |
Yes.
| Install, uninstall | No | Yes | No |
| and upgrade scripts | (possibly) | | |
Yes.
| Run from archive | Yes | No | Yes |
No, but certianly possible. (Replace the .tar.gz files with .zips. Worse
compression but easyer to use individual files. We could do .bz2.tar or
somesuch, but that's nastyer for others to deal with.)
| Resources| Yes | Yes | Yes |
Yes, I think. (Not certian what you mean by this.)
| Documentation| Yes | Yes | No |
Yes.
| Supports various | Yes | No | Yes |
| modules per archive | |(yes)| (packages) |
No (one file, one package). This could easily be changed, though.
| Merge many archives | Yes | No | Yes |
| in one | | | |
No, but wouldn't be hard with small extention.
| Usable with external | Yes | No | Yes |
| tools (e.g. WinZip) | | | |
Yes, with a little pain (ar archive + .tar.gz files).
| Dependencies of | Yes | Yes | No |
| the archive | (included) | | |
Yes. Complex dependencies supported (versions between A and B), and
support for autogeneration of dependencies in many cases.
| Build archive from | Yes | Yes | No |
| source tree | | (external) | |
Yes.
| Could be bundled | Yes | Probably | Maybe (if |
| with Perl 6? | | No | we bundle |
| | | (too big) | a JVM too) |
Yes. (I think.) (Binary of format-handling program is 110,288 -- a bit on
the big side, but not too bad.)
| Signed archives | No | No | Yes |
No. (Source packages are signed, though.) (At present, feature is planned
for future, and shouldn't be all that hard.)
-=- James Mastros
--
"All I really want is somebody to curl up with and pretend the world is a
safe place."
AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: assign to magic name-of-function variable instead of return
On Mon, Feb 05, 2001 at 08:56:05AM -0200, Branden wrote:
I don't really see what this buys us. First, `return' already handles it,
and it finishes sub execution. How would it be handled with that? `foo = 42;
last;'? I think `return 42;' is better...
That's the thing. return and setting the fname var have different primary
applications. For a function where you compute a value and return it,
"return" is wonderful. OTOH, for functions that look more like {startup;
compute; teardown}, magic-varable is nice. Think of the functions where you
have a varable named $ret or somesuch, and you compute it, have another few
lines or few screens of code, and then say "return $ret". I don't write
many of those, but sometimes they're nice.
And `return' handles scalar/list
context, mainly because it isn't a special variable, it is a statement. IMO,
`return' is perfect for the job, since it combines the familiarity of
passing a list as parameter to a statement, what is done in all practically
all Perl statements, and has no problem with context to return a scalar or a
list from a sub.
Yep. That's the rub. It doesn't "feel" like a statement, it "feels" like
an assignment. But we still want it to have many of the nice properties of
a statement, like having list and scalar contexts. A good solution to this
I have not; the best I can offer is two magic values, $^R and @^R. And, as
sombodyoranother pointed out, @^R can't be a real array, only a list. (I
don't think that will be a problem, though.)
[stuff about manual vs. automatic return-stack elminition]
Yeah, you're probably right. But return-as-assignment has certian nice
features from a stylistic viewpoint as well as an optimizational one.
-=- James Mastros
--
"My country 'tis of thee, of y'all i'm rappin'! Lan where my brothers
fought, land where our King was shot -- from every building top, let freedom
happen!"
-=- Monique, Sinfest[.net]
AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: assign to magic name-of-function variable instead of return
On Mon, Feb 05, 2001 at 11:39:47AM +0100, Bart Lateur wrote:
I wish this could be
extended to doing recursive calls without having to say the subs own
name, again.
Here's an idea. I think this has probably been discused before, but perhaps
not.
1) caller's return should be callable as a sub (IE have it's {} operator
overloaded), to call your caller.
2) caller(-1), should return your own information. (If it doesn't already
return somthing. Which I don't think it does.
3) Passing caller() a version-vector should be able to retrive information
on scopes that caller doesn't (IE any scope not a do, require, eval, or
sub-call.)
-=- James Mastros
--
"My country 'tis of thee, of y'all i'm rappin'! Lan where my brothers
fought, land where our King was shot -- from every building top, let freedom
happen!"
-=- Monique, Sinfest[.net]
AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: assign to magic name-of-function variable instead of return
On Sun, Feb 04, 2001 at 05:30:59PM +0100, Johan Vromans wrote:
James Mastros [EMAIL PROTECTED] writes:
And I always hated that about VB and Pascal -- you can assign to the magic
variable, but can't modify it.
That was before the invention of auto-assignment operators. In the
70s, Burroughs Extended Algol did it this way. So it would be
perfectly okay to write
sub foo {
foo = ...;
...;
foo += 5;
}
Right, but you can't do
sub foo {
foo = ...;
...;
if (foo == 42) {
foo=12;
}
}
Mind you, I'm not saying that it's a Bad Thing to offer it, I'm just saying
that /I/ wouldn't use it. TWMWTDI, though.
The $__ option seems a lot better to me, because there's no syntatical
reason against self-reference. ($^R for return might be a better name --
unless we've already used that for somthing else. Nope.)
Oh, here's an idea WRT extending the concept to cover both scalar and list
assignment: Have $^R be the return in scalar context, and @^R be the return
in list context. If @^R is unset, then a one-element list of $^R is returned.
-=- James Mastros
--
"My country 'tis of thee, of y'all i'm rappin'! Lan where my brothers
fought, land where our King was shot -- from every building top, let freedom
happen!"
-=- Monique, Sinfest[.net]
AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Really auto autoloaded modules
On Fri, Feb 02, 2001 at 01:17:35PM -0600, Jarkko Hietaniemi wrote: What I think is needed is some sort of opaque tag: the name of the 'contract' the API claims to fulfill. The name can be the name of the standard, the name of the company, the name of the individual. (Java does a very similar thing but they propose embedding the DNS name as part of the package name: I think they the right idea but the proposed implementation sucks.) Well, what you're looking for is a universaly unique identifier. Our current way for doing that is with a module name and a version number. That's nice and reasonable, but relies on two different modules not having the same name. That's not neccessarily a reasonable assumption. Sun's method takes some existing universaly unique thingy (domain names), then assumes that the unit identified (the domain name) can orgnize itself past that point. This might not be true of, say, the customers of an ISP. MS's method relies on 512-bit constants (GUIDs, like df5e0ce6-4def-4d6d-a47c-7d00cfffe1ae), which are chosen to have a low probablity of repitition (they incorporate the time and the MAC address of the network card, and some other random stuff). I think the current method is probably best for us. -=- James Mastros -- "My country 'tis of thee, of y'all i'm rappin'! Lan where my brothers fought, land where our King was shot -- from every building top, let freedom happen!" -=- Monique, Sinfest[.net] AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Really auto autoloaded modules
On Fri, Feb 02, 2001 at 01:47:29PM -0600, Jarkko Hietaniemi wrote:
A DNS name is assuming too much about the organizational
structure and a mile long hex digit isn't very friendly, and neither
of them is very descriptive. "XPG4 SysV IPC" would be. (I just made
that one up.)
Oh, I quite agree with your first (as quoted) sentance. I just don't see
how as "XPG4 SysV IPC" is any better then IPC::SysV::XPG4. And /neither/ of
them is good enough to be a contract name -- I'm certian that there's more
then one possible way to bind XPG4's SysV IPC scheme into perl. (And I
don't even know what XPG4 is.)
Speaking of contract names, is Damien about?
-=- James Mastros
--
"My country 'tis of thee, of y'all i'm rappin'! Lan where my brothers
fought, land where our King was shot -- from every building top, let freedom
happen!"
-=- Monique, Sinfest[.net]
AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Really auto autoloaded modules
On Fri, Feb 02, 2001 at 03:07:12PM -0600, Jarkko Hietaniemi wrote:
I'm not claiming to have solution: I claim that the com.sun.java.Gorkulator
isn't one.
Hmm. Though, perhaps, Commerce::WebCart::[EMAIL PROTECTED]::v1.0 would be.
I think the Java solution is basicly good, except for a few things:
1) Making the class name the same as the contract's name. I want to have
a sub Commerce::WebCart::checkout, not
Commerce::Webcart::{[EMAIL PROTECTED]}::v1.0::checkout.
2) Putting the uniquifying part before the meaning part. I care first if
it's about math or strings, not if it was written at a .com, a .net, or a
.mars.
3) Assuming that the entire domain name is one administrative zone.
[EMAIL PROTECTED] could have a completly different Commerce::WebCart
package.
BTW, I agree that contracts are not even a partaly ordered set, but that
doesn't mean we can't use version-vector number notation (1.2.3.4, v1.0) for
them. You should be able to use (at least) any valid identifier. And the
only rules about valid identifers are that they can't begin with certian
characters (0-9, some others I think), and that they can't contain two
consecutive colons. (or "'"s, but that's going to be thrown out, I assume).
-=- James Mastros
--
"My country 'tis of thee, of y'all i'm rappin'! Lan where my brothers
fought, land where our King was shot -- from every building top, let freedom
happen!"
-=- Monique, Sinfest[.net]
AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Why shouldn't sleep(0.5) DWIM?
On Thu, Feb 01, 2001 at 09:32:30AM +, David Grove wrote: John Porter [EMAIL PROTECTED] wrote: Simon Cozens wrote: "Perl should remain Perl" (once known as RFC 0) is bogus If you want things that *aren't* Perl, you know exactly where to find them. RFC 0 continues to be bogus, despite its repetition. Perl6 will be Perl, even though it won't be Perl5. Correct. However, the lack of that argument doesn't mean that we should arbitrarily slaughter the language. Keeping the time() function the time() function _if_possible_ while perhaps adding a millitime() function from a library or perl kernel whatsis or however it's added. I think you're both missing the point of "keep perl perl" argument: the idea is not that all perl code should transition with no changes, or even that some common idioms won't stop working. The idea is that we should not kill the fundemental soul of the language. For example, modern BASICs (like VB) have a different soul then old-school ROM BASIC. Now, in the case of basic, I think (for the most part), it's a better soul, but I like perl's soul the way it is. That doesn't mean I wouldn't like it better with a new haircut. Hell, I wish I could change my skin and hair and keep my soul. Languages are a lot more maliable then people. Changing time such that it gives its result slightly differently is not "not keeping perl perl", nor is it not keeping time time; changing time() such that it did somthing radicly different (like returning time-of-day instead) would be changing it's soul. And I don't think we should be keeping code-level compatablity just for the sake of same any more then we should be destroying it just because we can. -=- James Mastros -- "My country 'tis of thee, of y'all i'm rappin'! Lan where my brothers fought, land where our King was shot -- from every building top, let freedom happen!" -=- Monique, Sinfest[.net] AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: assign to magic name-of-function variable instead of return
On Thu, Feb 01, 2001 at 07:36:59PM -0600, David L. Nicol wrote: So a way to have the feature (direct assignment to external lvalue) and maintain portability might be to forget about magic names and just make the new LNV (which I am calling $__ in this thread) mean "An alias for the L-value of what the subroutine return value will get assigned to A /much/ better syntax, IMHO. However, $__ must act sanely when we're called as an inner function (IE foo(bar(42))). And I always hated that about VB and Pascal -- you can assign to the magic variable, but can't modify it. And if you try, you don't error, you recruse. And perl will happily recruse until you run out of memory, and VB will give a stack overflow, and take down the IDE and your code unless you're careful. -=- James Mastros -- "My country 'tis of thee, of y'all i'm rappin'! Lan where my brothers fought, land where our King was shot -- from every building top, let freedom happen!" -=- Monique, Sinfest[.net] AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Why shouldn't sleep(0.5) DWIM?
On Wed, Jan 31, 2001 at 09:53:23AM -0200, Branden wrote: Because with a better built-in that handles fractions of second (if that's ever desired, and I guess it is), time() would be deprecated and could be easily reproduced as int(now()) or anything like it. Why can't we change the meaning of time() slightly without changing to a different function name? Yes, it will silently break some existing code, but that's OK -- remember, 90% with traslation, 75% without. being in that middle 15% isn't a bad thing. -=- James Mastros -- "My country 'tis of thee, of y'all i'm rappin'! Lan where my brothers fought, land where our King was shot -- from every building top, let freedom happen!" -=- Monique, Sinfest[.net] AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Why shouldn't sleep(0.5) DWIM?
On Tue, Jan 30, 2001 at 01:07:18PM -0800, Nathan Wiger wrote:
If the internal timekeeping were changed, one thing that's apparent from
the discussions is that there would *have* to be a core way of providing
exactly what time() does currently or lots of stuff would break really
badly. Someone can certainly chime in if they see an easy way around
this, but as I recall there was little disagreement on this point.
I really and truly don't see why we can't have things dealing with a number
of seconds do the Right Thing with fractional seconds, including returning
them.
It isn't an issue that we don't have the resolution available; the functions
were, and will continue to be, best-effort. There isn't a real problem with
formatting; if you're programming in p6, you should be saying int(time) if
you don't want a period. Remember, 75% of p5 code works straight, 90% can
be translated. time - int(time) is easy to translate. And having it in
the 25% that needs to change isn't that bad. You shouldn't be using time()
to generate unique filenames becuase the time isn't unique. Splitting on a
period is probably valid in many cirucumstances, but you can deal.
You can't make an omlet without breaking a few eggs, and this is a little
one to break.
(And please, don't get into epoch discussions here. The units, accuracy,
resolution, and zeropoint of a measurement are all different questions. I
personaly would prefer to see units of seconds, a basepoint of 1/1/1970, and
resolution and accuracy best-reasonably-available.)
If you really want time() to do what it did before, you can always say:
sub time {int (CORE::time()) + epoch difference};
Indeed, a perl5::time module that does exactly that might be a Good Thing.
-=- James Mastros
--
"My country 'tis of thee, of y'all i'm rappin'! Lan where my brothers
fought, land where our King was shot -- from every building top, let freedom
happen!"
-=- Monique, Sinfest[.net]
AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: RFC 348 (v2) Regex assertions in plain Perl code
Maintainer: Bart Lateur [EMAIL PROTECTED]
Date: 28 Sep 2000
Last Modified: 1 Oct 2000
Mailing List: [EMAIL PROTECTED]
Number: 348
Version: 2
Status: Frozen
[can't find a good quote]
It'd be somwhat useful, I think, if you could return somthing like \matched
to
let paren-catching of the ?{} thingy have somthing other then "". (Remember,
a ref is always true.)
For example, that would let you parse somthing inside a regex that
requires a complicated decision only once, with only common
regexish stuff outside the regex itself.
Of course, auto-deref is evil, but you can't just use the return value, or
you couldn't return things that aren't true, but match.
Replace the old implementation of (?{...}). Optionally, throw out all
the "localizing" code. Do not set any special variables.
It'd possibly be useful if the entire regex was considered to be a scope
WRT lexicals. This lets you pass data around the regex without ugly
action at a distance (not much of a distance, anyway) without having
special rollback code -- any rollback needed either normal to local,
or it's not our job. It feels like "transactional variables" may be a
Good Thing here.
If you don't remember transactional varables, the idea is that
if the block succeeds, the variables retain their values as set in the
block,
and if the block dies, they get reset to their initial condition. The
difference
here is that the "exception" raised is when the block gets rolled back.
This requires thinking about it after the fact, which might be harder.
(but no harder then the current situation.)
Basicly, it'd be like the current local situation, but with explicit naming,
fitting in with a wider feature (just slightly different).
The new feature should:
have a zero width impact on matching in the regex
I think it would be very nice to have some sort of way of making the
bit 'o code have nonzero length. You can do that now, but it Isn't Pretty:
(?{somecodeeatingstuff; $numate=3}).{$numate}
This is fairly straightforward, but it's modifing a global varable, which is
a
Bad Thing.
The question, of course, is how to implement such a thing. An "eat" builtin
would be pretty cool, but alas, too useful a name for other things. G
either succeed of fail, depending on the returned value as a boolean
scalar: true means it's ok to continue, false means a veto, causing the
regex to immediately backtrack.
And if you die, it will abort the regex?
Sorry to bring this stuff up after freeze -- I let my perl6 mail pile up too
much.
Oh, and assuming that I'm not making some stupid mistake, and with eat and
returning a ref, here's a killer app:
/([$matchingpairs])(.*?)(?{local $_=eat 1; $_ eq ${$matchingpairs[$1]}
\$1)/
It doesn't handle nesting thingies, but it's close.
(Assumes $matchingpairs{'('}=')'..., and $matchingpairs=join '', keys
%matchingpairs.)
-=- James Mastros
Re: Attribute access
From: "Nathan Wiger" [EMAIL PROTECTED]
Sent: Friday, September 29, 2000 12:51 AM
James Mastros wrote:
As far as setting|getting, I'd like to make a simple proposal. Consider
it
an idea for whoever writes the RFC (I'm looking at you, Nate)
Oh, jeez, as if I didn't have enough already! ;-)
Well, you did rather say you did.
The idea is this: every variable should have a psudohash of attributes.
Idea is good, implementation I think should be different. Especially
since Schwern has professed "pseudohashes must die!".
Oh, sorry. By psudohash I meant a hash that doesn't really exist as a hash
of it's own, not a hash that's really an array.
my $subsline = $sub:{line};
However, overall I think this should be hidden. The internal magic of
attributes will likely not map 1:1 to hash keys, so requiring what is
essentially an accessor function for these is probably a good thing.
The internal magic I don't know, but attributes, to me, seem close
enough to hashes that throwing away all the power of hashes seems
silly and unperlish. (After all, an object is a ref, and a stack is an
array.)
Anyway, how do you do a foreach (keys attrib $scalar)?
Best of both worlds: Have attrib return a magicly lvalueable hash
(list) in one-arg form.
That way, attributes can be applied to objects, packages, subs, and
other things that don't have variable representations:
Hmm... I thought that a sub was a variable with a funny-char (with
some oddities, such as sub calling sub and giving that value, rather
then sub itself), and "An object is simply a reference that happens
to know which class it belongs to".
As to packages, I'd set the attributes on their namespace hash --
%%package::name:::{'fluffy'}++; (Three colons on the end.)
OK, that's pretty ugly, I'll admit, which is why the alternate syntax is
there.
The declaration of attrs is proposed vaguely in RFC 337. I'll add access
before the freeze.
Gah, I forgot that one.
Hmm, in 279, you propose a syntax like this:
LVALUE : ATTRIBUTE;
However, this syntax would make this:
$a[0] :32bit = get_val; # 32-bit
reasonably mean
Get the current value of $a[0], set the 32bit attribute on it,
and then replace that value with the return of the get_val
function.
This would end up making $a[0] = get_val with no attributes,
since the return of the get_val function (assumedly) has no
attributes.
-=- James Mastros
Attribute access
There are many (good) RFCs that specify new attributes. To the best of my
knowledge, there is no good RFC discussing how to go about making
attributes, setting them, and getting them.
As far as setting|getting, I'd like to make a simple proposal. Consider it
an idea for whoever writes the RFC (I'm looking at you, Nate) -- I don't
have the time to write or maintain an RFC.
The idea is this: every variable should have a psudohash of attributes.
To access the attribhash, you'd use somthing like this:
my($scalar,@array,%hash,^placeholder,sub);
my %arraysattribs = %@array:;
my $subsline = $sub:{line};
print "\%hash has the following attributes:\n";
foreach (keys %%hash:) {
print "\$\%hash:{$_} = ", $%hash:{$_}, "\n";
}
$subsattribsref = \%sub:;
This is to say, the attribhash for a varable VAR (where VAR includes the
funny-character is the hash VAR:. (You can use any expression with a valid
result for VAR.)
In 5.6, Cmy $foo: = "42\n"; has the same effect as Cmy $foo = "42\n";,
and Cprint $foo:; is a syntax error.
You need to keep the funnychar of the attributed thingy somewhere in the
attribhash syntax, since otherwise $foo's attribues aren't seperable from
@foo's.
The reason you want an attribute hash is fairly obvious, I think.
An operator with rvalue and lvalue semantics is also possible:
%foosattribs = attribs @foo;
%foosattribs{private}++;
However, I can't see how you could set an attribue on a value without making
a temporary.
Variable names containing a : that isn't part of a :: would be reserved.
(That, or the bare colon is an operator returning a hash (not a list).)
You can also set an attribute like this:
my $foo :private;
This is equivlent to:
my $foo;
$$foo:{private} = 1;
my $foo :private(1);
is equivlent to
my $foo;
$$foo:{private} = [1];
my $foo;
means that
exists($$foo:{private}) is false.
You can put an attribute in anything that can be used as a variable:
Whole arrays.
Whole hashes.
Scalars.
Array elements.
Filehandles
[Globs].
Subs.
Hash values.
Hash key-value pairs? This probably makes sense iff hash keys become full
scalars and not strings that act like scalars sometimes. It would be
useful, though.
Note the last one especialy.
$$hash{elem}:{raccess}++;
$hash{elem} = 42;
exists $$hash{elem}:{raccess}; #is false.
This is because %$hash{elem}: sets the attribute on the value of
$hash{elem}, not on the spot in the hash.
I don't know what a good syntax for the hash position would be. And I've
got other work to do now.
-=- James Mastros
Creating attributes:
--
-BEGIN GEEK CODE BLOCK-
Version: 3.1
GUCS d--- s-:- a20 C++ UL+++@ P L++@ E-() N o? K? w@ M-- !V
PS++ PE Y+ PGP(-) t++@ 5+ X+++ R+ tv+ b+++ DI+ D+ G e++ h! r- y?
--END GEEK CODE BLOCK--
Re: RFC 185 (v3) Thread Programming Model
On Wed, Sep 27, 2000 at 05:29:22AM -, Perl6 RFC Librarian wrote:
$ok = try $scalar;
$ok = try @array
$ok = try %hash;
$ok = try sub;
I'd like to see a more specific name for these. 'try' is too useful a word
for core to gobble it up for everything (IMHO). attempt_lock? Or simply
put these in a module and not export try by default. (Also, try might get
used for exceptions -- or would at least confuse people who expect it to be.)
Also, it'd be nice if an implicit join was done if a Thread was used in a
stringifying or numifying context. That way, you could treat it as a
function call that ran until it was acatualy needed, as in $factorial27 =
async{factorial(27)}, and somewhere later in your program, did a computation
involving it. At that point, $factorial27 would be forced to take a value
(to whit, 27!), and would no longer be a Thread. OTOH, this is broken wrt
things not returning numbers or strings (IE lists or refs), and makes
numifying/stringifying a mutator, which is probably a Bad Thing.
However, it seems amazingly useful. Hm, I think it could be done easily
enough as a wrapper class.
Sorry I didn't get these in on v2; I don't follow the perl6-language* lists
as well as I probably should. Too much trafic, to little time.
-=- James Mastros
--
-BEGIN GEEK CODE BLOCK-
Version: 3.1
GUCS d--- s-:- a20 C++ UL+++@ P L++@ E-() N o? K? w@ M-- !V
PS++ PE Y+ PGP(-) t++@ 5+ X+++ R+ tv+ b+++ DI+ D+ G e++ h! r- y?
--END GEEK CODE BLOCK--
Re: RFC 288 (v2) First-Class CGI Support
On Wed, Sep 27, 2000 at 07:36:42AM -, Perl6 RFC Librarian wrote:
Tainting should be able to be turned off, as Tom recommends,
but only if the user turns on the "absolutely, positively,
do NOT turn on taint mode" switch.
I can see it now -- Cno taint 'really';. Really, I don't see why we can't
just have a 'use taint' and 'no taint' pargma. You have to turn on tainting
at the commandline, but other then that, you can turn it on and off (even
Cuse taint 'warning', possibly) at runtime. Doing so is probably not a
good idea in the vast majority of cases, but should still be supported.
Perl should have a safety on its guns, but shouldn't prevent you from
shooting yourself in the foot if you really want to. Otherwise, perl would
be another BD language.
In specific, I can see a suid script dropping permissions, and then doing a
'no taint' so it can run freely in the end-user's account. Think
cgi_wrapper without spawning a new interpreter.
-=- James Mastros
--
-BEGIN GEEK CODE BLOCK-
Version: 3.1
GUCS d--- s-:- a20 C++ UL+++@ P L++@ E-() N o? K? w@ M-- !V
PS++ PE Y+ PGP(-) t++@ 5+ X+++ R+ tv+ b+++ DI+ D+ G e++ h! r- y?
--END GEEK CODE BLOCK--
Re: RFC 288 (v2) First-Class CGI Support
From: "Dan Sugalski" [EMAIL PROTECTED] To: "Nathan Wiger" [EMAIL PROTECTED] Sent: Wednesday, September 27, 2000 4:08 PM 'no taint' and 'use taint' shouldn't affect whether data is tainted--the rules for that should stay in effect. What they should alter instead is perl's response to tainted data while they're in effect. In a 'use taint' block perl should check, while in a 'no taint' block it shouldn't. Couldn't have said it better myself. And god knows I've tried. G It might be nice if the result of a calculation was never tainted when the calculation was in a 'no taint' block. That does make rather a lot of sense, though it's arguable whether it's a good idea if you don't know what you're doing. That's never been perl's problem, though... :) I think that 'no taint' should solicit a warning. (default warning set) It should warn sepperately if uid=0 or gid=0 when you 'no taint'. (default warning set) It should fail if you 'no taint' when uid=0 or gid=0 with 'use strict "taint"'. (in default strict set?) Hm, this behavor would be equivlent to making "unsafe" errors normal: 'no strict "taint"' == 'no taint' 'use strict "taint"' == 'use taint' 'use warnings "taint"' == 'use taint warnings' (You'd have to put the warnings/errors about 'no taint' in the 'notaint' set.) -=- James Mastros
Re: RFC 292 (v1) Extensions to the perl debugger
On Mon, Sep 25, 2000 at 07:34:04PM -, Perl6 RFC Librarian wrote:
Mailing List: [EMAIL PROTECTED]
Most of this RFC would probably be better off in perl6-stdlib; the debugger
isn't really part of the language. That being said, however...
The ability to easily retrieve and edit your N most recent commands to the
debugger (much like a bash_history).
Dosn't the default debugger do this if you've got ReadLine?
A better default pager.
I think it would be better for this to be a nonperl thing (possibly written
in perl, but not a part of the debugger proper).
The ability to provide a function name (preferably just the first unique
section of its name) and
You can do the unique prefix part by looking in the symbol table.
jump to where that function is defined,
This, I think, would be a quite useful and simple thing to acatualy put in
the language. Just have two implicit attributes on a sub: :line and :file,
that recive the value of __LINE__ and __FILE__ at the sub {} statement.
Note that the AutoLoader and such things that use evals to define subs would
probably want to change these attributes -- otherwise they'd probably get
the location of the AUTOLOADER sub and not where the sub being autoloaded
was acatualy written.
Most of the rest would require siginificant overhead on all programs that
might get debugged (the debugger is a module; you don't necessarly have to
start it from the commandline). Use a tags program. G
-=- James Mastros
--
-BEGIN GEEK CODE BLOCK-
Version: 3.1
GUCS d--- s-:- a20 C++ UL+++@ P L++@ E-() N o? K? w@ M-- !V
PS++ PE Y+ PGP(-) t++@ 5+ X+++ R+ tv+ b+++ DI+ D+ G e++ h! r- y?
--END GEEK CODE BLOCK--
Re: RFC 185 (v1) Thread Programming Model
$thread = new Thread \func , @args;
$thread = new Thread sub { ... }, @args;
async { ... };
$result = join $thread;
critical { ... }; # one thread at a time in this block
=item Casync BLOCK
Executes BLOCK in a separate thread. Syntactically, Casync BLOCK
works like Cdo BLOCK. In particular, it does not return a CThread
object. If you want the thread object, use one of the Cnew CThread
forms shown above.
Ooh! Ooh! Call on me! Call on me!
The async BLOCK won't know it's value for quite some time. This means that
it's a semi-lazy expression generator...
So,
$bignum = do {factorial(1024)}; # is equivlent to just plain
factorial(1024);
will compute $bignum now, ignoring the rest of the code on the thread until
we're done.
$bignum = async {factorial(1024)};
will work on computing $bignum while still executing code, and block on use
of $bignum if we aren't finished yet (or just make those expressions
semi-lazy on this one?)
$bignum = lazy {factorial(1024)}; # should be lazy factorial(1024)?
won't work on computing $bignum until we use it.
=head2 Critical section
Ccritical is a new keyword. Syntactically, it works like Cdo.
critical { ... };
The interpreter guarantees that only one thread at a time can execute
a Ccritical block.
You should specify that a critical block is temprorly like a do {} block
too -- the inner BLOCK is completely run before any code after it.
=head2 Event
Events have two states: Iset and Ireset. Threads Iwait on an
event; the Cwait call blocks until the event is set.
Might I suggest that things will be cleaner if events have the states
"signaled" and "unsignaled", rather then set and reset? For one thing,
reset implies that it was previously set, and thereby implies that "set" is
the default. Secondly, that way their signaled state works is obvious.
=item I$ok = wait_all(@objects)
Blocks until all of the synchronization I@objects are signaled.
Cwait_all does not change the state of any object until all the
objects are signaled. This prevents deadlock, at least between
competing wait functions.
Returns true on success, false on error. An error occurs if an element
of I@objects is not a synchronization object.
=head2 Mutexes
I dropped the lock($scalar) call from this interface in favor of
Mutexes. The two features provide roughly the same functionality,
so this is partly a matter style. One possible reason to prefer
mutexes is to simplify implementation of Cwait_all and
Cwait_one.
On the other hand, a lock($scalar) would provide for an easy way to
automaticly release your mutexes. Thus, I suggest another primitive:
critical $lock BLOCK, which runs BLOCK with $lock held (with held being
defined as approprate for the $lock).
=head2 Cdie
I dropped the I$thread-Ceval call from this interface, and didn't
say what happens if a thread Cdies. There are several possibilities
The exception is propagated to any thread that Cjoins it.
The interpreter prints C$@ on stderr and exits.
The thread just quietly goes away.
First off, I think that this is probably best left to the error handling
RFCs and not this one.
That said, however...
I think that the try stack should unwind all the way through the new Thread
call -- that is, that the catches for the block that the thread was started
in should be the ones in question.
If the thread has been join()d, however, we need to do somthing about them.
I'd say that the join() should die in the same way that the thread did; the
reason that join() is named like it is is that you're "joining" the thread
back into the "tapestry" of the program, so the join()d point should behaive
like the original function did.
-=- James Mastros
Re: RFC: Automatic accessors for hash-based objects
On Sat, Aug 26, 2000 at 08:24:19PM -0500, Dave Rolsky wrote:
This is an interesting idea. I would think that ideally it would be
combined with pre-declared limited keyspace hashes (which we currently
have in a semi-crippled way with pseudohashes).
This seems like a fairly orthagonal thing -- this is useful without that,
and that is useful without this. It deserves an RFC of it's own (or with
other constant stuff -- take a look at RFC #83. Suggestions on this point
would be highly useful -- they should go on perl6-language, though.
I'd much prefer that
these declarations happen outside the contructor, more like this maybe.
Also I really dislike 'rw' and such. Let's be a little clearer:
And this way we could drop the whole :accessible thing. How about this:
use fields qw(
name :read :write
age :read :write
peers :read :write
birth_date :read
);
I really dislike this. It takes moves this functionality from comple-time
to runtime, which is where I think it belongs. Why, you ask? Memonization.
You should be able to create (and destroy!) autoaccessed hash keys at
runtime. If you want to create constant autoaccessed keys at compile time
to take advantage of consant-floding (which could make this blazingly fast
without changing the users' synthax _at_ _all_), then that's wonderful for
you, create the hash inside of a BEGIN {} block.
This synthax confuses hashes with constant keys with autoaccessed keys,
which are unrelated except insomuch as they're often useful together.
use fields qw(
name :read = \name :write = \name
age :read = \get_age :write = \set_age
);
Once you do that, you've lost the whole point -- you shouldn't even have to
make a function call. Once you want to do a function call, just do it the
existing way, and ignore the autoaccessor functionality entirely.
Note that doing gets with the autoaccessor and puts with a normal function
is probably quite useful -- you normaly want to do the processing on the put
in accessor methods, and just return the value on a get.
OTOH, there are properties that it only makes sense to get and not to set,
where you'd want a :accessable('r!w') to forbid setting completely, and
precompute the value when relateds change (say, day of week).
--
-BEGIN GEEK CODE BLOCK-
Version: 3.1
GUCS d--- s-:- a20 C++ UL+++@ P L++@ E-() N o? K? w@ M-- !V
PS++ PE Y+ PGP(-) t++@ 5+ X+++ R+ tv+ b+++ DI+ D+ G e++ h! r- y?
--END GEEK CODE BLOCK--
Re: Extended Regexs
On Fri, Aug 18, 2000 at 08:46:17PM +0100, Richard Proctor wrote: There is one significant area of perl that has very little attention here (other than one of my RFCs) that is regexs. Perl has very powerfull regexs - but what other features might be desirable? Well, one thing that has acatualy come up (on -language-io, BCCed) is less powerful regexes. Specificly, making an additional /f modifer that told the compiler to use a faster DFA matcher instead of the default super-powerful, but slow one. (/d for DFA has been proposed, but I rather like f for Finite and Fast.) The DFA engine's language would be a proper subset of the full regex engine's, and at least version 8 regular expressions: character classes, alternitivies, grouping parens (not certian about capturing parens, def no backreferencing). The idea is that putting a /f on should (almost) always increase speed, but won't allow as much expressiveness. -=- James Mastros -- -BEGIN GEEK CODE BLOCK- Version: 3.1 GUCS d--- s-:- a20 C++ UL+++@ P L++@ E-() N o? K? w@ M-- !V PS++ PE Y+ PGP(-) t++@ 5+ X+++ R+ tv+ b+++ DI+ D+ G e++ h! r- y? --END GEEK CODE BLOCK--
Re: Extended Regexs
On Sat, Aug 19, 2000 at 07:57:34AM +1000, Jeremy Howard wrote: The choice of algorithms is a great idea, but why do we need a modifier? Isn't it a pretty straightforward set of rules that allow us to decide if a DFA matcher will work? clintonWell, that all depends what the meaning of the word work is./clinton Specificly, there may be cases where the normal matcher will return different results then the DFA matcher, but we wanted the DFA one anyway. Also, using the /f modifier promisses things about interpolated scalars, which can't be determinied by the compiler. -- -BEGIN GEEK CODE BLOCK- Version: 3.1 GUCS d--- s-:- a20 C++ UL+++@ P L++@ E-() N o? K? w@ M-- !V PS++ PE Y+ PGP(-) t++@ 5+ X+++ R+ tv+ b+++ DI+ D+ G e++ h! r- y? --END GEEK CODE BLOCK--
Re: Make lvalue subs the default (was Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument)
- Original Message -
From: "Jonathan Scott Duff" [EMAIL PROTECTED]
Sent: Wednesday, August 16, 2000 10:00 AM
Subject: Re: Make lvalue subs the default (was Re: RFC 107 (v1) lvalue subs
should receive the rvalue as an argument)
On Wed, Aug 16, 2000 at 12:14:09AM -0700, Nathan Wiger wrote:
No problem. In fact, this fits under your rules. HOWEVER, it also
assumes that Lincoln thought that param() was :lvalue-worthy. What if he
forgot? Or didn't think of this case?
Then you email him with a patch, and your reasons why your lvalue
patch should be applied.
Or, if you prefer, patch your local copy without emailing Lincon. Or do an
attributes(CGI::param) |= :lvalue; (assuming synthax that hasn't been
RFCed, but...)
However, I think that this can all be solved fairly simply, by intergrating
it with the other problem: that functions wouldn't be able to tell the
diference between their lvalue and rvalue values.
Now, I rather like Buddha Buck's solution, of making the lvalue attribute
take the variable name the rvalue should be passed in. However, for those
still of the mind that all subs should be lvalueable, might I propose that a
sub foo, called as foo(@a) = @b gets its @_ as @a,@b, as proposed in the
RFC, with the twist that the elements of @b are passed with a :rvalue
attribute, so that foo can care if it wants to, but if it doesn't, the
lvalue call will "simply work" without any further ado. Note also that this
means that :no_lvalue can be written in pure perl.
-=- James Mastros
Re: errors and their keywords and where catch can return to and stuff like that
From: "Peter Scott" [EMAIL PROTECTED]
Sent: Sunday, August 13, 2000 10:35 PM
try {
# fragile code which doesn't call any subroutines that might die
# and doesn't include any other try blocks
} catch {
# No code at all
}
Well, I don't really like that solution. It's exactly the same situation as
use strict / use warnings, BTW. I don't much like that either, but... In
any case, there we have exactly the situation we're speaking about (well, in
warnings, anyway) -- a heirichy of exceptions.
Therefore, I think we want some generic mechinisim to say what the behavor
of an uncaught exception is.
My proposal is:
$Exception::whatever::onuncaught = CODEREF.
Yes, this is a global. It has to be; the definition of when/how this gets
called is that if the unwind stack goes all the way /past/ the root of the
code, this code ref gets called. The only parameter is the exception. The
defalut would be sub {die shift;} (for "obviously" fatal things), which
would make the program exit with a fatal exception. Other normal choices
would be undef, ignore it (non-defualt warnings, like bareword), and sub
{warn shift;}, print out a warning message (default warnings, like... I
can't think of any).
The value of onuncaught should follow isa if it doesn't exist.
-=- James Mastros
Re: RFC 83 (v1) Make constants look like variables
nitpickyA semantic definition of "constant" would be nice./nitpciky I'd like to propose the following definition: A constant value cannot be assigned to, deleted, or used as the argument to a mutating function/operator. Doing any of these would be a catchable error. (However, it can be deleted by the GC, and thus may have a DESTROY method.) It cannot be local()ized, unless the "localizable" flag was given, IE my $foo = 42 : constant(localizable); (This should be an error sepperate from "cannot localize" and "assignment to a constant".) Note that I use the word "value" and not "variable". I suggest that additionaly, in a hash if a key is constant, it means that the key cannot be deleted, but it's value can be changed. To make the whole pair constant, set the value to be a constant -- removing the key would imply deleting the value as well, which is an error. A hash being constant, or a list being constant implies that all of it's members are constant. A ref to a thingy being constant is different from a ref to a constant thingy. The constant attribute can never be removed from a variable once it is set. The localizable flag cannot be added later, but can be removed. There may be other flags in the future; their addablity/removeablility is not defined. The constant attribute is rather odd in that normaly, somthing of the form "my $foo = 42 : attrib" creates $foo, sets it's "attrib" attribute, and then assigns 42 to it. OTOH, the constant attribute is set after the assignment -- otherwise the assignment would always be in error! -=- James Mastros
Re: Infinite lists (was Re: RFC 24 (v1) Semi-finite (lazy) lists)
Tangentialy, can I suggest that a nicer synthax might be -Inf..-1 / 1..Inf, etc. Assuming that we end up supporting full IEEE floats, this becomes the "obvious" synthax, and I find C(-Inf..Inf) to be far more clear then C(..). We've got plenty of puncuation already, thank you very much. Also, can someone please suggest a reasonable implementation of (-Inf...-1)? If not, can I suggest that we require that if one of the arguments to (list) .. s +/-infinity, it be the second one, and additionaly say that a..b is the list , a+1, a+2, ... b if ba, and a, a-1, a-2, ... b if ab. This would allow the full expressiveness of both (-inf..0) and (0..inf) without ever having an infinite starting point to a list. (If a..b where a==b, then we get the list containing only a.) In any case, (-inf...-1) would "obviously" either: begin with the smallest negitive integer representable, or begin with the IEEE -inf. If it begins with the IEEE -inf, then it has to continue with an infinite number of -infs, since -inf+1=-inf (a rule of IEEE arithmitic). Ergo, it is useless to begin at -inf unless perl6 becomes _very_ good at finding out what you "really" meant. OTOH, having it begin with the smallest non-(negitive)infinite value means that it becomes non-infinite, IE scalar((-inf..0)) != inf. This is obviously a Bad Thing. Also, if bignums are intergrated (as has been proposed), then there is no smallest representable integer. (This assumes that the float synthax will be extended to include "NaN" and "Inf" as valid floating-point numbers. (This does take away from non-reserved namespace.) Has this been proposed yet?) -=- James Mastros, In slightly over his head.
