Re: parsing error with ?: usage
On Fri, 8 Sep 2006 at 6:08am, A.J.Mechelynck wrote: > Hari Krishna Dara wrote: > [...] > > I know that this is possible, but as I said previously, it is a force of > > habit to compact as much as possible in some situations, though I > > normally prefer using whitespace and parenthesis to improve clarity. > > > > Also, the reason I mentioned using spaces is not really as a workaround > > but to show the subtle difference it makes to the parser. Once you use > > parenthesis, there is nothing really ambiguous about it. > > > > I have a suspcion that using parenthesis also didn't solve the issue in > > one of the cases (I remember it was calling script-local functions as > > part of map() expression). I have to try to reproduce it though, I don't > > remember it now. > > > > As Tim said, a liitle bit of paranoia is healthy here: If you write > > if condition_1 || condition_2 && condition_3 > > the parser will interpret it in a well-defined way, determined by the > syntax of the language, but when you come back 2 years hence, will it > still be clear to you? Some languages mandate left-to-right order in > this case, which results in the equivalent of > > if (condition_1 || condition_2) && condition_3 > > In others, "and" takes precedence over "or", which results in > > if condition_1 || (condition_2 && condition_3) > > With parentheses, precedence rules are unimportant and an error in logic > won't be overlooked even if you mistook a left-to-right language for an > and-before-or language or vice-versa. similarly for all other possible > ambiguities: remember, (x?a:1) is a valid expression if you have a > variable named a. You may even have an argument named a:a so what about > (x?a:a:a) if you have both a and a:a ? I repeat: don't trust priorities > and use parentheses. And if you caught a bad habit, reeducate yourself. > > > Best regards, > Tony. We are deviating from my original point. It is not that I don't know what is more cleaner way of writing code that I asked this question. I just want to write more compact code sometimes, and if that doesn't work in this case, I will avoid, there is no convincing required. I don't write this kind of code as a rule and it certainly is not my "regular" habbit. May be my use of word "habbit" is wrong here, but you didn't really have to give all the explanation. I am an experienced programmer (and I don't write just Vim scripts), and if you look at my Vim scripts, you will find that I write them very seriously (and passionately), following my own coding standards, tediously splitting the long lines for readability and doing all that you are suggesting here. My intention was to report a problem I found, and sometimes minor symptoms can lead to the discovery of major issues, so I don't generally ignore any bugs. I also wanted to know (for educational purpose) if it can even be parsed without ambiguity (ie., if the bug can even be fixed) to which I think Bram answered NO, and that is the answer I was looking for. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: parsing error with ?: usage
Hari Krishna Dara wrote: > I have hit this thrice already, while using the ?: ternary operator, in > some conditions, you are forced to put whitespace to separate the > operator otherwise Vim gets confused. Here is something that fails: > > let direction = (a:0?a:1:1) > > I had this issue before calling script-local functions from the > true or false condition. The workaround as I said for the above is: > > let direction = (a:0 ? a:1 :1) > > The problem is, sometimes I have a force of habit to skip the whitespace > in some places when I want the code to be really compact/tight > (especially when with map(), filter() or \=), and I will not notice the > problem until sometime later when the code gets executed. If the code > happened to execute with a :silent, you may have to do quite a bit of > debugging to find this kind of errors. Is it possible for Vim to parse > this unambiguously? The usage could be even worse, something like: > > let direction = (a:0>1?a:2:a:1) The ":" is overloaded, it's used both after a variable name and for ? :. You need to put a space before it when you want to use it for ? :. There is no other solution for this. Adding spaces is good for readability anyway. This is much easier to understand: let direction = a:0 ? a:1 : 1 Than this: let direction = a:0?a:1:1 -- ARTHUR: Then who is your lord? WOMAN: We don't have a lord. ARTHUR: What? DENNIS: I told you. We're an anarcho-syndicalist commune. We take it in turns to act as a sort of executive officer for the week. The Quest for the Holy Grail (Monty Python) /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: parsing error with ?: usage
Hari Krishna Dara wrote: [...] I know that this is possible, but as I said previously, it is a force of habit to compact as much as possible in some situations, though I normally prefer using whitespace and parenthesis to improve clarity. Also, the reason I mentioned using spaces is not really as a workaround but to show the subtle difference it makes to the parser. Once you use parenthesis, there is nothing really ambiguous about it. I have a suspcion that using parenthesis also didn't solve the issue in one of the cases (I remember it was calling script-local functions as part of map() expression). I have to try to reproduce it though, I don't remember it now. As Tim said, a liitle bit of paranoia is healthy here: If you write if condition_1 || condition_2 && condition_3 the parser will interpret it in a well-defined way, determined by the syntax of the language, but when you come back 2 years hence, will it still be clear to you? Some languages mandate left-to-right order in this case, which results in the equivalent of if (condition_1 || condition_2) && condition_3 In others, "and" takes precedence over "or", which results in if condition_1 || (condition_2 && condition_3) With parentheses, precedence rules are unimportant and an error in logic won't be overlooked even if you mistook a left-to-right language for an and-before-or language or vice-versa. similarly for all other possible ambiguities: remember, (x?a:1) is a valid expression if you have a variable named a. You may even have an argument named a:a so what about (x?a:a:a) if you have both a and a:a ? I repeat: don't trust priorities and use parentheses. And if you caught a bad habit, reeducate yourself. Best regards, Tony.
Re: parsing error with ?: usage
On Fri, 8 Sep 2006 at 4:41am, A.J.Mechelynck wrote: > Hari Krishna Dara wrote: > > I have hit this thrice already, while using the ?: ternary operator, in > > some conditions, you are forced to put whitespace to separate the > > operator otherwise Vim gets confused. Here is something that fails: > > > > let direction = (a:0?a:1:1) > > > > I had this issue before calling script-local functions from the > > true or false condition. The workaround as I said for the above is: > > > > let direction = (a:0 ? a:1 :1) > > > > The problem is, sometimes I have a force of habit to skip the whitespace > > in some places when I want the code to be really compact/tight > > (especially when with map(), filter() or \=), and I will not notice the > > problem until sometime later when the code gets executed. If the code > > happened to execute with a :silent, you may have to do quite a bit of > > debugging to find this kind of errors. Is it possible for Vim to parse > > this unambiguously? The usage could be even worse, something like: > > > > let direction = (a:0>1?a:2:a:1) > > > > The problem comes from the two meanings of the colon: as part of the > (?:) operator, or to separate the context prefix from the variable or > function name in v: s: g: l: a: b: w: t: &g: &l: > > To parse it unambiguously regardless of spaces, use parentheses: > > (a:0?(a:1):1) > and > ((a:0>1)?(a:2):(a:1)) > > are unambiguous (and more legible too). > > > Best regards, > Tony. I know that this is possible, but as I said previously, it is a force of habit to compact as much as possible in some situations, though I normally prefer using whitespace and parenthesis to improve clarity. Also, the reason I mentioned using spaces is not really as a workaround but to show the subtle difference it makes to the parser. Once you use parenthesis, there is nothing really ambiguous about it. I have a suspcion that using parenthesis also didn't solve the issue in one of the cases (I remember it was calling script-local functions as part of map() expression). I have to try to reproduce it though, I don't remember it now. -- Thanks, Hari > -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: parsing error with ?: usage
Hari Krishna Dara wrote: I have hit this thrice already, while using the ?: ternary operator, in some conditions, you are forced to put whitespace to separate the operator otherwise Vim gets confused. Here is something that fails: let direction = (a:0?a:1:1) I had this issue before calling script-local functions from the true or false condition. The workaround as I said for the above is: let direction = (a:0 ? a:1 :1) The problem is, sometimes I have a force of habit to skip the whitespace in some places when I want the code to be really compact/tight (especially when with map(), filter() or \=), and I will not notice the problem until sometime later when the code gets executed. If the code happened to execute with a :silent, you may have to do quite a bit of debugging to find this kind of errors. Is it possible for Vim to parse this unambiguously? The usage could be even worse, something like: let direction = (a:0>1?a:2:a:1) The problem comes from the two meanings of the colon: as part of the (?:) operator, or to separate the context prefix from the variable or function name in v: s: g: l: a: b: w: t: &g: &l: To parse it unambiguously regardless of spaces, use parentheses: (a:0?(a:1):1) and ((a:0>1)?(a:2):(a:1)) are unambiguous (and more legible too). Best regards, Tony.
Re: parsing error with ?: usage
this unambiguously? The usage could be even worse, something like: let direction = (a:0>1?a:2:a:1) Personally, I never leave these sorts of matters to the whims of the parser designer (no offense, Bram :) and always specify just as I would with something as ambiguous as a and b or c which could be parsed as (a and b) or c or a and (b or c) not trusting in the compiler, or my own ability to come back later and understand which condition it should be. Similarly, I always force a ternary operator with let direction = (a:0>1)?(a:2):(a:1) to ensure that it parses exactly as I want/expect. I know it's not an ideal solution as it sounds like you can solve your problem with a few extra spaces...however, it might be a habit worth developing to prevent ambiguity in code...both for the parser, and for you 6 months down the line. :) Just my $2.0e-2 -tkc
