Charles E Campbell Jr wrote:
> Ben Schmidt wrote:
>
>> Ben Schmidt wrote:
>>
>>
>>>> OTOH, with & there is no ambiguity because the various uses of & are
>>>> strictly separated:
>>>>
>>>>
>>> Actually, there still is ambiguity unless one requires a decimal point or
>>> exponent. Without that restriction
>>>
>>> &123.456
>>>
>>> could still mean 123 (or 123.0) concatenated with 456. But with the
>>> restriction
>>>
>>> &123
>>>
>>> is invalid. Not sure whether that's desirable. Probably the lesser of two
>>> evils.
>>> Of course, it needs to be enforced that printf and such functions either
>>> omit the
>>> ampersand for floats which happen to be integers (probably undesirable) or
>>> always
>>> append a '.0' in this case.
>>>
>>> Would wrapping floats in braces be a better syntax? I don't think this
>>> would clash
>>> with anything: dictionaries require keys followed by colons which don't
>>> occur in
>>> floats, and a float is also an invalid variable or function name due to
>>> starting
>>> with a digit or sign (+/-) so couldn't be used as part of curly-brace
>>> variable or
>>> function names. E.g.
>>>
>>> :let myfloat={12.52}
>>> :let mybig={1234e56}
>>> :let myintegerfloat={123}
>>>
>>> To me, this is nicer than a leading &, and avoids the nasty restriction of
>>> needing
>>> a decimal point all the time/ambiguity of decimal point vs. concatenation.
>>>
>>>
>> Actually, to clarify, my proposal is that a set of curly braces is taken to
>> represent a float if and only if it is (1) not preceded by a valid variable
>> name
>> character and (2) contains a valid float.
>>
>> I.e. floats:
>>
>> {+123.456}
>> {-123}
>> {123e-4}
>> {123.456}something_to_concatenate
>>
>> non-floats:
>>
>> {dictionary: 'value'}
>> variable_name_with_number_{123}
>> variable_name_with_number_and_variable_e_concatted_and_included_{123e4}
>> variable_name_with_six_digits_here_{123.456}
>> {variable_name_from_a_variable}
>> {10<x?'variable_1':'variable_2'}
>>
>> combination!:
>>
>> variable_name_with_float_expression_giving_{{0.55}<some_float?'true':'false'}
>> variable_name_with_float_that_prints_as_integer_{{123}}
>>
>> invalid:
>>
>> variable_name_with_punctuation_due_to_float_{{123.456}}
>>
>> I think it works unambiguously and sensibly, though, of course, you can
>> still do
>> dumb things if you try hard enough! But I don't think it breaks anything
>> that
>> currently works (even if what currently works is dumb)!
>>
>>
> let x12=3
> echo x{1.2}
>
> Works quite nicely -- and is ambiguous with respect to floating point
> overloading.
>
Sorry -- forgot about the no leading variable-name characters (ie.
[a-zA-Z:_<>]).
Regards,
Chip Campbell
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
