Re: Some PDL issues (was Re: Test)
At 12:38 PM 8/25/00 -0600, Nathan Torkington wrote: Dan Sugalski writes: The operative word in that last sentence is "Currently"... The problem is that you can tie() an array, but an object is a scalar. Also, there are many array operations (push, pop, etc) still not supported by tie. tie makes assumptions about arrays that are perhaps not valid with pdls. Tie will have a more comprehensive implementation in perl 6, I expect. And it may not be the method used to do this magic. (variable vtable functions should be writable in perl) Yes, but you're handwaving. If we don't come up with a way to address these issues by saying "this is what we want to be possible, this is how it might be done", this list will just spin and talk and discuss and debate without any idea of when it's done. Sure, it's handwaving, but it's handwaving with a purpose. What I don't want is for people to get bogged down by the limits of what perl 5 provides, or what looks to be some sort of reasonable extrapolation of those features. If a fully working tie's what you need, then ask for it. If full overloading on non-objects is what you need, then ask for it. If making objects look like non-objects is what you need, then ask for it. Basically if you want to be able to say: my Matrix @foo, @bar, @baz : bounds(5,5,5); # init foo and bar here @baz = @foo * @bar; to make foo and bar 5x5x5 matricies that you casn multiply to get baz then, well, say it. If that means you need to define a way to provide overridden operators in the Matrix package, then go for it and say that. Let the -internals folks worry about the Weird Magic needed to implement what you want. (This is a variation of my standard "Don't get hung up on the implementation, that's my job" speech) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Some PDL issues (was Re: Test)
At 01:11 PM 8/25/00 -0600, Nathan Torkington wrote: Heh, we're on the same page here. I'm just setting the framework for that discussion. I don't think the PDL folks yet know what they want, other than "better support for numerical structures". I'm trying to see what's wrong with the existing systems so that we can either fix them or replace them. Walking before we run, etc. Gotcha. Different approaches and all, I expect. I tend to figure out what I want and then try and shoehorn it into what I already have. :) It looks like we need to be able to override operations on arrays, have multi-dimensional arrays, and do some rather odd slicing operations that give values still linked to the original matrices. Has anyone asked for complex number support yet? Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: multidim. containers
At 10:28 AM 8/28/00 +1000, Jeremy Howard wrote: X-posted to [EMAIL PROTECTED] David L. Nicol wrote: If arrays as we know them implement by using a key space restricted to integers, I think a reasonable way to get matrices would be to open up their key space to lists of integers. I've been thinking along exactly the same lines. There's a lot of language issues to consider to get this to work consistently, such as interaction with reduce(), notation for slices across a dimension (and generalised slices such as diagonals), and so forth. I'm thinking that a n-dim array could just be a list of lists (of lists of lists of...) with the n-dim notation just being syntactic sugar (and perhaps helping with optimisation too). If you want efficiency, n-dimensional arrays really need to be a concrete data type all of their own. That way one big block of memory can be allocated and, if it's a typed array, properly sized. That doesn't mean that n-dimensional arrays won't be just sugar over the standard list-o-list structure to start, but they won't have to stay that way. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: New variable type: matrix
At 12:42 PM 8/29/00 -0400, Karl Glazebrook wrote:
Dan Sugalski wrote:
At 12:28 PM 8/29/00 -0400, Karl Glazebrook wrote:
But scalars are not compact.
Since scalars are singular things, how would you compact them anyway?
If I say $a = ones(float,10,10) in PDL then each element of $a
is a 4 byte floating point number.
I presume in PDL that gets you a 10x10 matrix of floats? In that case
you're not getting a scalar back, you're getting a matrix. That it needs to
be represented as an object is an indication of one of perl 5's
limitations. (And then the compactness would be something the object
applies to whatever data structure it builds
This is not a perl scalar.
Right, so the question still stands--since scalars are singular things, how
(and why?) would you compact them?
If I then say $b = $a-slice("(5),(5)") then $b is a zero-dim
piddle - not a scalar.
So then it's not relevant to the question. :)
Dan
--"it's like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Access to the perl6 parser
At 06:05 PM 8/29/00 +, Jim Edwards wrote: IMHO if the perl6 core only allow access to the parser, than a module can do just about anything including all of those things proposed in RFC 115 - 117. That's sort of on the list of things to allow (I think Damian RFC'd it) but whether it happens depends on the resulting parse speed. Hardcoded parsers seem to run faster than more dynamic, extendable ones, so it might cost too much. OTOH, parse speeds might end up being a trivial part of the total program load/compile time, so it might not matter. Regardless, you can already do this in perl 5, and will undoubtedly be able to do it in perl 6, with source filters. (If Damian can write perl that looks like Latin or Klingon, then python ought to be simple... :) Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: New variable type: matrix
At 01:47 PM 8/30/00 -0400, Karl Glazebrook wrote: If you do a plain my int @foo; it'll end up with a contiguous block of memory anyway. :compact seems to me more an attribute for sparse arrays than anything else. Uhm do you mean a contiguous block of 4 byte integers or a countiguous block of perl scalar structures? It is the former we are after. The former, at least until you do something that requires the array to hold things other than ints. Perl is supposed to, at that point, automagically upgrade the array to full scalars, or at least something that can handle the type being assigned to it. (Or so is my understanding of what Larry wants for 'shortcut types' like int, float, or str) Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 86 (v1) IPC Mailboxes for Threads and Signals
At 12:54 PM 8/11/00 -0400, Uri Guttman wrote: "DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS Nope. The code that accessses the array needs to support it. Different DS animal entirely. The ops don't actually need to know. but still that is overhead code for all arrays and not just the mailbox ones. Nope. Just for the shared ones. DS s/mailboxes/filehandles/; DS If we're talking a generic communication pipe between things, we DS should overload the filehandle. It's a nice construct that DS provides an ordered, serialized, blockable, pollable DS communications channel with well-defined behavior and a DS comfortable set of primitives to operate on it. pollable is a good thing. some mailbox designs are not pollable and some are. i like the idea of supporting polling then you can also have callbacks. but this does imply an implementation as semaphores and shared memory are not pollable. you would have to build this with pipes and filehandles. So? Inter-thread communication is almost undoubtedly not going to be built with something as heavyweight as pipes, shm, or mailboxes, so I don't see their limitations as relevant here. Regardless, don't design to the limitations of one particular implementation method. We can work around their limits if need be. overlaying it on filehandles is another question. i would like to see a single operation which does an atomic lock, block, retrieve, unlock. we don't have that for filehandles. you could use a new method on that special handle (i like 'get') which has the desired semantics. So we enhance filehandles to make reads on them atomic. does an atomic read on the filehandle. NBD. i think making mailboxes in some form is a good idea. but they should be special objects (even if they are filehandles) with their own methods to support the desired semantics. Overload filehandles. They really are a good fit for what you're looking for. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Are Perl6 threads preemptive or cooperative?
At 12:11 PM 8/28/00 -0500, David L. Nicol wrote: What if every subroutine tagged itself with a list of the globals it uses, so a calling routine would know to add those to the list of globals it wants locked? If you're looking for automagic locking of variables, you're treading deep into "Interesting Research Problem" territory (read: Solve the Halting Problem and win a prize!) if you want it to not deadlock all over the place. Been there. Tried that. Backed away *real* slowly... :) Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Stupid Newbie Question
At 04:21 PM 11/8/2001 -0800, John Rudd wrote: So, does this mean my other heart's desire of operator overloading might be coming forth? (I know, I know, here I am, a smalltalker, asking for operator overloading ... but, what are the smalltalkers gonna do, take away my membership card?) What, you mean being able to override the + function for a variable, complete with method dispatch depending on the types of the variables on both sides of the +? Yup ;) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Stupid Newbie Question
At 06:48 AM 11/9/2001 +, Piers Cawley wrote: Dan Sugalski [EMAIL PROTECTED] writes: At 04:21 PM 11/8/2001 -0800, John Rudd wrote: So, does this mean my other heart's desire of operator overloading might be coming forth? (I know, I know, here I am, a smalltalker, asking for operator overloading ... but, what are the smalltalkers gonna do, take away my membership card?) What, you mean being able to override the + function for a variable, complete with method dispatch depending on the types of the variables on both sides of the +? Yup ;) Um, you do realise you don't need multi dispatch to do operator overloading don't you? Of course. You don't *need* it, but it does make things nicer. Every so often I find myself thinking 'I should implement something that automagically turns all numbers and strings into objects', but there's always something more important to do. The multimethod dispatch'll take care of that, I think. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: What is Perl?
At 01:01 PM 8/1/00 -0400, Michael Mathews wrote: As far as Perl being an offspring of Unix I think that's great if it is in meant **in spirit**. But any opportunity for Perl6 can make things more understandable to the average programmer vs. the average Unix user should be taken advantage of. The "unlink()" example is a good one. Now that Perl is thriving on Mac and Win this sort of Unix-speak seems out-of-place. In spite of where Perl came from I don't think we should feel like we can't grow the language into something easier. Let's also not forget that Unix (or insert your favorite OS here) got some things just fundamentally wrong. (Signals anyone? :) It is, after all, software, and all software sucks by definition. Extracting out the Good Bits while tossing the Bad Bits and building an abstraction layer's not a bad thing. I'd quite like to see this happening. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: draft RFC: loop control and do
At 11:58 AM 8/1/00 -0500, Brust, Corwin wrote:
Would simple do { } blocks then also be cantidates for becoming Code Blocks?
I would hope not--I've used them in code specifically because they are
*not* control blocks, yet still get you a new level of scope.
What I'd rather see is the concept of the 'looped statement'--i.e. any
single statement that has a loop modifier on it could be lasted. So this:
last while 1;
would be a noop, but people doing Evil Things with lists and whatnot could
still last out, like so:
(foo(), bar() || die, baz() || last) while (xyzzy());
which would exit out of the looping statement as soon as baz() returned false.
You could, I suppose, separate out the lexical scoping properties of a
block from the loop control properties, so we have non-looping blocks that
define scope, or looping blocks that don't. (I'd propose characters, but I
passed on picking up the Unicode spec over lunch (didn't want to throw my
back out... ;))
Dan
--"it's like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
RE: Typeglobs, filehandles, asterisks
At 12:18 PM 8/1/00 -0500, Garrett Goebel wrote:
Personally, I like to be able to directly access the symbol table. It is
nice when generating classes from a template. I hope typeglobs go in the
washing machine instead of the bathtub. But, I don't mind it they are hard
to recognize when they come back.
Typeglobs != symbol tables.
You can access individual variable bits in the symbol table now without
using typeglobs. I don't see why that would have to change.
I'd also like to see lexicals addressed by name through some sort of symbol
table-ish thing. Maybe:
$PAD{my_var}[-1]
would give a ref to the lexical my_var that exists one level of scope out
from the current, or at least the my_var that's masked by the most recent
declaration of my_var. (So [0] is the current, [-1] the next most recent,
[-2] the one outside that, and so on)
Dan
--"it's like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Typeglobs, filehandles, asterisks
At 06:59 PM 8/1/00 +0100, Hildo Biersma wrote:
Dan Sugalski wrote:
I'd also like to see lexicals addressed by name through some sort of symbol
table-ish thing. Maybe:
$PAD{my_var}[-1]
would give a ref to the lexical my_var that exists one level of scope out
from the current, or at least the my_var that's masked by the most recent
declaration of my_var. (So [0] is the current, [-1] the next most recent,
[-2] the one outside that, and so on)
I like the idea... it's evil. (I hope it never makes it into the
language though.)
Damn straight! (And why?)
my @lexicals = keys %PAD;
would be quite nice. Folks would kill (or at least inflict really nasty
paper cuts) to have this available in the debugger.
Can you imagine doing this for 'local'? That would lead to some pretty
neat obfuscated code...
Sure. long_distance($var, -1) could give the most-recently-localized
version of $var. :-)
I'd rather not do it for globals, though. (Actually I'd be just as happy to
see local go missing entirely, but that's just me looking at the guts...)
Dan
--"it's like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
RE: Removing/fixing $[line noise here] variables
At 03:53 PM 8/1/00 -0500, Brust, Corwin wrote:
Could this then also give the programer control over the content of
error/warning messages produced by Perl at runtime?
That's feasable. It'd be a performance hit, but I can't picture this really
being a performance-critical area... :)
Put together an RFC for it. (Soon!) This is a language topic, but it will
impact internals a touch, and I'd like to get as many of the "impact
internals" things spec'd out as soon as possible. Even if the final form
differs, it's easier to modify a capability than bolt it on after. (cf
perl5 threads...)
-Original Message-
From: Steve Simmons [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 01, 2000 3:37 PM
To: Perl6 Language Changes
Subject: Removing/fixing $[line noise here] variables
For deprecation, we should have a %PERL_DEPRECATED{mod}{thing} hash as
well. `mod' is `CORE', `FORMATS', etc, as above. A value of 0 means the
function is actually gone, 1 means it's disappearing next major release,
2 mean next minor, etc. The programmer can control what happens when
the feature is used by setting a %PERL_DEPRECATED{mod}{warning} value
to 0 for default, 1 for once, 2 for never, etc, etc.
Dan
--"it's like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Typeglobs, filehandles, asterisks
At 05:19 PM 8/1/00 -0600, Tom Christiansen wrote:
Typeglobs != symbol tables.
You can access individual variable bits in the symbol table now without
using typeglobs. I don't see why that would have to change.
NB: $main::{fred} does not autoviv a typeglob when used lvaluably,
but *main::fred does.
Well, in perl 5 it doesn't, but that doesn't say anything about perl 6... :)
Dan
--"it's like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: What is Perl?
At 09:12 PM 8/1/00 -0400, Bryan C. Warnock wrote: On Tue, 01 Aug 2000, Matthew Cline wrote: Doesn't tying slow things down? If you did compile time type checking, this would take no perfromance hit. Also you could, say, add some opcodes for doing runtime checking, so that runtime checking would be faster than doing it with tying, but wouldn't bog SVs down with having to carry around too much more extra info. (At least, this is the impression I get from my limmited knowledge of Perl internals). Except perl, because it is perl, and does perlish things, always needs to do runtime checking. Removing automatic runtime checking in favor of an op indicating runtime checking will double the size of the optree, and make regular perl that much slower with everything else. I doubt it'd double the size, especially if it was smart and only inserted check opcodes where it wasn't sure they weren't needed. However, a vtable setup for scalars (now that I've got a handle on that) would reduce the cost significantly. In that case the scalar (or hash, or array, or whatever) itself would be responsible for typechecking, so the ops could just willy-nilly assign things and let the variables fend for themseles. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Don't you people sleep?!!
At 10:30 AM 8/2/00 -0400, Michael Mathews wrote: Okay, I'm impressed. 108 messages in my box this morning from the list. Shows spunk. But I'm concerned. Are you getting enough sleep? Of course not. :) Don't forget we've folks from England, North America, and Japan (that I know of, and I only know where a few folks are). That pretty much covers the whole day... Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: date interface (was Re: perl6 requirements, on bootstrap)
At 11:30 AM 8/2/00 -0400, Chaim Frenkel wrote: Since perl6 will/should have a new Configure methodology[1] there could be a registry (hate that word) of all available function calls[2], developed during the build processes. Then the core would be able to infer a 'use' command. Yes. What I'd like to have is a list of functions, prototypes, return type, calling type, shared libraries they reside in, and the C name. Whenever the lexer saw a name on the list it'd automagically mark that shared library for loading. So if the list had: localtime|$|@|op|time.so|localtime perl would know that the localtime function took a scalar, returned a list, is called like an opcode, and lives in time.so with a name of localtime. If (and only if) you used localtime, perl would load in time.so for you. In the optree (or bytecode stream or whatever) perl would have the I_cant_believe_its_not_an_opcode opcode with a pointer to the function we loaded in from time.so. This way it looks like an opcode, talks like an opcode, looks like an opcode, but isn't an opcode taking up valuable space. (Not to mention making the optimizer more complex--the fewer the opcodes the easier its likely to be) I've got an RFC started on this. The list would presumably be added to occasionally when a module is installed "NT" == Nathan Torkington [EMAIL PROTECTED] writes: NT Moving things to modules (a) does little for the size of Perl, and (b) NT promotes Pythonization of the language (i.e., all programs begin with NT 20 lines of `load this module, load that module, load the other NT module'). Your criteria for moving to a module can't simply be NT whether it's a system call or not, you must use something that takes NT into account the hindrance and the payoff. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183 Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC: On-the-fly tainting via $^T
At 11:57 PM 7/31/00 -0700, Matthew Cline wrote:
On Mon, 31 Jul 2000, Nathan Wiger wrote:
Instead, it would be really cool if Perl6 let you do this:
#! perl -T
local($^T) = 0;
$ENV{PATH} = read_config_file();
local($^T) = 1;
I would prefer something like:
#! perl -T
$ENV{PATH} = untaint( read_config_file() );
In other words, either make the 'Taint' and 'Untaint' packages part of the
standard distribution, or put them into the core language.
While a way to taint something could reasonably be part of the main
distribution (which'd be nice), I think I'd prefer to leave untainting to
regexes.
What I was thinking of was something along the lines of a lexically scoped
pragma--"use taint"/"no taint". (We could do this by sticking in an opcode
to set/unset the tainting status, as well as the warning status, and so on)
Taint checking is disabled in a no taint block. Whether we still set the
taint status on a scalar could depend on the -T switch, so data would still
be tainted in a no taint block.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: proto-rfc. Elements of @_ should be read-only.
At 08:20 AM 8/4/00 -0400, John Tobey wrote: Ken Fox [EMAIL PROTECTED] wrote: John Tobey wrote: The Perl 5 (and older) behavior may preclude some optimizations. I can't think of any optimizations @_ assignment precludes. If we don't analyze dataflow to figure out if a sub modifies its args, then we just assume it will. Suppose we use the low 2 bits as a type marker, so 30-bit ints are representable directly in the "SV*". Let's not--I really loathe that sort of thing, it can be a portability nightmare, and it's an internals thing anyway. Don't sweat the internals for this. Figure out whether its a good or bad thing based on the language merits, not the internals issues. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: proto-rfc. Elements of @_ should be read-only.
At 09:10 AM 8/4/00 -0600, Tom Christiansen wrote: At 12:47 AM 8/4/00 -0400, Ken Fox wrote: John Tobey wrote: The Perl 5 (and older) behavior may preclude some optimizations. I can't think of any optimizations @_ assignment precludes. If we don't analyze dataflow to figure out if a sub modifies its args, then we just assume it will. If we know how a sub accesses @_, we can optimize appropriately. If we don't know, odds are we're not doing the sorts of optimizations that would need the information. And to know whether you can know, there should be disqualifiers, like do FILE eval STRING fnaddr $fnname Anything that hits the lexer's problematic with the optimizer, as is anything that hits C code that's not ours, depending on what we allow it to do. (And as I'm up for extensions to do whatever the heck they want, that's pretty much anything) Indirect calls might not be a problem, depending on how much flow analysis we can do in the optimizer. While that won't be much in the on-the-fly-compile version (a 10s runtime with a 50s compile time's not a good thing...) I'm hoping the optimizer will be able to get darned aggressive when given free rein. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 18 (v1) Immediate subroutines
At 02:45 PM 8/4/00 +, Perl6 RFC Librarian wrote: =head1 TITLE Immediate subroutines This does complicate the job of the parser/lexer rather considerably. While not a reason to not do it, if we're going to do this we should do it with significant force and flexibility that we don't need to change or extend it much later. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: proto-rfc. Elements of @_ should be read-only.
At 05:16 PM 8/4/00 +0100, Piers Cawley wrote: Dan Sugalski [EMAIL PROTECTED] writes: Indirect calls might not be a problem, depending on how much flow analysis we can do in the optimizer. While that won't be much in the on-the-fly-compile version (a 10s runtime with a 50s compile time's not a good thing...) I'm hoping the optimizer will be able to get darned aggressive when given free rein. I wonder if something like the java hot spot on the fly profiler thing might not be handy for long running perl processes... Lots of things would be. Whether they're part of the reference interpreter's a separate question, of course. Stats gathering is a reasonable thing to plan for in the opcode interpreter. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Life without eval
At 01:30 AM 8/5/00 +0900, Simon Cozens wrote: On Fri, Aug 04, 2000 at 12:24:01PM -0400, Dan Sugalski wrote: At 02:31 PM 8/4/00 +0200, dLux wrote: My suggestion is: declare "eval $scalar" as a bad guy. It's not just string eval. It's also do FILE and require. Which you need at runtime, even in compiled code, to run external configuration files written in Perl. Oops! Yup, oops indeed. OTOH, if we do bytecompiled files (like emacs .el/elc stuff), it's not a huge oops, since we may well be able to load in the bytecompiled version. And it does mean that folks writing perl code to run on palms and other small devices might want a Plan B to save config files off. Which is just fine, TMTOWTDI. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 18 (v1) Immediate subroutines
At 02:42 AM 8/5/00 +1000, [EMAIL PROTECTED] wrote: [ Cc'd back to -language, hope you don't mind ] On Fri, Aug 04, 2000 at 09:08:18PM +0200, Jean-Louis Leroy wrote: [EMAIL PROTECTED] writes: Please take discussion on this RFC to the forthcoming -subs sublist. Really. Just hold off for a little while until the list is up. Should be really soon. Ok, but are you sure? It's more a RFC about precompiler features (which I see discussed right now on the language list) than about subs IMO. If it's a language thing (as your mailing list field in your RFC indicates) then it should be on -subs. If it's a precompiler thing then, um, doesn't that fall under internals? Nope. Internals implements (and possibly says "You want us to do *what*!?!?"), language designs. Get us a design and we'll do it. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Proto-RFC: A Standard Always-Live Preprocessor
At 01:23 PM 8/4/00 -0400, John Porter wrote: Jonathan Scott Duff wrote: Perl. :-) Isn't this what source filters is all about? There's something to be said for there being a standard, always-on preprocessor, the way C has cpp. While -P makes available a nice usable preprocessor for perl, not much code uses it, because not many programmers want to bother with the extra two keystrokes! Or perhaps more the point, -P is essentially never used in any of the canonical code examples, books, etc. More likely: 1) C's preprocessor isn't very perlish, so its awfully jarring 2) Lots of it isn't needed 3) C's preprocessor has a number of unpleasant flaws 4) Not everyone has a C preprocessor around to use If we're going to do it, it should be in perl and perlish. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Things to remove
At 09:17 AM 8/5/00 -0700, Larry Wall wrote: I'm not enamoured of the study interface, but the algorithm is definitely a win on certain classes of data. The basic problem with study is that it needs incestuous hooks into how you do string searching. So even if we moved study out into an external module, we'd still have to find some way to treat searching for constant strings as polymorphic within the regex engine. It should be possible to write external modules that both have hooks deep into perl and are automagically loaded. We could, for a first cut, define the hooks and yank study off into one of these modules, with a "do nothing" function in there. Then, when Clever People have had a chance to go think about it, we could drop in a replacement and get the win. This, of course, presumes that defining the hooks (which will also require Clever People) can be done correctly without actually writing the code that uses it... Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC17
At 01:21 AM 8/6/00 -0400, Chaim Frenkel wrote: I think there are two problems. One is the naming convention, the second, the global effects. Why not split them. The names could be improved. And the global nature (of the name) abolished. I'm not entirely sure that tossing the global nature of these things is a bad idea. It is kinda convenient to be able to mess with things (like $^W) and have them stay messed-with. Tossing that makes some sense from a stricture/no-action-at-a-distance standpoint, but having a quick dirty way to just *do* something is kinda perlish. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Deep copy
At 12:58 PM 8/5/00 -0700, Peter Scott wrote: Another one for my wish list: deep copying support built in. A devil inside me thinks this should be a new assignment operator. Damian? Sounds like this is up your alley. I want to do a sanity check before taking up RFC space. Regardless of how this looks, it has some pretty significant ramifications for the internals. What, for example, should happen if you deep-copy a DBI object attached to an Oracle database? Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC17
At 02:09 AM 8/6/00 -0400, Chaim Frenkel wrote: Then a mechanism for uplevel manipulation of variables should be used. uplevel 0, $Perl:Warnings=1;# Hit everyone uplevel -1, $Perl:Warnings=0; # Hit my wrapper (I think something better was proposed, but I don't recall what it was.) Yeah, I can see that. We're going to need a mechanism to hoist things to outer scope levels internally (for when we return objects from subs) so it might be worth generalizing things. "DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS At 01:21 AM 8/6/00 -0400, Chaim Frenkel wrote: And the global nature (of the name) abolished. DS I'm not entirely sure that tossing the global nature of these things is a DS bad idea. It is kinda convenient to be able to mess with things (like $^W) DS and have them stay messed-with. Tossing that makes some sense from a DS stricture/no-action-at-a-distance standpoint, but having a quick dirty DS way to just *do* something is kinda perlish. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183 Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Deep copy
At 05:31 AM 8/7/00 +1000, Damian Conway wrote: Another one for my wish list: deep copying support built in. A devil inside me thinks this should be a new assignment operator. Damian? Sounds like this is up your alley. I want to do a sanity check before taking up RFC space. Regardless of how this looks, it has some pretty significant ramifications for the internals. What, for example, should happen if you deep-copy a DBI object attached to an Oracle database? I would say that encountering an "external component" such as a file handle during a clone() should either shalow copy the component or else throw an exception. That's cool. I can also see calling a package's CLONE sub if you're cloning something blessed into it. Presumably it'd get the original as a parameter and return the new thing, or something of the sort. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Deep copy
At 06:23 AM 8/7/00 +1000, Damian Conway wrote: That's cool. I can also see calling a package's CLONE sub if you're cloning something blessed into it. I like it. And CLONE is preferred to the specified (2nd arg) handler. I'm tempted to say toss the second parameter entirely. If the package doesn't know how to duplicate itself, perhaps it ought not be done. Presumably it'd get the original as a parameter and return the new thing, or something of the sort. Thinking about it, it should get a reference to the original and return a reference to the new value. Works. We won't always be passing objects around, I suppose. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC: On-the-fly tainting via $^T
At 02:52 PM 8/1/00 -0400, Chaim Frenkel wrote: Please explain how having a no taint block would still keep the spirit of not making untainting easy? Hadn't thought that much about it. That is an issue which'd need to be dealt with if this proposal goes anywhere, which it very well might not. "DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS I think I'd prefer to leave untainting to regexes. DS What I was thinking of was something along the lines of a lexically scoped DS pragma--"use taint"/"no taint". (We could do this by sticking in an opcode DS to set/unset the tainting status, as well as the warning status, and so on) DS Taint checking is disabled in a no taint block. Whether we still set the DS taint status on a scalar could depend on the -T switch, so data would still DS be tainted in a no taint block. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183 Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC Archive
At 08:27 AM 8/3/00 -0400, Tad McClellan wrote: On Wed, Aug 02, 2000 at 10:09:04PM -0600, Nathan Torkington wrote: I'm about to push the button that will send my private set of RFCs off to the archive and mail them to perl6-announce. Fingers crossed. The RFC archive is at http://tmtowtdi.perl.org/rfc/ I suggest we zero-pad the RFC numbers for easy (string) sorting. But how many digits are we going to need? ... Figure six. If we blow that then I, for one, am outta here... :) Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: type-checking [Was: What is Perl?]
At 09:25 PM 8/1/00 +, Nick Ing-Simmons wrote:
Alan Burlison [EMAIL PROTECTED] writes:
No, I disagree. Perl gains a lot of its expressive power from being lax
about typing. I suspect it will also impose an unacceptable overhed for
the vast majority who don't want it - at the very least every variable
access will have to check an 'are you typed' flag.
Cross posted to internals ('cos it is...)
We should consider using "vtables" to avoid the cost of the conditional
branches (and running out of flag bits).
Works for me. Anyone care to flesh this out a bit? (Take pity on a guy
who's not had C++ inflicted upon him... :)
Thus this function would call variables "type check" "method" -
which for normal case would be pointer to blue-white-hot "NoOp" function
which is near always in-cache, for a typed var it could be a slow
as you wanted...
I was thinking that, since the compiler has most of the information, a
"type check" opcode could be used, and inserted only where needed. If, for
example, you had:
my ($foo, $bar);
my ($here, $there) : Place;
$foo = $bar;
$here = $there;
You'd only need to typecheck the assignment to $here. Granted assignments
through references would need to check unconditionally, and a typecheck's
in order if you're not sure of the types (say, by directly referencing @_
elements), but the optimizer could certainly toss a lot of checks.
Strong typing could also get us a win other places. If, for example, we said:
my @foo : integer : strict;
meant that @foo *only* has integers in it, we don't need to store full SVs
in it, and use an integer array only.
If strict's off I don't see any reason to forbid bad assignments of 'known'
types--if someone, using the above example, did a "$foo[2] = 'bar'" I don't
see any reason not to make $foo[2] have a value of 0. (With a warning
emitted by -w, of course)
Dan
------"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: RFC 27 (v1) Coroutines for Perl
At 01:17 PM 8/4/00 +0500, Tom Scola wrote:
[I think this belongs on the language list, FWIW, Cc'd there]
I like this, but I'd like to see this, inter-thread queues, and events
all
use the same communication method. Overload filehandles to pass events
around instead, so:
I'm proposing that events and threads be dropped in lieu of coroutines.
Not gonna happen. Tk and signals, at the very least, will see to that.
Coroutines are also an awfully limited threading mechanism, and I think
they'd have the same problems that threads have (or the use of multiple
processors in an SMP system would be shot), so it seems silly to limit
threading to coroutines.
Might as well do 'em all, though the low-level contstructs (i.e. what we
build) may overlap a bunch.
I view events and threads as low-level attempts to implement what coroutines
express elegantly.
In some ways, sure. In others, no.
There would be two perl run-times, one event-based and the other thread
based, much like java green threads and native threads.
Ah. Don't think so. Code duplication is Evil, and I'd rather have a unified
interpreter.
Invoking the coroutine could use another keyword,
perhaps invoke, that returns the filehandle the coroutine talks on. So:
$fh = invoke foo("1", "2", "3")
As I tried to explain in the RFC, the "invoke" keyword be redundant. Writing
to, or reading from the filehandle would invoke the coroutine.
You're overloading filehandle syntax way too much, and parameter passing's
nasty that way.
$foo = |coroutine "bar", "baz";
Yech. Ugly.
This would necessitate the expansion of select to check for pending
events/coroutine writes/data, but that's likely to happen anyway, so...
In my proposed event-based perl runtime, the select loop would be hidden
from the programmer. All I/O calls would be non-blocking and context
switching.
I meant select the perl construct, not select the low-level construct.
Dan
------"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Imrpoving tie() (Re: RFC 15 (v1) Stronger typing through tie.)
At 12:35 PM 8/4/00 -0400, Chaim Frenkel wrote: "DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS The language semantics of tie strongly impact the internals. tie() is DS basically a declaration that the rules are completely different (and DS unknown at compile time) for the tied variable. Shoots down optimization a DS bunch, since access to a tied varible has to be treated as a function call DS rather than as access to data with known behaviours. Why? The vtbl for a tied variable would do all the work. Either the pointer is to a springboard into perl code, or internal code, or the XS replacement code. It's more than that. If the optimizer does code flow, it can know that $foo's been assigned an integer, for example, and maybe even that that variable's never been changed, so this: $foo = 12; $bar = something(); $bar = $foo; could work out to: $foo = $bar = 12; something(); Where if you tie, we have *no* idea what you're doing. This: tie $foo, SomeModule; $foo = 12; could well reboot some server in outer mongolia for all we know. Tied variable access counts as a function call, which smacks optimization all by itself. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Language RFC Summary 4th August 2000
At 11:40 AM 8/5/00 +, Nick Ing-Simmons wrote: Damian Conway [EMAIL PROTECTED] writes: It definitely is, since formats do things that can't be done in modules. Such as??? Quite. Even in perl5 an XS module can do _anything at all_. It can't access data the lexer's already tossed out. That's where the current format format (so to speak) runs you into trouble. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Perl6 Prject Plan / Roadmap
At 06:04 PM 8/5/00 +0200, H.Merijn Brand wrote: In the roadmap, there's lot of actions and shamelines as spoken of in the camel herders association meeting. What was also talked about there, was an early release of perl6 to the active CPAN authors, so they would be able to try and implement the new language for their modules. I cannot find this in the timeline's You'll get it at the same time as everyone else, since it'll be out as soon as possible in general. (Assuming you don't mind working with alpha code...) The plan is for an alpha by next TPC. How alpha is, as always, an open question, given that's almost a year off. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Imrpoving tie() (Re: RFC 15 (v1) Stronger typing throughtie.)
At 09:45 AM 8/5/00 -0700, Nathan Wiger wrote:
Probably not with tie, but with function calls in general, sure. We can do
some flow control analysis on the subs and propagate it outwards so we
might know, for example, that:
sub foo {
my (@vars) = @_;
return scalar @vars;
}
doesn't change its args or any globals, so can be safely optimized around
to some extent.
I hate suggesting bad ideas (but I think this may be one), but has any
thought been given to a "pre-compiler" ala Java?
I know alot of thought is being given to a true compiler, but I'm not
convinced this is feasible. Maybe a pre-compiler that could do some
optimization and then dump the thing off as a ".bpl" (binary perl?)
program. This would still have to be run through the interpreter, but
would be much faster because of pre-optimization. The main difference
between us and Java is that we wouldn't *have* to pre-compile, but only
if speed was crucial (key CGI apps, for example). We already sort of
have hooks for this ability with dump/undump.
Granted, this is probably a really bad idea. Feel free to shoot it down
(my feelings *won't* be hurt). :-)
This is a really good idea, honestly. One of The Plans is to be able to
freeze the final bytecode that would be handed to the interpreter off to
disk instead. Should (if we do our jobs right) allow for faster startup,
and it should also let us do more aggressive optimizations than we do now.
Not because this method lends itself to better optimizations (freezing
parts of programs, like modules, actually hurts optimization some), but
because we have more *time* to optimize.
I don't, for example, want to pay an extra 30 seconds on each program
invocation to run the code through the optimizer. I would be perfectly
happy to do so, though, if the resulting code is frozen to disk so I didn't
pay it the next time.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: named parameters
At 04:37 AM 8/4/00 -0600, Tom Christiansen wrote: Point taken. But part of the goal was moving a lot of stuff out of CORE and making Perl faster. New features are great, but we should figure out whether or not they're truly CORE-worthy. Sticking it in a pragma like strict helps to solve this issue, but as always TMTOWTDI. I find the notion that Perl will become appreciably faster simply by having fewer default features to be unlikely. If we go the double-indirect opcode function route, cutting down on the number of opcodes may well help, as will careful grouping of the opcode functions so opcodes that execute in sequence have their function pointers close-by. This'll reduce cache misses, which is a good thing. It also reduces the number of opcodes the optimizer (and the people writing the optimizer) need to deal with, which isn't a bad thing either. (Though, granted, I really doubt anyone'll spend any significant amount of mental effort on the localtime op) Finally, it may make things slightly easier for folks writing JIT/compiler/translators for perl bytecode. If we yank the 'odd' ops out into separate functions, and the doodad writers provide an interface to the non-op functions, it means they don't have to worry about writing code to do localtime however we do it, they can just call our function. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Different points of view, a little perspective.
At 11:40 AM 8/7/00 -0400, Michael Mathews wrote: In the MLC discussion I have read many comments about how various "C-style" features would be easier for people to learn, remember, and use. In fact the MLC discussion itself was inspired by a desire to make Perl more C-like (actually Java-like) in how it handles comments. Is this a worthwhile argument, even on its own? Perl is one of the very few languages geared towards a conceptual model which is essentially people. Pretty much all the other languages I can think of target a conceptual model where a person isn't central. That's something I don't think perl should lose. Becoming more C-like (or Lisp-like, or APL-like, or Prolog-like, or...) is moving in the wrong direction. Snagging things they do, sure. Just not the way they do it, unless that way maps well to the way that normal human beings (and let's face it, that does *not* target your average programmer dead-on) think of things. Human brains work very differently from computer brains. At this point we no longer need to cater to the computer--we have the power and the technology to make people the central focus and still perform well. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Deep copy
There are a wide range of tricky problems associated with deep copy and deep compare. I like the idea, but circular references can make this problematic even without external things (filehandles, dirhandles, objects from non-perl sources) are thrown in. That needs to be taken into account when putting together the RFC for it, if someone even does. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: ISA number
At 12:27 PM 8/7/00 -0700, Peter Scott wrote: Have often wanted a way to tell whether a scalar was a number, and rolling a regex each time seemed wasteful given that Perl knew what it was anyway. So a user-friendly way to get at the SvIOK and SvNOK results would be great. The Sv?OK macros will likely go away in the new internals, or at least be different. It'd be better to figure out what you really want to know. Those macros tell you whether a scalar has already been changed to an integer, float, or string, rather than whether it can be an int, float, or string, for example. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Deep copy
At 01:27 PM 8/7/00 -0400, Uri Guttman wrote: "DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS At 10:07 AM 8/7/00 -0700, Peter Scott wrote: At 12:53 PM 8/7/00 -0400, Dan Sugalski wrote: There are a wide range of tricky problems associated with deep copy and deep compare. I like the idea, but circular references can make this problematic even without external things (filehandles, dirhandles, objects from non-perl sources) are thrown in. That needs to be taken into account when putting together the RFC for it, if someone even does. I don't want it to go undocumented; I can write an RFC since I started the thread, or Damian can write it since he brought up clone() before that. I defer to Damian. I don't think it's impossible to do something useful, if we think sufficiently Perlish. DS That's fine. I'm not against it (I like it), I just want to know DS what needs to be done under the hood, and we need to document the DS pitfalls to folks that'll use it. the biggest pitfalls are circular structures. i see two opposing ideas here. the first is to allow deep copying but caveat coder. if you are doing circles, override with your own clone method. i know some here do circles a great deal and have to deal with it in DESTROY and other messy place. but the majority of perl data structures are plain trees which can be cloned easily. i also know that lisp tends to more circular stuff (since they HAVE to :) so they never did a generic deep copy. Well, if we provide a primitive for this (a big if) I expect it can be piggy-backed onto the GC code somehow, which needs to do the same sorts of things. as for tied objects and databases, a hornets' nest awaits. No doubt. This is where the interesting work resides, which is why I'm all up for passing the buck to the mythical CLONE sub. :0 Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 58 (v1) Cchomp() changes.
At 10:12 AM 8/8/00 -0700, Larry Wall wrote: Ted Ashton writes: : Thus it was written in the epistle of Segher Boessenkool, : : The magic defined($_ = FILE) only happens if FILE is the only thing : inside while(). : : In this case, it's not (there's a chomp() inside as well), so the magic : doesn't apply. : : Ok. One more time . . . : : I'm proposing that we change that. Before we get too carried away discussing the syntax of chomp, let's look a bit at the semantics. What's chomp supposed to work on if we make $/ go away? I think any discussion of chomp without considering how the input discipline finds line terminators is destined to be a partial solution. If chomp exists in Perl 6 at all, I think it would have to be some kind of method call on the string that figures out what the discipline determined to be the terminator *for the current line*. Which brings up the questions: * What about scalars that didn't come from filehandles? * Should the chomp function use the filehandle's current separator, or the one in effect when it was read? * Do we even want to allow after-the-fact chomps, or do it automagically at read time? * Is it worth the extra space per scalar to store the record separator (or a pointer to the filehandle holding the record separator)? Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 48 (v2) Objects should have builtin stringifying
At 02:18 PM 8/8/00 +, Perl6 RFC Librarian wrote: This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Objects should have builtin stringifying STRING method =head1 VERSION Maintainer: Nathan Wiger [EMAIL PROTECTED] Date: 06 Aug 2000 Version: 2 Status: Developing Mailing List: [EMAIL PROTECTED] Number: 48 Is this an update to the original RFC 48 with a new title? Or is it a new RFC mis-numbered? Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 58 (v1) Cchomp() changes.
At 02:29 PM 8/8/00 -0400, Michael Mathews wrote: Dan Sugalski said: Which brings up the questions: * What about scalars that didn't come from filehandles? * Should the chomp function use the filehandle's current separator, or the one in effect when it was read? * Do we even want to allow after-the-fact chomps, or do it automagically at read time? YES, of course! That last was an "A or B" sort of question. Yes is rather ambiguous. :) * Is it worth the extra space per scalar to store the record separator (or a pointer to the filehandle holding the record separator)? What about a chomp($foo, '\r\n'); # or chomp(FH, '\r\n'); syntax. Looks an awful lot like: s/\r\n//; to me... Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
A plea to RFC authors
When writing RFCs that talk about the inclusion of "interesting" new features--things like coroutines, matrix math, bizarre regex theory (yes, I know that's redundant), curried (or garlic'd, or peppered) subs, for example--it would be helpful if there was a good reference in the references section of the RFC. It doesn't have to be on-line, books or periodicals are just fine, nor does it have to be included in the initial proposal, but it should be in the final one, and the earlier the better. A quick rule of thumb should be "If it's not convered in the Camel 3ed, it ought to have a reference". This'll help folks that might participate but have no idea what you're talking about, the people that need to judge whether it's reasonable and feasable, as well as the people that will have to write the code to implement the feature. Even if it's something that "most CS educated folks" ought to know (a category a number of us don't necessarily fall into), it's handy to know where to look to brush up on the details of the thing in question. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 58 (v1) Cchomp() changes.
On Tue, 8 Aug 2000, Michael Mathews wrote: Ted Ashton said: Thus it was written in the epistle of Uri Guttman, how do you tell the above two apart? by array do you mean only an array variable? then you can't chomp a list of scalar values or multiple arrays, etc. this needs to be clarified. Quite true. The two-argument one is new to me and I hadn't thought much about it. Do you have a suggestion? Like "join" the order of arguments would have to be "chomp($thing_to_remove, @array)" but this spoils the default behavior of $thing_to_remove being optional... unless you think we should require arrays to be passed by reference. It's an op. Arrays can be passed in any way we want. (Though I will personally drive out and smack the first person that suggests chomp should be lazy...) Dan
Re: RFC 71 (v1) Legacy Perl $pkg'var should die
On Wed, 9 Aug 2000, Damian Conway wrote: If you take this, I won't be able to port the forthcoming Klingon.pm module to Perl 6!!! And this would be a bad thing how, exactly? :) I SHOULD KILL YOU WHERE YOU STAND But, but... I'm sitting! :-P Dan
Re: RFC 73 (v1) All Perl core functions should return ob
On Tue, 8 Aug 2000, Mike Pastore wrote: On Tue, 8 Aug 2000, Dan Sugalski wrote: If you feel the need, it should be possible to let you do this, or at least a part of it for one or three ops, with a module. I think it might be better to wait until the plain way's in and then embellish it later. I do believe (and please, folks, correct me if I'm wrong) that's Larry's intent with this whole project is to make Perl6 a fundamentally object-oriented language. At least, that's what I've been able to gather from the discussion threads in this mailing list. I think, if you look in the archives and the Camel, you'll find that turns out not to be the case. Dan
Re: RFC 73 (v1) All Perl core functions should return ob
At 07:55 AM 8/9/00 -0700, Nathan Wiger wrote: It means a lot more code to write (and debug) for the things that return these objects, and that means parts of perl will be slower, take longer to write, and take up more space. Point taken. I don't think internals should be ignored altogether, just that they shouldn't be the driving force in the language design. Otherwise we'd wind up with something like C. :-) I do agree that the internals shouldn't drive the language (otherwise a crack team of Ninja would've already taken care of that Conway guy... :), but neither can they be completely ignored. I'm just weighing in with a rough estimate of the cost. It's someone else's job to balance that cost with the benefits, but that can't be done without at least some idea of the cost. (I expect Larry's got a good handle on that already, or will when he takes a hard look at the final proposal, but...) One alternative is to add a pragma to implement this, maybe called 'object'. So a person could 'use object' to get the objects flowing everywhere. But again, this is an implementation thing I'd rather save until at least v2, after people have given input on the idea itself. Honestly, I'd rather you put together a general scheme for handling the object/scalar morphing thingie and RFC it, and then we migrate the various functions that people think should do the object thing as time and effort allow. They all might not be in perl 6.0.0 (And what are we going to call the first dev release--perl 6.-1.0?) but could get added in as modules and make it into perl 6.2.0 or something) Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: vector and matrix calculations in core? (was: Re: Ramblings on base class for SV etc.)
At 04:06 PM 8/9/00 +, Ed Mills wrote: In keeping with Larry's design philosophy that the language should "not just sit there -do something!" I agree that there should be a number of vector/matrix manipulations available, performed in a psuedo-scalar context (not in a loop). That would be list context. (Or perhaps array or hash context, and yes I know we don't have those right now) Just to name a few: [Snip] etc. etc. This kind of functionality would attract a whole new category of users from mathematics and other areas, as well as giving us optimized solutions to operations that many of us do regularly in loop contexts. I expect it would make other things interesting as well, not just math things. (Running a substitution on an array would be keen, for example) On the other hand one can argue all of these belong in CPAN under a matrix:: library or something like that, but to me if would make Perl a powertool to build these kinds of functions into the language syntax. In many cases these can be treated as overloading scalar ops for a non-scalar context. While I'm firmly of the opinion the code to actually Do Something should be elsewhere (at least to start), support definitely needs to be in the core to notice what that something is--you won't get very far with: @a * @b if perl does a scalar on both arrays before doing the multiplication... Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 78 (v1) Improved Module Versioning And Searching
At 10:44 AM 8/9/00 -0700, Larry Wall wrote: [EMAIL PROTECTED] writes: : Note that it may not be possible to satisfy conflicting requests. If : module CA and module CB demand two different versions of the same : module CC, the compiler should halt and state the module conflicts. Pardon me for sniping at a great RFC, but I already promised the CPAN workers that I'd make that last statement false. There's no reason in principle why two modules shouldn't be allowed to have their own view of reality. Just because you write Foo::bar in your module doesn't mean that Perl can't know which version of Foo:: you mean. Does that mean, then, that when module A does a "$C::bar = 1" it affects a different package namespace than module B doing a "$C::bar = 2"? And does it also extend to things like this: package A; use C 1.2; package B; use C 1.4; where two packages in the same file use different versions of module C and get them? Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 78 (v1) Improved Module Versioning And Searching
At 11:11 AM 8/9/00 -0700, Larry Wall wrote: Dan Sugalski writes: : Does that mean, then, that when module A does a "$C::bar = 1" it affects a : different package namespace than module B doing a "$C::bar = 2"? Presumably. H. That brings up some issues of ambiguity, then. If you use C in package A, and also in package B, which do you see when you're in main and access $C::bar? : And does it also extend to things like this: : : package A; : use C 1.2; : package B; : use C 1.4; : : where two packages in the same file use different versions of module C and : get them? I expect that could also be made to work, provided the semantics of importation remain package-scoped and don't become lexically scoped. Sure. They'd have to be, otherwise packages split across different files would get a rather bizarre view of the world. This sort of means we'll need some sort of two-level stash, one per-package and one global. (Unless you're outlawing symbolic references... :) To me, it really just means that the *real* name of the package includes the implementation (author?) and version, but that when you say use C; you're just choosing to wildcard both the implementation and version. This view says that we probably ought to figure out how to encode the implementation and version syntactically as part of the package name, rather than as a 3rd argument to use. Yup. I can see the build procedures needing to know this too, since we'll probably need to give modules with shared libraries unique names. Some platforms (OS/2 and VMS, at least) will need that, as they get cranky if you try and load shareables with the same base filename. Think about the long names of fonts for an example of how far this can be taken. Would this be "Taken to its logical and sensible conclusion" or "Taken as far as it can possibly go, though it you turn around and look *really* hard with binoculars you can see where you crossed the line, way back there by the horizon"? Dan ------"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 73 (v1) All Perl core functions should return ob
At 12:09 PM 8/9/00 -0600, Nathan Torkington wrote:
I want the core to stay useful but not complex. If localtime returned
a hashref in scalar context, that'd be enough for me:
$now = localtime;
print $now-{MONTH};
print $now-{YEAR}; # already has 1900 added onto it :-)
print $now-{INTEGER};# epoch seconds value
To get what is now scalar localtime, you'd say
print localtime-{STRING};
I'd just as soon that was scalar(localtime)--if we're going to do this,
then we should do it so the short-hand format's convenient and useful.
Which sort of argues for localtime in a numeric scalar context to return
epoch seconds, in a string scalar context to return a time string, and in a
plain scalar context a hashref. (or mini-object, or tied thingamabob, or
whatever) Of course, we're trying to kill $! which does that, which is a
counter-argument...
In list context it would return a simple list of values as it does now.
RFC 48 is way too complex for my liking. In particular it expects
Perl to be able to distinguish between assignment to array and to a
hash.
I smell a counter-RFC, or at least a mailing list on which to thrash
this out.
Nat
Dan
--"it's like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Overloading ||
At 12:04 PM 8/9/00 -0700, Peter Scott wrote:
At 04:58 AM 8/10/00 +1000, Damian Conway wrote:
No. I don't want to see or || and not know whether it
short-circuits
without looking in the class interface. My brain is conditioned
through
years of C and Perl to expect that they always short-circuit. This
is too
venerable a semantic to change. Please.
What if I want to overload and || so that they help built an expression
tree, rather than immediately evaluating?
Is it worth the damage it will cause to fragile brains like mine?
"And now it's time for the head on top of your shoulders to explode"
I have often wondered whether a language could allow user-defined
operators. The fact that none have done it should be a clue :-)
What, like C++? ("I don't believe in it?" "What, C++? Just a conspiracy of
computer programmers?")
I guess it's getting too incestuous with the lexer.
Nah, though it does restrict the optimizer some depending on how it overloads.
Of course, by the time Damian's done, perl won't actually *do*
anything--you'll need to fire off another window and do a "kill
-HEYYOUGETMOVING 23442" to actually make something happen...
Dan
------"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: RFC 54 (v1) Operators: Polymorphic comparisons
At 05:12 PM 8/7/00 -0400, Chaim Frenkel wrote: "DC" == Damian Conway [EMAIL PROTECTED] writes: I currently fail to switch to 'eq' many times when I should, but the failure mode is obvious. Her the failure mode will be really strange. DC I would claim that the failure mode is not obvious: "dog"=="cat" is true Sure it is. I pass a large amount of data and _everything_ matches! Voila, I messed up the test. Test looks okay. (If I was a newbie, '==' is broken. Given my experience, I used the wrong test.) Both ways have issues. "dog"=="cat", but "10.0"ne"10". Both are arguably wrong--dogs aren't cats, but 10.0 really is 10... Dan ------"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Overloading ||
At 05:23 AM 8/10/00 +1000, Damian Conway wrote: Of course, by the time Damian's done, perl won't actually *do* anything--you'll need to fire off another window and do a "kill -HEYYOUGETMOVING 23442" to actually make something happen... Actually, the plan is exactly the opposite. By the time I'm finished everything will be done...in constant time! Sure, but being Quantum, we won't know how long that time is, or if we do we won't know what the answer is... (With all the lazy operations proposals, I can see the release slogan now: "Perl 6, the language for couch potatoes") Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: DRAFT RFC: Enhanced Pack/Unpack
At 10:53 PM 8/7/00 +0200, Bart Lateur wrote: Right. Why you people don't call it "Intel" vs. "Motorola", like the rest of the civilised world, I don't know. ;-) See the TIFF spec, for example. Er, in case you were in any doubt: Motorola (from the 68k processors) is BigEndian, Intel (x86) is LittleEndian. TIFF marks the files with either "MM" or "II". Yep, except for the PowerPC and 88k chips, which can do either, or the i860, which was BigEndian IIRC... Dan ------"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: DRAFT RFC: Enhanced Pack/Unpack
At 07:26 PM 8/7/00 +0100, Tom Hughes wrote: From /usr/include/endian.h on my linux box: #define __LITTLE_ENDIAN 1234 #define __BIG_ENDIAN4321 #define __PDP_ENDIAN3412 Basically PDP or middle endian is low byte first within each word but high word first in the overall longword. This, FWIW, is because the PDP-11 (as opposed to all the other PDP families) was a 16-bit machine, so this is actually two words each in little-endian storage... Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: chomp unchomp
At 03:36 PM 8/9/00 -0400, Bryan C. Warnock wrote: On Wed, 09 Aug 2000, Ed Mills wrote: Here is the argument- Perl has (had?) chomp(). It removes \n at the end of a line. That's something we often need to do. We ALSO often need to ADD \n to the end of a line. This usually looks something like: print "$kitty\n"; Chomp removes one or more line separators from the end. Chomp only removes one instance of the record separator from the end. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: vector and matrix calculations in core? (was: Re: Ramblings on base class for SV etc.)
At 11:13 PM 8/9/00 +0200, Bart Lateur wrote: On Wed, 09 Aug 2000 12:46:32 -0400, Dan Sugalski wrote: @foo = @bar * @baz; Given that the default action of the multiply routine for an array in non-scalar context would be to die, allowing user-overrides of the functions would probably be a good idea... :) [Is this still -internals? Or should we stop CC'ing?] Nope, and we should stop. One problem: overloading requires objects, or at least one. Objects are (currently) scalars. You can't make an array into an object. s/object\./object right now./; If the current plan goes through, arrays and hashes will be typeable, and therefore overloadable. (Think of it as a lightweight object--no method calls, just overloading) but a problem is: @copy = @ary; which only copies the items by value, as a list, and thus ignores the blessing. @copy is a plain array. Well... What happens depends on the type of @copy, and what we decide to do with whole-container assignments. It's reasonable to make @copy the same type as @ary. And if @copy's not a generic scalar array (and is, instead, an integer array, say) some sort of conversion might take place. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 73 (v1) All Perl core functions should return ob
At 09:16 PM 8/9/00 +, David L. Nicol wrote: Nathan Torkington wrote: Dan Sugalski writes: Which sort of argues for localtime in a numeric scalar context to return epoch seconds, in a string scalar context to return a time string, and in a plain scalar context a hashref. (or mini-object, or tied thingamabob, or whatever) Of course, we're trying to kill $! which does that, which is a counter-argument... I'm nervous about these different contexts. I thought scalar vs list was confusion enough. Now we're talking about overloading even further? We need to think VERY long and VERY hard about this before thinking it's a good thing. Nat We could stop insisting on these finitely enumerated and nonextendable "contexts" and start allowing overloading assignment, like so: The assignment operator is selected from the Rvalue's methods, therefore the Rvalue gets to examine the type of the Lvalue and decide what to give it. Both the l and rvalues will need to participate somehow, if for no other reason as to make sure that: @foo = @bar; doesn't bother with the list flattening/unflattening trick. I'm not sure that giving the rvalue unconditional control's a good idea. In this scheme, "time" could by default return an integer, except if the Rvalue has a defined time-override method, in which case it is used instead. Gack. The problem there is then you need to worry about time-return, stat-return, shm-return, foo-return, bar-return... Icky. I think perhaps Plan B would be better. (And no, I have no plan B at the moment) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 78 (v1) Improved Module Versioning And Searching
At 01:50 PM 8/9/00 -0700, Larry Wall wrote: Dan Sugalski writes: : At 11:11 AM 8/9/00 -0700, Larry Wall wrote: : Dan Sugalski writes: : : Does that mean, then, that when module A does a "$C::bar = 1" it affects a : : different package namespace than module B doing a "$C::bar = 2"? : : Presumably. : : H. That brings up some issues of ambiguity, then. If you use C in : package A, and also in package B, which do you see when you're in main and : access $C::bar? I dunno. I don't imagine the situation will arise that often. It'll happen at least once. I suppose we could go insane and make packages loaded in through modules completely invisible to all but the use-ing package, so in this case main wouldn't even know there was a C loaded, and if it tries to mess with things in the C package it gets its own empty stash to deal with. (Which all other packages that didn't use one version of the module or another get) I suppose that's a fancy way of saying namespaces created by used modules are private to the package using them. (Though that still leaves the issue of what happens when package B uses something from package C which wasn't created on the use, but then I'd probably just say "you get your version of C. Nyah!") Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC: Higher resolution time values
At 08:18 PM 8/9/00 +, Nick Ing-Simmons wrote: Dan Sugalski [EMAIL PROTECTED] writes: At 06:16 PM 8/9/00 +, Nick Ing-Simmons wrote: Dan Sugalski [EMAIL PROTECTED] writes: As an engineer I would really like to know when you are going to run out of precision in double - that is forty something bits of mantissa. That is more precision than you have in the real world. It's not precision, it's resolution. What do you do if your timers return values in 1/10ths of a second? What is the problem with that? You can't accurately represent a tenth of a second with floating point numbers. You could if you made 1/10th second the "unit" of the float internally. If we're going to handle them, we might as well be exact. Why - the 1/10 of second is not exact anyway (unless you happen to have an atomic clock in an appropriate physical enviroment attached to your machine). A double's mantissa is better than your typical oscillator. While it may not be correct, at least it's exact. If we go with an inexact representation, we run the risk of accumulating errors and eventually ending up with a number that's both inexact and incorrect. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: overloading assignment operators
At 10:33 PM 8/9/00 +, David L. Nicol wrote: Dan Sugalski wrote: Both the l and rvalues will need to participate. Sorry. Quick review of how C++ does it indicates that selecting an assignment operator from the lvalue's methods makes sense. Sure, and using the rvalue makes sense too, in some circumstances. Since we have dynamic typing, there's nothing keeping an assignment method from running through a set of things it would like to be assigned, and interrogating the rvalue to see if it can provide them. Yup, that's true. More work than I'd like to do by default in general, but a small subset's not out of order. But is there really an advantage, or is it just a neat trick? What, to a smart assignment? Sure. It means we can have efficient hash and array assignments, since they won't need to flatten. It means that if Damian gets his higher-order things going we can have assignment defer assignment. It means that we can maybe do 'smart' data copies (or not). It allows a lot of possibility. Whether any are worth making real is another issue entirely. :) Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Overloading ||
At 09:22 PM 8/9/00 -0400, Bryan C. Warnock wrote: But. It seems to me the generally inability to influence the lexer is the one general weakness in Perl. A weakness shared by pretty much every language I can think of. (Actually I can't think of one that doesn't have it, but I may be overlooking things) Yes, there is many very valid reasons on why this is an evil, evil, thing, and I agree with most of them. Nah, not evil. Major pain in a variety of body parts, but not evil. (That massive pain is one of the reasons its just not done) But, and this may just be the drugs talking here, it seems that the bulk of the RFCs deal with one of two issues: how Perl works internally, or how the Perl lexer needs to be able to handle something new. It makes sense, after all, because if it's not strictly an internal problem, and it's not really a lexer issue, than it can most likely already be included in the language via a module. Perl is extremely easy to extend. The Perl lexer is most heinous to extend. Lexers in general are heinous to extend. A lot of discussions (and two of my RFCs) are centered around adding a pragma to the language to influence the lexer to do this, or do that, so that we don't trample on anybody else. Perl will soon have more pragmas than keywords, and this makes it unfriendly and inconsistent. I've not seen a pragma yet that affects lexing, though I may have missed some. (I don't consider the lexical/package thing a lexer issue, since it's not) They change the behaviour of the generated code, yes, but not the lexing/parsing/whatever of the perl source. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 73 (v1) All Perl core functions should return ob
At 03:38 PM 8/10/00 +1000, Damian Conway wrote: An object that has many different -ify methods: stringify numify hashify listify objectify (!) Possible, but blech. Why is that more blech? Because it's "heavy". However, if Dan assures me that objects will have lower overheads in Perl 6, I will happily withdraw my "blech". Objects will have lower overhead in perl 6. This sort of thing doesn't have to be an object, either--it should be reasonably trivial to do with the perl 6 equivalent of magic, which should be even cheaper. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 78 (v1) Improved Module Versioning And Searching
At 10:43 AM 8/10/00 -0400, Bennett Todd wrote:
2000-08-09-21:00:31 Chaim Frenkel:
Making a module local to the using package, might have interesting
properties. [...]
The only breakage that I see, is having some way of globally setting
a variable. For example, turning on debugging for all uses. (FTP::Debug
I find quite popular.)
Can anyone see any other breakage?
Not other breakage, but another example of the same exact class
of breakage. In RFC 70 I proposed some (hopefully minor) language
cleanups to make it possible to have Fatal.pm actually work the
way people want it. If it worked, then Fatal.pm would be getting
some categories it supported, e.g. "use Fatal qw(:io);". I then
suggested that the invoked categories could be posted into a
testable variable, in case other module authors wished to cooperate
with this protocol.
Why not, then, introduce non-fatal errors and a new keyword to throw them?
Something like quit(), which could take an error class, an error identifier
(a number or short string or something) and a message. It'd work like a
bare return, but also stick something in $@, and could be trappable. (Quit
with one parameter would default the class to generic, and the identifier
to unknown)
This way, when something needs to bail with a non-fatal error it could:
quit('io', 'READERROR', "Unable to read from file $foo");
and the code calling the sub could, if it wanted, could do a plain:
$foo = some_sub($file);
or:
{
use fatal;
eval {
$foo = some_sub($file);
};
if ($@) {
if ($@-nonfatal) {
# handle non-fatal errors
}
}
}
or something like that.
*) Define a set of c
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: RFC 78 (v1) Improved Module Versioning And Searching
At 05:46 PM 8/10/00 +0100, Graham Barr wrote: On Thu, Aug 10, 2000 at 12:28:05PM -0400, Dan Sugalski wrote: No, it wouldn't, really. We could make "use fatal;" scoped, so that the quit op (or whatever it is) only jumps through all its hoops if the pragma's in effect. If its not, then quit(foo, bar, baz) does a bare return and that's it. You'd have the overhead of checking a flag when actually quitting with an error, but that adds a very small amount of overhead to an exceptional case. Why not make that flag avaliable instead of having a new op ? The user can then write $^fatal ? die : return; Sure, that works. Whatever keyword throws the non-fatal error might just be a perl sub that does exactly that, at least to start. (Maybe always, who knows) Hm, although people may start to mis-use the flag. What, people misuse core functionality? I can't picture *that* happening. It's so unperlish... :) Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 89 (v1) Controllable Data Typing
On Thu, 10 Aug 2000, Decklin Foster wrote: Syloke Soong [EMAIL PROTECTED] writes: my $varname type; The syntax my $varname : constant; # pun not intended :) Was brought up earlier (but probably not before this RFC was written). Perhaps something similar could be used for the sake of consistency. The syntax is actually: my type $varname; This is in perl 5.6.0. Modifiers go as attributes after the colon: my Dog $spot : constant = new Dog; dan
Re: Data type and attribute syntax (was Re: RFC 89 (v1) Controllable Data Typing)
At 02:29 PM 8/11/00 +1000, Jeremy Howard wrote: Dan Sugalski wrote: The syntax is actually: my type $varname; This is in perl 5.6.0. Modifiers go as attributes after the colon: my Dog $spot : constant = new Dog; Yes. But what about types and attributes within complex types? What about them? Attributes can take parameters easily enough: my bigint $pi : constant : digits(7) = "3.1415926" Also, do we want to be able to specify types and attributes within a sub prototype? It would be nice to guarantee that subs don't mutate particular parameters, that certain data will not be aliased, etc, so that appropriate optimisations can be done. I'm not sure I'd sweat the optimization stuff at this point. Besides, it's unlikely that the optimizer will know anything about attributes of non-core variable types anyway, so... Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Data type and attribute syntax (was Re: RFC 89 (v1) Controllable Data Typing)
At 10:58 AM 8/11/00 -0400, Chaim Frenkel wrote: Someone on this list (TomC?) has supplied a major diatribe against const. Maybe, but I don't see what's wrong with: my $foo :const = 12; A nice, named, lexically scoped constant. The optimizer should be able to make reasonably good use of that. "JH" == Jeremy Howard [EMAIL PROTECTED] writes: JH Dan Sugalski wrote: The syntax is actually: my type $varname; This is in perl 5.6.0. Modifiers go as attributes after the colon: my Dog $spot : constant = new Dog; JH Yes. But what about types and attributes within complex types? JH - Constant refs vs refs to constants? JH - Types of hash (or 'pair') keys and elements? JH - Attributes (e.g. constantness) of hash keys and elements? JH - Ditto for arrays/lists... JH I left this out of v1 of the RFC because I wanted to get some feedback on JH syntax. If we can flesh this out I'll incorporate it into v2. JH Also, do we want to be able to specify types and attributes within a sub JH prototype? It would be nice to guarantee that subs don't mutate particular JH parameters, that certain data will not be aliased, etc, so that appropriate JH optimisations can be done. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183 Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Against overloading || and (RFC 20) -- we just need lazy evaluation
At 11:13 AM 8/11/00 -0400, John Porter wrote: Bart Lateur wrote: Actually, we don't need it. All we need, is lazy evaluation. The idea comes from Lisp, No, that's no good; lazy evaluation was necessitated by functional programming, which of course perl should avoid like the plague... Why? (And which should we avoid, lazy evals or functional programming?) Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Data type and attribute syntax (was Re: RFC 89 (v1) Controllable Data Typing)
At 05:09 PM 8/11/00 -0400, Chaim Frenkel wrote: Hmm, perhaps we should rename the attribute :read-only Works, though I like "constant" (or const, that's OK) just as much. Might be worth having a way to set things to read-only temporarily, too. Won't help the optimizer, but it could keep some of the more sublte "whoops"es from happening. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 83 (v1) Make constants look like variables
At 11:07 AM 8/12/00 +1000, Jeremy Howard wrote: My current thinking is that a ref to a constant should only be possible through creating a constant first, and then creating a reference to that separately. What, like: $foo = \5' which you can do in perl 5 right now. (Basically a scalar's created (probably), given the value '5', and marked read-only) I'm still unsure of array and hash elements, however. Using the ':' in this way has the potential to cause ambiguity with list generation syntax (RFC 81), and add complexity where there may not be much payoff. If you want individual elements of hashes or arrays to be read-only, that's OK, though I can see that complicating things. And constants, of course, may well be substituted for in the bytestream anyway--if you write: my $foo : const = 5; $bar = $foo; you may well get: $bar = 5; under the hood. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 71 (v1) Legacy Perl $pkg'var should die
On Wed, 9 Aug 2000, Damian Conway wrote: Perl used to use $pkg'var instead of the modern $pkg::var. This is still in Perl 5. It's gotta go. (At least, it should.) N! If you take this, I won't be able to port the forthcoming Klingon.pm module to Perl 6!!! And this would be a bad thing how, exactly? :) Besides, if you can write perl in Latin, I'm sure you can manage Klingonese... Dan
Re: Imrpoving tie() (Re: RFC 15 (v1) Stronger typing through tie.)
At 09:38 PM 8/4/00 -0400, Ken Fox wrote:
Dan Sugalski wrote:
$foo = 12;
$bar = something();
$bar = $foo;
could work out to:
$foo = $bar = 12;
something();
If $foo is a lexical variable and it hasn't been aliased then
you might be able to do that optimization. The following is just
as good and safer:
$foo = 12;
scalar(something());
$bar = $foo;
Integer constant assignment may well be cheaper than scalar copies. You're
right about the scalar bit, though, since it's not the same as void context.
Where if you tie, we have *no* idea what you're doing. This:
tie $foo, SomeModule;
$foo = 12;
could well reboot some server in outer mongolia for all we know. Tied
variable access counts as a function call, which smacks optimization all by
itself.
Do we have to worry about pass-by-ref semantics and @_ assignments
too? This is a weird edge case that I've never ran into. That's going
to put a big damper on optimization with subs.
Probably not with tie, but with function calls in general, sure. We can do
some flow control analysis on the subs and propagate it outwards so we
might know, for example, that:
sub foo {
my (@vars) = @_;
return scalar @vars;
}
doesn't change its args or any globals, so can be safely optimized around
to some extent.
Actually, we have this problem without tie if we allow external
code to register new primitive types. For example, we assume that +
is commutative so that we can re-order expressions and fold constants.
That would break a module that implemented some weird + that wasn't
commutative.
Yup. It's an issue for things that implement any non-standard semantics for
existing ops, especially if those ops are overridden at runtime so the
optimizer doesn't know. It's one thing to mess with tied variables, its
another entirely to make + behave differently.
I think we'll need to get a ruling from Larry at some point on this one.
Anybody that does this has to define a new operator, i.e. if they
use the standard operators, they have to live with the standard
semantics. (This is why string concatentation should never use +!)
That works for me.
I really need to start playing with a parser and dataflow analysis
before thinking too much more about this. It might be that we need
something *way* more strict than use strict before aggresive
optimization is possible.
Well, we can still do some pretty aggressive things, but there will be some
significant limits to code movement and such. Luckily (?) perl's not fast
enough that rescheduling's a big deal--it's not like with machine code
where you want to reorder to avoid cache misses and pipeline stalls and
such. Hoisting code out of a loop, like so:
foreach (1..10) {
$i = $_;
print $i;
}
to
foreach (1..10) [
print $_;
}
$i = 10;
Or, I suppose, this:
print "12345678910";
$i=10;
will be a win, but when exactly assignments happen isn't nearly as big a
deal. I think. Maybe.
Dan
--"it's like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Language RFC Summary 4th August 2000
At 04:00 AM 8/5/00 +1000, Damian Conway wrote: It definitely is, since formats do things that can't be done in modules. Such as??? Well, the easy binding of variables for later use. When one declares a format, variables in it are saved for later use without needing refs. Formats are sort of like a quote where the variables are referenced rather than interpolated when defined, with the values pulled (and possibly altered) when the quote is used. If they yank formats out (which is just dandy by me) that means that some means of providing format's functionality needs has to be designed in. I'm working on it. :) I promised Kirrily that I'd race you in the RFC count... Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Imrpoving tie() (Re: RFC 15 (v1) Stronger typing through tie.)
At 12:48 PM 8/13/00 +1000, Jeremy Howard wrote: Dan Sugalski writes: I don't mind if someone overrides the vtable functions for a variable of a built-in type--a standard declaration of: my $foo; is really shorthand for: my generic_scalar $foo; more or less. If a variable gets its vtable functions messed with, well, that's OK. If + doesn't actually add, well, no biggie. I'd like to have the optimizer not assume functionality on variables that have been overridden somehow. (So if $foo gets tied we stop assuming we know what + does, for example) The bigger thing I worry about is if someone does something odd like make + short-circuit, or not short-circuit. That's the sort of base behaviours I'd like written in stone someplace. Would that really be a problem? Damian is writing an RFC that will propose allowing '?' in a function prototype to indicate a lazily evaluated parameter. If someone overloaded C+ with a function that had a prototype where the 2nd parameter was evaluated lazily, couldn't Perl notice this and do the right thing? Yeah, but we can't guarantee that the function doing the overriding is one written in perl. (Tying and overriding may share an underlying implementation, though I'm not sure yet) Regardless, we can't always tell at compile time if a variable is tied or not, so we'd actually need to have both code paths available with some sort of 'ifweird' opcode that chose the path based on the variables involved. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: vector and matrix calculations in core? (was: Re: Ramblings on base class for SV etc.)
At 05:39 PM 8/9/00 +0200, Bart Lateur wrote:
On Wed, 09 Aug 2000 09:41:22 -0400, Dan Sugalski wrote:
@foo = @bar * 12;
@foo = map { $_ * 12 } @bar;
I don't see the need for a new notation.
Well, compactness for one. With a scalar on one side it's less odd (it was
a bad example). When funkier, though:
@foo = @bar * @baz;
the expansion becomes less obvious and quite a bit larger, especially if
the arrays are multidimensional.
(Isn't this becoming a "language" issue? -language CC'ed.)
Good call.
If you're talking about matrix manipulations, I should immediately hold
you back. Perl arrays are pretty bad as is for representing matrices.
Don't let anybody tell you otherwise: Perl data structures are
one-dimensionaly by nature.
That doesn't necessarily have to remain the case.
For vector manipulation, I can understand that, *in principle*, but not
really. I remember that a few functional language extensions have been
proposed, including "apply a function (code block) to each combination
of item i from the first list with item i of the second list, for each
i". You can easily roll your own. It will do what you want, not what the
implementors thought useful. For example: vector multiplication. What
will @foo*@bar do? Will it return the scalar product
(abs(@foo)*abs(@bar)*cos(angle), the vector product (returning a vector
orthogonal to both others), or a matrix multiplication? If you roll your
own, you can choose.
Choosing is a good thing, yep.
No, I am more in favor of solid yet flexible overloading mechanism, so
that you can use the appropriate module, which does the multiplication
of your choice, and which still allows you to use something like the
above notation. $foo and $bar will then be (vector or matrix) objects,
instead of plain Perl arrays. Much like BigInt now.
Given that the default action of the multiply routine for an array in
non-scalar context would be to die, allowing user-overrides of the
functions would probably be a good idea... :)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Language RFC Summary 4th August 2000
At 12:04 AM 8/7/00 +0200, Bart Lateur wrote: On Sun, 06 Aug 2000 01:38:13 -0400, Dan Sugalski wrote: Even in perl5 an XS module can do _anything at all_. It can't access data the lexer's already tossed out. That's where the current format format (so to speak) runs you into trouble. Only if you insist on the identical syntax as it has been until now. You can cock something together something with here-docs. Implementation can at least partly be based upon sprintf. You can fake it now, sure. But it makes embedding expressions in the format-replacement a pain, and complicates the code a bit. Besides, what formats let you do is nice, and quite easy. Rather than force people to jump through hoops so we can remove it, we should instead generalize what it does so everyone can use it. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Imrpoving tie() (Re: RFC 15 (v1) Stronger typing through tie.)
At 12:23 PM 8/12/00 -0700, Larry Wall wrote: Dan Sugalski writes: : Yup. It's an issue for things that implement any non-standard semantics for : existing ops, especially if those ops are overridden at runtime so the : optimizer doesn't know. It's one thing to mess with tied variables, its : another entirely to make + behave differently. : : I think we'll need to get a ruling from Larry at some point on this one. I haven't been terribly happy with tie for some time. I'd rather we had more type-based approach, which could: 1) factor the work out to one spot so you wouldn't have to call tie on every element of an array, for instance. 2) let us tie lexically scoped variables that don't leak out to the surrounding program. I'm hoping for both. Playing vtable games should help with it. And even if we keep the current tie interface (and we probably have to, even if we add a better way), we can probably limit the damage other ways. If we see a declaration like: my int $foo; we can decide either that $foo will never be tied, or that it will never be tied to an implementation that violates the standard meaning of +. I don't mind if someone overrides the vtable functions for a variable of a built-in type--a standard declaration of: my $foo; is really shorthand for: my generic_scalar $foo; more or less. If a variable gets its vtable functions messed with, well, that's OK. If + doesn't actually add, well, no biggie. I'd like to have the optimizer not assume functionality on variables that have been overridden somehow. (So if $foo gets tied we stop assuming we know what + does, for example) The bigger thing I worry about is if someone does something odd like make + short-circuit, or not short-circuit. That's the sort of base behaviours I'd like written in stone someplace. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: errors and their keywords and where catch can return to and stuff like that
At 03:30 PM 8/13/00 -0500, David L. Nicol wrote: Why not call them throw and catch, like everywhere else, and reccomend them over die? "If everyone else was jumping off a bridge, would you jump too?" (With apologies to my mom... :) What everyone else is doing isn't hugely relevant. What we already do is far more so, certainly. And, given that perl cribs from english as much as any other language, spending some time to get names that fit well makes perfect sense, especially since most of the perl programmers that start using this won't be coming with huge gobs of experience from languages that already do it. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 89 (v2) Controllable Data Typing
At 11:15 AM 8/14/00 -0700, Nathan Wiger wrote: I'm going to actually ask for a new mailing sublist, probably called -object, on which this should be discussed. There's lots and lots and lots and lots of details to work out. It might be best to wait a bit and see how the proposed internal representation settles down first. You may find a lot of this isn't actually necessary. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
At 01:48 PM 8/14/00 -0500, Jarkko Hietaniemi wrote: How 'bout 100ns ticks from base date, stored in a 64-bit number? That We are going to have quads supported on all platforms, then? With software emulation of our own if nothing else is available? I wouldn't object, mind... I'd like to provide ints of that size, yes. Whether they're native (on, say, Alphas or SPARCs), faked by the compiler, or faked by perl is an open question, but I would like them in. This might end up in BigInt format instead of plain int if the platform integers are too small, but that's OK, I think. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 84 (v1) Replace = (stringifying comma) with =
At 03:53 PM 8/15/00 -0400, John Porter wrote: Stephen P. Potter wrote: Lightning flashed, thunder crashed and John Porter [EMAIL PROTECTED] whispered : | Here's a counter-proposal: throw out hashes as a separate internal | data type, and in its place define a set of operators which treat | (properly constructed) arrays as associative arrays. It's the Doesn't it make more sense to get rid of arrays and just use hashes? I guess it depends on what you think makes sense; but it seems to me that an array is a more fundamental data type; that it's easier (i.e. more efficient) to build associative arrays from arrays, than vice versa. It's silly to throw either of them out. Perl might be many things, but a reductionist language it ain't... Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 109 (v1) Less line noise - let's get rid of @%
At 05:53 PM 8/15/00 -0400, John Porter wrote: Dan Sugalski wrote: Tossing the worthless and confusing ones is good. Tossung the useless and distinguishing ones is bad. Uh, which ones did you have in mind, by "useless and distinguishing"? ;-) D'oh! (or is that now D::oh?) I meant _useful_ and distinguishing. Really I did... Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 84 (v1) Replace = (stringifying comma) with =
At 06:04 PM 8/15/00 -0400, John Porter wrote: Dan Sugalski wrote: Generality good. For many things, yes. For computers, say. For people, no. Generality bad. Specificity and specialization good. People aren't generalists. They're a collection of specialists. The distinction is important. I'm sorry if I don't find this argument convincing. This argument suggests that *every* type carry a distinguishing prefix symbol -- including ones to distinguish between numbers and strings, say. Numbers and strings really aren't different things, at least not as far as people are concerned. They are for machines, but computer languages ultimately aren't for machines, they're for people. Of course, you don't mean this. A balance must be struck. And while we're looking for the equilibrium, let's not prejudicially presume that "no symbols" is not an option. I'm not presuming that, though there are plenty of languages already that have no symbols. Perl's not one of them, though. Even assuming highlander types, the punctuation carries a rather significant amount of contextual information very compactly. Yep. So, what's the gripe with it? Other than that it's not what you're used to, I mean. It's going to always be more difficult. You need to *think* to turn a word into a symbol. = is already a symbol. Less effort's needed. ...exploiting instinct and inherent capabilities give you faster response times, and quicker comprehension. Sure. But "instinct and inherent capabilities" do not apply here. Yes, they do. People write source. People read source. People are the most important piece of the system. The computer can be made to cope with the syntax, whatever the syntax is. People can't be made to cope nearly as easily, nor to nearly the same degree. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 109 (v1) Less line noise - let's get rid of @%
At 10:28 PM 8/15/00 -0400, Ted Ashton wrote: I don't know for sure what Perl's main goal is, but it's definitely significant to Perl to make life easier and it has done that. It seems to be the language to Fix Things That Annoy Us. :) Or so it's always seemed to me. (And it seems to be the driving force behind a lot of the stuff in perl...) Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 84 (v1) Replace = (stringifying comma) with =
At 11:46 PM 8/15/00 -0400, Stephen P. Potter wrote: Lightning flashed, thunder crashed and Dan Sugalski [EMAIL PROTECTED] whispered: | Doesn't it make more sense to get rid of arrays and just use hashes? | | I guess it depends on what you think makes sense; but it seems to me | that an array is a more fundamental data type; that it's easier (i.e. | more efficient) to build associative arrays from arrays, than vice versa. | | It's silly to throw either of them out. Perl might be many things, but a | reductionist language it ain't... Why is it silly? Hashes and arrays are *conceptually* very similar (even if they are extremely different implementation-wise). It's because they've got so different an implementation, and their performance characteristics are so different. They're also conceptually distinct. While there is a lot of overlap, there's also a rather large area of difference. While you can fake one with the other, it doesn't mean you should. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 84 (v1) Replace = (stringifying comma) with =
At 11:09 AM 8/16/00 -0400, John Porter wrote: Dan Sugalski wrote: Numbers and strings really aren't different things, at least not as far as people are concerned. They are for machines, but computer languages ultimately aren't for machines, they're for people. I guess I can't fault you for towing the party line on this... Would you stop that? I'm not toeing anything. If I disagreed, believe me you'd hear about it. Strings and numbers are not *exactly* the same, even to humans, are they? At many levels, yes they are. After a point they differ, but what you see written is pretty much treated the same. Most numbers have no solid meaning to people without actual though. IIRC you get zero, one, two, and lots. The difference between numbers and strings is analogous to -- or, on further reflection, IDENTICAL to -- the difference between arrays and associative arrays. (The former are numerically indexed, the latter indexed by strings.) The analogy doesn't hold. And people treat arrays and hashes *very* differently, far more so than the trivial differences in the notation might lead you to believe. I'm not presuming that, though there are plenty of languages already that have no symbols. Perl's not one of them, though. Now you're appealing to the argument that "if we changed the language to be like that, it simply Wouldn't Be Perl." Not buying it. That's fine, I'm not selling it. It is, nonetheless, rather true. It's going to always be more difficult. You need to *think* to turn a word into a symbol. = is already a symbol. Less effort's needed. I guess I'm not sure what you're getting at here. In the expression Cfoo( bar ), bar is a symbol, regardless of its type. There's no "turning a word into a symbol" going on that I can see. Not symbol to the computer, symbol to the *person*. Human's higher-reasoning capabilities are all symbol based, and a lot of the brain is set to turn external stimuli into symbols to be processed. The visual cortex is good at recognizing things and tagging them with a symbol. When you see a dog, for example, it gets tagged with the symbol for dog. If you're familiar with it, it might get a more specific symbol--a breed, or even an individual. That doesn't happen with words--they're already abstract symbols, though in a different way. Because of that they get recognized at a lower level and passed to the language centers for translation to symbols. That extra handoff and translation takes time and mental effort. ...exploiting instinct and inherent capabilities give you faster response times, and quicker comprehension. Sure. But "instinct and inherent capabilities" do not apply here. Yes, they do. People write source. People read source Sure. No argument there. Nonetheless, humans certainly have no instincts, and very likely no inherent capabilities, relevant to computer programming, except for abstract reasoning, which IMHO does not favor one side of this argument over the other. That's an incorrect presumption. Humans have instinct and inherent capabilities for symbol manipulation, language, and pattern matching. That's what's used to write programs and, while it's not ideally suited to the task, it's what we've got. Taking advantage of those human capabilities is one of the things that perl does better than most other languages. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 84 (v1) Replace = (stringifying comma) with =
At 09:49 PM 8/16/00 +0200, Kai Henningsen wrote: [EMAIL PROTECTED] (Dan Sugalski) wrote on 15.08.00 in [EMAIL PROTECTED]: At 06:04 PM 8/15/00 -0400, John Porter wrote: Dan Sugalski wrote: Generality good. For many things, yes. For computers, say. For people, no. Generality bad. Specificity and specialization good. People aren't generalists. They're a collection of specialists. The distinction is important. I'm sorry if I don't find this argument convincing. This argument suggests that *every* type carry a distinguishing prefix symbol -- including ones to distinguish between numbers and strings, say. Numbers and strings really aren't different things, at least not as far as people are concerned. Bovine excrement. Numbers and strings completely different things to people. After a certain point, yes, more or less. Up until then, no. And most numbers are, in most contexts, treated as adjectives by people, where they have little more meaning than any other adjective. They're just mental symbols tacked on as a modifier to other symbols. Hashes and arrays, OTOH, really aren't different for people. The concept of an index needing to be a nonnegative number is a computer concept. Arrays are essentially sequences of things--first thing, second thing, third thing, and so on. Hashes, on the other hand, are named things--the person that's Bob, the person that's Jim, the person that's Jason. It's the difference between position and identity. Those are very, very different concepts. They are for machines, but computer languages ultimately aren't for machines, they're for people. I agree that computer languages are for people - in fact, that's the sole reason they were invented. Otherwise we'd still program in machine language. This statement isn't, strictly speaking, true. Very few computer languages are actually designed *for* people. Most of them are designed to map over a particular problem space, be it theory or hardware. C wasn't designed for people. Neither was Lisp, or Fortran. COBOL, oddly enough, was, though it shows the limitations of the machines and techniques of the era. People are generally an afterthought. However, I do think your ideas about what does and does not come naturally to people are incredibly warped. Perhaps, but then again perhaps not. I've got two young children. Watching kids as they grow lends a certain perspective on things. I see what does and doesn't come naturally. When designing perl, a book on cognitive psychology or early childhood education may be as (if not more) useful than a CS text. I'm not presuming that, though there are plenty of languages already that have no symbols. Perl's not one of them, though. I presume you mean $@% when you say symbols (and not, for example, the stuff that goes into a symbol table, because I certainly don't know any language that doesn't have those). Yep. It's an open question if these are a good idea. I'm not convinced. Personally, I see them as one of the ugly warts in Perl. Even assuming highlander types, the punctuation carries a rather significant amount of contextual information very compactly. s/significant/in/ IMNSHO, even ignoring the "even" part. A single small picture, and one that can be easily picked out by your visual cortex, carries an awful lot of contextual information with it, and carries it quickly. YHO is, I think, incorrect. It's going to always be more difficult. You need to *think* to turn a word into a symbol. = is already a symbol. Less effort's needed. Maybe *you* have to think to turn a word into a symbol. Most people seem to grow up with that concept. I'll have to check, but I'm not sure 'most' is appropriate here, as a large portion of the world uses iconographic languages. Regardless, more mental effort is needed to turn the word "rock" into the concept of a rock than a picture of a rock does. It's not conscious, generally speaking, but more of your brain is involved in dealing with words than with pictures. As for *recognizing* the stuff, ever heard of redundancy? It's the stuff that makes recognizing stuff easier. No, redundancy is the stuff that makes recognizing things more reliable. Words, by being longer, are easier to recognize than non-alphabetic symbols. Non-alpha symbols are *faster* to recognize. That's their advantage. Overloading them with too much meaning is bad, as then you end up needing to think more. When you see something like: $foo the first thing that happens is your brain picks out the whole space-separated thing as a single 'thing'. That happens in your visual cortex, it's fast, and takes very little effort. That gets stripped down into pieces. Your brain's already dealing with a perl context, and $ gets recognized as the 'single thing' marker. 'foo', meanwhile, is wending its way through your language centers. That's slower. The thinking part of your b
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
At 09:25 AM 8/15/00 -0700, Larry Wall wrote: [EMAIL PROTECTED] writes: : Yep. Or more generally "Standardize Perl on all platforms to one : common time epoch" and reccommend the Unix epoch since it's so : widespread. :-) Oh, gee, where's your sense of history? (As in creating our own. :-) Maybe we should invent our own epoch, like the year 2000. Or use a really standard one, like the year 0 AD (aka 1 BC). I think I'd snag a date after the last western country went Julian, just to avoid some of the less fun time conversion issues. (How long ago Jan 1, 1690 was depends on what country you're in) While I personally like the smithsonian base date (17-nov-1858) that's rather parochial (well, US-centric) and difficult to remember. If we're picking a new one, I'm partial to Jan 1, 2000. Or shall we choose year 0 in the Chinese calendar? I have this horror that people will still be using 1970 as the epoch in the year 31,536. Nah. I'm sure we'll have switched over to Elvis' birthday as base date by then... :) Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
At 10:56 PM 8/14/00 -0500, Jarkko Hietaniemi wrote: Is Perl currently using different epochs on different platforms? If so, I Yes. MacOS and VMS. (Though VMS' localtime() uses the UNIX definition, just to be portable.) MacOS' epoch zero is 1900 (or was it 1901?), VMS' epoch zero is 17-NOV-1858 00:00:00.00, for some astronomical reason IIRC. It's the Smithsonian Base Date, FWIW. On VMS, though, perl presents all time in Unix epoch seconds. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
At 02:23 PM 8/15/00 -0400, [EMAIL PROTECTED] wrote: Modified Julian Day 0 thus started on 17 Nov 1858 (Gregorian) at 00:00:00 UTC. (somebody threw that date out, It appears to be purely arbitrary rather than based on some celestial event) Not arbitrary at all. From: http://www.kgb.com/calend.html This information comes from the original (pre-Motif) DECwindows help file which accompanied VMS version 5.3. by Marios Cleovoulou http://ourworld.compuserve.com/homepages/cleovoulou/ Copyright © 1988, 1989 by Digital Equipment Corporation. The Julian Period Astronomers use the Julian period because it is convenient to express long time intervals in days rather than months, weeks and years. It was devised by Joseph Scaliger, in 1582, who named it after his father Julius, thus creating the confusion between the Julian (Caesar) calendar and the Julian (Scaliger) period. Julian Day 1 began at 12:00 noon, January 1, 4713 BC. This date was thought by some to correspond approximately to the beginning of the universe. Certainly it predated any known astronomical events known in the 16th century without resorting to negative times. Scaliger decided on the actual date on the grounds that it was the most recent coincidence of three major chronological cycles: - The 28-year solar cycle, after which dates in the Julian calendar (for example September 27) return to the same days of the week (for example Tuesday). - The 19-year lunar cycle, after which phases of the moon return to the same dates of the year. - The 15-year indiction cycle, used in ancient Rome for tax regulation. It takes 7980 years to complete the cycle. Noon of January 1, 1988, marks the beginning of Julian Day 2447161. The Julian period is also of interest because of its use as a time base by the VMS operating system. VMS and the Julian Period or: Why VMS regards November 17, 1858, as the beginning of time... The modified Julian date adopted by SAO (Smithsonian Astrophysical Observatory) for satellite tracking is Julian Day 240, which turns out to be November 17, 1858. SAO started tracking satellites with an 8K (nonvirtual) 36-bit IBM 704 in 1957, when Sputnik went into orbit. The Julian day was 2435839 on January 1, 1957. This is 11225377 octal, which was too big to fit into an 18-bit field. With only 8K of memory, the 14 bits left over by keeping the Julian date in its own 36-bit word would have been wasted. They also needed the fraction of the current day (for which 18 bits gave enough accuracy), so it was decided to keep the number of days in the left 18 bits and the fraction of a day in the right 18 bits of one word. Eighteen bits allows the truncated Julian day (the SAO day) to grow as large as 262143, which from November 17, 1858, allowed for 7 centuries. Possibly, the date could only grow as large as 131071 (using 17 bits), but this still covers 3 centuries and leaves the possibility of representing negative time. The 1858 date preceded the oldest star catalogue in use at SAO, which also avoided having to use negative time in any of the satellite tracking calculations. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Things to remove
At 06:00 PM 8/21/00 -0700, Larry Wall wrote: [EMAIL PROTECTED] writes: : How about this then: : : In a void context, Cdump dumps the program's current opcode representation : to its filehandle argument (or STDOUT, by default). It's not clear to me that reusing a lame keyword for this is the highest design goal. Let's come up with a real interface, and then if we want to reuse the (the presumably missing) dump keyword for some method name or other, that's fine. But we're currently designing it from the wrong end. What I've been hoping for is: 1) The ability to dump the program and its current state out into something that can be reloaded later. (Though filehandles and other external-interface things make this tricky) 2) The ability to dump out a variable and all its attached state into something that can be loaded in later somewhere else. #1 is a natural outgrowth of bytecompiling a program--when you dump the bytecode, you have already executed module initialization code and BEGIN blocks, so that means variable dumps. #2 is because I want to be able to do: print SOME_SOCKET freeze_dry($an_obj) and have the other end do: my $remote_obj = reconstitute(scalar SOME_SOCKET); Or something like that, at least... Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
