Re: main and Re: C strings and other things!

[Lars Hupfeldt Nielsen]

Hi again Keith,

Sorry for my late reply, I am a bit stressed right now.

> > Keith, did you ever get around to reading the Sather-K specification?
>
>      I have looked at this, but there is, in my opinion, no point in
> modifying the language until we have a production quality implementation
> which will permit any such modification to be done without the significant
> compiler overhead needed at present.  There is no point in patching on
> patches on patches on patches ...  Changes should use replacement code -
> not a patch - which has been properly designed from scratch to achiver the
> necessary changes.

I perfectly agree with this as the only way to achieve quality code.

>      By the way, I am not in favour of changing a language design for neat
> features if it breaks the language consistency.  At present the language is
> not quite consistent - particularly in respect of some of the concurrency
> things!!

I regret my choice of words, "neat" was not really what I meant. At least one 
feature,
namely the ability of a (bound) Sather-K stream to retain state across multiple 
seperate
loops, seems to me as an important improvement over the way iterators are 
implemented.
The reason that I feel this change should be implemented soon, is that it will 
change the
semantics of a bound iterator. At least the way that they work in 1.2b will 
change, I
have not seen what the precise definition of a bound iterator specifies with 
regard to
invoking a bound iterator in different loops says.

> > As far as I remember, in the old STR class there was no method converting 
> > an STR to
> > a C_CHAR_PTR, but handing an STR to a function taking a '\0' terminated 
> > char[] would
> > work. This was very ugly. May I suggest something like STR.byte_str_z?
>
>      No!  For all 'array'-based (well, AREF in particular) classes there is
> a feature specified as
>
> array_ptr : REFERENCE
>
> which does what you are intending.  It is a perfectly ordinary feature and
> is used, for example in the library IO sub-section - for both binary and
> text IO!

Does this mean that "array_ptr : REFERENCE" will return a zero terminated 
string,
regardless of the type of array? From the name I would not expect the array to 
be zero
terminated, and I would expect a pointer to the start of the data in the array 
whatever
format (encoding) that might be. What I intended was a function returning a zero
terminated array of C_CHARs (which might possibly involve conversion).

Merry Christmas again.

Regards,
Lars Hupfeldt.