A question of type assertion

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

A question of type assertion

Dibyendu Majumdar
Hi,

As I progress with Ravi I often wish there was a way to perform type
assertion or coercion in the language. For example:

local t = { 1 }
local i: integer = t[1]

Above fails in Ravi as the compiler cannot know that the value
returned from t[1] is an integer.

It would be nice to be able to say:

local i: integer = t[1] as integer

Or some such like.

Language support is essential for performance reasons; Ravi already
supports type coercion of function return values. So following already
works.

function asinteger(a) return a end
local i: integer = asinteger(t[1])

Problem is this is bad for performance.

Now here is a hypothetical question - if Lua had been statically typed
language - what would the ideal expression be for this kind of type
coercion?

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: A question of type assertion

Coda Highland
On Mon, Nov 9, 2015 at 2:00 PM, Dibyendu Majumdar
<[hidden email]> wrote:

> Hi,
>
> As I progress with Ravi I often wish there was a way to perform type
> assertion or coercion in the language. For example:
>
> local t = { 1 }
> local i: integer = t[1]
>
> Above fails in Ravi as the compiler cannot know that the value
> returned from t[1] is an integer.
>
> It would be nice to be able to say:
>
> local i: integer = t[1] as integer
>
> Or some such like.
>
> Language support is essential for performance reasons; Ravi already
> supports type coercion of function return values. So following already
> works.
>
> function asinteger(a) return a end
> local i: integer = asinteger(t[1])
>
> Problem is this is bad for performance.
>
> Now here is a hypothetical question - if Lua had been statically typed
> language - what would the ideal expression be for this kind of type
> coercion?
>
> Regards
> Dibyendu
>

Personally I'd go with asinteger() (or perhaps cast.integer(), to
limit the namespace pollution to a single keyword) so that the grammar
doesn't need modified, and then special-case the function invocation
as some kind of intrinsic instead of an actual function call.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: A question of type assertion

Daurnimator
In reply to this post by Dibyendu Majumdar


On 9 Nov 2015 2:00 pm, "Dibyendu Majumdar" <[hidden email]> wrote:
>
> Hi,
>
> As I progress with Ravi I often wish there was a way to perform type
> assertion or coercion in the language. For example:
>
> local t = { 1 }
> local i: integer = t[1]
>
> Above fails in Ravi as the compiler cannot know that the value
> returned from t[1] is an integer.
>
> It would be nice to be able to say:
>
> local i: integer = t[1] as integer
>
> Or some such like.
>
> Language support is essential for performance reasons; Ravi already
> supports type coercion of function return values. So following already
> works.
>
> function asinteger(a) return a end
> local i: integer = asinteger(t[1])
>
> Problem is this is bad for performance.
>
> Now here is a hypothetical question - if Lua had been statically typed
> language - what would the ideal expression be for this kind of type
> coercion?
>
> Regards
> Dibyendu
>

Have you seen typedlua? https://github.com/andremm/typedlua

Reply | Threaded
Open this post in threaded view
|

Re: A question of type assertion

Roberto Ierusalimschy
In reply to this post by Dibyendu Majumdar
> Now here is a hypothetical question - if Lua had been statically typed
> language - what would the ideal expression be for this kind of type
> coercion?

If Lua was statically typed, it would know the type of the expression.
Either it has the correct type or the wrong type. In both cases type
coercion seems useless.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: A question of type assertion

Dibyendu Majumdar
On 9 November 2015 at 22:32, Roberto Ierusalimschy
<[hidden email]> wrote:
>> Now here is a hypothetical question - if Lua had been statically typed
>> language - what would the ideal expression be for this kind of type
>> coercion?
>
> If Lua was statically typed, it would know the type of the expression.
> Either it has the correct type or the wrong type. In both cases type
> coercion seems useless.
>

That is true if there was no type such as 'any'. I mean a system that declares:

local x as table of any

is also statically typed, but the type is declared to be 'any'.

The statically typed languages I am familiar with all appear to
support type conversion operators although this is usually to support
polymorphism.

With Ravi of course there is a the special problem of bridging dynamic
typing with static typing.

When I declare:

local x: integer[] = {1}
local i: integer = x[1]

No coercion is needed as compiler can tell that the expected type if
x[1] is an integer so no problem.

But in the example cited earlier this static analysis is not possible.

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: A question of type assertion

Dibyendu Majumdar
In reply to this post by Coda Highland
On 9 November 2015 at 22:15, Coda Highland <[hidden email]> wrote:
>> Now here is a hypothetical question - if Lua had been statically typed
>> language - what would the ideal expression be for this kind of type
>> coercion?
>>
> Personally I'd go with asinteger() (or perhaps cast.integer(), to
> limit the namespace pollution to a single keyword) so that the grammar
> doesn't need modified, and then special-case the function invocation
> as some kind of intrinsic instead of an actual function call.
>

According to the 'Evolution of Lua' paper the last Lua version that
had intrinsics was 3.2. I had a quick look but it seems that the
intrinsics were just predefined library functions - i.e. the VM wasn't
aware of those functions in any special way - but I could be mistaken
as I only glanced at this very quickly.

I have been thinking about the idea of intrinsics that the VM is aware
of. Agree that doing it this way means that it behaves no different
than if there were some functions that did the same thing.

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: A question of type assertion

Dibyendu Majumdar
On 9 November 2015 at 23:09, Dibyendu Majumdar <[hidden email]> wrote:

> On 9 November 2015 at 22:15, Coda Highland <[hidden email]> wrote:
>>> Now here is a hypothetical question - if Lua had been statically typed
>>> language - what would the ideal expression be for this kind of type
>>> coercion?
>>>
>> Personally I'd go with asinteger() (or perhaps cast.integer(), to
>> limit the namespace pollution to a single keyword) so that the grammar
>> doesn't need modified, and then special-case the function invocation
>> as some kind of intrinsic instead of an actual function call.
>>
>
> I have been thinking about the idea of intrinsics that the VM is aware
> of. Agree that doing it this way means that it behaves no different
> than if there were some functions that did the same thing.
>


Come to think of it actually it could be a noop function - i.e. the
function call would cause the code generator to insert type coercion
operations but then the VM would recognise the noop function and do
nothing. So I can imagine a function called cast() which is this magic
noop function.

local i: integer = cast(x[1])

Would cause the code generator to emit TOINT opcode after calling the
function cast(). But the VM would not call any function at all as it
would recognize 'cast()' as noop.

Does this sound crazy?

Regards

Reply | Threaded
Open this post in threaded view
|

Re: A question of type assertion

Roberto Ierusalimschy
> Come to think of it actually it could be a noop function - i.e. the
> function call would cause the code generator to insert type coercion
> operations but then the VM would recognise the noop function and do
> nothing. So I can imagine a function called cast() which is this magic
> noop function.
>
> local i: integer = cast(x[1])
>
> Would cause the code generator to emit TOINT opcode after calling the
> function cast(). But the VM would not call any function at all as it
> would recognize 'cast()' as noop.

What do you mean by "the VM" in this sentence? If the code generator can
recognize the noop funcion (so that it does not insert a call to it),
couldn't it recognize a cast function and inline it?

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: A question of type assertion

Dibyendu Majumdar


On Tuesday, 10 November 2015, Roberto Ierusalimschy <[hidden email]> wrote:
> Come to think of it actually it could be a noop function - i.e. the
> function call would cause the code generator to insert type coercion
> operations but then the VM would recognise the noop function and do
> nothing. So I can imagine a function called cast() which is this magic
> noop function.
>
> local i: integer = cast(x[1])
>
> Would cause the code generator to emit TOINT opcode after calling the
> function cast(). But the VM would not call any function at all as it
> would recognize 'cast()' as noop.

What do you mean by "the VM" in this sentence? If the code generator can
recognize the noop funcion (so that it does not insert a call to it),
couldn't it recognize a cast function and inline it?

Yes you are right. I use the term VM to mean the interpreter and the generated JIT code; typically I first prove the concept in interpreter mode and then implement the JIT code generation.

I think though the VM will have a hard time recognising the special functions ... So maybe the parser needs to recognise and generate a new bytecode instruction. Not looking forward to that!

Regards
Dibyendu