Re^4: getting rid of costly special features

[LanX]

in reply to Re^3: getting rid of costly special features
in thread getting rid of costly special features

> Care to back that assertion up with some evidence?

Strings are immutable in JS, now how would you implement a postincrement?

Instead of i++ of a primitive value i, you need to use objects for all scalars with methods like i.postInc() and i.preInc() and i.getValue()

[BrowserUk]

Essentially what you are arguing is that we should change the Perl5 language and interpreter so that you can replace it with another interpreter written in Javascript. Which is ....!

Besides which, in order to preserve Perl5's semantics, you would have to have a scalar type that could represent integers, floats, strings and references. Ie. You would have to box your ints.

Here you are saying that to do so would make things too slow; and yet it is only a few months since you were advocating autoboxing everything in Perl for the sake of some OO ideology, and hang the (enormous) performance hit.

There's nothing like consistency. And that's nothing like it :)

[LanX]

nonsense ... Did the possibility to insert no autovivification change the language?

[BrowserUk]

Man, you really don;t think things through do you.

A configurable pragma won't speed numerical increment up, it'll slow it down. It's just one extra test that will need to be performed every time.

And it won't help a JS port, unless the JS port will only run code that disables all the things that come from having transparent type conversion.

That includes things like 2**32 (or 2**64) + 1 becoming an NV; and 0+'12' doing the right thing. And at that point; it ain't Perl.