Re: cmd line like switches for functions and operators.
On Tue, 22 Jun 2004, Juerd wrote:
rename -v = 1, $orig, $new;
[snip]
I think just using named arguments would be better and much easier.
sub rename ($old, $new, +$verbose) {
say Renaming '$old' to '$new' if $verbose;
On Tue, 22 Jun 2004, Brent 'Dax' Royal-Gordon wrote:
It's already being done:
rename $orig, $new :verbose;
sub rename($orig, $new, +$verbose) {
say Renaming `$orig' to `$new' if $verbose;
On Tue, 22 Jun 2004, Luke Palmer wrote:
No, builtins can and will have named arguments. And you can even add
your own to builtin functions:
Well, much of what has been said here seems to be quite a bit above my
head as far as my Perl6 knowledge is concerned. However I'd like to
provide some context for my proposal: one motivation is to give yet
more WTDI, and another one is to give a quick'n'easy WTD certain things.
AIUI the first point is already addressed as explained in your mails
above. As for the second one, the key concept is that of suitable
defaults. For example, using Perl5 syntax, here's what I mean:
perl -le 'unlink and print removing $_ or warn something: $!\n for *.txt'
Well, it would be nice if that may just be
perl -e 'unlink *.txt :v'
And here of course I do *not* want to roll my own version of unlink to
manage the verbose info, otherwise it wouldn't be easier than in the
first attempt above. Even if put in a package, it would imply more
typing:
perl -MVerbose -e 'unlink *.txt :v'
^^^ or even more letters!!
Of course you may ask why not using
rm -v *.txt
from start instead, but then there are indeed situations in which perl is
actually useful. For example one I can think of (and done in practice) is
this:
perl -lne 'rename $_, do{($t=$_)=~s/.../.../; $t}' files.txt
^^ fake!
[no strictures for one-liners!]
Well, IMHO it would be a Good Thing(TM) to have a few letters long (or a
one letter long) switch to print verbose info... of course it would be
most useful in one-liners but as many other things it would come handy
also in more complex scripts...
Michele
--
Se non te ne frega nulla e lo consideri un motore usa e getta, vai
pure di avviatore, ma e' un vero delitto. Un po' come vedere un
cavallo che sodomizza un criceto!!!
- Cesare/edizioni modellismo sas su it.hobby.modellismo
A stack for Perl?
This is yet another proposal that is probably a few years late. I've had some (admittedly limited) experience with S-Lang in the past: the language has currently a syntax that resembles much that of C but was originally designed to be strongly stack-based and still is behind the scenes, a consequence of which is that it supports an (undocumented, AFAIK!) alternative RPN syntax. Now Perl is not like that, although internally Perl5's bytecode is stack-based, whereas it's known that Perl6's one will be register-based. However I wonder if an implicit stack could be provided for return()s into void context. It is well known that currently split() in void context has the bad habit of splitting into @_, which is the reason why doing that is deprecated. But it's somewhat anomalous amongst perl's functions I'd say. To be fair I've *never* felt the need to have a stack like that in Perl, but who knows? It may come handy in some cases... Any thoughts? Michele -- Comments should say _why_ something is being done. Oh? My comments always say what _really_ should have happened. :) - Tore Aursand on comp.lang.perl.misc
user-defined operators?
I don't know if this is already provided by current specifications, but since I know of Perl6 that is will support quite a powerful system of function prototyping (signatures?), I wonder wether it will be possible to specify a (finite number of) argument(s) on the left of functions, thus allowing to create user-defined operators. I had tried sml (a functional language) and despite its being really simple if compared to Perl, it provided this functionality... Michele -- Dante, _The Inferno_, in particular the line about, ``Abandon all hope ye who enter here.'' - William F. Adams in comp.text.tex, Re: Book Suggestion for MS Word?
Re: user-defined operators?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michele Dondi wrote: | I don't know if this is already provided by current specifications, but | since I know of Perl6 that is will support quite a powerful system of | function prototyping (signatures?), I wonder wether it will be possible | to specify a (finite number of) argument(s) on the left of functions, thus | allowing to create user-defined operators. I had tried sml (a functional | language) and despite its being really simple if compared to Perl, it | provided this functionality... If SML is anything like Haskell, user-defined operators are really just syntactic sugar around normal function definitions, with appropriate allowances in the grammar for arbitrary operators to exist and be parsed correctly. Haskell also has an interesting backticks operator, which turns any two-argument function into an infix operator, and is generally used for readability purposes. Thus, although you can do modulus with the 'mod' function like this: mod 3 4 you can also write 3 `mod` 4 which can be handy when trying to get an arithmetic-type feel to your programs. I doubt Perl would need something like this though. Haskell of course also lets you do things like infixr 3 +++ which defines a right-associative infix operator at precedence level 3, denoted by the token '+++' and later you can say something like (+++) :: Num a = a - a - a x +++ y = x + y which defines the +++ operator to have exactly the same effect as + (although probably with different precedence, I have no idea what the numeric precedence level of + is in Haskell, and indeed if + is right or left associative, as I always get those two muddled up, so that might be different too) when applied to numbers. Pretty pointless really, unless you wanted a tight-binding + or a backwards one, but you get the idea. Most combinator parsing libraries use user-defined operators to denote parser combination and choice, and GUI libraries tend to use them to denote things like signal connection, property setting and so forth. Wrangling this back to some sort of on-topicness, it would be great if Perl could have user-defined operators that actually work properly. I'm thinking new operator characters (Unicode's got lots left), and also the ability to define short-circuit operators like C's and || (I can't remember what they've become in Perl 6, did they change? I seem to remember them changing). Not being able to do this is a major weakness in C++'s operator overloading, because it effectively means that and || are untouchable unless you really want to mess with other people's heads, and demonstrate the only point operator overloading has against it (that is the potential disruption of expected semantics; this is all IMO of course). So can we at least have the ability to define short-circuit operators, even if we can't define new ones? -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA2rP20UvYjCBpIlARAsFKAJoCBjgP8+wmbQP3XO1HLD+6AC43DQCfVvj3 kTT9cYnblCADyVCWCrpcpD0= =G7FE -END PGP SIGNATURE-
Re: A stack for Perl?
On Thu, Jun 24, 2004 at 12:06:14PM +0200, Michele Dondi wrote: However I wonder if an implicit stack could be provided for return()s into void context. It is well known that currently split() in void context has the bad habit of splitting into @_, which is the reason why doing that is deprecated. But it's somewhat anomalous amongst perl's functions I'd say. To be fair I've *never* felt the need to have a stack like that in Perl, but who knows? It may come handy in some cases... In the interest of laziness, it's best to identify a clear need (and clear semantics!) before implementing something. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
definitions of truth
Every now and then I have this discussion with people at work that involve Perl's ideas of boolean truth. I usually break it down like this: In Perl5, the following values are FALSE: undef, '0', 0, and ''. Anything not in that list is considered TRUE in a boolean context. That means that Perl5 has some notions of truth that confuse some folk. I mean, I can understand 00 being true, even if it seems a little odd to me personally, but \0??? How is a single null byte *true*? Okay, so it's binary data. So is 0 and 0, if you look at it that way. I realize the internal representations are different, but the programmer shouldn't have to care about that. I just figure that if my bit of $data contains one byte, and I'm checking that $data for boolean truth, I'd expect a null to be false, as would ba-zillions of C programmers (from which backgroud I came). I know we aren't trying so hard to imitate C behavior anymore, but still, doesn't this violate the principle of least surprise? So my question is this, with apology for the ramble aside from P6's other changes, is a single null byte of binary data still going to register as TRUE, or will it now be what seems to me the more sensible FALSE? Paul * The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 113
Re: definitions of truth
In Perl5, the following values are FALSE: undef, '0', 0, and ''. What you fail to note is that each of these is false for a reason. undef is false so that you can test an object for truth; if it is undef it obviously contains no data, so it's false. 0 is false so that you can test numbers for truth. '' is false so that you can test strings for truth. The really special case is '0', which is false for arcane (but very sensible) reasons. Okay, so it's binary data. So is 0 and 0, if you look at it that way. The difference here is that there is no normal circumstance wherein you would get a binary null if there's no data. The only situation I can think of that even comes close would be if you were reading null-terminated strings from a C or Assembler program out of some kind of binary file, and in that case you'd almost certainly split on binary null, so you'd get if there were no data in a given string, and that would be false as per the existing rules. Perl is a pragmatic language; things are true (or false) for good reasons, so that you can do various things easily. I realize the internal representations are different, but the programmer shouldn't have to care about that. When are you going to run into binary nulls if you're NOT mucking about with internal representations? I just figure that if my bit of $data = contains one byte, and I'm checking that $data for boolean truth, You can always check the number of bytes (or characters), and it'll be false in boolean context if it's zero: mumblefrotz(\$data) while length $data; So my question is this, with apology for the ramble aside from P6's other changes, is a single null byte of binary data still going to register as TRUE, or will it now be what seems to me the more sensible FALSE? As I understand it, the addition of properties in Perl6 (See the Apocalypse 12 article) allows for even undefined values to be true if you choose to make them so.
Re: user-defined operators?
On Thu, Jun 24, 2004 at 12:34:44PM +0200, Michele Dondi wrote: : I don't know if this is already provided by current specifications, but : since I know of Perl6 that is will support quite a powerful system of : function prototyping (signatures?), I wonder wether it will be possible : to specify a (finite number of) argument(s) on the left of functions, thus : allowing to create user-defined operators. I had tried sml (a functional : language) and despite its being really simple if compared to Perl, it : provided this functionality... Yes, this is already provided for with infix/postfix operators/macros, with the caveat that if you wish to specify multiple arguments to the left, you'll have to do one of: 1) give your operator a looser precedence than comma 2) group the arguments with some kind of brackets or parens to make them a single argument 3) put some kind of introductory macro out front that parses things the way you want 4) write the definition of your infix/postfix macro to have incestuous knowledge of the parser in order to slurp the leftwise arguments that have already been reduced by the ordinary grammar. Simple. :-) Actually, I suspect that infix macros have precedence much like operators, so #4 probably reduces to #1. (Macros differ from ordinary operators in how they treat the subsequent text, not the preceding text.) Larry
Re: definitions of truth
On Thu, 2004-06-24 at 08:04, Jonadab the Unsightly One wrote: In Perl5, the following values are FALSE: undef, '0', 0, and ''. ... The really special case is '0', which is false for arcane (but very sensible) reasons. I don't agree that '0' being false is sensible. This, plus less than vigilant programmers, has led to a great '0' hole, where many Perl programs correctly handle all possible input except for one: a string consisiting of a single 0. To ensure that your program doesn't suffer from the '0' hole, you need to use frob($k) if defined($k) length($k); anywhere you would normally just say frob($k) if $k. This somewhat strange incantation has become idiomatic in Perl5. As a related question, why is 0 false, but 0.0 is true? Floats are second-class citizens? As I understand it, the addition of properties in Perl6 (See the Apocalypse 12 article) allows for even undefined values to be true if you choose to make them so. That's the way I understand it too. You can also do the same in reverse, making it so your function can return, say, Failure! but evaluate to false. However, it seems that because Perl is finally getting a typing system, this hack can be fixed in Perl itself! No programmer intervention needed. Undef and '' can be false for strings, undef and 0 can be false for integers, undef, 0, and 0.0 can be false for floats, etc. Unfortunately, so that machine-converted Perl5 code still works, I think that untyped variables will probably still need to follow this oddball rule. Am I understanding correctly? Thanks, - Scott
Re: user-defined operators?
On Thu, Jun 24, 2004 at 11:59:03AM +0100, Matthew Walton wrote: : -BEGIN PGP SIGNED MESSAGE- : Hash: SHA1 : : Michele Dondi wrote: : : | I don't know if this is already provided by current specifications, but : | since I know of Perl6 that is will support quite a powerful system of : | function prototyping (signatures?), I wonder wether it will be possible : | to specify a (finite number of) argument(s) on the left of functions, thus : | allowing to create user-defined operators. I had tried sml (a functional : | language) and despite its being really simple if compared to Perl, it : | provided this functionality... : : If SML is anything like Haskell, user-defined operators are really just : syntactic sugar around normal function definitions, with appropriate : allowances in the grammar for arbitrary operators to exist and be parsed : correctly. Same in Perl 6. For instance, to call the binary addition operator C $a + $b by its true name, you'd say C infix:+($a,$b) . When you define an operator, you always use the true name form. : Haskell also has an interesting backticks operator, which turns any : two-argument function into an infix operator, and is generally used for : readability purposes. Thus, although you can do modulus with the 'mod' : function like this: : : mod 3 4 : : you can also write : : 3 `mod` 4 : : which can be handy when trying to get an arithmetic-type feel to your : programs. I doubt Perl would need something like this though. It would be easy to define a meta-operator in Perl 6 to do this, but I also doubt that Perl will need it to be standard. : Haskell of course also lets you do things like : : infixr 3 +++ : : which defines a right-associative infix operator at precedence level 3, : denoted by the token '+++' : : and later you can say something like : : (+++) :: Num a = a - a - a : x +++ y = x + y : : which defines the +++ operator to have exactly the same effect as + : (although probably with different precedence, I have no idea what the : numeric precedence level of + is in Haskell, and indeed if + is right or : left associative, as I always get those two muddled up, so that might be : different too) when applied to numbers. Pretty pointless really, unless : you wanted a tight-binding + or a backwards one, but you get the idea. : Most combinator parsing libraries use user-defined operators to denote : parser combination and choice, and GUI libraries tend to use them to : denote things like signal connection, property setting and so forth. And here we see a weakness of Haskell's approach: you need to know the numeric precedence level. In Perl 6, all precedence levels are defined relative to existing operators. You don't have to care about the numeric level, and in fact, the actual precedence levels are probably encoded with strings internally rather than numbers, because that makes it trivial to add an arbitrary number of precedence levels between any other two precedence levels without having to resequence. Precedence levels are a bit like surreal numbers in that respect. But the user doesn't have to know that... : Wrangling this back to some sort of on-topicness, it would be great if : Perl could have user-defined operators that actually work properly. I'm : thinking new operator characters (Unicode's got lots left), Gee, I'm thinking the same thing. Fancy that. 'Course, the fact that I already said as much in the Apocalypses could have something to do with it. :-) : and also the : ability to define short-circuit operators like C's and || (I can't : remember what they've become in Perl 6, did they change? I seem to : remember them changing). Not being able to do this is a major weakness : in C++'s operator overloading, because it effectively means that and : || are untouchable unless you really want to mess with other people's : heads, and demonstrate the only point operator overloading has against : it (that is the potential disruption of expected semantics; this is all : IMO of course). Well, any operator or function that knows how to call a closure can function as a short-circuit operator. The built-in short-circuit operators are a bit special insofar as they're a kind of macro that treats the right side as an implicit closure without you having to put braces around it. No reason in principle you couldn't write your own infix macro to do the same thing. : So can we at least have the ability to define short-circuit operators, : even if we can't define new ones? Already there. You can even define new short-circuit operators. The new ones can even be Unicode operators, if you're willing to go into hiding for the next five years or so till most everyone learns how to type Unicode. Alternately, be willing to stare down the occasional lynch mob... On the other hand, we've tried to make it trivially easy to defer evaluation of a chunk of code. All you have to do is slap some curlies around it. Larry
Re: definitions of truth
On Thu, 2004-06-24 at 10:44, Scott Bronson wrote: I don't agree that '0' being false is sensible... I don't mean to imply that I think it's senseless. Just that, to me, it smells suspiciously like a hack. :) - Scott
Re: definitions of truth
Scott Bronson skribis 2004-06-24 10:44 (-0700): However, it seems that because Perl is finally getting a typing system, this hack can be fixed in Perl itself! No programmer intervention needed. Undef and '' can be false for strings, undef and 0 can be false for integers, undef, 0, and 0.0 can be false for floats, etc. I think this makes sense: string: undef, number: undef, 0 (implies 0.0) other: convert to number and then decide. Anything that can't naturally be converted to a number (i.e. would be invalid syntax if unquoted) is true. /me wanted to write this in Perl 6, but couldn't think of a good way to represent true and false when returning from is_true :) Perhaps having real true and false values (where true cannot be false and false cannot be true) would make a lot of things much easier. I, for one, would like return true; (where true is undef-ish: a keyword that always returns the same value). Juerd
Re: cmd line like switches for functions and operators.
On Tue, Jun 22, 2004 at 11:50:03AM -0600, Luke Palmer wrote:
: That one doesn't work. Named arguments have to come at the end of the
: parameter list (just before the data list, if there is one). This is
: a decision I'm gradually beginning to disagree with, because of:
:
: sub repeat (code, +$times = Inf) {
: code() for 1..$times;
: }
:
: This is a plausable routine. Now look how it's called:
:
: repeat {
: print I'm ;
: print doing ;
: print stuff\n;
: } :times(4);
:
: This is a horrid violation of the end weight principle.
Fer shure.
: Much nicer is the illegal:
:
: repeat :times(4) {
: print I'm ;
: print doing ;
: print stuff\n;
: }
For some time I have been contemplating allowing (at least) a single
closure parameter to come at the end after the list parameter. Otherwise
it becomes rather difficult to write a Cfor loop without chicanery.
It's not clear to me, though, how cascaded if/elsif/else blocks should
come in. I'm leaning towards thinking that it still comes in as a
single closure, but with properties that contain the cascaded closures.
We'll have to be careful to make sure the list can be unambiguously left
out entirely, particularly when we want to pipe to such a function. Also,
a form like
for 1... { foo() }
reminds us that we can't just evaluate the list and pop off the closure at
at run time. :-)
Larry
Re: definitions of truth
On Thu, Jun 24, 2004 at 08:04:10PM +0200, Juerd wrote: : Scott Bronson skribis 2004-06-24 10:44 (-0700): : However, it seems that because Perl is finally getting a typing system, : this hack can be fixed in Perl itself! No programmer intervention : needed. Undef and '' can be false for strings, undef and 0 can be false : for integers, undef, 0, and 0.0 can be false for floats, etc. : : I think this makes sense: : : string: undef, : number: undef, 0 (implies 0.0) : other: convert to number and then decide. Anything that can't : naturally be converted to a number (i.e. would be invalid syntax if : unquoted) is true. Nope, various user-defined types will want to define their own version of truth. That's precisely what you're doing when you say 0 but true, for instance. : /me wanted to write this in Perl 6, but couldn't think of a good way to : represent true and false when returning from is_true :) 0 and 1 works pretty well, according to Professor Boole... :-) : Perhaps having real true and false values (where true cannot be false : and false cannot be true) would make a lot of things much easier. I, for : one, would like return true; (where true is undef-ish: a keyword : that always returns the same value). This is Perl 6. Everything is an object, or at least pretends to be one. Everything has a .boolean method that returns 0 or 1. All conditionals call the .boolean method, at least in the abstract. (The optimizer is free to optimize the method call away for known types within known conditionals, of course. It had better, or evaluating the truth of .boolean will end up calling .boolean again... :-) It's likely that untyped scalars will still treat the string 0 as false, but that any kind of explicitly typed string will treat only the null string as false. (The special 0 rule will not pose as much trouble for Perl 6 as for Perl 5, because most iteration will be done with Cfor rather than Cwhile, and a Cfor terminates when its iterator runs out, not when the data becomes false. Plus we'll have the // operator.) Larry
Re: definitions of truth
Scott Bronson writes: On Thu, 2004-06-24 at 08:04, Jonadab the Unsightly One wrote: In Perl5, the following values are FALSE: undef, '0', 0, and ''. ... The really special case is '0', which is false for arcane (but very sensible) reasons. I don't agree that '0' being false is sensible. But you're fine with 0 being false? 0 and '0' are pretty much interchangeable in Perl 5 -- wherever you can use one, you can use the other and it gets coerced to it. So it really wouldn't make sense to have them being treated differently for truth purposes. As a related question, why is 0 false, but 0.0 is true? Floats are second-class citizens? '0' is the string representation of zero. 0.0 is also zero. But 0 and 0.0 (and 0x, and 2 - 2, and ...) are all the same zero, and all stringify to '0'. '0.0' is not a representation of that same zero; it's a string that would evaluate to zero if converted to a number, but it isn't interchangeable with the other zeros. If you think '0.0' should be false, what about '0x' or '2 - 2' or '$x - $x'? Smylers
Re: definitions of truth
Larry Wall skribis 2004-06-24 11:29 (-0700): This is Perl 6. Everything is an object, or at least pretends to be one. Everything has a .boolean method that returns 0 or 1. All conditionals call the .boolean method, at least in the abstract. (The optimizer is free to optimize the method call away for known types within known conditionals, of course. It had better, or evaluating the truth of .boolean will end up calling .boolean again... :-) I didn't know about the (to-be) existence of .boolean. It makes things fun and easy, though. However, is the name boolean final? I would prefer true, perhaps with a corresponding false. That is, assuming that there will be $foo.defined and $foo.empty. Hm. I wonder where (and if) I read about .empty. Can't find it. not when the data becomes false. Plus we'll have the // operator.) I'll be wanting a length-or. Perl 6 will make coding it easy enough to not need it in the core. But the operator needs a symbol. I'm assuming infix: will work. But will there be a way to ask Perl if syntax can be used without introducing possible ambiguity? A circumfix ++ operator won't work for several reasons. What will Perl do if you try defining one? Please don't say that picking a random sequence of at least 5 different unicode dingbats will be the best way to be sure :) Juerd
Re: definitions of truth
On Thu, Jun 24, 2004 at 08:44:45PM +0200, Juerd wrote: : Larry Wall skribis 2004-06-24 11:29 (-0700): : This is Perl 6. Everything is an object, or at least pretends to be one. : Everything has a .boolean method that returns 0 or 1. All conditionals : call the .boolean method, at least in the abstract. (The optimizer is : free to optimize the method call away for known types within known : conditionals, of course. It had better, or evaluating the truth of : .boolean will end up calling .boolean again... :-) : : I didn't know about the (to-be) existence of .boolean. It makes things : fun and easy, though. : : However, is the name boolean final? I would prefer true, perhaps : with a corresponding false. Well, the type/property name doesn't have to be boolean--it could be truth, instead. But we mustn't confuse the type (false, true) with either true or false. In general, the name of a property is a type, so the truth property is something like boolean or truth, with an underlying base type of bit. According to A12, you can use a value of an enumerated type as a shorthand, so if you say $x.true it's short for something like $x.boolean == boolean::true And when you say 0 but true a whole bunch of magic happens that creates a type with a .boolean method that returns the value true. : That is, assuming that there will be $foo.defined and $foo.empty. Hm. I : wonder where (and if) I read about .empty. Can't find it. I'm afraid .empty was just a p6l speculation. But .defined is a real property/method. : not when the data becomes false. Plus we'll have the // operator.) : : I'll be wanting a length-or. Perl 6 will make coding it easy enough to : not need it in the core. What do you mean by length? Length is not a generic concept in Perl 6, and there is no .length method. You'll have to be more specific about what *kind* of length you're talking about: byte length, codepoint length, grapheme length, element length, etc. However, for most types possessing one or more kinds of length, it works out that the boolean value will be true if there is any length and false otherwise. (Untyped scalars still have the caveat about string 0 though.) So you don't need a length-or at all. (Or if you do, you need it less than Perl 5 did, and we've gotten by without it for quite a while now there.) : But the operator needs a symbol. I'm assuming : infix: will work. But will there be a way to ask Perl if syntax can be : used without introducing possible ambiguity? Good question. I expect we can manage to give an optional warning if one operator completely hides another. On the other hand, it might be intentional. (However, infix: wouldn't necessarily hide anything, since it would only be looked for where an operator is expected. prefix: is another matter... But it's probably a bad idea anyway since you'd screw up the lookahead that determines whether you can drop the parens on a method call.) : A circumfix ++ operator won't work for several reasons. What will Perl : do if you try defining one? Probably depends on whether Perl decides the initial circumfix + is indistinguishable from a unary +. While it's theoretically possible to attempt to parse as circumfix and then backtrack to prefix if that doesn't work, it's probably a bad plan from a human understandability point of view. Backtracking is a wonderful concept till you have to do it. On the other hand, if you declare your circumfix:++ with is forced or some such, then maybe it just hides prefix:+ without a warning. : Please don't say that picking a random sequence of at least 5 different : unicode dingbats will be the best way to be sure :) Oh, I'd never say that. The Perl Way is that the computer always tries insanely hard to serve your needs. In Soviet Russia (and similar places) the computer is served by you. However, visual distinctions might well be the best way to keep the *human* reader clued to his terminal, so you might want to keep those five random dingbats close to hand... Larry
Re: definitions of truth
On Thu, 2004-06-24 at 11:34, Smylers wrote: Scott Bronson writes: But you're fine with 0 being false? 0 and '0' are pretty much interchangeable in Perl 5 -- wherever you can use one, you can use the other and it gets coerced to it. Let's back up... Strings and numbers are meant to be interchangeable in Perls 1 through 5. You should not care if a varaible is represented internally using a string or an int or a float or a bignum or... The problem is, how should Perl compare two values when it doesn't know what they are? Larry solved this by creating a whole new set of operators to explicitly force a context: num str ==vs. eq vs. lt etc. OK, comparison is handled. But what about evaluating to true or false without comparison? The representation problem still exists. If Larry had solved this problem the same way he did comparison, he would have created even more operators and control structures: num str ! vs. not ifvs. sif while vs. swhile For whatever reason, he chose to solve this problem differently. Instead of creating stringy evaluation, he decided to have 0 evaluate false. On the surface, and in practice, this trick seems to work pretty well. Unfortunately, it leaves a lot of weird behavior lying around the edges. What about 0.0? Or 00? And your example, 0x00? Those are all perfectly valid ways of reperesenting 0. If strings and ints truly were interchangeable, all of these strings would be false, woudln't they? And what about when you KNOW an expression should be evaluated as a string? You need to remember to use defined($s) length($s), otherwise you will suffer from the '0' hole (where the string 0 is handled differently from all other strings in your program). So it really wouldn't make sense to have them being treated differently for truth purposes. OK, name another language that does this. Well, other than PHP, whose string handling is even screwier than Perl's. :) I think that Ruby is an example of a scripting language that has solved this problem very well (and I think Python is similar...?). So, in summary, though 0==false appears to work, it leads to a number of strange boundary conditions and, therefore, bugs. It's hard for new programmers to grasp and even old hacks are still sometimes tripped up by it. It just feels inconsistent. That's why I'd love to see this straightened out for Perl6. - Scott
Re: definitions of truth
Larry Wall skribis 2004-06-24 12:24 (-0700):
Well, the type/property name doesn't have to be boolean--it could
be truth, instead.
I understand that 'true' and 'false' can't be used.
However, truth is in the same category as definedness, and
$foo.definedness looks awful :)
Perhaps for conversion to a certain type, simply the type name can be
used as a method. Then $foo.int and $foo.bool make the same kind of
sense. (Or $foo.Int and $foo.Bool, but then int $foo would be strange
(I assume int $foo returns a fully functional scalar integer))
[length-or]
What do you mean by length? [bytes, graphemes, etc]
Good question. Probably byte length. If there is one byte, that has to
represent at least one of the other length-units, right?
Not having 'length' will be hard to get used to. Perhaps I'll try to
make it easier (and thus harder in the longer term) for myself by
defining something that does .isa('Str') ? .chars : .isa('str') ? .bytes
: .isa('Hash') ? .keys : .isa('Array') ? .elements : 1.
Synopsis 6 describes 'str' as 'native string'. Is my assumption that
such a string is one that doesn't have multi-byte characters correct?
Juerd
Re: definitions of truth
Larry Wall wrote: What do you mean by length? For a string, it obviously either means number of bytes or number of characters. Pick one, document it, and let people who want the other semantic use a pragma. I don't think it matters which one you pick as default, as long as it's clearly documented.
Re: cmd line like switches for functions and operators.
Michele Dondi writes:
On Tue, 22 Jun 2004, Juerd wrote:
rename -v = 1, $orig, $new;
[snip]
I think just using named arguments would be better and much easier.
sub rename ($old, $new, +$verbose) {
say Renaming '$old' to '$new' if $verbose;
On Tue, 22 Jun 2004, Brent 'Dax' Royal-Gordon wrote:
It's already being done:
rename $orig, $new :verbose;
sub rename($orig, $new, +$verbose) {
say Renaming `$orig' to `$new' if $verbose;
On Tue, 22 Jun 2004, Luke Palmer wrote:
No, builtins can and will have named arguments. And you can even add
your own to builtin functions:
Well, much of what has been said here seems to be quite a bit above my
head as far as my Perl6 knowledge is concerned. However I'd like to
provide some context for my proposal: one motivation is to give yet
more WTDI, and another one is to give a quick'n'easy WTD certain things.
AIUI the first point is already addressed as explained in your mails
above. As for the second one, the key concept is that of suitable
defaults. For example, using Perl5 syntax, here's what I mean:
perl -le 'unlink and print removing $_ or warn something: $!\n for *.txt'
Well, it would be nice if that may just be
perl -e 'unlink *.txt :v'
Well it's certainly not going to be that, since the glob operator is
going far, far away.
At first I thought it would be a good idea to just make it a perl
command-line argument:
perl -ve 'unlink glob *.txt'
Since it would seem that one-liners would be their primary use. But now
I think about the many times I've written in longer scripts:
print Moving $old to $new\n;
rename $old = $new or die Move failed: $!\n;
# ...
And indeed I would love to have written:
rename $old = $new :verbose;
Instead.
And here of course I do *not* want to roll my own version of unlink to
manage the verbose info, otherwise it wouldn't be easier than in the
first attempt above. Even if put in a package, it would imply more
typing:
perl -MVerbose -e 'unlink *.txt :v'
^^^ or even more letters!!
Oh dear. Not that.
I understand your logic, but I believe this case is tolerable if it need
exist.
Of course you may ask why not using
rm -v *.txt
from start instead, but then there are indeed situations in which perl is
actually useful. For example one I can think of (and done in practice) is
this:
perl -lne 'rename $_, do{($t=$_)=~s/.../.../; $t}' files.txt
^^ fake!
Just as a side note, that awful en passant substitution has been cleaned
up to a functional version something like:
perl -lne 'rename $_, do { .s/.../.../ }' files.txt
Or perhaps:
perl -lne 'rename $_, do { .subst(/.../, { ... }) } files.txt
Luke
Re: A stack for Perl?
Michele Dondi writes: This is yet another proposal that is probably a few years late. I've had some (admittedly limited) experience with S-Lang in the past: the language has currently a syntax that resembles much that of C but was originally designed to be strongly stack-based and still is behind the scenes, a consequence of which is that it supports an (undocumented, AFAIK!) alternative RPN syntax. Now Perl is not like that, although internally Perl5's bytecode is stack-based, whereas it's known that Perl6's one will be register-based. However I wonder if an implicit stack could be provided for return()s into void context. It is well known that currently split() in void context has the bad habit of splitting into @_, which is the reason why doing that is deprecated. But it's somewhat anomalous amongst perl's functions I'd say. To be fair I've *never* felt the need to have a stack like that in Perl, but who knows? It may come handy in some cases... To be honest, I have no idea what you're asking for. Might you explain in a little more detail? Luke
Re: definitions of truth
On Thu, Jun 24, 2004 at 04:19:25PM -0400, Jonadab the Unsightly One wrote: : Larry Wall wrote: : : What do you mean by length? : : For a string, it obviously either means number of bytes or number : of characters. Pick one, document it, and let people who want the : other semantic use a pragma. What do you mean by character? Do you mean codepoint or grapheme? And if grapheme, language dependent or language independent? (Leaving aside the fact that ten years ago character generally meant byte.) : I don't think it matters which one you pick as default, as long : as it's clearly documented. Documentation has not kept people from saying length(@array) over and over in Perl 5. In such cases it's better not to have a default, as long as it's not too onerous to be specific. In Perl 6 you never ask for the length(). You ask for things like bytes(), codepoints(), graphemes(), or elems(). This is an area where clarity must be enforced. Muddy concepts like characters and length will only produce muddy programs. Larry
Re: definitions of truth
Scott Bronson writes: On Thu, 2004-06-24 at 11:34, Smylers wrote: But you're fine with 0 being false? 0 and '0' are pretty much interchangeable in Perl 5 -- wherever you can use one, you can use the other and it gets coerced to it. Let's back up... Strings and numbers are meant to be interchangeable in Perls 1 through 5. You should not care if a varaible is represented internally using a string or an int or a float or a bignum or... Uh-huh. But what about evaluating to true or false without comparison? The representation problem still exists. If Larry had solved this problem the same way he did comparison, he would have created even more operators and control structures: num str ! vs. not ifvs. sif while vs. swhile For whatever reason, he chose to solve this problem differently. Because the above would've been insane: saying that Csif ($x) treats $x as a string would be pretending that Cif always treats its arguments as numbers, but something such as Cif ($x eq 'frog') doesn't have any numbers in it. Instead of creating stringy evaluation, he decided to have 0 evaluate false. On the surface, and in practice, this trick seems to work pretty well. Well, not always, as you point out -- often input of 0 is an edge-case that doesn't do the right thing; it's just that in many programs it's an edge-case that doesn't matter. Larry's plan to drop this in Perl 6 for things explicitly typed as strings sounds sensible to me. I wasn't claiming that having '0' be false is unquestionably a good thing; merely that it makes sense from 0 being false. Unfortunately, it leaves a lot of weird behavior lying around the edges. What about 0.0? Or 00? And your example, 0x00? Those are all perfectly valid ways of reperesenting 0. If strings and ints truly were interchangeable, all of these strings would be false, woudln't they? No; none of the above strings are interchangeable. All of those strings have the numeric value of zero when treated as a number, but then so does the string crumpet. Being interchangeable involves swapping them either way round. If you want to emit the string '0' then you can either use that string or the number zero, and that number can be calculated from an expression or be a constant in your program that is typed in your Perl source code as 0 or 0.0 or 0x00. But if you want to emit the string '0.0' then you have to have that exact string; there is no numeric value at all which is interchangeable with '0.0' such that printing it will yield exactly that output. So 0, 0.0, 0x00, 2 - 2, and '0' _are_ all different ways of representing the same thing; '0.0' is a different thing, which isn't interchangeable with any of the first lot. And what about when you KNOW an expression should be evaluated as a string? You need to remember to use defined($s) length($s), I've honestly never used that; I hadn't even considered it to be an idiom till you mentioned it. For cases when Cif ($s) doesn't apply I've always found Cif (defined $s) to be adequate. What I am looking forward to is the Perl 6 C// operator: when writing Perl 5 I keep finding places where I want to use it and either have to write uglier code or just use C|| and accept that a value of 0 won't be recognized. So it really wouldn't make sense to have them being treated differently for truth purposes. OK, name another language that does this. I'm not really familiar with any other programming language where numbers and strings are used interchangeably, where it isn't necessary to use some explicit conversion function or cast syntax to convert from one to the other. I'm not claiming that Perl 5's way is _the_ definitive right way of doing things, but it is consistent with other aspects of Perl 5. 'MySQL' kind-of blurs the boundaries between numbers and strings. It treats things as false if the evaluate to zero in a numeric context, so '0.00' is false but so is 'stottie'. That is also consistent ... but I get the feeling that defining all non-numeric strings as false wouldn't actually be to your liking either? 'Bash' goes the other way and treats all non-empty strings as true, therefore '0' is true, but so is 0. I think that Ruby is an example of a scripting language that has solved this problem very well I don't know Ruby; could you elaborate how this has been done. Smylers
Re: definitions of truth
Larry Wall [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] This is Perl 6. Everything is an object, or at least pretends to be one. Everything has a .boolean method that returns 0 or 1. All conditionals call the .boolean method, at least in the abstract. My reading of A12 leads me to expect this to be defined as a coercion, using the as operator, not dot: $foo as boolean What am I missing? Dave.
Re: definitions of truth
--- Dave Whipp [EMAIL PROTECTED] wrote: Larry Wall [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] This is Perl 6. Everything is an object, or at least pretends to be one. Everything has a .boolean method that returns 0 or 1. All conditionals call the .boolean method, at least in the abstract. My reading of A12 leads me to expect this to be defined as a coercion, using the as operator, not dot: $foo as boolean What am I missing? This is Perl 6. Everything is an object, or at least pretends to be one. Everything has a .boolean method that returns 0 or 1. :) =Austin
Re: definitions of truth
Austin Hastings skribis 2004-06-24 14:29 (-0700): $foo as boolean This is Perl 6. Everything is an object, or at least pretends to be one. Everything has a .boolean method that returns 0 or 1. If I understand the current design correctly, having both .boolean and casting via as would mean that $foo.boolean and $foo as Bool and $foo as Bit mean the same in boolean context, but the first literally is 1 or 0, the second is true or false and the third is 1 or 0 again. But all this only by default, because every one of these three can be overriden. And actually, I don't think I understand it correctly. It's been a while since I had a feeling of understanding Perl 6 :) Is this complexity really needed? Juerd
Re: definitions of truth
--- Juerd [EMAIL PROTECTED] wrote: Austin Hastings skribis 2004-06-24 14:29 (-0700): $foo as boolean This is Perl 6. Everything is an object, or at least pretends to be one. Everything has a .boolean method that returns 0 or 1. If I understand the current design correctly, having both .boolean and casting via as would mean that $foo.boolean and $foo as Bool and $foo as Bit mean the same in boolean context, but the first literally is 1 or 0, the second is true or false and the third is 1 or 0 again. I don't think so. Specifically, I'd expect $x = 0 but true; print $x.boolean; # 1 print ($x as Bit); # 0 # (I don't know about 'Bool') Is this complexity really needed? I'd say yeah, it is. 0-but-true is pretty nice to have. (Finally the system calls can return something other than -1.) Juerd =Austin
Re: definitions of truth
Austin Hastings skribis 2004-06-24 15:54 (-0700): I'd say yeah, it is. 0-but-true is pretty nice to have. (Finally the system calls can return something other than -1.) That we already have. 0 but true. (perldoc -f fcntl) It's 1 but false that's really special :) Juerd
Re: definitions of truth
On Thu, Jun 24, 2004 at 03:24:25PM -0700, Scott Walters wrote: : I want an okay. Routines should be able to return okay to indicate : an ambivalent degree of success. okay would be defined as true | false, Some messages want to be simultaneously Warnocked and not Warnocked... Larry
Slices
Come the glorious age of Perl6, will hash slices be enhanced to allow
things like the following?
[EMAIL PROTECTED]'expected'} = [EMAIL PROTECTED];
Specifically, having the slice be something other than the last element.
This likely dictates having {} be able access a list of of hashrefs, not
just a single hashref or hash.
Comments?
Re: Slices
Rod Adams writes:
Come the glorious age of Perl6, will hash slices be enhanced to allow
things like the following?
[EMAIL PROTECTED]'expected'} = [EMAIL PROTECTED];
Well, you can always do this:
[EMAIL PROTECTED] = [EMAIL PROTECTED];
But I definitely look forward to the definitions of the slice semantics
coming in... A8 is it?
Luke
Specifically, having the slice be something other than the last element.
This likely dictates having {} be able access a list of of hashrefs, not
just a single hashref or hash.
Comments?
RE: definitions of truth
-Original Message- From: Dave Whipp [mailto:[EMAIL PROTECTED] Sent: Thursday, June 24, 2004 5:22 PM To: [EMAIL PROTECTED] Subject: Re: definitions of truth Larry Wall [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] This is Perl 6. Everything is an object, or at least pretends to be one. Everything has a .boolean method that returns 0 or 1. All conditionals call the .boolean method, at least in the abstract. My reading of A12 leads me to expect this to be defined as a coercion, using the as operator, not dot: $foo as boolean What am I missing? Why not just use say ?$foo Isn't the prefix ? operator designed specifically for this use? Joe Gottman
Re: definitions of truth
On Thu, 2004-06-24 at 14:17, Smylers wrote: Because the above would've been insane: saying that Csif ($x) treats $x as a string would be pretending that Cif always treats its arguments as numbers, but something such as Cif ($x eq 'frog') doesn't have any numbers in it. Doesn't it? perl -e '$x = frog; print(($x eq frog) . \n);' No; none of the above strings are interchangeable. All of those strings have the numeric value of zero when treated as a number, but then so does the string crumpet. Being interchangeable involves swapping them either way round. Erm, we're talking about boolean context, right? All those strings evaluate to true. I'm asking about being interchangeable when used in a conditional statement; of course they're not interchangeable with each other. :) Larry's plan to drop this in Perl 6 for things explicitly typed as strings sounds sensible to me. That's the plan? Happy day! I was not aware of that. Because I didn't see anything about this in Perl 6 Essentials, I just figured that Perl5's '0'==undef was being brought forward into Perl6. The horror! Sorry for the bad assumption. :) - Scott
Re: definitions of truth
I seemed to have opened a can of worms, lol
But did anybody see the one that had something to do with my question
crawling around? (I've obviously missed a couple of messages. They're
probably hanging out down at the router in the cyberspace equivelent of
teenagers ogling girls on the street corner smoking cigs.)
So, in P6:
if 0 { print 0\n; } # I assume this won't print.
if '0' { print '0'\n; } # I assume this won't print.
if ''{ print ''\n;} # I assume this won't print.
if undef { print undef\n; } # I assume this won't print.
But my question is, will this:
if \0 { print null\n; } # Is this going to print, or not?
And if the answer is because I've somehow botched my syntax, please
correct it and answer the question I obviously *meant* to ask as well?
=o)
Paul
--- Hodges, Paul [EMAIL PROTECTED] wrote:
Every now and then I have this discussion with people at work that
involve Perl's ideas of boolean truth. I usually break it down like
this:
In Perl5, the following values are FALSE: undef, '0', 0, and ''.
Anything not in that list is considered TRUE in a boolean context.
That means that Perl5 has some notions of truth that confuse some
folk. I mean, I can understand 00 being true, even if it seems a
little odd to me personally, but \0??? How is a single null byte
*true*?
Okay, so it's binary data. So is 0 and 0, if you look at it that
way. I realize the internal representations are different, but the
programmer shouldn't have to care about that. I just figure that if
my bit of $data contains one byte, and I'm checking that $data for
boolean truth, I'd expect a null to be false, as would ba-zillions of
C programmers (from which backgroud I came). I know we aren't trying
so hard to imitate C behavior anymore, but still, doesn't this
violate the principle of least surprise?
So my question is this, with apology for the ramble
aside from P6's other changes, is a single null byte of binary data
still going to register as TRUE, or will it now be what seems to me
the more sensible FALSE?
Paul
__
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail
Re: definitions of truth
Paul Hodges writes:
I seemed to have opened a can of worms, lol
But did anybody see the one that had something to do with my question
crawling around? (I've obviously missed a couple of messages. They're
probably hanging out down at the router in the cyberspace equivelent of
teenagers ogling girls on the street corner smoking cigs.)
So, in P6:
if 0 { print 0\n; } # I assume this won't print.
if '0' { print '0'\n; } # I assume this won't print.
if ''{ print ''\n;} # I assume this won't print.
if undef { print undef\n; } # I assume this won't print.
But my question is, will this:
if \0 { print null\n; } # Is this going to print, or not?
And if the answer is because I've somehow botched my syntax, please
correct it and answer the question I obviously *meant* to ask as well?
=o)
As far as things are currently defined, yes, it will print. And your
syntax is perfect... well, maybe not:
if undef { print undef\n; }
Might be interpreted as:
if undef( { print undef\n; } ) # syntax error, expecting {
But close enough anyway.
If you must check for a null byte, it's as simple as:
unless $chr { print 0, '', or '0' }
unless ord $chr { print null byte }
Luke
Re: definitions of truth
Juerd wrote: That we already have. 0 but true. (perldoc -f fcntl) It's 1 but false that's really special :) No, what's really special is the ability to return entirely different things in string versus numeric context, like the magic $! does in Perl5. That, or interesting values of undef :-)
Re: definitions of truth
--- Luke Palmer [EMAIL PROTECTED] wrote:
Paul Hodges writes:
So, in P6:
if 0 { print 0\n; } # I assume this won't print.
if '0' { print '0'\n; } # I assume this won't print.
if ''{ print ''\n;} # I assume this won't print.
if undef { print undef\n; } # I assume this won't print.
But my question is, will this:
if \0 { print null\n; } # Is this going to print, or not?
As far as things are currently defined, yes, it will print. And your
syntax is perfect... well, maybe not:
if undef { print undef\n; }
Might be interpreted as:
if undef( { print undef\n; } ) # syntax error, expecting {
But close enough anyway.
Maybe I should have been more specific:
if undef() { whatever(); }
But it's a moot point, since only a moron would test what he knowks the
answer to -- unless it's one of those wierd cases, and then he could
just use 0 instead..
So, putting it back into the context of real things.
If you must check for a null byte, it's as simple as:
unless $chr { print 0, '', or '0' }
unless ord $chr { print null byte }
So a null byte is still Boolean true.
Ugh, yarf, ack, etc.
But as long as I know -- easy enough to check explicitly.
But just tell me thisam I the only guy who thinks this *feels*
wierd? Understanding the reason doesn't make it any more ~comfortable~.
Paul
__
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
Re: definitions of truth
Scott Bronson wrote:
That's the plan? Happy day! I was not aware of that. Because I didn't
see anything about this in Perl 6 Essentials, I just figured that
Perl5's '0'==undef was being brought forward into Perl6. The horror!
Sorry for the bad assumption. :)
Perhaps not as happy as you think:
my $foo = '0';
my String $bar = '0';
if $foo { say 'foo true' }
if $bar { say 'bar true' }
Would print 'bar true', but not 'foo true'. (In other words, variables
of type Any keep the Perl 5 behavior, but variables of type String have
the behavior you want.)
--
Brent Dax Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
