On Thu, 15 Nov 2001, CBFalconer wrote:
Mirsad Todorovac wrote:
... snip ...
However, SPARSE SETs seem to me like an excellent challenge for a programmer, but they *do* introduce new issues, for example memory allocation problems - since their size can't be computed at compile time since it depends on actual # of set members; and so on and so on ...
Frank, what do you think of these thoughts of mine? Anybody?
I am a crusty old conservative when it comes to Pascal. I don't think it should be extended to do everything. I don't even believe in sets of over 256 items. The code generation should be kept simple and accurate. If you want a sparse set you can build it yourself, probably out of linked lists of subsets. If you really want large sets an array of subsets is quite adequate.
Maybe. But (Visual) Basic, C++ and FORTRAN also evolve, don't they? For example, consider Visual Basic's "collections", which are basically sets of members which can have various types (also mentioned in gpc info's TODO list as ???).
Besides, for example, when UNICODE comes into play, you will need at least set of range 65536 to test ranges in Chinese Big5 set, won't you? And using current representation of bit-array it takes 8kb per set, so alternate forms of representation might be and probably will be considered.
Besides, compiler programmers on average have higher coding skills than program writters that use those compilers, so if it's built-in in language, there's less repetative work that each and every programmer has to do.
Besides, sparse sets I have to debug in each program, while sparse sets in debugger are made correct (or even state-of-the-art) once and then reused many times.
Besides, sparse sets wouldn't put too much of a hard burden on compiler itself, since 95% of the stuff required to make it work belongs to RTS library anyway, doesn't it?
Besides, it can be done without compiler and language interface change, just by making RTS functions more sophisticated.
This would mean preserving compiler elegant, simple and accurate, while doing additional stuff in RTS library.
These are NOT items you use every day. However, SET OF ['0'..'9'] is.
Yup, but for a Chinese programmer this ['0'..'9'] may run well beyond your 256 elements per set (since their glyphs number about 3000 to read daily newspapers). With i18n issues, all design based on assumption that people will never want to use anything outside US-ASCII will eventually have to be rewritten IMHO, and that might be a very close future.
You will probably agree with me that programming languages somewhat shape the way we think and program: so, even before C++ X Windows were object oriented, but with C++ OO design comes natural. (Also with OO Pascal.) So, it's hard to estimate how useful is feature of comp.lang. before it's implemented.
I consider the lack of comprehensive range checking to be a very serious failing. This makes a mockery of taut typing with subranges. With such there is no need to check indices, instead you can rely on the programmer to specify a suitable type for them.
I remember wonderful {$R+} and {$R-} in UCSD Pascal back then in '87 when I was writting high-school gradutation thesis program. With range checking I was able to debug very fast program of 1500 lines (but then I was younger also :-) ... ). I meant to say how range-checking in Pascal cuts bugs much sooner than debugging in C.
With proper subranging you can keep the cost of run-time checks way down. Studies have shown it to be in the order of 5%.
5% less, or 95% eliminated? Didn't quite catch that.
Anyway, range checking can be life saving. For example, remember Arianne launch failure when a 16-bit counter that was there for years rolled-over into negative when something was speeded-up. (In the time of design they said it can never go over 16 bits.) So, the unit failed, after which rendundant unit was consultet only to have the same result (of course, using the same software and same 16-bit counter). Then the rocket's computer thought it started to fall down and activated self-destruct sequence, even though it was climbing.
This story makes me agree that extensive range-checking, especially with arrays, sets and (last but not the least) implicit precision conversions is very important. That's also a weakness of C language which C++ hasn't eliminated (but I'm slightly off-topic maybe?) ...
I'm way of out line (for a short reply) this time, so I'm ending message without final conclusion.
mirsad
-- This message has been made up using recycled ideas and language constructs. No plant or animal has been injured in process of making this message.