[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: #s semantics (was Re: Lua 5.1-work6 cumulative PATCH #1)
- From: Mark Hamburg <mhamburg@...>
- Date: Wed, 03 Aug 2005 14:50:36 -0700
I would buy that argument.
on 8/3/05 2:44 PM, Mike Pall at email@example.com wrote:
> 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'.