#400 Unicode symbols as alternatives to c operators

helium Thu 20 Nov 2008

Fan uses the same operators C uses. What about allowing the more conventional unicode symbols as alternative.

!= ?
<= ?
>= ?
&& ?
|| ?
!  ¬

edit: OK, sorry, but Unicode is not supported by this forum. I tried posting this with Opera as well as Firefox (both latest version). In both cases the preview works but as soon as I submit everything but the not symbol got translated into questionmarks.

So I'm suggesting

!= 2260
<= 2264
>= 2265
&& 2227
|| 2228
!  00AC

helium Thu 20 Nov 2008

Test:

00C0 À

1E00 ?

2100 ?

helium Thu 20 Nov 2008

Test2:

00C0 À

1E00 ?

2100 ?

brian Thu 20 Nov 2008

OK, sorry, but Unicode is not supported by this forum.

This is a bug - we definitely need to fix it.

What about allowing the more conventional unicode symbols as alternative.

I do find the limitations of traditional ASCII maddening. But I don't really like the idea of having core syntax which doesn't rely on ASCII characters. They are hard to type and it forces source files to be UTF-8 instead of simple ASCII. I know Fortress is going that route, but I don't think it is right for Fan.

helium Thu 20 Nov 2008

Well, I don't suggest to replace the old operator names but to allow the alternatives with the same meaning. So as long as you don't have an easy way to enter them you can use &&, || and friends.

Otherwise this is the chicken-egg problem, right? Nobody uses these characters so editors don't offer simple ways to enter them. Editors don't offer easy ways to enter these symbols so nobody uses them.

helium Thu 20 Nov 2008

Perhaps they should allways be stored as <=, >=, ... so you can edit the files even in realy bad editors, but Fan-aware editors could display them as the unicode characters?

katox Thu 20 Nov 2008

I don't think it is a good idea. Users will copy'n'paste code snippets to (various) forums and back, that's for sure. You'll have to translate unicode and ascii back and forth all the time (using exclusively Fan-aware editors).

Easier possibility to mess the posted code the worse. It's often problem for 2D syntax languages - and could be for Fan semicolumn-less code.

And the "hard to type problem" isn't caused by bad editors but by a keyboard design. I certainly don't want to write code using a "insert character" wizard. Note: I'm using a local keyboard layout so I'm not lazy to press altgr - czech alphabet has 13 accented characters ;)

helium Thu 20 Nov 2008

Users will copy'n'paste code snippets to (various) forums and back, that's for sure.

As long as it's not this forum that's no problem ;)

Just to make that sure: fooäöüáà???? is a valid identifier in C#.

You'll have to translate unicode and ascii back and forth all the time (using exclusively Fan-aware editors).

OK, let's drop that idea of storing characters differently.

I certainly don't want to write code using a "insert character" wizard. Note: I'm using a local keyboard layout so I'm not lazy to press altgr - czech alphabet has 13 accented characters ;)

IMO it depends. If it's e.g. right control + ! => ¬ than it wouldn't be too bad (I never use the right control key). So allways press right control plus the key used for the first letter of the C-operator results in the unicode character.

alexlamsl Thu 20 Nov 2008

Just passing by to say that Perl 6 is doing that as well...

brian Thu 20 Nov 2008

Perhaps they should allways be stored as <=, >=, ... so you can edit the files even in realy bad editors, but Fan-aware editors could display them as the unicode characters?

I think that is an editor issue, not really a Fan compiler issue. In fact it might be cool if code editors worked kind of like Word where <= "auto-corrected" itself to the Unicode char.

But I don't want to change Fan's compiler to accept alternate syntax for those operators. If that technique does become common, we could add it in the future without effecting backward compatibility.

Login or Signup to reply.