[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RE: lua-l Digest, Vol 28, Issue 37
- From: <AllanPfalzgraf@...>
- Date: Fri, 16 Nov 2012 14:47:48 +0000
Thu, 15 Nov 2012 <email@example.com>
>I'm not clear in my mind whether you mean lexical typing or
>table/userdata subtyping as envisaged by the subject of
>If you mean lexical typing. i.e. associating a name permanently
>with a certain type, you get an interesting language: for instance,
>I assign something to a variable that has been typed "string".
>Is it a run-time error if the object is not of type "string"?
>Is coercion to string automatically invoked? Or can the user
>choose by calling some control routine?
Yes, the intent would be to have a name (variable) permanently set to a certain type.
This is also intended to be an option that may be chosen but does not have to be used. When it is not used Lua operates as it always has.
One advantage would be that there is no special syntax needed within operations, such as divide, when the type is fixed. If the assignment in the divide operation is to an integer, the result will be an integer without the need for a "//" instead of a "/" operator. Perhaps using fixed types hides the details more than a new operator would; the operator is in the assignment but the type declaration is on some other line in the script.
Lua is already type-aware. With a fixed type coercion may take place but a change in the type of the name being assigned a value would not happen. If the assignment is beyond what can be accommodated with coercion then a run-time error is a reasonable result. More than likely in that situation there is an error in the script that must be corrected, it should stop.
On the human interface side I have encountered users who misunderstood value based on presentation. When an unsigned integer with its most significant bit set is displayed as a signed integer there can be confusion for the novice user. More precise data types can prevent this type of misunderstanding. Particularly true if the print() function was aware of the optional extended data type information and acted on it appropriately when present.
Just to be clear; this suggestion is not about the description of the data type but the nature of it.