In a message dated 12/04/05 20:37:00 GMT Daylight Time, [EMAIL PROTECTED] writes:
> > There are often good reasons for using array slices. Although work-arounds > are usually possible, they may require shifting data into other arrays which > is both time and space consuming. > > An array descriptor merely presents a logical view of the data. If Turbo > at present just sees that a parameter is an array and ignores any indices, > then parsing those indices would have to be implemented - something that > could be a major job! If, however, the indices are accessable to Turbo, then > its simply a matter of creating a descriptor based on those indices - not > much more difficult than creating the descriptor for the whole array? > > The problem as I see it is that the slicing information, which could only be used by Turbo for a machine code extension, would have to be sent by Parser via the intermediate code to codegen which would then have to package it so that in the "proc/fn_rom" section in the entry code (taken from the Turbo library and put in every compiled task) the appropriate (new) code could use the information to set a correct S*BASIC type descriptor. The new code in the entry code is easy. It is the other bits that are not. George _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
