| Re: Ambiguous keyword abbreviation error [message #55790] |
Wed, 12 September 2007 14:39 |
R.G.Stockwell
Messages: 163
Registered: October 2004
|
Senior Member |
|
|
"David Fanning" <david@dfanning.com> wrote in message
news:MPG.215209833e83e7c2989cc9@news.frii.com...
> R.G. Stockwell writes:
>
>> PS if i sound a little gruff, it is because I am going through
>> some code with 8 character obsfucated funtion names, which
>> redefines variables all over the place (m = n_elements then
>> m = matrix size then m = counter in a loop argh!) and explicitly
>> declares the size of arrays at the main level, AND
>> deep within subroutines. Basically, it is unmodifiable.
>
> We should have lunch. Are you still in Boulder?
> I could complain to you about how hard it is to get
> old and no longer be able to see a tennis ball clearly,
> and you could tell me all about this. :-)
Yes, I am still in Boulder. I am not sure if I want to risk
catching this "getting old" disease you speak of :).
There is website that reports hilarious programming blunders
at http://worsethanfailure.com/Default.aspx, it's pretty funny.
Cheers,
bob
PS actually, I am afraid I already have "getting old" disease.
|
|
|
|
| Re: Ambiguous keyword abbreviation error [message #55791 is a reply to message #55790] |
Wed, 12 September 2007 14:35  |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
R.G. Stockwell writes:
> PS if i sound a little gruff, it is because I am going through
> some code with 8 character obsfucated funtion names, which
> redefines variables all over the place (m = n_elements then
> m = matrix size then m = counter in a loop argh!) and explicitly
> declares the size of arrays at the main level, AND
> deep within subroutines. Basically, it is unmodifiable.
We should have lunch. Are you still in Boulder?
I could complain to you about how hard it is to get
old and no longer be able to see a tennis ball clearly,
and you could tell me all about this. :-)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
|
|
|
|
| Re: Ambiguous keyword abbreviation error [message #55792 is a reply to message #55791] |
Wed, 12 September 2007 14:24 |
R.G.Stockwell
Messages: 163
Registered: October 2004
|
Senior Member |
|
|
keyword abbreviations seem like a remnant of the
old days of command line processing.
Does anyone still do that?
And using single letter keywords sounds like a sin
against programming styles. It is in the same boat
as calling your funtions f1, f2 and f3.
A unique descriptive name is always nice. :)
Cheers,
bob
PS if i sound a little gruff, it is because I am going through
some code with 8 character obsfucated funtion names, which
redefines variables all over the place (m = n_elements then
m = matrix size then m = counter in a loop argh!) and explicitly
declares the size of arrays at the main level, AND
deep within subroutines. Basically, it is unmodifiable.
|
|
|
|
| Re: Ambiguous keyword abbreviation error [message #55798 is a reply to message #55792] |
Wed, 12 September 2007 11:20 |
jkj
Messages: 48
Registered: April 2007
|
Member |
|
|
>
> This is diverging OT into more of a style thing, but why not bite the bullet and punch out
> the extra two characters for the sake of clarity:
>
> pro my_procedures, column=column, color=color
>
> ?
>
> cheers,
>
> paulv
Actually, I do and did :-) but in the post it seemed clearer to stress
that only one unique letter was required in order to satisfy IDL.
Also, I personally never abbreviate keywords and think it's poor
practice to do so (what if an additional keyword gets added to a later
version that matches some abbreviation I have grown accustomed to...
uuugh!).
-Kevin
|
|
|
|
| Re: Ambiguous keyword abbreviation error [message #55799 is a reply to message #55798] |
Wed, 12 September 2007 10:15 |
Foldy Lajos
Messages: 268
Registered: October 2001
|
Senior Member |
|
|
On Wed, 12 Sep 2007, Rick Towler wrote:
> Lajos, why aren't you working for ITT? Boulder is very nice.
>
> Who am I kidding. Boulder is nice but it can't compete with Budapest. :)
> Maybe you can telecommute?
>
> -r
>
They have not approached me :-) And working on a hobby project is much
more fun.
regards,
lajos
|
|
|
|
| Re: Ambiguous keyword abbreviation error [message #55800 is a reply to message #55799] |
Wed, 12 September 2007 09:27 |
Rick Towler
Messages: 821
Registered: August 1998
|
Senior Member |
|
|
Lajos, why aren't you working for ITT? Boulder is very nice.
Who am I kidding. Boulder is nice but it can't compete with Budapest.
:) Maybe you can telecommute?
-r
F�LDY Lajos wrote:
>
> On Wed, 12 Sep 2007, David Fanning wrote:
>
>> Conor writes:
>>
>>> You would think that since the keyword I'm using exactly
>>> matches an actual keyword, IDL could figure out that I'm referencing
>>> that keyword, rather than using an abbreviation.
>>
>> What algorithm would you use to do that? How could
>> you do it unambiguously?
>>
>> Cheers,
>>
>> David
>>
>
> FL does exactly this. The interpreter searches for an exact match first,
> and looks for abbreviations only if an exact match can not be found.
>
> Eg. let's have a simple procedure:
>
> pro INT, long=l32, long64=l64
> end
>
> Now INT can be called succesfully with keywords LONG, LONG6 or LONG64,
> only L, LO and LON will fail.
>
> regards,
> lajos
>
|
|
|
|
| Re: Ambiguous keyword abbreviation error [message #55801 is a reply to message #55800] |
Wed, 12 September 2007 09:20 |
Paul Van Delst[1]
Messages: 1157
Registered: April 2002
|
Senior Member |
|
|
Conor wrote:
> This bug always annoys me (well, I guess it's a feature, not a bug,
> but that's how I see it). For instance, in a lot of my programs I
> like to use the keyword /s for silent. Unfortunately, since it is a
> one-letter keyword, once I've declared it I can't use anyother
> keywords that start with the letter 's'. I find this to be highly
> irritating. You would think that since the keyword I'm using exactly
> matches an actual keyword, IDL could figure out that I'm referencing
> that keyword, rather than using an abbreviation. Oh well. At least
> when you get this error, you know exactly what the problem is.
Interesting. I use /q for quiet. Not many words in my field start with "q" (although I
thought of about 5 whilst typing that sentence.... :o)
cheers,
paulv
>
> On Sep 12, 10:08 am, Paul van Delst <Paul.vanDe...@noaa.gov> wrote:
>> jkj wrote:
>>>> I was under the
>>>> mistaken notion that these were like named variables, so as long as I had
>>>> unique names for each one I was good to go.
>>> pro my_procedures, col=col, color=color
>>> I'm thinking "column" when I use col=col and in parts of the code
>>> where "color" is not also a keyword "col" works just fine, but as soon
>>> as I have "col" as the beginning of another keyword IDL cannot tell
>>> the two apart (because IDL does not require you to use the entire
>>> keyword, only enough of it that it can be uniquely determined)... so I
>>> have to at least append 1 letter (other than 'o') to "col" and use
>>> something like:
>>> pro my_procedures, coln=coln, color=color
>> This is diverging OT into more of a style thing, but why not bite the bullet and punch out
>> the extra two characters for the sake of clarity:
>>
>> pro my_procedures, column=column, color=color
>>
>> ?
>>
>> cheers,
>>
>> paulv
>
>
|
|
|
|
| Re: Ambiguous keyword abbreviation error [message #55804 is a reply to message #55801] |
Wed, 12 September 2007 08:43 |
Foldy Lajos
Messages: 268
Registered: October 2001
|
Senior Member |
|
|
On Wed, 12 Sep 2007, David Fanning wrote:
> Conor writes:
>
>> You would think that since the keyword I'm using exactly
>> matches an actual keyword, IDL could figure out that I'm referencing
>> that keyword, rather than using an abbreviation.
>
> What algorithm would you use to do that? How could
> you do it unambiguously?
>
> Cheers,
>
> David
>
FL does exactly this. The interpreter searches for an exact match first,
and looks for abbreviations only if an exact match can not be found.
Eg. let's have a simple procedure:
pro INT, long=l32, long64=l64
end
Now INT can be called succesfully with keywords LONG, LONG6 or LONG64,
only L, LO and LON will fail.
regards,
lajos
|
|
|
|
| Re: Ambiguous keyword abbreviation error [message #55805 is a reply to message #55804] |
Wed, 12 September 2007 08:25 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Conor writes:
> You would think that since the keyword I'm using exactly
> matches an actual keyword, IDL could figure out that I'm referencing
> that keyword, rather than using an abbreviation.
What algorithm would you use to do that? How could
you do it unambiguously?
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
|
|
|
|
| Re: Ambiguous keyword abbreviation error [message #55808 is a reply to message #55805] |
Wed, 12 September 2007 08:07 |
Conor
Messages: 138
Registered: February 2007
|
Senior Member |
|
|
This bug always annoys me (well, I guess it's a feature, not a bug,
but that's how I see it). For instance, in a lot of my programs I
like to use the keyword /s for silent. Unfortunately, since it is a
one-letter keyword, once I've declared it I can't use anyother
keywords that start with the letter 's'. I find this to be highly
irritating. You would think that since the keyword I'm using exactly
matches an actual keyword, IDL could figure out that I'm referencing
that keyword, rather than using an abbreviation. Oh well. At least
when you get this error, you know exactly what the problem is.
On Sep 12, 10:08 am, Paul van Delst <Paul.vanDe...@noaa.gov> wrote:
> jkj wrote:
>>> I was under the
>>> mistaken notion that these were like named variables, so as long as I had
>>> unique names for each one I was good to go.
>
>> pro my_procedures, col=col, color=color
>
>> I'm thinking "column" when I use col=col and in parts of the code
>> where "color" is not also a keyword "col" works just fine, but as soon
>> as I have "col" as the beginning of another keyword IDL cannot tell
>> the two apart (because IDL does not require you to use the entire
>> keyword, only enough of it that it can be uniquely determined)... so I
>> have to at least append 1 letter (other than 'o') to "col" and use
>> something like:
>
>> pro my_procedures, coln=coln, color=color
>
> This is diverging OT into more of a style thing, but why not bite the bullet and punch out
> the extra two characters for the sake of clarity:
>
> pro my_procedures, column=column, color=color
>
> ?
>
> cheers,
>
> paulv
|
|
|
|
| Re: Ambiguous keyword abbreviation error [message #55809 is a reply to message #55808] |
Wed, 12 September 2007 07:08 |
Paul Van Delst[1]
Messages: 1157
Registered: April 2002
|
Senior Member |
|
|
jkj wrote:
>> I was under the
>> mistaken notion that these were like named variables, so as long as I had
>> unique names for each one I was good to go.
>
> pro my_procedures, col=col, color=color
>
> I'm thinking "column" when I use col=col and in parts of the code
> where "color" is not also a keyword "col" works just fine, but as soon
> as I have "col" as the beginning of another keyword IDL cannot tell
> the two apart (because IDL does not require you to use the entire
> keyword, only enough of it that it can be uniquely determined)... so I
> have to at least append 1 letter (other than 'o') to "col" and use
> something like:
>
> pro my_procedures, coln=coln, color=color
This is diverging OT into more of a style thing, but why not bite the bullet and punch out
the extra two characters for the sake of clarity:
pro my_procedures, column=column, color=color
?
cheers,
paulv
|
|
|
|
| Re: Ambiguous keyword abbreviation error [message #55819 is a reply to message #55809] |
Tue, 11 September 2007 23:15 |
jkj
Messages: 48
Registered: April 2007
|
Member |
|
|
> I was under the
> mistaken notion that these were like named variables, so as long as I had
> unique names for each one I was good to go.
pro my_procedures, col=col, color=color
I'm thinking "column" when I use col=col and in parts of the code
where "color" is not also a keyword "col" works just fine, but as soon
as I have "col" as the beginning of another keyword IDL cannot tell
the two apart (because IDL does not require you to use the entire
keyword, only enough of it that it can be uniquely determined)... so I
have to at least append 1 letter (other than 'o') to "col" and use
something like:
pro my_procedures, coln=coln, color=color
-Kevin
|
|
|
|
| Re: Ambiguous keyword abbreviation error [message #55823 is a reply to message #55819] |
Tue, 11 September 2007 12:23 |
Foldy Lajos
Messages: 268
Registered: October 2001
|
Senior Member |
|
|
On Tue, 11 Sep 2007, Jonathan Greenberg wrote:
> So I have NEVER seen this error before, and now I've seen it twice in one
> day, with two completely different programs (one I wrote, one I didn't):
>
> Ambiguous keyword abbreviation: [name of function/program]
>
> I've been poring through the user group here and I *sort-of* see what is
> going on, but what ARE the rules for naming keywords? I was under the
> mistaken notion that these were like named variables, so as long as I had
> unique names for each one I was good to go. Does this behavior differ from
> system to system (the 2nd of the two failures was from a program that I have
> to assume has been run at least ONCE before I got a hold of it, so it should
> have shown the error before I received it -- this may be an incorrect
> assumption...)? Is there an easy way to disable this, or do I have to go
> back through and rename keywords all over the place...
>
> Thoughts? Thanks!
>
> --j
>
Keywords must be unique and they can not be abbreviations of other
keywords. Have you ever wondered why IDL uses LONG for 32 bit integers and
L64 (instead of LONG64) for 64 bit ones?
regards,
lajos
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
