Re: #s semantics (was Re: Lua 5.1-work6 cumulative PATCH #1)

[Mark Hamburg <mhamburg@...>]

I would buy that argument.

Mark

on 8/3/05 2:44 PM, Mike Pall at mikelu-0508@mike.de wrote:

> Hi,
> 
> Roberto Ierusalimschy wrote:
>> Except for the "#s performance improvement", all those corrections are
>> incorporated in the next release;
> 
> Ok, then here is the official plea to change these semantics:
> I'd like #s to be tied down in the core, just like #t is.
> I do not see a point in being able to override it. I explained
> my rationale for this back then in the mailing list thread after
> the announcement.
> 
> This is really more about consistency than just performance.
> When I read some random binary stuff from a file and pass it
> around as a string, then I definitely want *s to return the
> length in bytes and not some strange other measure.
> 
> And about performance: you can bet on it that everyone will
> use #s instead of string.len(s) in the future and then wonder
> why this is slower. Bad PR.
> 
> I have one additional rationale now: It's exceptionally easy
> for a JIT engine optimizer to infer that #s is a string length
> operation and this inlines to only 2 instructions. But it's
> exceptionally difficult (or very unsafe) to do so if the
> behaviour can be changed dynamically.
> 
> IMHO if anyone wants different string 'lengths' (# of chars,
> # of glyphs etc.) they can provide extra function calls or
> extra types. But #s should really consistently return the
> string 'size' aka 'length in bytes'.
> 
> Bye,
>    Mike