Unicode: unexpected syntax errors due to feature aliases

[Rosivaldo Fernandes Alves]

I have aliased some features with "decorated" operators, like ∃², ∄², ∀², ∃ˣʸ, ∄ˣʸ and ∀ˣʸ. So far so good. I have also a feature declared

filtered alias "|" (...): ...

with no problem.

But I can't declare the feature below

filtered_xy alias "|ˣʸ" (...): ...

or another like

filtered_pair alias "|²" (...): ...

because I get a syntax error on both cases, so I have to change these aliases to "｜ˣʸ" and "｜²", respectively (where the vertical bar is the Unicode 0xFF5C character).

Am I doing something wrong or is EiffelStudio choking with mixed ASCII/Unicode sequences inside alias strings?

Thanks in advance.

Rosivaldo.

[Eric Bezault]

On 16/07/2019 20:53, Rosivaldo Fernandes Alves wrote:
> Am I doing something wrong or is EiffelStudio choking with mixed
> ASCII/Unicode sequences inside alias strings?

There is already a bug report for that:

https://support.eiffel.com/report_detail/19535


--
Eric Bezault
mailto:er...@gobosoft.com
http://www.gobosoft.com

[Rosivaldo Fernandes Alves]

Thanks, Eric. Is there a way of following this report up? That is, another than inspection from time to time?

Em terça-feira, 16 de julho de 2019 16:35:47 UTC-3, Eric Bezault escreveu:

(...)

There is already a bug report for that:

https://support.eiffel.com/report_detail/19535

(...)

[Alexander Kogtenkov]

Dear Rosivaldo,

 

Eiffel is moving towards better support of Unicode, including special syntax for the language constructs like loops. For example, it will be possible to write

 

    ∀ x: list ¦ x.has_some_property

 

instead of the current

 

    across list as x all x.item.has_some_property

 

(Unfortunately, the vertical bar was taken for free operators already, so the broken vertical bar is used.)

 

This raises a question whether such a change can break some user’s code if it uses special symbols like ∀, ∃, ¦. So far not that many users used Unicode operators. But you mention that they are used a lot in your code. So, I wonder if the new syntax could cause problems with your code.

 

I could not find Unicode operators in set-theory-0.30.d, so, I hope, it is unaffected. But I wonder if some of your unreleased code could be affected by the change, so that we need to figure out how to avoid the problem. The idea is to treat ∀, ∃, ¦, ⟳, ⟲ as special symbols, unavaibale for use as operators. If you think this goes too far, let us know, please, and we start a discussion what can be done. I’m looking forward for any feedback on the subject.

 

Best regards,

Alexander Kogtenkov

 

 

Rosivaldo Fernandes Alves <rosiva...@gmail.com>:

[Rosivaldo Fernandes Alves]

Hi Alexander.

Indeed my unreleased code uses such symbols extensively. I do not mind
if I have to change the code to embrace the new syntax. But I really
think that forbiding the use of them as operators is too much. :-)

May I have any hope of keeping my beloved operators? :-p

Best regards,

Rosivaldo.

Em 30/11/2019 09:51, 'Alexander Kogtenkov' via Eiffel Users escreveu:
> Dear Rosivaldo,
>  
> Eiffel is moving towards better support of Unicode, including special
> syntax for the language constructs like loops. For example, it will be
> possible to write
>  
>     ∀ x: list ¦ x.has_some_property
>  
> instead of the current
>  
>     across list as x all x.item.has_some_property
>  
> (Unfortunately, the vertical bar was taken for free operators already,
> so the broken vertical bar is used.)
>  
> This raises a question whether such a change can break some user’s code
> if it uses special symbols like ∀, ∃, ¦. So far not that many users used
> Unicode operators. But you mention that they are used a lot in your
> code. So, I wonder if the new syntax could cause problems with your code.
>  
> I could not find Unicode operators in set-theory-0.30.d, so, I hope, it
> is unaffected. But I wonder if some of your unreleased code could be
> affected by the change, so that we need to figure out how to avoid the
> problem. The idea is to treat ∀, ∃, ¦, ⟳, ⟲ as special symbols,
> unavaibale for use as operators. If you think this goes too far, let us
> know, please, and we start a discussion what can be done. I’m looking
> forward for any feedback on the subject.
>  
> Best regards,
> Alexander Kogtenkov
>  

>  (...)

[Alexander Kogtenkov]

Hi Rosivaldo,

 

Would it be OK to reserve single-letter symbols such as ∀ by the language while allowing sequences with these symbols for free operators? In such a case, ∀ alone could not be used for user’s operators, but a decorated version with some additional symbols (such as ^∀) would be fine.

 

Best regards,

Alexander Kogtenkov

 

 

Rosivaldo Fernandes Alves <rosiva...@gmail.com>:
 

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/3a82d2ee-22b1-c1f6-46cb-63a3325fe1ab%40gmail.com.
 

 

[Rosivaldo Fernandes Alves]

Hi Alexander,

It sounds OK to me.

Thanks a lot for your attention.

Rosivaldo.

Em 09/12/2019 10:57, 'Alexander Kogtenkov' via Eiffel Users escreveu:
> Hi Rosivaldo,
>  
> Would it be OK to reserve single-letter symbols such as ∀ by the
> language while allowing sequences with these symbols for free operators?
> In such a case, ∀ alone could not be used for user’s operators, but a
> decorated version with some additional symbols (such as ^∀) would be fine.
>  
> Best regards,
> Alexander Kogtenkov

> (...)

[Chris Tillman]

You could always combine a non-breaking space character with your individual symbol to make a combination without additional graphics being shown.

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/5753e4e9-9389-4d1b-9fb6-d1176d129876%40gmail.com.

--

Chris Tillman
Developer