Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Revelation (4242)

Revelation
  (email not shown publicly)

Journal of Revelation (4242)

Monday June 23, 2003
09:43 PM

Beware Of The Sigil:

[ #13022 ]

Some more thought about the development of Perl 6- in relation to Perl 5. I consider myself an avid Perl user, who has become better and better at the language as time has gone on. I consider the sigil in Perl 5 to be one of the nicest and most natural constructs, because it gives me an immediate idea of what type of data I’m dealing with. However, as Perl 6 continues to steamroll its way along, I’ve become to fear what’s most natural to me- the sigil! That precious $, @, and % is lashing out at me, and why? Why is because I’ve accrued a lot of knowledge about clean OO programming with ruby (Perl’s OO system is a smokes and mirrors kludge that does its job admirably) and I love the elegance of its constructs. It has always made sense to me to hierarchicallize my data- in auction scripts or other scripts I’ve freelanced for it’s always made things so much simpler to find- and as such I love doing the same even with datatypes.

Perl’s evolution is with me: Perl 6 is doing essentially this- hierarchicalizing datatypes. So much so that, from what I understand from Apoc, and Exegis, I believe sigils will not really mean that much (they'll be the standard definitions, which will be a lot less loosely enforced). Furthermore, there will now be opaque objects, which are basically what I want. If they're implemented as I wish (we'll see- they hopefully will be!), you can consider this a justification of them- otherwise, you can consider this a personal warning. However, it continues with the basic three datatypes that it has always had. Coming from a Perl background this makes sense, arrays, hashes, and scalars (which encompass closures, references, etc.) are all I’ve ever needed and used. Unfortunately, coming from a linguistic background, this pisses me off: I expected to be able to subclass “Arrayâ€, and make my own datatypes, without using the sometimes-wonderful ruby construct obj.instance_eval(). I wanted my own defined datatype to be no different from the basic three datatypes- it would be nice if my own “Pseudo-array†class, for instance, would have the same basic look and implementation as the array class- although it wouldn’t be adopted by so many programmers (I think), it’d be possible for not a massive revision to take place, if it was somehow adopted as a basic datatype, or an important datatype.

This would be, to me, the ultimate proof that Perl 6 was the community’s rewrite instead of Larry’s. The community would be able to contribute to what was considered even a basic datatype- such that a basic array could even be modified, if the community thought it should be different. This is the type of revolutionary thought that made perl the asset to the programming community it initially was. Yes… I know that I could probably write code resembling my @item is PseudoArray, but the first thing people are going to think is “that’s an arrayâ€- and as such its default behavior would have to resemble an array rather than a hash. What if I wanted to have its default behavior resemble neither? Would I be able to do my item is PseudoArray, and if so will people test to see its superclass or just get incredibly confused as to why the item has a sigil? I’d prefer my hypothetical pseudo-array class just had a little bit more weight against the titans of Array, Hash, and Scalar. Regardless of whether this suggestion is taken into account, I’ll use Perl 6- probably more avidly than I’ve used Perl 5, but sigils just continue to scare me.

NB: One thing that I’m really hoping is that strings will act like both an array of letters, and a single string (even stronger implicit conversion, which is what makes Perl such a great language for me- actually this conversion isn’t all that implicit, since we’re telling it to return an array- however it’d be great if it was implicit- so that .string.letters would hold $.string (held by scalar, or string) @.string ( held by array or letters ) and %.string (held by some third field- hash?). It’d be nice to be able to do:

foreach $letter (letters $.string) { print char(ord($letter) + 1);}
which would translate to:
foreach $letter ( (.string.letters) ) { print char(ord($letter) + 1 }

and the same would be true of a pseudo-array:
foreach $letter( .item_which_actually_hold_a_pseudo_array.letters ) { }
At least Larry could consider disallowing IO and other things to go by the external label ‘item’, so that instead a superobject of some sort could go there instead for those of us who wanted all datatypes to be equal. If the superobject exhisted, arrays, hashes and everything else wouldn't be allowed for that symbol. Or if they were allowed, they wouldn't be decared, only used as references to the superobject's method.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.