[U2] Case Sensitivity and Databasic conversion
Trying to change the title, because this isn't really about conversion in general anymore. There are different aspects of case sensitivity of course, and different platforms have different levels of support. If you haven't actually used D3, you may not realize how far it carries case insensitivity: In Basic: Basic Reserved words: On D3, universe, and Cache, reserved words are case insensitive. On most other systems they are not. The line: print hello world will compile on d3 or universe, but not on unidata or jbase where PRINT is not print. This is a nice feature if you like the look of lower or mixed-case code. Basic Identifiers: ABC=45 Crt abc works on D3, but not anywhere else by default (Cache has a flag to allow this.). Having this reduces unassigned variable errors from typos if you like to use variables like camelCasedValue but prevents you from using case-sensitive variables on purpose (which hopefully no one except old FORTH programmers are in the habit of doing) Basic data: If code=X then STOP On d3 (and nowhere else) the conditional will be true of code=X or code='x'. No mv platform except jbase ever implemented this afaik. From TCL: Case insensitive commands: LIST ERRMSG list ERRMSG D3, universe, and Cache allow this. Unidata looks like it does, but is really a special case--using a lower or mixed case command on unidata overrides the ECLTYPE setting and runs the ECLTYPE U form of the verb, which can have very different behavior from the pick version of the verb Case insensitive keywords: LIST VOC with F1 = V Will work on D3 and Cache, but not on universe. I guess it does work on unidata (unless some keywords also have emulation-specific behavior there) Case insensitive data: LIST voc WITH f1 = v This will work on D3 but nowhere else. On d3 VOC and voc are the same file, F1 and f1 the same dict item, and V an v the same literal. There are probably other case sensitivity issues that I haven't mentioned. And I think someone else already pointed out that D3 does allow you to turn off case insensitivity (for compatibility with R83). On Apr 8, 2011, at 3:09 AM, Mecki Foerthmann wrote: Tony, I don't mind case in-sensitivity in Basic, it actually can make code more readable, but case-insensitive data can be a real pain. On 08/04/2011 00:58, Tony Gravagno wrote: From: Mecki Foerthmann AFAIK UD can be run in case insensitive mode as well. I always turned case-insensitivity off in D3 because I think it's a real pain in the neck. Sounded great to start with but when you see the first printouts (i.e. invoices) you curse yourself if you didn't turn it off.:-( Not to (re)start a war but just present the other side: I consider case-insensitivity to be one strong advantage in D3 over other platforms. I constantly stumble on the requirement to get the casing just right at TCL and elsewhere in some MV environments when it's completely unnecessary and archaic that we should need to stumble on such a thing. Same goes for the difference between dashes and dots (LIST-ITEM vs LIST.ITEM) which is nicely translated for us in QM, Caché, and maybe in some flavors in U2. So just to balance it out. Some people swear at case-insensitivity, but I swear by it. WRT the OP : As soon as I saw the question about D3 to Unidata I immediately thought of the years of pain to which Bill Haskett was subjected. From his experience I swore off ever porting to Unidata. YMMV Symeon, perhaps in another thread (or email) you could explain why a site feels a need to migrate from D3, and then why they chose Unidata. With apologies to the sensitive, I don't think a migration from D3 is justified except for some extreme cases, and as to choosing Unidata, I don't see the business or technical benefits at all. Oh OK, I'll start a holy war. The only compelling reason for migration from a competing platform to U2 _used_ to be the IBM name. That doesn't exist anymore. Now these platforms need to compete on their technical merits and Rocket needs to sell itself on superiority as a business partner. Sorry folks but I don't see any of that. Really - where's the beef? U2 is good software and the U2 team at Rocket are good people. But I don't see any compelling reasons to choose this platform over any other these days. The political can't get fired for buying IBM edge is gone. Feel free to defend the platform because you've already made the investment and it's politically correct for you to take an obvious position, but be prepared for some pragmatic requests for more compelling reasoning. I'd really like to understand why any site would want to migrate to U2 these days. T ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Case Sensitivity and Databasic conversion
Unidata BASIC has the -I option to allow reserved words to be case insensitive - print would work, although this wasn't available in the older versions. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Ed Clark Sent: Friday, April 08, 2011 2:29 PM To: U2 Users List Subject: [U2] Case Sensitivity and Databasic conversion Trying to change the title, because this isn't really about conversion in general anymore. There are different aspects of case sensitivity of course, and different platforms have different levels of support. If you haven't actually used D3, you may not realize how far it carries case insensitivity: In Basic: Basic Reserved words: On D3, universe, and Cache, reserved words are case insensitive. On most other systems they are not. The line: print hello world will compile on d3 or universe, but not on unidata or jbase where PRINT is not print. This is a nice feature if you like the look of lower or mixed-case code. Basic Identifiers: ABC=45 Crt abc works on D3, but not anywhere else by default (Cache has a flag to allow this.). Having this reduces unassigned variable errors from typos if you like to use variables like camelCasedValue but prevents you from using case-sensitive variables on purpose (which hopefully no one except old FORTH programmers are in the habit of doing) Basic data: If code=X then STOP On d3 (and nowhere else) the conditional will be true of code=X or code='x'. No mv platform except jbase ever implemented this afaik. From TCL: Case insensitive commands: LIST ERRMSG list ERRMSG D3, universe, and Cache allow this. Unidata looks like it does, but is really a special case--using a lower or mixed case command on unidata overrides the ECLTYPE setting and runs the ECLTYPE U form of the verb, which can have very different behavior from the pick version of the verb Case insensitive keywords: LIST VOC with F1 = V Will work on D3 and Cache, but not on universe. I guess it does work on unidata (unless some keywords also have emulation-specific behavior there) Case insensitive data: LIST voc WITH f1 = v This will work on D3 but nowhere else. On d3 VOC and voc are the same file, F1 and f1 the same dict item, and V an v the same literal. There are probably other case sensitivity issues that I haven't mentioned. And I think someone else already pointed out that D3 does allow you to turn off case insensitivity (for compatibility with R83). On Apr 8, 2011, at 3:09 AM, Mecki Foerthmann wrote: Tony, I don't mind case in-sensitivity in Basic, it actually can make code more readable, but case-insensitive data can be a real pain. On 08/04/2011 00:58, Tony Gravagno wrote: From: Mecki Foerthmann AFAIK UD can be run in case insensitive mode as well. I always turned case-insensitivity off in D3 because I think it's a real pain in the neck. Sounded great to start with but when you see the first printouts (i.e. invoices) you curse yourself if you didn't turn it off.:-( Not to (re)start a war but just present the other side: I consider case-insensitivity to be one strong advantage in D3 over other platforms. I constantly stumble on the requirement to get the casing just right at TCL and elsewhere in some MV environments when it's completely unnecessary and archaic that we should need to stumble on such a thing. Same goes for the difference between dashes and dots (LIST-ITEM vs LIST.ITEM) which is nicely translated for us in QM, Caché, and maybe in some flavors in U2. So just to balance it out. Some people swear at case-insensitivity, but I swear by it. WRT the OP : As soon as I saw the question about D3 to Unidata I immediately thought of the years of pain to which Bill Haskett was subjected. From his experience I swore off ever porting to Unidata. YMMV Symeon, perhaps in another thread (or email) you could explain why a site feels a need to migrate from D3, and then why they chose Unidata. With apologies to the sensitive, I don't think a migration from D3 is justified except for some extreme cases, and as to choosing Unidata, I don't see the business or technical benefits at all. Oh OK, I'll start a holy war. The only compelling reason for migration from a competing platform to U2 _used_ to be the IBM name. That doesn't exist anymore. Now these platforms need to compete on their technical merits and Rocket needs to sell itself on superiority as a business partner. Sorry folks but I don't see any of that. Really - where's the beef? U2 is good software and the U2 team at Rocket are good people. But I don't see any compelling reasons to choose this platform over any other these days. The political can't get fired for buying IBM edge is gone. Feel free to defend the platform because you've already made the investment and it's politically correct for you to take
Re: [U2] Case Sensitivity and Databasic conversion
I see that -I option in the 6.1 developing unibasic applications manual so it isn't brand new. In fact it's listed in the options list twice :) But identifiers are still case sensitive (and aren't in D3). On Apr 8, 2011, at 2:40 PM, Dave Davis wrote: Unidata BASIC has the -I option to allow reserved words to be case insensitive - print would work, although this wasn't available in the older versions. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Ed Clark Sent: Friday, April 08, 2011 2:29 PM To: U2 Users List Subject: [U2] Case Sensitivity and Databasic conversion Trying to change the title, because this isn't really about conversion in general anymore. There are different aspects of case sensitivity of course, and different platforms have different levels of support. If you haven't actually used D3, you may not realize how far it carries case insensitivity: In Basic: Basic Reserved words: On D3, universe, and Cache, reserved words are case insensitive. On most other systems they are not. The line: print hello world will compile on d3 or universe, but not on unidata or jbase where PRINT is not print. This is a nice feature if you like the look of lower or mixed-case code. Basic Identifiers: ABC=45 Crt abc works on D3, but not anywhere else by default (Cache has a flag to allow this.). Having this reduces unassigned variable errors from typos if you like to use variables like camelCasedValue but prevents you from using case-sensitive variables on purpose (which hopefully no one except old FORTH programmers are in the habit of doing) Basic data: If code=X then STOP On d3 (and nowhere else) the conditional will be true of code=X or code='x'. No mv platform except jbase ever implemented this afaik. From TCL: Case insensitive commands: LIST ERRMSG list ERRMSG D3, universe, and Cache allow this. Unidata looks like it does, but is really a special case--using a lower or mixed case command on unidata overrides the ECLTYPE setting and runs the ECLTYPE U form of the verb, which can have very different behavior from the pick version of the verb Case insensitive keywords: LIST VOC with F1 = V Will work on D3 and Cache, but not on universe. I guess it does work on unidata (unless some keywords also have emulation-specific behavior there) Case insensitive data: LIST voc WITH f1 = v This will work on D3 but nowhere else. On d3 VOC and voc are the same file, F1 and f1 the same dict item, and V an v the same literal. There are probably other case sensitivity issues that I haven't mentioned. And I think someone else already pointed out that D3 does allow you to turn off case insensitivity (for compatibility with R83). On Apr 8, 2011, at 3:09 AM, Mecki Foerthmann wrote: Tony, I don't mind case in-sensitivity in Basic, it actually can make code more readable, but case-insensitive data can be a real pain. On 08/04/2011 00:58, Tony Gravagno wrote: From: Mecki Foerthmann AFAIK UD can be run in case insensitive mode as well. I always turned case-insensitivity off in D3 because I think it's a real pain in the neck. Sounded great to start with but when you see the first printouts (i.e. invoices) you curse yourself if you didn't turn it off.:-( Not to (re)start a war but just present the other side: I consider case-insensitivity to be one strong advantage in D3 over other platforms. I constantly stumble on the requirement to get the casing just right at TCL and elsewhere in some MV environments when it's completely unnecessary and archaic that we should need to stumble on such a thing. Same goes for the difference between dashes and dots (LIST-ITEM vs LIST.ITEM) which is nicely translated for us in QM, Caché, and maybe in some flavors in U2. So just to balance it out. Some people swear at case-insensitivity, but I swear by it. WRT the OP : As soon as I saw the question about D3 to Unidata I immediately thought of the years of pain to which Bill Haskett was subjected. From his experience I swore off ever porting to Unidata. YMMV Symeon, perhaps in another thread (or email) you could explain why a site feels a need to migrate from D3, and then why they chose Unidata. With apologies to the sensitive, I don't think a migration from D3 is justified except for some extreme cases, and as to choosing Unidata, I don't see the business or technical benefits at all. Oh OK, I'll start a holy war. The only compelling reason for migration from a competing platform to U2 _used_ to be the IBM name. That doesn't exist anymore. Now these platforms need to compete on their technical merits and Rocket needs to sell itself on superiority as a business partner. Sorry folks but I don't see any of that. Really - where's the beef? U2 is good software
Re: [U2] Case Sensitivity and Databasic conversion
Ed: The case-insensitivity allowed in UD are those demanded by their biggest clients. There was no resolution of the issue overall in UD, like in D3, but a piecemeal approach. Bill - Original Message - *From:* u...@edclark.net *To:* U2 Users List u2-users@listserver.u2ug.org *Date:* 4/8/2011 1:32 PM *Subject:* Re: [U2] Case Sensitivity and Databasic conversion I see that -I option in the 6.1 developing unibasic applications manual so it isn't brand new. In fact it's listed in the options list twice :) But identifiers are still case sensitive (and aren't in D3). On Apr 8, 2011, at 2:40 PM, Dave Davis wrote: Unidata BASIC has the -I option to allow reserved words to be case insensitive - print would work, although this wasn't available in the older versions. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Ed Clark Sent: Friday, April 08, 2011 2:29 PM To: U2 Users List Subject: [U2] Case Sensitivity and Databasic conversion Trying to change the title, because this isn't really about conversion in general anymore. There are different aspects of case sensitivity of course, and different platforms have different levels of support. If you haven't actually used D3, you may not realize how far it carries case insensitivity: In Basic: Basic Reserved words: On D3, universe, and Cache, reserved words are case insensitive. On most other systems they are not. The line: print hello world will compile on d3 or universe, but not on unidata or jbase where PRINT is not print. This is a nice feature if you like the look of lower or mixed-case code. Basic Identifiers: ABC=45 Crt abc works on D3, but not anywhere else by default (Cache has a flag to allow this.). Having this reduces unassigned variable errors from typos if you like to use variables like camelCasedValue but prevents you from using case-sensitive variables on purpose (which hopefully no one except old FORTH programmers are in the habit of doing) Basic data: If code=X then STOP On d3 (and nowhere else) the conditional will be true of code=X or code='x'. No mv platform except jbase ever implemented this afaik. From TCL: Case insensitive commands: LIST ERRMSG list ERRMSG D3, universe, and Cache allow this. Unidata looks like it does, but is really a special case--using a lower or mixed case command on unidata overrides the ECLTYPE setting and runs the ECLTYPE U form of the verb, which can have very different behavior from the pick version of the verb Case insensitive keywords: LIST VOC with F1 = V Will work on D3 and Cache, but not on universe. I guess it does work on unidata (unless some keywords also have emulation-specific behavior there) Case insensitive data: LIST voc WITH f1 = v This will work on D3 but nowhere else. On d3 VOC and voc are the same file, F1 and f1 the same dict item, and V an v the same literal. There are probably other case sensitivity issues that I haven't mentioned. And I think someone else already pointed out that D3 does allow you to turn off case insensitivity (for compatibility with R83). On Apr 8, 2011, at 3:09 AM, Mecki Foerthmann wrote: Tony, I don't mind case in-sensitivity in Basic, it actually can make code more readable, but case-insensitive data can be a real pain. On 08/04/2011 00:58, Tony Gravagno wrote: From: Mecki Foerthmann AFAIK UD can be run in case insensitive mode as well. I always turned case-insensitivity off in D3 because I think it's a real pain in the neck. Sounded great to start with but when you see the first printouts (i.e. invoices) you curse yourself if you didn't turn it off.:-( Not to (re)start a war but just present the other side: I consider case-insensitivity to be one strong advantage in D3 over other platforms. I constantly stumble on the requirement to get the casing just right at TCL and elsewhere in some MV environments when it's completely unnecessary and archaic that we should need to stumble on such a thing. Same goes for the difference between dashes and dots (LIST-ITEM vs LIST.ITEM) which is nicely translated for us in QM, Caché, and maybe in some flavors in U2. So just to balance it out. Some people swear at case-insensitivity, but I swear by it. WRT the OP : As soon as I saw the question about D3 to Unidata I immediately thought of the years of pain to which Bill Haskett was subjected. From his experience I swore off ever porting to Unidata. YMMV Symeon, perhaps in another thread (or email) you could explain why a site feels a need to migrate from D3, and then why they chose Unidata. With apologies to the sensitive, I don't think a migration from D3 is justified except for some extreme cases, and as to choosing Unidata, I don't see the business or technical benefits at all. Oh OK, I'll start a holy war
