Re: is it required to use type declarations?
On Wed, Dec 18, 2002 at 09:31:41AM +, Piers Cawley wrote:
Dave Storrs [EMAIL PROTECTED] writes:
It seems like Perl6 is moving farther and farther away from Perl5's
(almost) typelessness.
It depends what you mean by typed. Perl has always had strongly typed
*values* (which strike me as being a damn sight more useful than
typed variables).
No argument from me. When I want/need the abilities that come with
specifying type, I want the language to support it. I just don't want
to _have_ to do it, when I don't want/need those abilities.
In a language with typed values, being able to
declare a typed variable is useful for a few reasons:
* After watching things in a profiler, you sacrifice programmer
flexibility by typing a couple of variables as a way of giving the
Optimizer something to get its teeth into (if you have a typed
variable then you can limit the amount of runtime checking you have
to do in favour of compile time checks)
Agreed.
* For setting up multiply dispatched methods and functions. Consider
the example below (which I know I've used before).
sub grep ( (Rule | Block) $selector, @*args ) { @args.grep($selector) }
sub grep ( (Rule | Block ) $selector, Collection $collection ) {
$collection.grep($selector)
}
sub grep ( WeirdSelector $selector, @*args ) {
grep $selector.as_block, *@args;
}
Because we can declare the types of the function parameters we can
let the language sort out the dispatch for us. Without typed
parameters and multi dispatch those three function definitions
become:
sub grep ( $selector, $first, @*args ) {
if @args.length {
return [ $first, @args ].grep($selector);
}
else {
$first.grep($selector);
}
}
method Object::grep ($self: $selector {
[ $self ].grep($selector);
}
Hm. I'm way short on sleep today, so I'm probably missing something,
but I don't see why Perl can't sort this out without a specific
typing.
On a more nit-picky level, the first two subs in the top block seem to
show that arrays are not derived from Collection. Surely, if
everything is an object, they should be?
Which, to my way of looking at things is deeply ugly.
I certainly find the first version easier to read...which, given my
particular set of prejudices, makes it enormously preferably in my
eyes.
* And last and least, for 'strictness'. Personally I think this is
the least useful choice; the programmer sacrifices flexibility for
having the compiler catch errors that would be more usefully caught
in a test suite. And to make matters worse, if you want the
compiler to catch the errors you have to make *everything*
explicitly typed, and and life's too short for buggering about like
that thank you very much.
Agreed.
--Dks
Re: is it required to use type declarations?
Attribution lists are getting a bit complex. This is in response to what Piers wrote on Wed, Dec 18, 2002 at 03:50:44PM +. DKS [specifying types] Hm. I'm way short on sleep today, so I'm probably missing something, but I don't see why Perl can't sort this out without a specific typing. PC Well, you've got to specify the types *somewhere* when you set up your multimethods. The parameter list seems a better place than most. Ah! Ok, yes, I missed something. I thought you were saying that we would need to type the variables not just in the signature, but in every call to the function/method as well...and that second part is what I was objecting to. No, of course you need to mark the types in the signature. --Dks
Re: Comparing Object Identity
On Fri, Dec 13, 2002 at 09:32:02AM -0800, Michael Lazzaro wrote: $obj.ID; $obj.IDENTITY; FWIW, I favor the latter. --Dks
Re: Everything is an object.
On Mon, Dec 16, 2002 at 06:47:39PM +, Piers Cawley wrote:
Michael Lazzaro [EMAIL PROTECTED] writes:
Mind you (purely devil's advocate), I'm not entirely sure the R-to-L
syntax truly _needs_ to be in Perl6. It's true I use it all the time,
but I can retrain to use L-to-R method calls with little effort.\
Personally I really don't like the L to R style;
That's ok. Personally, I do. You find R2L easier to read, I find L2R
easier. TIMTOWDI. Perl6 should be smart enough to support both.
I know we've got it
for C for ... - $a { ... } , but I can see the logic behind
that, otherwise L to R looks worryingly like C++ to me.
I'm not convinced that language snobbery is a good reason to include
or exclude a feature from Perl6. And, if there is logic in having L2R
in one case (for), why shouldn't we generalize it to be useful (or at
least possible) in all cases?
If we have a post-given, e.g. Cmap {...} given @a or Cmap {...} is
given @a, I think that gives us R-to-L without any special {...}
rules at all.
No, just the addition of much ugliness to code for no gain in
readability. And one more area where Perl 6 fails to look like Perl 5
for no good reason.
Personally, I'm not fond of the specific syntax that MikeL is suggesting.
However, I think that L2R is valuable enough that it should make it
into the language, and I don't have a better suggestion.
--Dks
Re: Everything is an object.
On Mon, Dec 16, 2002 at 08:26:25PM +, Piers Cawley wrote:
Dave Storrs [EMAIL PROTECTED] writes:
On Mon, Dec 16, 2002 at 06:47:39PM +, Piers Cawley wrote:
Michael Lazzaro [EMAIL PROTECTED] writes:
I haven't been arguing against his syntax for adding L to R
pipelines, but against the damage he proposes doing to R to L syntax.
Fair enough. I'd like to find a way for neither of them to go away,
or get damaged.
However, I think that L2R is valuable enough that it should make it
into the language, and I don't have a better suggestion.
Well, L2R is really easy:
@ary.map({...}).grep(rx/.../).whatever(...);
For ugly values of 'really easy' of course.
Yick. I'll definitely agree on the ugly part.
However, I'm curious--and I know this has been hashed over, I'm just
not clear on where we stand at this point--are you proposing that map,
grep, and whatever would be methods on Array? Because that seems
unnecessarily restrictive. And yet, having them be methods of Object
seems a bit TOO generous.
Perhaps the answer is to have an inheritance tree that goes
Object
|
v
Collection
|
+-Array
|
+-Hash
|
+-etc (maybe Set, or maybe junction)
...and map, grep, etc, would be elements of Collection, overriden in
sensible ways by the derived classes?
This is an off-the-cuff idea and I may well be full of it.
--Dks
Re: Everything is an object.
On Mon, Dec 16, 2002 at 03:44:21PM -0500, Dan Sugalski wrote: At 11:12 AM -0800 12/16/02, Dave Storrs wrote: You find R2L easier to read, I find L2R easier. TIMTOWDI. Perl6 should be smart enough to support both. Why? Yes, technically we can do both R2L and L2R. We can also support an alternative Scheme/Lisp form of perl's syntax, as well as a Forth/Postscript style. Heck, we can probably manage a prolog-style unification style for a not-insignificant subset of perl programs. That doesn't mean its a good idea. Just so I'm clear, are you saying that you think L2R is a bad idea, and should not be supported? Or just that it has not yet been demonstrated that this is a good idea? --Dks
Re: Comparing Object Identity
On Fri, Dec 13, 2002 at 09:56:15AM -0500, John Siracusa wrote: Using the method/attribute named id for this is the same object comparisons is just plain bad Huffman coding. The this is the same object method/attribute should have a name that reflects the relative rarity of its use. FWIW, I have agreed with John throughout this entire thread, but I felt that he was stating things quite clearly and I didn't have anything further to add. I just want to chime in so he doesn't feel like a lone voice in the wilderness. --Dks
Re: Comparing Object Identity [x-adr][x-bayes]
On Fri, Dec 13, 2002 at 09:49:44AM -0600, Garrett Goebel wrote: Other common names for the proposed .id are: UUID: Universal Unique Identifier (DCE) GUID: Globally Unique Identfier (EFI) Of the 2, usage of GUID seems to be more common IMHO. Both of the above are identical in implementation. And won't rollover until 3400AD ;) Which is actually rather a shame, since Global has multiple common meanings in programming, which Universal does not. --Dks
Re: is it required to use type declarations? (was Re: 'hashkey context/Str context')
On Wed, Dec 11, 2002 at 12:13:49PM -0700, Luke Palmer wrote: [Dks wrote:] So...are we intending that types and type safety will be like 'use strict' (optional and only on request), or will they be like sigils (mandatory, can't be turned off)? Or, perhaps, on by default but able to be turned off? Optional by request, but not explicit request. If you type a variable, you're asking for type checking on that variable. Excellent. That's the best of all worlds. Thanks; I am much relieved. --Dks
Re: REs as generators
On Thu, Dec 12, 2002 at 10:35:47AM +1100, Damian Conway wrote: Dave Storrs wrote: - the ability for the programmer to set limiters (??better name??) on the junction, which will specify how the junction should collapse--e.g. always collapse to the lowest/highest value that hasn't been supplied yet, or to the lowest/highest unsupplied value that causes a particular code block to return true, or whatever. Junctions don't collapse. They distribute. Remember: Junctions Aren't Quantum. Ah. Obviously, I don't know JAQ. (sorry) However, I don't believe this answers my question...or, more likely, I am just misunderstanding junctions. I believe that this code: my $i = one(7...); print $i; Is roughly equivalent to this English: - declare a lexical variable $i - create a junction. The states of the junction are (7..Inf). The type of the junction is one - assign the junction to $i - distribute the junction [that still doesn't sound right, but ok] by choosing one of the states (at random??) - print the number chosen in the previous step. First of all, am I correct about this? Second, what I was originally asking is this: could there be some way for the programmer to attach a (method/code block/sub/whatever) to the junction, such that when the state is chosen, the default method of choosing a state is overriden by the code supplied by the programmer. --Dks
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
On Wed, Dec 11, 2002 at 02:54:18PM -0800, Dave Whipp wrote: Michael Lazzaro [EMAIL PROTECTED] wrote: After thinking about it a little more, I'll set myself on the yes side. And propose either '===' or ':=:' to do it. Definitely '==='. Hopefully, this thread has been settled by Damian's pointing out the existence of id(), but could I put in a strong vote against the use of '===' for anything? It is far too easy to misread as ==, IMHO. --Dks
Re: REs as generators
On Tue, Dec 10, 2002 at 03:38:58PM -0800, Rich Morin wrote: On occasion, I have found it useful to cobble up a little language that allows me to generate a list of items, using a wild-card or some other syntax, as: foo[0-9][0-9] yields foo00, foo01, ... I'm wondering whether Perl should have a similar capability, using REs. Will Perl6 still have the increment a string ability? I can't count the number of times that's been my saving grace when I needed to portably and easily generate a unique filename. --Dks
is it required to use type declarations? (was Re: 'hashkey context/Str context')
On Mon, Dec 09, 2002 at 03:58:54PM -0700, Luke Palmer wrote: From: Dave Storrs [EMAIL PROTECTED] My understanding was that in Perl6, you could use pretty much anything for a hashkey--string, number, object, whatever, and that it did not get mashed down into a string. Did I have this wrong? By default they're keyed by strings. You can smack a property on them to key them by something else, though: my %sparse is keyed(Int); my %anything is keyed(Object); # or UNIVERSAL Hmmm...maybe this is a good time to bring up something that's been bothering me for a while. It seems like Perl6 is moving farther and farther away from Perl5's (almost) typelessness. All of a sudden, we are getting into ints, Ints, Objects, Strs, etc...more and more of the code examples that are being posted to these lists use type declarations in method signatures, variable declarations, and anywhere else that they might squeeze in. It isn't clear to me if this is being done because we are currently discussing the new types and type-safety mechanisms--all of which are optional, and only come into play when you request them--or if it is expected that this will be the new paradigm for Perl programming. So...are we intending that types and type safety will be like 'use strict' (optional and only on request), or will they be like sigils (mandatory, can't be turned off)? Or, perhaps, on by default but able to be turned off? --Dks
Re: REs as generators
On Tue, Dec 10, 2002 at 10:37:10PM -0700, Luke Palmer wrote: Why use regexen when you can just use junctions? my $foos = 'foo' ~ any(0..9) ~ any(0..9); At what moment does a junction actually create all of its states? Hmm...perhaps a clearer way to say that is At what moment does a junction allocate memory for, and initialize that memory with, all of its states? I would hope that we could simply store the defining conditions of a junction without having to generate all possible states at the moment the junction is declared. optimizations. MODE=wild speculation I wonder if junctions could support the following: - lazy generation...when one of the calls (e.g. any, one) which requires that only one value (or one value that satisfies the condition) be generated, we would not need to generate the whole list. I would hope this would be the default, but I'm not assuming anything. - the ability for the programmer to set limiters (??better name??) on the junction, which will specify how the junction should collapse--e.g. always collapse to the lowest/highest value that hasn't been supplied yet, or to the lowest/highest unsupplied value that causes a particular code block to return true, or whatever. /MODE --Dks
'hashkey context/Str context' (was Re: purge: opposite of grep)
On Sat, Dec 07, 2002 at 01:28:41PM +1100, Damian Conway wrote: Dave Whipp wrote: I notice everyone still want Int context for eval of the block: Pease don't forget about hashes. Is there such a thing as 'hashkey context'? I doubt it. Unless you count Str context. My understanding was that in Perl6, you could use pretty much anything for a hashkey--string, number, object, whatever, and that it did not get mashed down into a string. Did I have this wrong? --Dks
Re: right-to-left pipelines
On Sun, Dec 08, 2002 at 09:35:16PM -0800, Dave Whipp wrote:
is to use an alphabetic name (e.g. || vs or). perhaps the we
could name this operator Cpp: its vaguely remenicent of the
@out = @in
pp map { foo }
pp grep { bar }
pp sort { $^a = $^b }
I like the idea of an alphabetic operator name here, but I would like to find
something other than 'pp', for two reasons:
1) to me, pp looks too much like one of the quote operators
2) it isn't particularly self-documenting (not that qq or grep or whatever
are, but...)
My suggestion would be one of the following:
to, after, sendto, into, thru
@out = @in to map { foo } to grep { bar } to sort { $^a = $^b }
@out = @in after map { foo } after grep { bar } after sort { $^a = $^b }
@out = @in sendto map { foo } sendto grep { bar } sendto sort { $^a = $^b }
@out = @in into map { foo } into grep { bar } into sort { $^a = $^b }
@out = @in thru map { foo } thru grep { bar } thru sort { $^a = $^b }
I'm not deliriously happy with any of these, but I think 'to' and
'after' are the best of the lot. Anyone else have a better
suggestion?
--Dks
Re: Numeric Literals (Summary 4)
On Mon, Nov 25, 2002 at 09:01:36AM -0800, Michael Lazzaro wrote: (Umm... what's a better name than coloned form? That term sounds really... um... bad.) How about: - explicit radix - dotted notation - DSD (Dot Separated Digits) --Dks
Re: perl6 tests
On Fri, Nov 22, 2002 at 05:49:58PM +, Piers Cawley wrote: Dave Storrs [EMAIL PROTECTED] writes: Ideally, there could even be a per-list switch and a global switch that says (don't) show unique ids when interpolating lists/arrays. By default, it gets set to show, but it can be turned off if you want. What would that gain you? Apart from a global variable the world would be better off without? Remember, if you want to print it out without the 'id' information you can just do Cprint @$array_ref; It would mean that, by setting a command line switch or passing a command-line argument, I could change the behaviour of my code without having to change the code. --Dks
Re: perl6 tests
On Thu, Nov 21, 2002 at 09:43:08PM +, Piers Cawley wrote: [ how should printed lists behave? ] Please make the default behaviour 'debugging friendly' rather than 'pretty' if that makes any sense at all. In other words, it'd be handy if whatever got printed out included some unique ID for the scalar so, when I'm sticking debugging print statements into code I can tell at a glance whether [ 'one', 'two', 'three' ] and [ 'one', 'two', 'three' ] are the same thing or simply two arrayrefs that *look* the same. How about something like 'Array(id)[...]'? Verbose admittedly, but useful. Ideally, there could even be a per-list switch and a global switch that says (don't) show unique ids when interpolating lists/arrays. By default, it gets set to show, but it can be turned off if you want. --Dks
Re: Help! Strings - Numbers
On Fri, Nov 22, 2002 at 12:10:11PM -0800, Michael Lazzaro wrote: On Friday, November 22, 2002, at 10:59 AM, Luke Palmer wrote: From: Michael Lazzaro [EMAIL PROTECTED] I've been under the impression that the following would _not_ work: $s ~~ /number/; print I found $number; As a minor nit...I think this should work, it just won't do what you wanted. It should do just what it does in P5--print the currently-scoped value of the variable which happens to be named $number...and if there is no such variable, it will throw a warning/error and put in a ''. --Dks
Re: Help! Strings - Numbers
On Thu, Nov 21, 2002 at 01:22:50AM -0500, Tanton Gibbs wrote: I actually rather like MikeL's suggestion for the unary ops; clear, concise, and highly readable. And look: my str $s = sprintf(%x, $i);# 30 characters my str $s = hex $i; # 19 characters my $s = ~hex $i; # 16 characters I think these are good, but I really think that Larry's idea of an as function is the best. Not only does it provide a decent syntax my str $s = $i.as(%x); it also has the ability to be overloaded for various user defined types. I do agree that having it be a method (and hence overloadable) is the best solution. I just wish there were some way to get away from those dratted sprintf format strings. --Dks
Re: Help! Strings - Numbers
On Thu, Nov 21, 2002 at 01:29:32AM -0500, Tanton Gibbs wrote: As a tangent...one of the things that has bothered me about but and is for properties since the beginning is that they make for excessively long code. Does this bother anyone else? --Dks Properties have bothered me, but for a different reason. It appears that everyone's answer to everything is make it a property! Properties are just strange to comprehend...they are like hidden attributes that are squirreled away until you least expect them...then I would say that properties are very powerful and, like most powerful things, could easily be abused. Oddly enough, it always seemed to me like the whole concept of properties grew out of wanting a clean way to handle the case where you want to return a 0 but true value (0E0 is and always was squinky). (along with grammar rewrites...in which you can make your one character program make your morning toast for you if you decide to rewrite the grammar). Ah, but think of all the lovely entries the Obfuscated Perl Contest judges will be soon be receiving! ; So, yes properties bother me, no not because they are wordy (wordiness is not bad...clarity good...linenoise bad). I don't generally mind wordiness...it just seems like properties can go a little overboad, particularly when there are more than two or three of them. Just my 0.02, though. --Dks
Re: Help! Strings - Numbers
On Thu, Nov 21, 2002 at 03:26:09AM -0500, Tanton Gibbs wrote:
Dave Storrs wrote
best solution. I just wish there were some way to get away from those
dratted sprintf format strings.
Well, for the general case, you could create convienence functions that
handle getting the correct format
sub hex { return %x; }
print \$i is $i.as($(hex))
[snip]
Hmm...good suggestion; that does make me rather happier.
Thanks!
--Dks
Re: Contributor License forms
On Thu, Nov 21, 2002 at 02:41:33AM -0800, Ask Bjoern Hansen wrote: [EMAIL PROTECTED] (Dave Storrs) writes: send in our Contributor License Forms. You can read all the license details at: http://snipurl.com/bkt http://pdp.perl.org/contributor_agreement also sends you to that page (and we can keep that url alive forever (for some definition of that). Good enough; the snipurl URL was the one that I got from brian d foy, but in the future I'll mention the pdp one. or email scanned copy to: [EMAIL PROTECTED] No, please make it pdp-editors at perl.org for now. The other address doesn't work and probably never will. :-) If this is the case, you might want to rewrite the submission guidelines that are in the document itself, since I just retyped what I saw there. --Dks
Re: Help! Strings - Numbers
On Thu, Nov 21, 2002 at 09:10:53AM -0800, Larry Wall wrote: On Wed, Nov 20, 2002 at 10:16:54PM -0800, Dave Storrs wrote: : As a tangent...one of the things that has bothered me about but and : is for properties since the beginning is that they make for : excessively long code. Does this bother anyone else? It's *supposed* to bother you. It's a sign that you're abusing the property system. Properties are not a replacement for object attributes, and they're not a replacement for function arguments. Just try sending a memo to your boss with five Post-It notes on it, and see how it well it works out... Larry I see and agree with your point. Although, I would hope the I am the boss of the interpreter instead of the other way around. : --Dks
License forms
Ok folks, this is your Friendly Neighborhood License-Form Thug calling: For those who came in late, we all need to sign and submit a license form saying that the Perl Documentation Project gets the IP on the documentation we write. The form is here: http://www.snipurl.com/bkt/ It contains complete submission instructions. When you submit yours, please email me with P6License in the title and let me know that you submitted yours. It isn't hard...it took me under 5 minutes to print, sign, and fax mine in, and the majority of that time was spent waiting for the fax machine to do its thing. We seriously need to get those license forms in. Although we aren't being hardnosed about it yet, eventually we are going to have to draw a line in the sand and say If you don't have your license form in, we can't use anything you submit...so please don't post, because we don't want even the appearance of having used your ideas. Here is the complete list of everyone who I know has submitted a license: David Storrs --Dks
Re: License forms
On Wed, Nov 20, 2002 at 05:55:12PM -0500, Bryan C. Warnock wrote: [eventual need to refuse stuff from unlicensed people] Hard and fast? ie, patches, even for a simple typo? Or new work, as corrections to a licensed document should imply concurrence. I'm very glad to say that I'm not the one who has to make that call. : I'm not sure who is--maybe MikeL (as the chief ListOp), or maybe someone at the Perl Documentation Project--but it ain't me. Seriously, Alison asked me to be the thug on this one, so I'm just trying to do the job the best I can. Here is the complete list of everyone who I know has submitted a license: David Storrs And what of the people you don't know? :-) Well, obviously I don't know about them. ; However, when I posted the original please send in your license forms message a week ago, I did ask that people email me when they did it. I also checked with brian d foy before posting _this_ message, and he said he hadn't gotten any recent emails (though he had been away from his snail mailbox for a while). --Dks
Re: String to Num (was Re: Numeric Literals (Summary))
On Wed, Nov 20, 2002 at 12:11:21PM -0800, Larry Wall wrote: On Wed, Nov 20, 2002 at 11:57:33AM -0800, Michael Lazzaro wrote: : and _I'm_ trying to promote the reuse of the old oct/hex : functions to do a similar both-way thing, such that: What's a two-way function supposed to return if you pass it something that has both a string and a numeric value? Convert it both directions? Larry It should return a junction, of course. : --Dks
Re: String to Num (was Re: Numeric Literals (Summary))
On Wed, Nov 20, 2002 at 01:23:04PM -0800, Dave Whipp wrote: Larry Wall [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... On Wed, Nov 20, 2002 at 11:57:33AM -0800, Michael Lazzaro wrote: : and _I'm_ trying to promote the reuse of the old oct/hex : functions to do a similar both-way thing, such that: What's a two-way function supposed to return if you pass it something that has both a string and a numeric value? Convert it both directions? It returns a junction, of course ;-) D'oh! Another Dave anticipated me! That'll teach me to read the whole thread before responding. (Oh well, at least our smileys were different.) Seriously though, I dislike the proposal. Of course, if we have a 'do-it-as-a-string' operator modifier (As discussed for bitops, etc), then we could have: ~hex(10) eq 'a' hex(10) eq '16' But I still tend to read that ~ as a 1's complement. Fwiw, I suspect that the ~ will be used more often as stringification than as 1's complement, so people will fairly quickly remap their brains to the new meaning. --Dks
Re: Help! Strings - Numbers
On Wed, Nov 20, 2002 at 05:51:17PM -0500, Tanton Gibbs wrote: It's going to be hard to beat sprintf( %x, $i ) for clarity or conciseness. Unfortunately, it's pretty easy to beat it for readability. It's also a holdover from C, an ancestor language that we are (at least to a degree) trying to outgrow. I actually rather like MikeL's suggestion for the unary ops; clear, concise, and highly readable. And look: my str $s = sprintf(%x, $i);# 30 characters my str $s = hex $i; # 19 characters my $s = ~hex $i; # 16 characters These all do the same thing, but the third one supplies the string context explicitly...and is half the size of the sprintf version. As to the other formatting that sprintf supports, I would suggest doing those with properties, not adverbs. Here's why: # Could you really tell what this does at a glance? my $s = ~hex:w4p2d0rs $i; my $s = ~hex $i but width 4 but precision 2 but padded 0 but rightjustified but usesign; The second one is definitely longer...and substantially longer than the equivalent sprintf. But I also don't need to dig out my KR to remember how to write it. As a tangent...one of the things that has bothered me about but and is for properties since the beginning is that they make for excessively long code. Does this bother anyone else? --Dks
Re: String to Num (was Re: Numeric Literals (Summary))
On Fri, Nov 15, 2002 at 11:50:52PM +0200, [EMAIL PROTECTED] wrote:
Michael Lazzaro writes:
Let's summarize some of the string-to-num issues:
my int $i = literal 0xff; # 255
(3) -- We want to be able to parse a string as a number using a very
_specific_ rule; for example, if a user is expected to enter a value in
a specific format, like octal 755 or hex FF, we want to know what
we're expecting. That implies there may be functions for each common
format:
my int $i = sci 1e33;
my int $i = hex 00ff;
the default behaiviour of literal should be same as perl parsing of
literals. but sub literal can have additional parameters .
Could we come up with a name other than literal? This function's
job is to take a string (which may be a literal, user input, or
whatever), and turns it into a number--the human-expected version of
that number, not necessarily the result you would get if you simply
numified the string.
How about to_num? Or even just num?
also it seems that there sould be symmetry ( as was declared ) between
types and type - casting functions
so , probably literal should be called num or int or uint16 ,
depending on WYW . or the casting may be let to happen in two stages
: string - num - specific num type ,e.g. uint16
How about if we got adverbial on the problem:
my $str = 0xff;
my $i = num $str;
my $i = num $str : uint16;
my $i = num 1.0_731e3 : float;
my $i = num 1.0_898_798_798_794e7 : double;
And this makes an interesting corner case:
my $i = num 10_000 : byte; # value too large for 1 byte
I can see two ways to handle this--we can have a compile-time warning,
or we could store it to the smallest type that will hold the value and
issue a warning.
(4) -- We want to be able to output numbers to strings according to
specific formatting rules. One way to do this (aside from using
sprintf) is to use sprintf-style formatting strings, perhaps as
properties to tie them to individual instances:
my int $i = literal 0xff but as_string('%02x');
Actually, this would be a good reason to have a function called
literal -- if it went both ways. So, I could do this:
print literal(200+55):hex; # == print 0xff;
print literal(0xff)); # == print 255;
--Dks
Re: Numeric Literals (Summary 2)
On Mon, Nov 18, 2002 at 10:57:10AM -0800, Michael Lazzaro wrote: --- Numeric Literals --- bin/oct/hex notation: 0b0110 # bin 0c0123 # oct 0x00ff # hex 0x00fF # hex, == 0x00ff 0x00FF # hex, == 0x00ff I would assume that 0B0110, 0C0123, and 0X00FF are all equivalent to the forms with lower-case base markers, right? -0xff # ok -0x00ff # ok Are these two identical? Is 0x-ff an error? (I would say yes.) If not, is it the same as -0xff? 0xf_f # ok Ok. 0x_ff # ok Wait a minute...the rule is that underscore can only appear between digits. Here, the 'x' is not a digit, it is a base marker. Therefore, shouldn't this be an error? explicit radix: (radix 2-32) 20:1gj # base 20 20:1GJ # base 20 (identical) 20:1.G.J # base 20 (identical) 20:1_G_J # base 20 (identical) 20:1.16.19 # base 20 (identical) 20:1_16_19 # NOT identical; == 20:11619 20:1.1_6.19 # WRONG: dotted form may not have underlines -20:1GJ # base 20 (negative) -20:1.16.19 # base 20 (negative) The more I think on it, the more it seems like the negative sign should really go to the right of the colon (20:-1GJ)...otherwise, it really does look like you're using a negative radix (is that even possible?). I realize this is out of step with the traditional -0xff, but it still seems like The Right Thing to me...what do other people think? 62:zZ # base 62 (?) 62:z.Z # base 62 (identical?) 62:z_Z # base 62 (identical?) 62:Zz # base 62 (not identical?) Why is that last one not identical? (radix 33-RADIX_MAX) 256:0.253.254.255 # base 256 256:0_253_254_255 # base 256 Are these two intended to be identical or not? I expect not...the first should be a 4 digit number and the second a 10 digit number. Other issues w/ literals: - radix = 32, alpha digits may be upper or lowercase Implying that in radii 32, case matters? I thought we had decided it was better to go the other way, and have case never matter, which meant that for radii higher than 32, you had to use dotted notation? --Dks
Re: Numeric Literals (Summary)
On Mon, Nov 18, 2002 at 03:14:52PM +, Graham Barr wrote: On Sat, Nov 16, 2002 at 11:12:15PM -0800, Dave Storrs wrote: 24*60*60:10 # one day in seconds, easy representation And the advantage of that over 24*60*60*10 would be ? Well, for one thing, my version means 1 day and yours means 10 days. Are we not just getting too carried away with all this base of literals. Perhaps. I don't feel strongly enough about it to argue it if people don't like the idea. I also think -documentation is the wrong place to discuss this. In all seriousness, where would you suggest it should be discussed? I thought part of the purpose of this list was to define all the corner cases...surely, whether or not the radix can be an expression is a corner case. --Dks
Re: Numeric literals, take 1
On Thu, Nov 14, 2002 at 07:58:55PM +0100, Angel Faus wrote: Hi all, Hi Angel, This is the numeric literals part, reformated to follow Michael's outline. My contribution is some copyediting and a few suggestions. Take what you think is worthwhile. - =section * Numeric Literals =section ** Integer and Decimal literals There are many ways to specify literal numeric values in perl, but they default to base 10 for input and output. s/perl/Perl/ (Aren't we still using the capitalization to distinguish between the interpreter and the language?) Perl allows you to use the standard scientific notation s/the// It works just like the standard scientific notation: Delete this phrase; you've already said that this IS standard SN. the left portion of the Ce is the coefficient, and the s/the/The/ right is the exponent, so a number of the form CC.CCCeEE is actually intepreted as CC.CCC * 10**EE. I would suggest using XX for the exponent, so as to have less confusion with the 'e'-as-exponent-marker. Also, add a sentence stating that the exponent marker may be in either case. Then you get: ...right is the exponent, so a number of the form CC.CCCeXX is actually intepreted as CC.CCC * 10**XX. You may use either upper- or lowercase 'e' as the exponent marker, so, for example, 3.6e3 is the same as 3.6E3. For example, the literal C7.828e6 is interpreted as C7823000. 7828000, as was already pointed out You can use negative numbers in the exponent side, allowing you to write very small numbers. You may write very small numbers by using negative exponents. =section ** Radix Notation For integer numbers, you can represent the literal value in any other base, using the Cradix: syntax. s/other// a need to represent digits that are greater than 9. You can do this in two ways: Make the above be one paragraph; you haven't started a new thought yet. Alphabetic characters: Following the standard convention, perl will interpret the A letter as the digit 10, the B letter as digit 11, and so on. s/perl/Perl/ ...will interpret the letter A...the letter B as the digit ^^^ Separating by dots: You can also write each digit in its decimal representation, and separate digits using the C. character. Although separating by dots is perfectly correct and fluid, I would suggest using the term dotted notation, just so people start getting used to it. my $m = 256:255.255.255.0;# 256-base # base 256 For example, the integer 30 can be written in hexadecimal base in two equivalent ways: Either say: ...in hexadecimal... or ...in base 16..., but don't mix them. Also note that a compile-time error will be generated if you specify a digit that is larger than your radix can support. For instance, my $x = 3:23; # error Very small nit: the problem here is the digit 3, but on first glance it looks like you are saying that the digit in question is 23. Extend the comment to explain: my $x = 3:23; # error; can't use digit '3' in base 3 Beware that when writing negative integers, the negative character C- should be at the leftest point of the expression: When writing negative integers, be aware that the minus sign (C-) must always be the leftmost character in the literal, which means it will come to the left of the radix when using radix notation. my $z = -256:234.254; # negative number my $e = 256:-234.254; # error Keep in mind that once the number has been read by perl Perl it becomes just a magnitude. That is it loses all trace of s/That is it/That is, it/ the way it was originally represented and is just a number. Perl will use decimal base when printing all the numbers, no matter what base did you use to type them. Either say base 10 or decimal notation, not decimal base. I would suggest: Perl always uses decimal for printing numbers, regardless of what base you used to enter them. =section ** Underscore character as a seprator Perl allows the underscore character, C_, to be placed as s/placed/used/ a separator between the digits of any literal number. You can use this to break up long numbers into more readable forms. ...to break up a long number into a more readable form. There aren't any rules to it; you can use it however you like: The only rule is that you may only use underscore between digits, not between any other characters that is allowed to appear in a number. 123_456_000.000 (floating point) 2:0110_1000 (binary) 16:FF_88_EE (hexidecimal) 1312512.25(decimal number) 1_312_512.25 (the same) 1_312_512_.25 (error) 1_312_512._25 (error) 1.375_e56 (error) 1.375e_56 (error) _2_3_45___6 (error) [delete intermediate comment, collapse examples together, add
Contributor License forms
Greetings all, Allison has asked me to be the coordinator to make sure that we all send in our Contributor License Forms. You can read all the license details at: http://snipurl.com/bkt Basically, what it comes down to is that we need everyone to sign a document saying that, for all the docs you write, you assign the license to the Perl6 project. This is pretty important, so please try to send them in soon--you can fax them, email them, or snail-mail them. The info is: Download form from:http://snipurl.com/bkt Fax to:1 413 254 0312 (in the US) +44 (0) 870 120 7793 (in the UK) or email scanned copy to: [EMAIL PROTECTED] or snail-mail to: The Perl Documentation Project 5301 N. Kenmore Rd. #2 Chicago, IL 60640, USA All of this is specified in the second paragraph of the Agreement; I'm just reiterating for your convenience. When you've sent it in, please let me know and I'll mark you down. --Dks
Re: Numeric Literals (Summary)
On Sun, Nov 17, 2002 at 03:01:08PM +0200, Markus Laire wrote: On 15 Nov 2002 at 12:02, Dave Whipp wrote: A couple more corner cases: $a = 1:0; #error? or zero Shouldn't base-1 be: 1:0 == 10:0 1:1 == 10:1 1:11 == 10:2 1:111 == 10:3 1:1010111 == 10:5 etc.. Nope. Remember, for any N, base N consists of the digits from 0 up to N-1. So, in base 2 (binary), you may only use the numbers 0 and 1. In base 10 (decimal), you may only use the digits from 0-9. And so on. Therefore, in base 1, you can only use the digit 0. (Actually, I think base 1 is a corner case--you only get one digit, but that digit is 1, so you can represent any number N by making N tally marks.) Also 0:0 == 10:0 In base 0, you would get no digits at all, so you can't represent anything...which makes sense: after all, how many times must you multiply 0 by itself to represent the decimal number 10? --Dks
Re: Numeric Literals (Summary)
On Sun, Nov 17, 2002 at 08:13:58PM -0700, Luke Palmer wrote: Date: Sun, 17 Nov 2002 18:51:05 -0800 From: Dave Storrs [EMAIL PROTECTED] Therefore, in base 1, you can only use the digit 0. (Actually, I think base 1 is a corner case--you only get one digit, but that digit is 1, so you can represent any number N by making N tally marks.) [...] As for semantics, base zero is of course an error, and I'd say base one should be as well. Just because I prefer consistency over almost-useless exceptions. Ditto. I was just being pedantic.
Re: Glossary?
On Thu, Nov 14, 2002 at 02:29:38PM -0600, Garrett Goebel wrote: It is interesting that no one has yet taken the time to start defining the terms we're using. Good point. I volunteered to be keeper of the glossary a while ago, but I never actively started creating one. That said, let's make this the first entry. Comments and constructive criticisms welcomed from all comers. Term: literal Definition: A literal is a way of writing a particular fixed value. For example, 65 (decimal), b101 (binary), and 0x41 (hexadecimal) are all literals, are all constants, and are each a different representation of the same fixed value. Sometimes literals come in groups...most commonly in lists or arrays. An example of a list of literals would be: (1, 2, 3). An example of an array of literals would be: ['a', 'b', 'c']. (*) Note that there is a subtle difference between saying an array of literals and a literal array. An array of literals is simply an array that happens to contain nothing but literals. A literal array is a more slippery concept since an array is actually three things strung together: a name, a memoryspace that acts as a container, and a value (see the Larray entry for more information). Of these, the name is a literal, the container is not a literal, and the values stored in the container may or may not be literals. (In the example given in the Larray section, the values 7 and 'a' are literals, while $quux is not.) Examples of literals: 7, 3.1415926535897932384, 'Fourscore and seven', 0xDEADBEEF, b10100011, 'z'. Examples of non-literals: $foo, @bar, %baz, jaz() Term: array Definition: An array is a collection of Perl Lliterals and/or variables, indexed by number using square brackets, where the first index is 0. Therefore, you would say @myarray[0] to retrieve the first element, @myarray[1] to retrieve the second, and so on. On a deeper level, an array is actually three things at once: it is a name, a container, and a collection of values. For example, an array @a which contained the values 7, 'a', and $quux would look like this: Name: @a | Container: +++ ||| Values:(7) (a)($quux) Here we see that the name of this array is '@a', the name is associated with a container in memory, and that there are currently three values in that container. The first two of these values are Lliterals (specifically, the number 7 and the letter 'a'), but the third item is another container: a Lscalar variable named $quux. When accessed with an index that is a positive integer N, an array will access the element at the N-1th place (because, remember, indices start with 0). When accessed with an index that is a Bnegative integer M, an array will access the element that is at position M+1 from the Bend of the array. Therefore, @array[-1] returns the last element, @array[-2] returns the second to last element, and so on. Arrays know how to manage their own size; they will grow and shrink as needed when you add or remove elements. You never need to worry about whether an array has enough space to hold the number of elements you are about to insert. (***) Examples of arrays (usage): @foo = (1, 2,3); # create/init an array @foo[2]; # fetch last element @foo[-1]; # fetch last element undef @foo; # destroy array, free associated memory, #and decrement reference count on each #value NOTES: (*) There was a long thread a little while ago on how arrays would be written. I believe the final decision was that [] was the array composer, but I'm not sure. Can someone confirm or deny this for me? (I'll go dig through the archives after I send this, but if someone knows offhand, it would save time.) (**) There needs to be a point here explaining the difference between list of literals and literal list (and the same for arrays), but I find that I don't understand it well enough myself to explain it. (***) I feel like there should be some discussion here of the fact that an array is really a reference, and that when you pass it or assign it, you are really assigning the reference--I'm just not quite sure how to put it. Any suggestions? Also, a couple of questions: First, when I originally started writing these entries, they were substantially shorter. As I look at them now, I wonder if I haven't written something that is too long for a glossary entry, and would better be used for main documentation (or bird cage liner, if you are unkind)--what do you all think? Second, what format should this document be kept in? I know that POD is the standard, but I feel that POD by itself is a poor fit for a glossary, since a glossary needs very little presentation but a lot of structure (for example, you want to group the definition
Re: Literals, take 2
On Fri, Nov 15, 2002 at 12:03:32PM -0800, Larry Wall wrote: On Thu, Nov 14, 2002 at 12:24:50AM -0800, Dave Storrs wrote: : Also, on this subject...what happens if I want to use letter notation : in a base higher than 36? What happens then is that people will think you're silly. :-) Larry On that point, I wholeheartedly agree. However, SOMEONE will try it. So, the final answer is that, for bases over 36, your only option is to use dotted notation, correct? --Dks
Re: Numeric Literals (Summary)
On Thu, Nov 14, 2002 at 01:33:31PM -0600, Jonathan Scott Duff wrote:
On Thu, Nov 14, 2002 at 10:28:38AM -0800, Michael Lazzaro wrote:
1.23_e_4# ok?
Hrm. This one is annoying, but I think it should be okay.
Are you sure? If so, can you explain why for me, because I don't
think it should. Larry said that _ is only allowed between
digits--and here 'e' is not a digit, it is an exponent marker. It
serves a similar function to the decimal ('.') in 7.3 -- not an actual
component of the number (i.e., a digit), but a structural marker
within the number (saying this next part is the (decimal|exponent)
for floats/exponentials, respectively).
20:1.G.K# base 20 (identical?)
20:1_G_K# base 20 (identical?)
20:1.16.19 # base 20 (identical?)
20:1_16_19 # base 20 (identical?)
(I still don't see
a use for non-decimal floating point representations, but that's
probably just my lack of imagination).
It's not just you--I don't see it either, fwiw. The only reason I can
come up with--and I am not convinced by it--is that if you are doing a
long series of calculations in one base, you might now want to do the
context switch in your head just because you need to use a float.
--Dks
Re: Numeric Literals (Summary)
On Fri, Nov 15, 2002 at 12:02:02PM -0800, Dave Whipp wrote: $b = 4294967296:1.2.3.4 # base 2**32 Hmm, interesting. Just as an aside, this gives me an idea: would it be feasible to allow the base to be specified as an expression instead of a constant? (I'm pretty sure it would be useful.) For example: 4294967296:1.2.3.4 # working with a really big base, hard to grok 2**32:1.2.3.4 # ah, much better 24*60*60:10 # one day in seconds, easy representation Or how about run-time evaluated versions? # Set a timer to run for either a day or an hour, depending $timer = 60*60*($use_days ? 24 : 1):10 Or a REALLY sick one: fetch_base():7.9# great for Obfuscated Perl. also good for # concisely (though not partiuclarly readably) # determining multiple values for the index # into a dispatch table. --Dks
Re: Literals, take 2
On Wed, Nov 13, 2002 at 12:33:09PM -0800, Larry Wall wrote: : 1_2_3_4__5___6 (absurd, but doable) Nope, _ is allowed only between digits (counting a-f as digits in hex). Larry Does this mean that you can't use _ in numbers if the radix is higher than 16? (For example, in base 20, the letters A-J should be considered to be digits...can you put underscores between them?) Also, on this subject...what happens if I want to use letter notation in a base higher than 36? --Dks
Re: Docs Data Format (was Re: Project Start: Section 1)
[examples of how to create the glossary links snipped] Assuming that we do go with the maintain a unique list of keys in %glossary, then do an s/// approach, I'd be willing to maintain the list of terms. --Dks
Re: Project Start: Section 1
On Tue, Nov 12, 2002 at 12:06:13PM -0600, Garrett Goebel wrote: I wonder if it'd be feasible to do lists something like: [...] =* level1 = level2 =+ level3 =* level4 = level3 = level1 I personally like the idea of keeping the '=' required, to be consistent with other commands. However, I see no reason why it needs to be required at each level. Maybe we could take a page from Doxygen's book, and have the POD parser use whitespace smartly: =list - level one, unordered -# level two, ordered (because of the number sign) - level three - level four - level three again -# level two again (must be consistent about use of number sign) - level one again =endlist --Dks
Re: Project Start: Section 1
On Tue, Nov 12, 2002 at 12:16:53PM -0600, Jonathan Scott Duff wrote: On Tue, Nov 12, 2002 at 12:06:13PM -0600, Garrett Goebel wrote: Or if the leading = really must be required: =* level1 = level2 =+ level3 =* level4 = level3 = level1 What about this for bulletted lists: =item * level1 =item ** level2 =item *** level3 =item level4 =item *** level3 =item * level1 and this for ordered lists: =item # level1 =item ## level2 =item ### level3 =item level4 =item ### level3 =item # level1 FWIW, I would not want ot have to count '#'s in order to tell how many levels of indentation I was getting. But maybe we could hit a middle ground? =item 1# Foo =item 2 Bar =item 2 Baz =item 3 Jaz =item 4 Quux =item 1# Raboof Produces this: 1. Foo * Bar * Baz * Jaz * Quux 2. Raboof (Yes, I deliberately used 4 space indent instead of 8; I wanted to make sure I could fit 4 levels of indentation on one line. Holy wars are two doors down at /dev/null.) I propose that the author would be required to be consistent about the use or non-use of '#' at a particular level, just to keep things clear. --Dks
doubled messages??
Is anyone else getting all the traffic from this list twice? I don't get it from any of the other p6 lists, so I'm not quite sure what's up. --Dks
Re: [RFC] Perl6 Operator List, Take 5
On Wed, 30 Oct 2002, Larry Wall wrote: If no one saw them then it could well be a problem on my end. I'm trying to use a mailer (pine) that doesn't know about UTF-8 in a «+» b I'm using Pine 4.33 on FreeBSD 4.3, and I see these fine. --Dks
Re: plaintive whine about 'for' syntax
On Wed, 30 Oct 2002, Michael Lazzaro wrote:
On Wednesday, October 30, 2002, at 12:48 PM, Dave Storrs wrote:
for a; b - $x is rw; $y { $x = $y[5] };
I agree that it's an eyeful. How many of your issues could be solved
if the above were just written:
for (a;b) - ($x is rw; $y) { $x = $y[5] };
Would that suffice to make it clearer?
Actually, yes, that would solve everything for me...and I knew
this was valid syntax. However, (A) the fact that Larry went to some
fairly serious lengths to eliminate the need for parens everywhere he
could says to me that we should find a system that doesn't require them
and (B) since it CAN be written in the 'eyeful' way (*) it WILL be written
in that way...and I and others are going to have to maintain code that
uses that and, as I said, I think it's going to lead to a lot of bugs.
Maybe I'm the only one who is bothered by this...if so, I'll cope and
deal.
--Dks
Re: plaintive whine about 'for' syntax
On Wed, 30 Oct 2002, Austin Hastings wrote:
--- Dave Storrs [EMAIL PROTECTED] wrote:
for @a - $x; @b - $y { $x = $y[5] };
Yes!!!
(Except for the ''. That's feigen-ugly.
*shrug* You may not like the aesthetics, but my point still
stands: is rw is too long for something we're going to do fairly often.
Give me any one- or two- character marker you want that means rw (if
ro is the default) or r (if rw is the default).
I prefer default=ro, though,
because that let's the optimizer do more by default.)
I don't feel strongly enough about this to argue it. Personally,
I prioritize readablility over ease-of-optimization...I let Moore's law
take care of speed. Other people, who work in other problem domains than
I do, may need to have other priorities.
I proposed the multiple arrow thing a long while back, but it didn't
work out because of precedence with comma and because of
topicalizing/binding/etc.
But that was before semicolon which can have a different precedence
from arrow. And screw the binding -- it just looks right:
for @first - $a;
@pairs - $b is rw, $c;
{
print woo-hoo!\n;
}
You're right, that does look good...but you had to manually insert
whitespace in to make it look good. And (assuming that you used a TAB to
indent the '@pairs...' line), assuming that my TAB settings are the same
as yours.
The problem is, if we make those assumptions, I can even make the
current syntax look (reasonably) good:
for @a; @b
- $x is rw; $y
{
}
--Dks
Re: plaintive whine about 'for' syntax
On Thu, 31 Oct 2002, Damian Conway wrote:
Dave Storrs wrote:
Actually, yes, that would solve everything for me...and I knew
this was valid syntax.
So is this vertical layout, which I think will become fairly standard
amongst those who care about readability:
for a ; b
- $x is rw ; $y { $x = $y[5] };
To be honest, this just makes it less readable for me.
--Dks
worth adding collections to the core language?
In the Re: Wh[ie]ther Infix Superposition ops thread
On Wed, 30 Oct 2002, Piers Cawley wrote:
But given a decent Collection hierarchy:
my $seen = Set.new($start,$finish);
for - $next {
print $next unless $next =~ $seen;
$seen.insert($next);
}
Just a thought...are sets (or other Collection types) something that we
use often enough that they would deserve to be in the core language? I
know I've used hashes as no-repeats-allowed sets many times, so clearly
they are commonly useful. On the other hand, since this can be done,
maybe there is no need to implement a new core feature for them.
I suspect the answer is no, we don't need them but I just thought I'd
ask; I'm curious about the design reasons either way.
--Dks
Re: plaintive whine about 'for' syntax
On Wed, 30 Oct 2002, Angel Faus wrote: Then let's make the parens required when there is more than one stream. Sane people will put them there anyway, and it will force the rest of us to behave. It also solves the ;-not-a-line-seperator problem. -angel Yes! Thank you, this is perfect. Minimal disruption of the syntax Larry designed, minimal exception to remember, and it completely resolves all my issues. See, I knew there had to be a simple, elegant solution I was missing. --Dks
Re: plaintive whine about 'for' syntax
On Wed, 30 Oct 2002, Graham Barr wrote: On Wed, Oct 30, 2002 at 01:57:00PM -0800, Dave Storrs wrote: *shrug* You may not like the aesthetics, but my point still stands: is rw is too long for something we're going to do fairly often. I am not so sure. If I look back through a lot of my code, there are more cases where I use the variable in a read-only fashion than I do for modifying the value. Ok, fair enough. --Dks
Re: Perl6 Operator List, Damian's take
On Tue, 29 Oct 2002, Austin Hastings wrote: Hell, we might as well throw in multiple dispatch. Actually, I am really hoping we do. Any of you OO guys know of a case where $a = $a + $b; # A [+]= B; -- A = A [+] B; and $a += $b; # A [+=] B; should be different? Any time that evaluating $a produces a side effect--for example, if $a is a tied variable implementing a counter and increments itself by one every time its value is fetched. If it started with a value of 5, then $a += 3 leaves it with a value of 8, but $a = $a + 3 leaves it with a value of 9. Dave Storrs
Re: Wh[ie]ther Infix Superposition ops
On Tue, 29 Oct 2002, Dan Sugalski wrote: At 1:34 PM -0800 10/29/02, Brian Ingerson wrote: Every eigenbunny needs a supercozy! Absolutely. Eigenbunnies in supercozens. Sounds like we've found the mascot for Perl 6! I really want to work a pear pimples for hairy fishnuts reference in here somewhere, but I can't quite make it work. Dave Storrs
Re: Light ideas
Ah! Ok, yes, I had missed that. Thanks, this is exactly what I wanted. Dave On Mon, 5 Aug 2002, Stephen Rawls wrote: Doesn't the :w option do that? :w/one two/ translates to /one \s+ two/ Not exactly. The regex you showed would match any of these (using underscores for spaces for clarity): one_two, one__two, one__two Ah, ok. This is from Synopsis 5, this should be what you want: A leading ' indicates an interpolated literal match (including whitespace): / 'match this exactly (whitespace matters)' / cheers, Stephen Rawls
Re: Light ideas
On Sat, 3 Aug 2002, Ken Fox wrote:
Dave Storrs wrote:
why didn't you have to write:
rule ugly_c_comment {
/
\/ \* [ .*? ugly_c_comment? ]*? \* \/
{ let $0 := }
/
}
Think of the curly braces as the regex quotes. If { is the quote
then there's nothing special about / and it doesn't need to be
escaped.
Ok, good. Then it *does* work the way I thought. Thanks.
Also, I don't think you want spaces between / and *
because / * isn't a comment delimiter.
True, but as I understand it, literal whitespace in a regex is no
longer significant...so writing / * in a regex is equivalent to writing
/* or /* etc. In order to match an actual / *, you would need
to write /\s+*.
Actually, this is one thing that has troubled me about the new
regex rules, and I've mentioned it before. I would still like for there
to be a reverse /x switch, that would tell the regex that I want it to
treat whitespace literally...if for no other reason than because it would
reduces line noise in regexen. In most situations you probably wouldn't
want it, but I can think of occasions when you would.
Dave Storrs
Re: Apoc 5 questions/comments
I assume that 'fatal.pm' is a new pragma. 1) What (if anything) does it do, aside from turning 'fail' into a fatal exception when used outside a regex? 2) Do you need to use it before you can (usefully) use 'fail' INSIDE a regex? (I would assume not, but thought I'd check.) Dave On Fri, 7 Jun 2002, Larry Wall wrote: On Fri, 7 Jun 2002, Dave Storrs wrote: Just to be sure I understood: you meant that (A) yes, you can use fail in a subroutine outside a regex, and (B) if you do, it is no different from die. Is that correct? Depends on the caller's use of use fatal. If they don't use fatal, it returns undef. Larry
Re: Apoc 5 questions/comments
On Mon, 10 Jun 2002, Larry Wall wrote: On Mon, 10 Jun 2002, Dave Storrs wrote: I assume that 'fatal.pm' is a new pragma. Already exists for Perl 5, actually. *blush* Must have missed it. Drat, and I just finished rereading Camel III. Apologies. Dave
Re: Apoc 5 questions/comments
On Fri, 7 Jun 2002, Luke Palmer wrote: Dave Storrs wrote: Can we please have a 'reverse x' modifier that means treat whitespace as literals? Yes, we are living in a Unicode world now and your data could /FATAL ERROR\:Process (\d+) received signal\: (\d+)/ I don't see how this example is nearly as flexible as this: m:w/FATAL ERROR\: Process (\d+) recieved signal\: (\d+)/ Yours will only match 4 spaces after FATAL ERROR:, whereas mine will match any number. [...] I see the :w modifier as a good flexibility enforcement. It will keep people away from matching things that very literally. Respectfully, Luke, I think you and I are discussing separate issues. You are talking about the best way to match multiple whitespace--and I agree with what you're saying, one should never assume that it will always be 4 spaces instead of 5. Were I writing that code in a real project, instead of as a demo for the list, I would use \s+ (in P5, anyway...in P6, whether I would use \s+ or \h+ would depend on circumstances). However, the point I was making was that, if I feel confident in only handling a limited subset of the possibilities because I know what I'm going to be getting (because, e.g., I wrote it out myself), then I would like a way to do away with the visual clutter involved in backwhacking or entity-izing every bit of whitespace. Perl has never been a nanny-language...one of its greatest strengths has always been that it trusts me to make my own decisions and, if I want to shoot myself in the foot, I can. : The suggestions that other people have been making about defining subrules and then building them up in order to make the entire match are good, and in general that's a very powerful technique. However, the lines devoted to those subrules still count as visual clutter, and I'd still like a way to do away with them. Dave
Re: Apoc 5 questions/comments
On Fri, 7 Jun 2002, Damian Conway wrote:
Dave Storrs wrote:
Somehow, this feels like we're trying to roll all of Prolog
into Perl,
No. We're rolling in all of yacc/lex/RecDescent instead. ;-)
And this should reassure me _why_? *grin*
Just to verify, this:
s:3rd /foo3/bar/
would do the 3rd, 4th, and 5th, correct?
Yes, but only if they were consecutive.And it would only replace them with a
single bar.
Sorry, my question was poorly phrased. Good, this did what I
expected it to do.
I am a little unclear on what the difference is between these two:
my foo = $rx;
my foo = m/$rx/;
In Perl 5 terms, the first is equivalent to:
my foo; while (m/\G($rx)/gc) { push foo, $1 }
The first is equivalent to:
my foo; foreach (m/($rx)/g) { push foo, $1 }
That is, the first one is implicitly anchored to the end of the last match, so
the matches have to be contingous. Whereas the second is unanchored, so the
matches can occur anywhere in the string.
Urm...ok. I understand what you've said, (although you said
first is equiv... both times :) but I guess I'll need to go back and
reread A5 to map your answer to the original text.
You could also use the {'...'} construct for comments, but then
you risk warnings about useless use of a string in void context.
Could we automagically turn off that warning inside such constructs, when
the only thing there was a string?
Depends how much Larry wants to discourage inline comments, I guess. ;-)
He's fairly strongly opposed to them.
I don't actually care one way or the other, I was just throwing
out a suggestion.
/ pattern ::: { code() or fail } / # fails entire rule
Farther down:
A pattern nested within a closure is classified as its own rule,
however, so it never gets the chance to pass out of a {...}
closure.
If I understand correctly, that means that this:
/ pattern ::: { $regex or fail } /
would NOT fail the entire rule...correct?
As I understand it, it definitely *would*.
The code:
$regex or fail
has the $regex object in a boolean context, so it matches (if it can)
and returns true or false. If it fails to match the Cor fires off
a failure, which causes the closure to fail, which causes the top-level
regex to backtrack, whereupon it hits the :::, which causes the top-level
rule to immediately fail.
Yikes. Ok, I obviously badly misunderstood that. I'll go back
and reread it. So, can you provide an example of a pattern nested
within a closure, since I obviously didn't understand?
my rx := /(xxx)/;
Should that be a $ instead of a on the rx variable?
That ain't a variable, friend, that there's a gen-u-ine subroutine!
And it's being bound to a regex!!
(It's really just another way to give a regex a name ;-)
Hmmm...what are the implications, here? The results of the match
are passed as arguments to the func? When you run the func, the regex is
called? Something else?
Can subroutines that aren't used in regexen use 'fail' to throw an
exception? If so, how is it different from 'die' when used outside a
regex?
As I understand it, it isn't (currently).
Just to be sure I understood: you meant that (A) yes, you can use
fail in a subroutine outside a regex, and (B) if you do, it is no
different from die. Is that correct?
Dave Storrs
Apoc 5 questions/comments
Well, A5 definitely has my head spinning. The new features seem amazingly
powerful...it almost feels like we're going to have two equally powerful,
equally complex languages living side-by-side: one of them is called
Perl and the other one is called Regexes. Although they may talk to
one another, I really did come away feeling like they were completely
separate animals.
I admit I'm a bit nervous about that...so far, I'm completely sold on
(basically) all the new features and changes in Perl 6, and I'm eagerly
anticipating working with them. But this level of change...I don't know.
I've spent a lot of time getting to be (reasonaly) good at Perl regular
expressions, and I don't like the thought of throwing out all or most of
that effort. Somehow, this feels like we're trying to roll all of Prolog
into Perl, and I'm not sure I personally want to go there (note the
personally...YMMV).
For now, I'm just going to defer worrying about it until I see Exegesis 5,
since past experience has shown me that there is a good chance that all my
fears will be shown to be groundless once concrete examples are being
demonstrated.
In any case, I do have some specific questions:
-
Page 8:
s:3x:3rd /foo/bar/
That changes the 3rd, 6th, and 9th occurrences.
Just to verify, this:
s:3rd /foo3/bar/
would do the 3rd, 4th, and 5th, correct?
-
Page 8:
The u1-u3 mods all say level 1 support. I assume this was a typo, and
they should go (u1 = 'level 1', u2 = 'level 2', u3 = 'level 3').
-
Can modifiers abut the delimiter?
s:3x /foo/bar# most (all?) examples looked like this
s:3x/foo/bar # is this legal?
-
Can we please have a 'reverse x' modifier that means treat whitespace as
literals? Yes, we are living in a Unicode world now and your data could
theoretically be coming in from a different character set than expected.
But there are times when it won't...when (for example), you wrote the data
out yourself, or you're operating on files that are generated and
maintained purely in-house, so they are guaranteed to be in the same
character set as the Perl source code you're writing. I understand the
arguments for the way the defaults are set. I even agree with them. But
you will NEVER convince me that the first example below is not easier to
read than any of the alternatives:
/FATAL ERROR\:Process (\d+) received signal\: (\d+)/
/FATAL ERROR\:\ \ \ \ Process\ (\d+)\ received\ signal\:\ (\d+)/
/FATAL ERROR\: \h+ Process \h+ (\d+) \h+ received \h+ signal: \h+ (\d+)/
/FATAL ERROR\: \s+ Process \s+ (\d+) \s+ received \s+ signal: \s+ (\d+)/
(Yes, I know that the last one matches vertical whitespace and
therefore means something slightly different than the others.)
If this means that we need to store a byte or two to remember what
character set the originally-read-in code was in before being converted to
UTF-8 (or whatever we're using internally), so that we know what character
set to assume literal ws refers to...well, that seems like a small
price to pay for a lot of convenience.
-
Page 9:
my $foo = ?/.../; # boolean context, return whether matched,
my $foo = +/.../; # numeric context, return count of matches
my $foo = _/.../; # string context, return captured/matched string
This 'initial character to force evaluation' rule initially seemed
annoying, but the more I think about it, the more I like it; one
character isn't much to type, and it makes it extremely clear why you're
doing the match (i.e., what you're trying to get back). Kudos to our
Fearless Language Designer!
-
I am a little unclear on what the difference is between these two:
my foo = $rx;
my foo = m/$rx/;
If I understand correctly, it works like this:
my stuff;
$_ = foofoofoo;
$rx = /:each foo/;
for (0..2) { stuff = $rx }
# above line is equialent to following 3 lines:
stuff = ('foo', 'foo', 'foo');
stuff = ();
stuff = ();
for (0..2) { stuff = m/$rx/ }
# above line is equialent to following 3 lines:
stuff = ('foo', 'foo', 'foo');
stuff = ('foo', 'foo', 'foo');
stuff = ('foo', 'foo', 'foo');
Is that correct?
-
Page 10:
You could also use the {'...'} construct for comments, but then
you risk warnings about useless use of a string in void context.
Could we automagically turn off that warning inside such constructs, when
the only thing there was a string? (Perhaps there could be a switch
that prevented it from being turned off, if people really wanted to
see it; if so, make it be OFF by default, so it needs to be enabled,
much like 'use strict.')
-
Page 11:
/ pattern ::: { code() or fail } / # fails entire rule
Farther down:
A pattern nested within a closure is classified as its own rule,
however, so it never gets the chance to pass out of a {...}
closure.
If I understand
Re: 6PAN (was: Half measures all round)
On Tue, 4 Jun 2002, Luke Palmer wrote: On Tue, 4 Jun 2002, Miko O'Sullivan wrote: No configuration files (.e.g .cpan) are necessary. However, you can use a configuration file if you want tp indicate a .cpan-like file cpan --conf ~/.cpan load Date::EzDate What about no configuration file if ~/.6pan's not there, and ~/.6pan if it is. Personally, I'd like it to: 1) work just fine without a config file, 2) if I specify one, it uses that, 3) if I don't specify one, but the default exists, it uses that 4) if it uses a config file (specified or default) it shows the full path to what it's using, so that I have a chance of detecting Trojans and typos if I'm paying attention (I don't need or want it to ask for confirmation, just show a message and maybe 'sleep 1' before continuing) - Authors don't need to indicate dependencies. CPAN figures it out from the use's and require's. CPAN will not accept modules that depend on other modules that aren't on CPAN. (Yes, there might be a chicken and egg problem there, I'm sure we can find a solution.) This leads me to... Having it figure out the dependencies is definitely a major plus. As to how to solve the chicken-and-egg...just provide a way to upload multiple separate modules simultaneously. Dave
named params, @_, and pass-by-reference
On Thu, 11 Apr 2002, Damian Conway wrote:
Piers wrote:
one could always handle the first case
more explicitly by doing:
sub load_data ($filename; $version) {
$version = 1 if _.length 2;
...
}
Err...no. If you specify named parameters, you don't get _.
I'm a couple months behind on the discussion and haven't read
Apoc4 carefully yet, so my apologies if this has already been hashed out.
Something I've always wished for in Perl (which of course I didn't
think of during the RFC period) was a way to have self-documenting
parameter names inside a function, but still maintain pass-by-reference
semantics, and do it all without fancy, hard-to-read aliasing tricks.
Ideally, I want something like:
sub load_data ( \$filename; $version; _ ) {
$filename =~ s{/$}{}; # Affects $filename back in caller
my $protocol = shift || 'html'; # shift defaults to _
...
}
Note that here, $filename is pass-by-reference, $version is
pass-by-value, and, if extra arguments are passed, they will come in
through _ so that I can still take advantage of the fact that most list
operators default to _. (Whether the contents of _ are p-b-v or p-b-r
I'm not weighing in on.)
Perhaps using \ in the signature to indicate p-b-r is not the
best...it could confuse people into thinking that they will need to
manually dereference the variable, which they shouldn't need to do.
Is there a way to do this now? If not, will there be a way in
Perl6?
Dave Storrs
Re: named params, @_, and pass-by-reference
[Several people said something like $var is rw will do it) Ah, that's right. I had forgotten about this. Thanks to everyone who responded. Dave
Re: strings: sequence-of-integer ... list of chunks
On Thu, 31 Jan 2002, Bryan C. Warnock wrote: print There's a letter in here!\n if (substr($pi, 0, 200) =~ /[a-z]/); *shrug* I actually did think of that when I first proposed this; doesn't substr make a fresh copy of the string? (I honestly don't know.) What happens if you take a substring of a generator? Have you just used up the first 200 characters? What if I the thing I'm matching on is tied, and taking a substring of it has side effects? Plus the fact that, folding this functionality into the regex engine gives us an extra set of tools for doing optimizations with...if we can determine that their pattern cannot match more than N characters, then we can stop after N characters, without having to take substrs or such. I assume we're going to have this ability in the RE for its own use...why not make it directly available to the user? Dave
Re: strings: sequence-of-integer ... list of chunks
On Thu, 31 Jan 2002, Dan Sugalski wrote:
There is an issue of time--what do we do, for example, in the case:
my $pi = Pi::Generate;
if ($pi =~ /[a-z]) {
print There's a letter in here!\n;
}
if Pi::Generate returns a generator object that will calculate pi for
you to however far you want, that regex will run forever or until it
runs out of memory, whichever comes first.
--
Just a thought...the following would be *really* cool:
my $pi = Pi::Generate;
# Check the first 200 characters only; halt w/success if NO match
print There's a letter in here!\n if ($pi =~ /[a-z]/h200t);
# Check the first 200 characters only; halt w/failure if NO match
print There's a letter in here!\n if ($pi =~ /[a-z]/h200f);
This would be useful for cases where you might be dealing with
infinite data, or when you are only going to need to use the first section
of a string.
Dave
Re: Apoc 4: The skip keyword
On Wed, 30 Jan 2002, Ted Ashton wrote: Thus it was written in the epistle of Dave Hartnoll, Oh, one other tweak. The RFC proposes to overload next to mean fall through to the next case. I don't think [...] I would like to suggest a different keyword that does not imply some `jumping' action. For years, I have used `nobreak' in my C code when I want to indicate that a case fall-through is intentional: [...] skip was uncomfortable when I read it (I at first took it to mean skip over the following rather than skip to the following), but I find nobreak also a bit strange. How about proceed? Ted First, a 'me too' to everything Ted said. Second, to me 'nobreak' is not sufficiently visually distinct from 'break'. Dave Storrs
Re: What can be hyperoperated?
Note: I'm actually not talking about hyperoperators below, or
map/grep/sort. Just 'for'.
On Sat, 26 Jan 2002 12:32:06 -0600, Jonathan Scott Duff wrote:
@result = for @a; @b - $a; $b { $a op $b }
I'd like to chime in withthe people who have already said that the
semicolons are a bit confusing.
I'd like to propose a slightly different syntax. Is this maybe valid, or
have I missed a gaping problem?
# Simplest case: one data source, pulling elements one at a time,
# operating against a constant
@result = for @a - ($a) { $a + 2 }
More formally, this would be:
for LIST - LIST [[, LIST - LIST]...] CLOSURE (returns: LIST)
So, you could write things like so:
# pull elements off two-by-two
for @a - $x, $y { ... }
# flatten @a, @b together, pull elements off two-by-two
for @a, @b - $x, $y { ... }
# pull one off @a, one off @b
for @a - $x,
@b - $y
{ ... }
# pull one off @a, two off @b
for @a - $x,
@b - $y, $z
{ ... }
Of course, all of these only DWIM if - knows that it takes exactly one
item on the left, and a list on the right.
As an extra bit of magic, perhaps, when the only thing to the left of -
is a scalar, it could reduce to this (in Perl5 terms):
# This Perl6:
for $_ - $x { ... }
# is the same as this Perl5:
{
my $x = $_;
local ($_);
{ ... }
}
Dave Storrs
The Lost String Functions
In strings.pod, the following string functions are documented and (most|all) are already implemented: DOCUMENTED: chopn concat length substr string_nprintf However, Perl5 also includes the following functions that operate on or otherwise relate to strings: IN PERL5: chomp chr crypt hex index lc lcfirst oct ord pack q/STRING/ qq/STRING/ reverse rindex tr/// uc ucfirst y/// Are these latter functions going to receive opcodes and vtable entries of their own? Or will they be composites of lower level ops? (Simon, I remember that you said you wanted to hold on vtable modifications for the nonce; and thank _you_ for remembering me! :) Dave
string vtable editing script
I've been offline for a few days and haven't caught up on email yet
(nor, most likely, will I ever), so I hope no one else has already
done this, but
Attached is a file, msv.tar.gz which contains a simple script and .pm
file (*) for editing the string vtable. It asks you for a bunch of
typedef/function_name pairs and then rewrites string.h, string.c, and
all of the encoding code files (strnative.c, strforeign.c, strutf*.c),
incorporating what you gave it.
PROS:
- you can give it as many typedef/function pairs as you want at once
- it adds your new typedef only if it isn't already there
- before adding your new function, it checks the vtable in string.h to
make sure that there isn't already an identical function, or one that
differs only by return type
- it understands that (e.g.) 'two_strings_to_iv_t' should expand to:
IV (*two_strings_to_iv_t)(STRING *, STRING *);
(Actually, it understands numbers up to nine, but I hope you never go
that high.)
- it sets up stubs in string.c and all the encoding files, and adds
the appropriate entry to each file's vtable
- if your encoding files don't exist, it will generate them for you
CONS:
- your typedefs must match: type+_to_type_t where type is
composed only of word characters. The arguments (the part before the
'to') must be separated by underscores. So, these are legal:
string_to_string_t
iv_nv_to_string_t
three_strings_nv_to_nv_t OR three_string_nv_to_nv_t (same thing)
these are not legal:
(*_t (not a valid symbol)
string_string_t (doesn't specify a return type)
worst of all, this doesn't work:
substr_t(the patch to change it to an accepted version
is below)
- any comments that you put in the vtable or the typedef section will
be stomped the next time you run the program. If people actually use
this and find it useful, I will fix this misbehaviour.
NOTES:
- the stubs that are put into string.c and the encoding tables don't
have names for their parameters, since the program has no way of
knowing what meaningful names would be.
- the bodies of the stubs consist almost solely of 'FINISH ME', not in
comments (so that it won't compile). There is probably more that I
could make it do for you here, but I wanted to get a working version
out.
- the program uses various parts, including comments, of the string.h
file as delimiters, so if you start making regular manual changes it
might stop working or misbehave.
A sample session (actually a record of the last session I ran before
writing this email) is below. I've put my inputs on the line
following the prompt and indented them to make them stand out.
CUT HERE--
Enter a function name (e.g. chopn), or RET to quit:
reverse
Enter a typedef name (e.g. iv_to_iv_t) to associate with reverse:
string_to_string_t
Enter a function name (e.g. chopn), or RET to quit:
About to rewrite string.h...
Successfully wrote revised text to 'string.h.working'
About to rewrite string.c...
Successfully wrote revised text to 'string.c.working'
About to rewrite encoding files...
Successfully wrote revised text to 'strforeign.c.working'
Successfully wrote revised text to 'strnative.c.working'
Successfully wrote revised text to 'strutf16.c.working'
Successfully wrote revised text to 'strutf32.c.working'
Successfully wrote revised text to 'strutf8.c.working'
About to move working copies to primary versions...
Successfully moved working file 'strforeign.c.working' to 'strforeign.c'
Successfully moved working file 'strutf32.c.working' to 'strutf32.c'
Successfully moved working file 'strutf16.c.working' to 'strutf16.c'
Successfully moved working file 'strutf8.c.working' to 'strutf8.c'
Successfully moved working file 'strnative.c.working' to 'strnative.c'
Successfully moved working file 'string.h.working' to 'string.h'
Successfully moved working file 'string.c.working' to 'string.c'
./msv.pl completed successfully.
$ [edit string.c and strnative.c]
$ [compile and test]
$ [celebrate by submitting]
Here is the patch to change substr_t into something this program can
accept:
[dstorrs@localhost parrot]$ cvsp -q diff -c string.h
-- DIFF OUTPUT STARTS ON NEXT LINE ---
Index: string.h
===
RCS file: /home/perlcvs/parrot/string.h,v
retrieving revision 1.5
diff -u -d -c -r1.5 string.h
cvs server: conflicting specifications of output style
*** string.h2001/09/14 14:08:00 1.5
--- string.h2001/09/16 03:54:37
***
*** 25,31
typedef IV (*string_to_iv_t)(STRING *);
typedef STRING* (*string_iv_to_string_t)(STRING *, IV);
typedef STRING* (*two_strings_iv_to_string_t)(STRING *, STRING *, IV);
! typedef STRING* (*substr_t)(STRING*, IV, IV, STRING*);
typedef IV (*iv_to_iv_t)(IV);
struct string_vtable {
--- 25,31
typedef IV (*string_to_iv_t)(STRING *);
typedef STRING*
Re: String API
(As previously remarked, I'm trying to catch up from a few days offline, so excuse me if this is OOD.) On Tue, 11 Sep 2001, Ken Fox wrote: The interpreter knows the internals of the stack structure and is responsible for managing it. To change the stack implementation, we'll have to carefully examine all the interpreter code. The semantics of the stack aren't real clear either. For example, when changing the stack code what invariants must be preserved? If the stack had an API the interpreter used I think this would be much clearer. If we defined that API as a series of tests, we might save ourselves a lot of grief. I'll volunteer to (attempt to) write the tests, if someone will specify what the invariants are. Dave
Re: RFC 289 (v1) Generate module dependencies easily
How would this handle code and/or packages that are generated at run time? Or would that be another caveat? Dave On Fri, 31 Aug 2001, Steve Simmons wrote: Perl6 should ship with a simple utility that shows all modules a program uses, and all modules those modules use. Presumably with the caveat that no usage list can be generated for any missing modules.
Re: Source/Program metadata from within a program
On Fri, 31 Aug 2001, Bryan C. Warnock wrote: Access to the source code. Particularly comments and POD. I'd also like to be able to access information on the particular perl that is running this program...e.g., does it support 64-bit nums, what is the endianness of the native numbers, does it support threads and (if so) what threading model (though this is probably a moot point in P6, perhaps it is something that could be included into 5.8.x). Dave Storrs
PDD for the debugger API
=head1 TITLE API for the Perl 6 debugger. =head1 VERSION 1 =head2 CURRENT Maintainer: David Storrs ([EMAIL PROTECTED]) Class: Internals PDD Number: ? Version: 1 Status: Developing Last Modified: August 18, 2001 PDD Format: 1 Language: English =head2 HISTORY =over 4 =item Version 1 First version =back =head1 CHANGES None. First version =head1 ABSTRACT This PDD describes the API for the Perl6 debugger. =head1 DESCRIPTION The following is a simple English-language description of the functionality that we need. Implementation is described in a later section. Descriptions are broken out by which major system will need to provide the functionality (interpreter, optimizer, etc) and the major systems are arranged in (more or less) the order in which the code passes through them. Within each section, functionality is arranged according to (hopefully) logical groupings. =head2 Compiler =head3 Generating Code on the Fly =over 4 =item * Compile and return the bytecode stream for a given expression. Used for evals of user-specified code and edit/JIT compiling of source. Should be able to compile in any specified context (e.g., scalar, array, etc). =item * Show the bytecode stream emitted by a particular expression, either a part of the source or user-specified. (This is basically just the above method with a 'print' statement wrapped around it.) =back # Closes 'Generating Code on the Fly' section =head2 Optimizer =head3 Generating and Comparing Optimizations =over 4 =item * Optimize a specified bytecode stream in place. =item * Return an optimized copy of the specified bytecode stream. =item * Show the diffs between two bytecode streams (presumably pre- and post-optimization versions of the same stream). =back # Closes 'Generating and Comparing Optimizations' section =head2 Interpreter =head3 Manipulating the Bytecode Stream =over 4 =item * Display the bytecodes for a particular region. =item * Fetch the next bytecode from the indicated stream. // @@NOTE: from a design perspective, this is nicer than doing (*bcs) everywhere, but we definitely don't want to pay a function call overhead every time we fetch a bytecode. Can we rely on all compilers to inline this properly? =item * Append/prepend all the bytecodes in 'source_stream' to 'dest_stream'. Used for things like JIT compilation. =back # Closes 'Manipulating the Bytecode Stream' section =head3 Locating Various Points in the Code =over 4 =item * Locate the beginning of the next Perl expression in the specified bytestream (which could be, but is not necessarily, the head of the stream). =item * Locate the beginning of the next Perl source line in the specified bytestream (which could be, but is not necessarily, the head of the stream). =item * Search the specified bytestream for the specified bytecode. Return the original bytecode stream, less everything up to the located bytecode. // @@NOTE: Should the return stream include the searched-for bytecode or not? In general, I think this will be used to search for 'return' bytecodes, in order to support the step out of function functionality. In that case, it would be more convenient if the return were Bnot there. =item * Search the specified bytecode stream for the specified line number. This line may appear in the current module (the default), or in another module, which must then be specified. =item * Search the specified bytecode stream for the beginning of the specified subroutine. =item * Locates the beginning of the source line which called the function for which the current stack frame was created. =item * Locate the next point, or all points, where a specified file is 'use'd or 'require'd =back # Closes 'Locating Various Points in the Code' section. =head3 Moving Through the Code =over 4 =item * Continue executing code, stop at end of code or first breakpoint found. =item * Continue up to a specified line, ignoring breakpoints on the way. =item * In the source which produced a specified bytecode stream, search forwards for a specified pattern. =item * In the source which produced a specified bytecode stream, search backwards for a specified pattern. =item * In the source which produced a specified bytecode stream, search forwards for lines where expression is satisfied =item * In the source which produced a specified bytecode stream, search backwards for lines where expression is satisfied =back # Closes 'Moving through the Code' =head3 Variable and Code Manipulation =over 4 =item * List all subroutines in a particular module (or all modules). =item * Locate the file containing the definition of the specified func/method. =item * Fetch an element from a specified (default: main::) symbol table. =item * Fetch all elements from a specified (default: main::) symbol table. =item * Set an element of a specified symbol table. =item * Retrieve an element from a
Re: Semi-OT: Good compiler book?
The Dragon Book is (AFAIK) still considered the definitive book on the subject. It's called that because it has (or at least, had, for the edition that I bought) a red dragon on the cover. The official title is: Compilers : Principles, Techniques, and Tools by Alfred V. Aho, Ravi Sethi, Jeffrey D. Ullman (Contributor) ISBN: 0201100886 You can get it from Fatbrain: http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0201100886vm= Dave On Tue, 7 Aug 2001, Brent Dax wrote: I'm going on vacation soon, and I'd like to get a good book on writing compilers--hopefully one that will help me when we actually start coding Perl 6. Any suggestions? I have no formal education on compilers, and I only know C, C++ and Perl (duh). (If this is too off-topic, let me know.) Thanks, --Brent Dax [EMAIL PROTECTED]
Re: as long as we are discussing 'nice to have's...
On Sun, 22 Jul 2001, Johan Vromans wrote: Dave Storrs [EMAIL PROTECTED] writes: I discovered today that I had forgotten to put 'use strict' at the top of one of my modules...it was in the script that _used_ the module, but not in the module itself. Putting it in instantly caught several annoying bugs that I'd been trying to track down. It would be nice if there was a use strict 'recursive'; Good reasoning, although this occurs to me as trying to kill a fly with a nuclear bomb. Ah, but note that, while using a nuke as a flyswatter may be massive overkill, it is also very _effective_. : The essence of modules is that they are independent, and are unaffected by outside pragmata. This is what makes them reusable. A 'recursive' pragma would break that. True, a recursive pragma would break a module's ability to manage its own internals as it pleases. However, if I _want_ them to be affected, there is no reason they shouldn't be...it's like any other powerful technique; if I misapply it, I am responsible for the consequences. Dave
Re: as long as we are discussing 'nice to have's...
On Sat, 21 Jul 2001, Dan Brian wrote: The debugger API PDD that I submitted a couple of days ago suggested that we incorporate a profiler into the core. What do people think of this idea? I think that with a clean API, many third-party profilers could and would be created. I am skeptical of the value of putting it in the core, when a well-designed API would exist specifically with the end of getting some of that work out of the porter's pockets, and instead allow the World to develop their own, much as it currently happens with Java. A good point. There should definitely be a clean API so that other people can develop their own profilers which could then be plugged in. This still leaves the question though...should core provide a default profiler? Dave
Re: as long as we are discussing 'nice to have's...
On Sat, 21 Jul 2001 [EMAIL PROTECTED] wrote: On Sat, Jul 21, 2001 at 02:47:43PM -0700, Dave Storrs wrote: It would be nice if there was a use strict 'recursive'; option that you could set in a script or module (package, whatever) which would force all the modules it used to operate under strict. HUGE MASSIVE PROBLEM HERE! This might be useful if *all* the modules you use and *all* the modules which are then used are *all* under your control and that none of them are have elected to *not* use strict for some reason (like Exporter, which would be silly to use strict 'refs'). Otherwise, you're just causing unnecessary bugs. Please note that I addressed this in my original post. This was the specific reason that I suggested the exclude option. Second topic: The debugger API PDD that I submitted a couple of days ago suggested that we incorporate a profiler into the core. What do people think of this idea? You mean like Devel::DProf, the profiler that's already in the core? ;) And is this new debugger API like the current debugger API, DB.pm? (Actually, I hope it isn't. Just making sure you're aware of what's already there.) No, I do not mean something like Devel::DProf; that is a module. I mean something that is in the core binary, the same way that the perl debugger is in the core binary. Perhaps I should have made a distinction between 'core' meaning inside the perl binary and 'core' meaning distributed in the default bundle which includes the perl binary and a whole slew of Perl- and/or XS-based modules. I agree that it should be possible to use any debugger and/or profiler you choose. I am simply asking if we should provide a default profiler, in the core binary, which will be invoked when no other profiler is specified. Dave
as long as we are discussing 'nice to have's...
First topic: I discovered today that I had forgotten to put 'use strict' at the top of one of my modules...it was in the script that _used_ the module, but not in the module itself. Putting it in instantly caught several annoying bugs that I'd been trying to track down. It would be nice if there was a use strict 'recursive'; option that you could set in a script or module (package, whatever) which would force all the modules it used to operate under strict. Perhaps we could even extend it to (something like): use strict 'recursive:except' qw(DBI, CGI, MyFoo); I don't care about the syntax, as long as it's clear what's intended (which I hope this is). ( PS As often happens with Perl, it may well be that this already exists and I've just never run across it. If so, I will happily RTFM if someone will just point me to the appropriate part of the FM. ) Second topic: The debugger API PDD that I submitted a couple of days ago suggested that we incorporate a profiler into the core. What do people think of this idea? Dave
re: time travel paradoxes (was Re: Multi-dimensional arrays andrelational db data)
On Mon, 11 Jun 2001, Daniel S. Wilkerson wrote: For example, the going back in time and preventing your grandparents from having sex situation. Bah, who needs sex these days? A little in vitro here, a little cloning with genetic tweaking there...a whole new person, no sex involved! ... [freeze some eggs, then] Whenever you wish You thaw them out to romance wigglies In a Petrie Dish Then plant the little goober in a girl of seventeen Who's into natural living And prevention magazine No fuss, no muss, no stretch marks (Well not on *you*) Maternal instinct satisfied The modern thing to do. ... --Christine Lavin, Biological Time Bomb
Re: $foo.Foun (was Re: Properties and stricture)
On Thu, 7 Jun 2001, Michael G Schwern wrote: On Wed, Jun 06, 2001 at 01:37:23AM -0500, Me wrote: BD languages What's BD? Bondage and Discipline, scum! You're not a good enough programmer to be trusted not to make mistakes! Now drop and give me fifty! Hmmm...Michael, I think you're a little off there...that seems more like you are providing an example of a DI (Drill Instructor) language. I think a BD language would be more like: Bondage and Discipline, boy! I told you to use KR indentation style and you deliberately disobeyed! Crawl and lick my keyboard! Dave
Re: suggested properties of operator results
On Fri, 8 Jun 2001, Chris Hostetter wrote:
After reading the Apocalypse Exegesis articles, and seeing some examples
of properties and the is operator, I'd like to suggest that the
less-then operator be changed, so it is functionally equivalent to:
$v2 = VALUE2;
$v1 = (defined VALUE1.valueR ? VALUE1.valueR : VALUE1);
return ($v2-$v1 == abs($v2-$v1)) is valueR($v2);
which (assuming the operator's association was changed to left) would
cause the following code to mean what beginning programmers always think it
should mean:
if ($foo $bar $baz) { ... }
It should be obvious how = = lt gt le ge can similarly
be modified. Then even this would make sense...
if ($foo = $bar $yak lt $wak) { ... }
For certain definitions of sense. :
Seriously, I have several thoughts on this:
1) The do this because it will be more intuitive for beginners
argument comes up a lot, and is pretty appealing at first. However, as
someone (was it tchrist?) pointed out, beginners don't stay beginners for
long, so writing a language for beginners may cost you people when they
grow out of your language. I don't this we should do this just because
it would be better for beginners; if we're going to do it, let's do it
because it is a good feature.
2) This feature would be very prone to abuse (makes it easier to
obfuscate code), but that isn't a reason to disqualify something either.
3) Used for what it is intended for, it seems like a very concise,
expressive way to do multiple relationship tests without needing all those
s and such. If we assume that these expressions read from left to
right by overlapped pairs, so that these are equivalent:
($foo $bar $baz $jaz)
(($foo $bar) ($bar $baz) ($baz $jaz))
...then I don't think we're giving up any comprehensibility, and
we are gaining conciseness. I vote 'yes' (fwiw).
Dave
Re: Properties and stricture
On Tue, 5 Jun 2001, Michael G Schwern wrote: On Tue, Jun 05, 2001 at 01:34:35PM -0700, Daniel S. Wilkerson wrote: I cannot imagine running an enterprise critical application As a complete digression, can we please strike the term enterprise from the English lexicon? Completely redundant and drives me up the wall. Almost as bad as ecommerce. But if we did, how could we hope to get a good new Star Trek series? : Dave
Re: PDD 2nd go: Conventions and Guidelines for Perl Source Code
On Tue, 5 Jun 2001, Hugo wrote: I'd also like to see a specification for indentation when breaking long lines. Fwiw, the style that I prefer is: someFunc( really_long_param_1, (long_parm2 || parm3), really_long_other_param ); or, for really complex expressions: ( really_long_param_1 (parm1 || long_parm1) ( yet_another_long_param parm2 (long_parm2 || parm3) ) ); Putting the final close paren on the next line makes it easier to tell where the (sub)expression finishes. Dave
Re: Properties and stricture
On Tue, 5 Jun 2001 [EMAIL PROTECTED] wrote: So I'd say no, Perl can't know at compile-time if your method is declared or not. Only in certain restricted cases, such as if you don't inherit from anything, or if *all* your parent classes are declared strictly. (By 'strictly', I think you mean 'all methods (etc) are declared explicitly in code, not generated by AUTOLOAD, etc'. If I'm not understanding you correctly, please correct me.) Couldn't we still have a 'be-super-strict' flag that would throw warnings upon encountering a construct that would interfere with compile-time checking? Make it be off by default, of course, but if people want Perl to help them check this kind of thing, it should be possible. Dave
Re: Stacks, registers, and bytecode. (Oh, my!)
On Tue, 5 Jun 2001, Dave Mitchell wrote: dispatch loop. I'd much rather have a 'regex start' opcode which calls a separate dispath loop function, and which then interprets any further ops in the bytestream as regex ops. That way we double the number of 8-bit ops, and can have all the regex-specific state variables (s, send etc in the earlier example) and logic separated out. This is an interesting idea...could we use this more generally to multiply our number of opcodes? Basically, you have one set of opcodes for (e.g.) string parsing, one set for math, etc, all of which have the same value. Then you have a set of opcodes that tells the interpreter which opcode table to look in. The 'switching' opcodes then become overhead, but if there aren't too many of those, perhaps its acceptable. And it would mean that we could specialize the opcodes a great deal more (if, of course, that is desirable), and still have them fit in an octet. (Sorry if this is a stupid question, but please be patient; I've never done internals stuff before.) Dave
Re: properties
On Tue, 22 May 2001, Graham Barr wrote:
On Tue, May 22, 2001 at 12:29:33PM +1000, Damian Conway wrote:
We actually want the possibility of that kind of namespace collision:
for polymorphism.
Many people keep bringig this up as a confusion and you give the same reply.
With the current approach I can see most code accessing properties with
$var.prop{name}
because they want to make sure they get the property and not a method, whereas
it would be shorter, in the common case, to have something like $var'name
Graham.
I am one of the people who brought this up as confusing and
requested a separate syntax, so I obviously agree with Graham. I would
like to vote against the $var'name suggestion, though, for several
reasons:
- it could conflict with old Perl 4 code (which is still out
there),
- having an unmatched ' screws up most highlighting editors
- I personally think it is an unattractive syntax (MHO)
Dave
Re: properties
On Mon, 21 May 2001, Jonathan Scott Duff wrote: On Mon, May 21, 2001 at 10:01:28AM -0700, Dave Storrs wrote: Would you also advocate separate declarative syntax for variable properties and value properties? That's where I think much confusion will be. Yes, I would. What that syntax would be, I'm not so sure...although the following all have some appear: my $pi is constant; # compile time my $foo is now true;# run time my $pi is always constant; # compile time my $foo is now true;# run time my $pi is_perm constant;# ct my $foo is_temp true; # rt my $pi.perm_prop.constant = 1; # ct my $foo.temp_prop.true = 1; # rt my $pi permanently constant;# ct my $foo transiently true; # rt Actually, of these I probably like the first ones best; each of the others has some warts. Dave
Re: properties
On Mon, 21 May 2001, Jonathan Scott Duff wrote: So, if I have a Dog $spot, here's a little table where a 1 in the M column means $spot has a bark method that says 'woof', 1 in the V column means $spot has a bark variable (compile-time) property that says 'arf' and a 1 in the A column means $spot has a bark value (run-time) property that says 'yip'. MVA $spot.bark (+$spot).bark 000 Error Error 001 yip yip 010 arf Error 011 arf yip 100 woofwoof 101 woofwoof 110 woofwoof 111 woofwoof First of all, thanks for putting this table together; this is good way to clear all the up. Second: I'm afraid that even after all this discussion and puzzling over this table for a bit, I'm still a bit baffled by this stuff. Perhaps I'm just slow, but let's assume for the sake of argument that I'm not the only one still scratching his head. Could we revist the idea of alternate syntax to disambiguate between value and variable cases? Perhaps now that we've freed up the '-' we could use that to access properties on the variable, while '.' continues to be for the value (since that is more consistent with other usages of '.', such as $foo.callSomeMethod() ). Then the table above would look like this (note that this does away with the (+spot).bark syntax that some people feel is ugly): MVA $spot-bark $spot.bark 000 Error Error 001 yip yip 010 arf Error 011 arf yip 100 woofwoof 101 woofwoof 110 woofwoof 111 woofwoof Third, a question about the table above. (+spot).bark evaluates to the value properties, yes? So, shouldn't the 'arf' and 'Error' be switched for 010? Dave
Re: Separate as keyword? (Re: 'is' and action at a distance)
On Fri, 18 May 2001, Nathan Wiger wrote: Maybe there are two different features being conflated here. First, we have is, which is really for assigning permanent properties: my $PI is constant = '3.1415927'; So, those make sense, and we'd want them to remain through assignment. However, the true, error, false, etc, really are *temporary* conditions. Maybe we need a separate keyword - as - for this: return $zero as true; For stuff declared with this as keyword, it would last until next assignment or other value change. That is, these are value dependent and designed to pass extra information along. By definition, though, when the value changes we'll want these properties to change as well. I think you may be onto something here, but I get nervous about as and is being the chosen keywords...they are only one letter apart and the cognitive difference between them is very small(*); I think it would be very easy to mix them up. Dave * For an example of words that are only one letter apart but have a very large cognitive difference, try now and not.
Re: Perl, the new generation
Hmmm...ok, on thinking about it, I generally agree with you. There is only one point that I would debate (and, as you'll see, there's a solution for that one, too): On Wed, 16 May 2001, Nathan Torkington wrote: Dave Storrs writes: 1) One of the great strengths of Perl is that its learning curve is very shallow but very long. Adding more stuff to the language makes the curve steeper, because you need to hold more in your head as you learn it. I see those as orthogonal. I can add more to the high end of a language that beginners don't need to know. While it may be true that beginners don't need to use a particular feature--or even know about it--how will they know that until they have studied it? ACTION = insert($tongue, $cheek) Imagine the following conversation: JAPH: Here's a list of all the features in Perl. It may look overwhelming, but don't worry...you don't need to know all of them until later. Beginner: GAACKK!!! /ACTION Actually, something like what Randal was recently talking about, with the llama (i.e., introduction, small subset, whathaveyou) probably addresses this concern. We just have to make sure to point everyone at that document as soon as possible upon their entry into Perl. Dave
Re: Exegesis2 and the is keyword
Ok, this is basically a bunch of me too!s.
On Tue, 15 May 2001, Nathan Wiger wrote:
Awesome. Simple, Perlish, easy to read, etc. Also, I see you took the
suggestion of:
Access through... Perl 5 Perl 6
= == ==
Array slice @foo[@ns] @foo[@ns]
Hash slice @foo{@ks} %foo{@ks}
Which is kewl since it makes a good amount of sense IMO.
Here's the first one.
$*ARGS is chomped;
I wonder if that wouldn't be better phrased as:
autochomp $*ARGS;# $ARGS.autochomp
[...] I don't think actions should be declared using is,
necessarily. [...] In particular, it puts the action in the passive
voice[...]
It seems actions should be active functions, so:
autoflush $STDERR; # $STDERR.autoflush
$var = read $ARGS;
print $STDOUT Hello, World!\n;
Here's the second one.
:
:$ARGS prompts(Search? ); # Perl 6
:while ($ARGS) {
I'd think I'd rather see that as:
prompt $ARGS Search? ; # $ARGS.prompt(Search? )
Without the extra new ambiguity. Thoughts?
Hmmm...the '$ARGS prompts(Foo?)' version actually works better
for me. I think that, in line with what you said above, 'prompt $ARGS
Foo?' should be interpreted as an action...that is, something that
should be done _right_now_. But I don't want the prompt to be printed
right now...I want it to be printed just before I do a read on the
filehandle. In this case, I really am setting a property, not setting a
property.
I'm not sure what the appropriate way to disambiguate the two is,
or if there even needs to be a specific mechanism (can perl be smart
enough to DWIM on this?). Definitely something to think about.
Dave
Re: Damian Conway's Exegesis 2
On Tue, 15 May 2001, Simon Cozens wrote: On Tue, May 15, 2001 at 03:30:07PM -0700, Dave Storrs wrote: - A while ago, someone suggested that the word 'has' be an alias for 'is', so that when you roll your own properties, you could write more-grammatically-correct statements such as my $var has Colors(3). Since 'are' is being considered as a synonym, is there a possibility that 'has' will make it too? It would be disappointing if a substantial proportion of the built-in keywords were merely syntactic sugar for each other. is|are|has|: seem like far too many ways to express exactly the same concept. I understand your point, but I respectfully disagree with it. Consider that there are about 10 ways to do a loop (map, grep, for, foreach, while, and at least 4 others that I'm not remembering at the moment; before you say it, I grant you there are minor differences between the constructions, so they are not exactly the same concept, but they are very close). Perl has always put an emphasis on reading like grammatical English--see all the Perl poetry, or look at the 'unless' keyword, or the fact that conditionals can be prefix or postfix. Finally, is ':' actually sugar for is? I guess I missed that; I'll go back and read it again. Dave
apology (was Re: Exegesis2 and the is keyword)
I recently received the following email from someone whose name I have snipped. * Dave Storrs [EMAIL PROTECTED] [05/16/2001 08:11]: Ok, this is basically a bunch of me too!s. Keep the snide comments to yourself. Thanks. This was regarding a reply I had made to one of Nathan Wiger's posts in the Re: Exegesis2 and the is keyword thread. This is a case of miscommunication; the bunch of me toos was referring to what _I_ was writing...that is, I was saying that the majority of my email consisted of agreeing with what Nathan had written, which I thought was very well constructed and well thought out. Obviously, I was not clear enough, for which I apologize. Dave
Re: Perl, the new generation
On Wed, 16 May 2001, Nathan Torkington wrote: Dave Storrs writes: SARCASM=EXTREME Everyone, please try to stop the downhill descent of the conversation. This is not just Dave, but others in the thread too. For the record, the original post in this sequence came from David Grove, not from me (David Storrs). My response to David was an attempt at *preventing* a downhill descent...which is why Simon's comment, which came off feeling abrasive to me, bothered me. You're right; I should have refrained from sarcasm and simply asked Simon to please not treat my concerns so dismissively. It sounds like the concern is that each new version of Perl adds features, which programmers use. To be able to maintain or extend code, you need to know those features. Thus, the core knowledge for survival in Perl, is ever-growing. This is what I understood to be David Grove's point (David, please correct me if I have misunderstood). I don't know if I agree with this (I also may not have the background to answer it, since I didn't come on until 5.x), but I do feel, as I said before, that the language is sufficently large that it is hard to hold in one's head and that making it significantly larger would be a cause for concern. Other people may disagree with me on this; it's only my opinion. In some ways I agree with this. In particular, the growing number of modules with an OO interface means that knowing how to use objects is more and more important. This is true, but it could be taken as a counterargument...if there is a growing number of OO modules, that is because a growing number of Perl programmers are accustomed to, and make use of, OO techniques. [single programmer doesn't need advanced features, teams are not used for solving small problems so it is reasonable that they need advanced stuff] So I guess I don't see it as that big a problem. Am I missing something? Well...I'm not sure my concerns are well enough defined to be convincing, but I'll try to lay them out: 1) One of the great strengths of Perl is that its learning curve is very shallow but very long. Adding more stuff to the language makes the curve steeper, because you need to hold more in your head as you learn it. 2) If the language is so big that you can't hold all of its features in your head, then those extra features might as well not exist. Now, after all of the above discussion, I should just say that I'm not convinced that Perl is too big (I think it's _big_, which is different from _too_ big), or that anything that we are adding is going to _make_ it too big. I'm simply trying to point out one side of the argument. Dave Storrs
Re: Perl, the new generation
On Wed, 16 May 2001, Simon Cozens wrote: On Wed, May 16, 2001 at 11:14:57AM -0700, Dave Storrs wrote: afraid of, and to express your concerns about it. However, the way that you chose to do that (Once quick and dirty dies, Perl dies.) implies that the only thing that Perl is good for is q-n-d A veritable lesson in logic! Here's an equivalent statement. Once all the oxygen suddenly disappears from the atmosphere, humanity is wiped out. SARCASM=EXTREME Thank you for your courteous response. I tried very hard to write that email in a rational, logical way, and I'm very glad to see that see people respond in kind. /SARCASM That naturally suggests that the only thing humanity is good for is is respiring oxygen, right? And it's an almost *exactly* equivalent statement, because it's almost as likely that Perl will stop being good for quick 'n' dirty stuff as all the oxygen dropping out of the atmosphere. Oddly enough, you've just restated my exact point...just in a way which, to me at least, seems much more combative. Dave Storrs
RE: Perl, the new generation
On Wed, 16 May 2001, David Grove wrote: For me, it's the bare minimum amount of Perl you must *use* to be productive that I see increasing in our plans and discussions. I'm afraid of Perl turning into a verbose monstrosity to please verbosity addicts of languages whose only point of advocacy is Perl FUD. Once quick and dirty dies, Perl dies. Several thoughts for you, David. All of these should be taken from the perspective of someone who cut his teeth on 5.x and has never had to deal with the (joys|differences|horrors) of 4.x. 1) I agree that Perl is a big language and it's hard to hold it in your head. I frequently find that some bit of it that I haven't used in a while has fallen out and I need to go read up on it again. 2) Respectfully, I don't think that we can accurately say that the minimum amount of Perl needed in order to be productive is increasing; we haven't finished defining P6 yet, so how can we know this? 3) You have every right to be afraid of anything you want to be afraid of, and to express your concerns about it. However, the way that you chose to do that (Once quick and dirty dies, Perl dies.) implies that the only thing that Perl is good for is q-n-d, and this is simply not the case. I have written enterprise-quality code, for large systems, in Perl, and I will absolutely defend Perl's ability on that playing field. 4) While your concern is well taken, I think you are doing yourself a disservice by using such inflammatory language...it makes me (and probably others) focus more on your tone than on your point. Dave Storrs
Re: Perl, the new generation
On Wed, 16 May 2001, Adam Turoff wrote: On Wed, May 16, 2001 at 08:57:42AM -0700, Peter Scott wrote: It doesn't look to me like the amount of Perl one needs to know to achieve a given level of productivity is increasing in volume or complexity at all. What it looks like to me is that there are additional features being added which enable one to achieve greater levels of productivity and performance if one wants to learn them. Who *wants* to be unproductive? I think Peter's point is that you can at least maintain your current level of productivity without doing anything but that, if you take the time to learn the new features, your productivity might go up...not necessarily, since the new features may not help with what your doing, but maybe. (Peter, I'm putting words in your mouth, so correct me if I'm wrong.) Dave
Re: Damian Conway's Exegesis 2
First of all: Damian, thank you for putting this together. This is a really good way to dispell the concerns/doubts/pick-a-word that people (including myself) have been having about whether Perl6 would be the language that we all know and love. There was a great deal of stuff in there and I for one am going to need some time to digest it. My initial reactions are as follows: at first I was alarmed and a bit appalled at a lot of the changes...e.g., the 'HASH $tree is rw' parameter declaration. Jesus, I thought if I wanted a typed languaged, I'd use C++. The more I read, however, the more I became convinced that these were actually elegant Perlisms...you can have exactly as much freedom as you want, if you carry the responsibility for it. Alternatively, you can have Perl do more of the work for you, if you are willing to live with constraints. Elegant. Perlish. Good. The only questions I have at this point are: - Is there a way to declare a property constant/final/choose your keyword? - Is there a way to do a read-only access on a property? - A while ago, someone suggested that the word 'has' be an alias for 'is', so that when you roll your own properties, you could write more-grammatically-correct statements such as my $var has Colors(3). Since 'are' is being considered as a synonym, is there a possibility that 'has' will make it too? - Might it be possible to make properties prefix-able when being used with types, so that it would be possible to say 'my constant int $foo = 0;' ?? It's a minor point, but it would make it easier for people from C-based languages to transfer (whether that's enough of a reason is a separate question.) I understand it would be difficult, since properties work off the 'is' keyword, which returns its left arg; still, I don't see why this is harder (from a programming view) than making 'if' and 'unless' capable of prefix or postfix usage. Dave
