Ben Schmidt wrote:
> 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.
>>
>
> No, it isn't ambiguous. By (1) of my definition, this is not to be
> interpreted as
> a float. Furthermore, a variable with name 'x1.2' is invalid. A more
> confusing
> example would be
>
> let e=3
> let x132=4
> echo x{1e2}
>
> but it still isn't ambiguous by my definition.
>
A variable with the name 'x1.2' is invalid, but: 1.2 currently -> 12,
and x12 is not invalid. But, as you said, the {} in my example is being
preceded by a valid variable name character, so my objection is nullified.
Regards,
Chip Campbell
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
