Problem-solving: Should ¿? and ¡! be an alternative to "" ?

[AlexDaniel]

See this draft PR with a discussion: https://github.com/rakudo/rakudo/pull/3218
Further comments should be left here.

[AlexDaniel]

Just to clarify, the mentioned PR also implements — —, but let's first decide on ¿? and ¡!.

[alabamenhu]

I don't believe it should — at least not as a quote mechanism.

As I mentioned in the thread with the PR (and as a regular user of two languages that employ ¿? and ¡!), the more logically interpretation would be as a truthy circumfix. Thus, I would interpret ¿ $foo && $bar ? to be equivalent to ?($foo && $bar), and ¡ $foo && $bar ! to be equivalent to !($foo && $bar).

...which actually would be kind of nice, since it would remove a set of parentheses.

[JJ]

@alabamenhu love that.

[jnthn]

I've not seen any convincing arguments in favor of adding them as quoting constructs.

We do have quite a range of alternatives to the "..." and '...' quotes in place - which was done because folks did type those forms and we may as well make them Just Work. I'm fine with us looking at adding quote forms that clearly are used in the same role as "..." in other natural languages. However, it doesn't look like ¿? nor ¡! meet that condition; their primary role is not for quoting.

Thus, no.

[jnthn]

...which actually would be kind of nice, since it would remove a set of parentheses.

You can use not or so without parentheses if the precedence is right, which it often will be. Thus the saving is not so great - especially when explicit boolification is not called for terribly often anyway.

[AlexDaniel]

Now that I think about it, this page lists some criteria for adding new unicode ops and ¿?/¡! barely fulfill just one (I guess it's not that easy to implement it in a module). It's fun to think about new fancy features but it'd need to be the right time for adding some, and now it's definitely not.

[alabamenhu]

...which actually would be kind of nice, since it would remove a set of parentheses.

You can use not or so without parentheses if the precedence is right, which it often will be. Thus the saving is not so great - especially when explicit boolification is not called for terribly often anyway.

Oh, I get it. I'm not necessarily advocating for its inclusion, just saying if it were, that's what its function ought to be. But you have to admit, the alignment on them looks rather cool.

¿ 
| $a 
| $b 
| $c
? 

(I guess it's not that easy to implement it in a module)

I tried implementing this for funsies, but the custom circumfix doesn't work easily because the eager matching of the terminal token causes problems. If that were work-aroundable (or fixable, depending if it's working as designed or just not previously contemplated), it would render the question entirely moot.

Edit: Actually, it was causing problems elsewhere, which definitely feels buggy:

#multi sub circumfix:<¿ ?> (\a) { so a }
say ? False;
say ( ? False)

Uncomment out the circumfix sub, and the second one becomes a syntax error, but the first one doesn't.

[AlexDaniel]

But you have to admit, the alignment on them looks rather cool.

¿ 
| $a 
| $b 
| $c
? 

I don't think you can do that. You'll get a slip. You probably meant || too, but it has the same problem.

[alabamenhu]

I don't think you can do that. You'll get a slip. You probably meant || too, but it has the same problem.

I've been dealing with regex/binex way too much ;-)

[treyharris]

I’m honestly kind of shocked—in perusing
https://github.com/rakudo/rakudo/wiki/save-me-from-ASCII — that
the →, ↔ and ⇒ haven’t been implemented yet. I was just messing with my
Haskell editor bindings to autocorrect to Unicode, and very likely would
have stuck those into Raku mode as well without realizing it wouldn’t
produce functional Raku code.

[AlexDaniel]

@treyharris yeah, these three kinda make sense because ->, <-> and => are really just trying to paint arrows. Moreover at least some software (e.g. libreoffice) autocorrects -> to → by default. So that's 2 reasons out of 4, maybe even 3.

\ But is it worth it? People don't even use unicode quotes even though they're actually more useful, so I don't know what to think. Most keyboards suck, default layouts suck even more and people are generally unwilling to change anything about their setups. We can implement all unicode ops in the world and just a few people will use them.
\

[CurtTilmes]

We can implement all unicode ops in the world and just a few people will use them.

In the beginning perhaps -- but is that a problem? Or a reason not to implement? If people are happy to use ascii, let them. I suspect that will be true for a while.

But technology improves over time, and more and more will come to better technologies. The next generation of keyboards, editors, languages (and yes programmers too) will come to do the newer stuff. The question is which language will be there to meet them when they finally are ready?

[treyharris]

On Mon, May 4, 2020 at 15:25 Curt Tilmes [e-mail] wrote:

We can implement all unicode ops in the world and just a few people will
use them.

In the beginning perhaps -- but is that a problem? Or a reason not to
implement? If people are happy to use ascii, let them. I suspect that will
be true for a while.

But technology improves over time, and more and more will come to better
technologies. The next generation of keyboards, editors, languages (and yes
programmers too) will come to do the newer stuff. The question is which
language will be there to meet them when they finally are ready?

I already find it intensely annoying that I now have to open a text editor
and copy-paste if I’m involved in an email or comment exchange like this
and need to refer to -> and not → , -- and not —, and so on,
because so many different layers are all trying to “fix” my ASCII into
Unicode for me. We all have dealt with this forever—it’s the basic reason
why programmers use editors rather than word processors—but it would be
extremely pleasant for characters that

1. Are just repaintings
2. Are frequently autocorrected by certain OS’s, including mobile OS’s
3. Are already represented in programming-oriented fonts as double-width
   (or whatever width is relevant) characters.

So yes, this is a real problem and yes, it will get worse as time goes on.

[AlexDaniel]

@treyharris well, then start a problem-solving ticket for unicode arrows. :)