Per Witte wrote:

>>Dave Westbury writes:
>>
>>...different data structures in Qlib'd programs, perhaps it wasn't.
>
>Probably not. Arrays are treated identically to the parser in Qlib :)

I think the problem was that the functions first scanned the name table for
specific integer array names (and checked they were of the correct size) before
filling them from the data stream. When QLib'd they always responded not-found
so I guessed the nametable wasn't used within compiled programs?.

>I cant say Ive hit too many limitations using Qlib with SMSQ/E.

I found that many that it was too daunting to consider rewriting it (just did a
quick try and got 388 MISTakes). It was a very specific program anyway (a Yamaha
SY35 synthesiser voice filer/editor) which required access to MIDI port on a QL.

> ...un-initialised variables,

The one thing I dislike most about SMSQ is the practice of setting unused
variables to zero or empty string. I have spent hours looking for bugs that
turned out to be a typo in a variable name! Something like the INSTR_CASE
command for changing the default behaviour would be welcome.

>try
>
>a$='abc': PRINT ('x'&a$)(4)


chr$(0), strange.

>If the location and format of Turbo arrays were known, and the parser could
>be told to shut up about array parameters passed to m/c procedures, then
>extention toolkits could test for Turbo and take the appropriate action.
>Unless the header or storage format are very different, even patching some
>non supported toolkits might be possible. Just a thought.

The new TURBO_V will apparently allow some powerful array structures
manipulations.

Regards,
Dave.


Reply via email to