Slash Boxes
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 ]

Ovid (2709)

  (email not shown publicly)
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Friday July 17, 2009
05:40 AM

Things I Wish Were Syntax Errors #213

[ #39306 ]

    pid => {
        data_type     => "CHAR",
        default_value => "",
        is_nullable   => 0,
        size          => 15,
    title => {
        data_type     => 'TEXT',
        default_value => undef,
        is_nullable   => 0,
        size          => undef,
    type => {
        data_type     => "VARCHAR",
        default_value => "",
        is_nullable   => 0,
        size          => 64,
    advertising => {
        data_type   => 'ENUM',
        is_nullable => 0,
    syndication => {
        data_type   => 'TINYINT',
        is_nullable => 0,
        size        => 1,
    deprecation_date => {
        data_type     => "DATETIME",
        default_value => "",
        is_nullable   => 0,
        size          => 19

This constantly breaks my code. It's not a syntax error, but I can't think of any circumstance under which I would ever want this behavior. Maybe I should write a vim plugin to try and auto-detect that.







What? You didn't see it right away? I wonder if that's relevant ...

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • I mean, I use "HASH(0x1731300)HASH(0x174c918)" all the time.

    I think I saw it on the fourth read-through.

    If not a syntax error, at least a warning.

    -- dagolden

    • I agree with Schern that it should be a warning, not a fatal error (I don't think it could be a syntax error since we don't know what's in those scalars at compile time).

      A run time error would be bad for all the reasons Schern mentioned, but specifically because we all have debugging or logging code that does this. String interpolation shouldn't cause a run-time error. But since I've been bitten by this before I'm all in favor of it being a warning!

      • I was thinking that the concatenation would be the warning, not the interpolation.

        • But the concat is just one example of this problem isn't it? What about trying to use the wrong point in a nested data structure in a string? I've often used some 1 element array ref as a string because I missed something in some module's API.

    • Personally, I think that this is an example of something which should be another type of compile time error, which we don't have: semantic error. Specifically, the language technically allows it, but it has meaning that nobody would ever conceivably want.

      As I understand that what I can conceive is limited, I'd probably add a runtime option to perl to disregard semantic errors. However, without that option, I'd have it complain about interpolating the literal hash and exit immediately.

    • As soon as I say Dominus' email, I started thinking that it shouldn't apply to blessed objects due to overloading, but I see that Schwern already raised that case.

      Still, other than that, I could see a warning or a new 'strict' type being added in future versions of Perl.

  • I admit I didn't see it at first. So I copied the code into emacs. I have a habit of using perltidy in emacs to clean up my code, So I did that first. The problem jumped right out at me because of the indentation.

    Then I tried just using cperl-mode indenting and it pointed the problem out to me also.

    So does it really need to be a error/warning? or should we rely on our editor to find it.

    • I argue in my roles talk (well, the one I'm giving in Lisbon) that complexity management tools should be pushed into the langauge (when possible), rather than relying on external tools. While I don't think this falls in the category of complexity management, I think that the principle of "language support, when possible" applies here. If someone doesn't have your editor setup, they could easily miss this. Personally, I think this problem is common enough that a warning is quite appropriate.

      I still rememb

  • You could easily pull it off with an error match. I have a few of those on my after\ftplugin\javascript.vim, for guarding against things like trailing commas and whatnot. Here's mine:

    match Error /,\_s*[)\]}]\|[:,][^ ]\|\\|\\|[^0]\.[0-9]\+\|=\@!===\@!\|!==\@!/
  • In a way, it's nice that everything can be converted to a string, but at least without something like autobox [] combined with overload [], where you can have control what it converts into (at least, I hope that will do the trick), it's generally not very useful.