Re: RFC 258 (v1) Distinguish packed binary data from printable strings
On 19 Sep 2000, Perl6 RFC Librarian wrote: Distinguish packed binary data from printable strings What defines a "printable" string? What if I'm working in an environment that can "print" bytes that yours can't? Specifically I'm wondering how this proposal handles Unicode. Perl should fly far and fast from starting down the bumpy road where that data is strongly typed in the mythical and deceptive text-vs-binary sense, for that path is one littered with the frustrations of a legion of programmers stretching from the plodding mainframe operating systems of our grandfathers to the toybox legacies of our less fortunate brethren of today. Heed the wisdom of the Unix and the song of the C: Let your data be simply data, homogenously clean. To do otherwise is to suffer unending inanities and combinatoric misconnects of noncongruent types. --tom
Re: RFC 258 (v1) Distinguish packed binary data from printable strings
Tom Christiansen wrote: Perl should fly far and fast from starting down the bumpy road where that data is strongly typed in the mythical and deceptive text-vs-binary sense ... Heed the wisdom of the Unix ... Tom's exactly right. Data should be data, at least by default. One of the beauties of UNIX, and one of the reasons it doesn't suck (unlike some other "operating systems") is that it's guided by simplicity: everthing's a file, and a file contains data. No drive letters or .txt vs .exe files to ruin your day. If you need the facility to do this type of checking, tie, operator overloading, and more is there for you. As the examples show, this is an infinitely complicated issue. One thing that Nat will soon be releasing is an RFC on strict typing. I'll also have one (hopefully) on an embedded tie-like solution that will allow you to create your own variable types. With these you would conceivably be able to say: use strict 'types'; my packed $b = 5; # oops! Basically, I think the type of stuff you suggest is best viewed as *extensions* to Perl, and not default behavior that could potentially cause many more problems than it solves. -Nate
Re: RFC 258 (v1) Distinguish packed binary data from printable strings
Nathan Wiger wrote: One thing that Nat will soon be releasing is an RFC on strict typing. I'll also have one (hopefully) on an embedded tie-like solution that will allow you to create your own variable types. With these you would conceivably be able to say: use strict 'types'; my packed $b = 5; # oops! Um, I *think* the following suggestion falls in this category. The other day a coworker tracked down a bug that boiled down to: if ($string != '') Obviously, the operator should have been "ne". I was going to suggest that comparison operators, where one operand is a constant, should produce a warning message when the operator is inappropriate. I am sure that sometimes you'll want to do if ($foo gt 5) but for the most part, that's the Wrong Thing. (That would be better written as "if ($foo gt '5')" anyhow). In light of Nate's comment above, maybe it would be approporiate to have this warning under "use strict 'types'" only; or perhaps it would normally be a warning, but under "use strict 'types'", it would be a compile-time error. If so, please add this suggestion to the RFC. If not, should I make a separate RFC? -- Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort Senior Software Engineer'tona ', 'reh', 'ekca', 'lre', Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';
Re: RFC 258 (v1) Distinguish packed binary data from printable strings
Nathan Wiger wrote: Tom Christiansen wrote: Perl should fly far and fast from starting down the bumpy road where that data is strongly typed in the mythical and deceptive text-vs-binary sense ... Heed the wisdom of the Unix ... I shouldn't have used the term "binary" in the proposal because that's not the distinction. Usage determines whether or not the string is likely to be meant to be readable. An attempt at some added DWIMishness. The data are never examined. I've removed all references to "binary" so people won't misconstrue. (I know that's not the totality of your point; I just wanted to clarify.) Tom's exactly right. Data should be data, at least by default. One of the beauties of UNIX, and one of the reasons it doesn't suck (unlike some other "operating systems") is that it's guided by simplicity: everthing's a file, and a file contains data. No drive letters or .txt vs .exe files to ruin your day. I can't argue with any of that. And true to that spirit, no data were harmed in the creation of this RFC! The DWIMish behavior regarding strings, packed or not, is largely retained. The changes seem to me to apply only to a narrow range of situations, and those only when asked. I've endeavored to arrange things such that this RFC will not change how people use perl now, but will reduce the occurance of one class of errors. As the examples show, this is an infinitely complicated issue. Perhaps it is to those of you who can see more of the Perl landscape than I, but from down here the RFC looks well cirucmscribed and limited. If there *is* infinite complexity looming, obviously it will never be done; no need for further argument on this list. [... snip ...] Basically, I think the type of stuff you suggest is best viewed as *extensions* to Perl, and not default behavior that could potentially cause many more problems than it solves. The example code was meant to convey that the additional checking is only done when explicitly invoked via Cuse strict 'packed' and/or Cuse warnings 'packed'. Perhaps I should make that more explicit. In a sense, it's already proposed to be sort of an extension, just one which is provided to everyone. Everyone's short of tuits, but I'd love to see some hint of where you think this causes problems. -- -- Tim Conrow [EMAIL PROTECTED] |
Re: RFC 258 (v1) Distinguish packed binary data from printable strings
Perhaps what you're truly looking for is a generalized tainting mechanism. --tom
Re: RFC 258 (v1) Distinguish packed binary data from printable strings
Tom Christiansen wrote: Perhaps what you're truly looking for is a generalized tainting mechanism. Sounds cool, but I have only the vaguest idea what you (may) mean. Pointers? RFCs? Examples? Hints? -- -- Tim Conrow [EMAIL PROTECTED] |
Re: RFC 258 (v1) Distinguish packed binary data from printable strings
Tim Conrow wrote: Tom Christiansen wrote: Perhaps what you're truly looking for is a generalized tainting mechanism. Sounds cool, but I have only the vaguest idea what you (may) mean. Pointers? RFCs? Examples? Hints? Sorry for the clutter, but I didn't want to come off too clueless. I know what tainting is, I just don't know what you mean by generalized tainting. If it's been discussed before I'd love to see a pointer to the thread. -- -- Tim Conrow [EMAIL PROTECTED] |
Re: RFC 258 (v1) Distinguish packed binary data from printable strings
Tim Conrow wrote: Tom Christiansen wrote: Perhaps what you're truly looking for is a generalized tainting mechanism. Sounds cool, but I have only the vaguest idea what you (may) mean. Pointers? RFCs? Examples? Hints? Sorry for the clutter, but I didn't want to come off too clueless. I know what tainting is, I just don't know what you mean by generalized tainting. If it's been discussed before I'd love to see a pointer to the thread. You want to have more properties that work like tainting does: a per-SV attribute that is enabled or disabled by particular sorts of expressions, sometimes dependent upon the previous presence or absence of that property, other times, not so. --tom
