Rust, Macros, λ-calculus/Church numerals, oh my • Hacker News Board

Re: Rust, Macros, λ-calculus/Church numerals, oh my

#41

Post by celrod » Sat, Jun 08, 2019, 11:13 AM UTC

krapht wrote: post #30

jimmy_dean wrote: post #19

Earlier quoted context omitted.

100% this. To understand code written with Greek letters you'd also need to understand the author's intentions for using said letters. Is mu an average or coeff of friction? Why should I lean on a crutch of context for a casual skim of code? It doesn't help readability and it surely isn't enjoyable to write.

It all depends on context. Short identifiers absolutely help readability. I feel like some people absolutely go too far with overly verbose variable names, especially in Java or C#. Notation matters. What if I told you that to add two numbers you had to write it out as plus(number, number)? Clearly you'd riot. The reason people complain about short IDs is because they're not used to it, but there are a lot of domains…

Aditionaly, in statistics Greek letters denote parameters, while the modern Latin alphabet we all use today is for variables. The data `x` has a normal(mu, Sigma) distribution, for example.

These sorts of conventions enhance readability by providing extra information. You know instantly that `y` must be data, while `theta` is a parameter.

Re: Rust, Macros, λ-calculus/Church numerals, oh my

#42

Post by fluffything » Sat, Jun 08, 2019, 11:20 AM UTC

deogeo wrote: post #40

Sharlin wrote: post #24

Earlier quoted context omitted.

Because people in non-English-speaking countries are perfectly within their rights to name source code entities in their native language instead of either having to mangle words into ASCII representations (possibly even leading to ambiguities in case of near-homonyms that have identical ASCII bastardizations!) or being forced to awkwardly translate domain terminology into English which is a task that may be any of th…

As a non-native-English-speaker, the idea of having invisible bugs in code due to lookalike characters terrifies me. The allowed set of characters would have to be vetted very carefully before I'd consider non-ASCII. Edit: A small taste of what we can expect: https://i.imgur.com/k8S00sM.jpg

> the idea of having invisible bugs in code due to lookalike characters terrifies me.

Unicode maintains a list of these characters (homographs), and Rust rejects them / warns on them.

Re: Rust, Macros, λ-calculus/Church numerals, oh my

#43

Post by Sharlin » Sat, Jun 08, 2019, 11:22 AM UTC

deogeo wrote: post #40

Sharlin wrote: post #24

Earlier quoted context omitted.

Because people in non-English-speaking countries are perfectly within their rights to name source code entities in their native language instead of either having to mangle words into ASCII representations (possibly even leading to ambiguities in case of near-homonyms that have identical ASCII bastardizations!) or being forced to awkwardly translate domain terminology into English which is a task that may be any of th…

As a non-native-English-speaker, the idea of having invisible bugs in code due to lookalike characters terrifies me. The allowed set of characters would have to be vetted very carefully before I'd consider non-ASCII. Edit: A small taste of what we can expect: https://i.imgur.com/k8S00sM.jpg

As a Finn, I don't see how the additional characters ä and ö (which in Finnish are not umlauted a and o but separate letters in the alphabet) could suddenly cause invisible bugs like that. But I can very easily see how ASCIIfying ä and ö to a and o can lead to real misunderstandings (just as an example väärä means "wrong" or "incorrect", but vaara means "danger" (also "esker" but that's less likely to cause confusion :P) Germans might be fine with transcribing ä and ö to ae and oe but in Finnish that's not proper.

Also, bugs caused by accidental homographs in identifier names are caught by any reasonable type system, just like any typos. As for your edit, you can't stop clever people being clever without code reviews anyway, no matter what the language.

Re: Rust, Macros, λ-calculus/Church numerals, oh my

#44

Post by fluffything » Sat, Jun 08, 2019, 11:23 AM UTC

orbital-decay wrote: post #17

db48x wrote: post #11

Earlier quoted context omitted.

I disagree. I looked through the source code to Principia a while back, and it makes really effective use of Greek script, black-letter script, math symbols, etc for implementing a physics engine. (It's a mod for Kerbal Space Program that implements n-body gravitation.) It's really well written and used just enough to make things more understandable. (They've got a great units system too; it's worth reading the code…

>Here's a random selection: https://github.com/mockingbirdnest/Principia/blob/master/phy... I don't think r² as a variable name is a good idea. It may look natural for some (including myself), but for others it implies a function while not being one.

I don't see how r² is worse than r2 or r_2 or r_to_the_power_of_two..

Re: Rust, Macros, λ-calculus/Church numerals, oh my

#45

Post by fluffything » Sat, Jun 08, 2019, 11:24 AM UTC

saagarjha wrote: post #39

db48x wrote: post #13

Earlier quoted context omitted.

Hmm. What would you attack? That is, if you were writing a crate that I was thinking of using in my program, how would homographs allow you to compromise my code?

Here’s a somewhat contrived “attack”: I write a crate with two functions that are named similarly, wait for you to integrate it, then file a pull request using the Unicode function name (and hence calling the malicious function) and be relatively assured that if you looked up the function you’d stop reading code at the ASCII one.

The code published on crates.io does not need to match the code in your github repository, so... you don't need unicode homographs to do this kind of attack.

Also, homographs currently produce a warning...

Re: Rust, Macros, λ-calculus/Church numerals, oh my

#46

Post by magicalhippo » Sat, Jun 08, 2019, 12:07 PM UTC

ajross wrote: post #2

While it's definitely cute and amusing, this is exactly why languages that specify their source code in non-ascii encodings are a bad idea. Fully 92.6% of working programmers have no idea how to produce a λ or γ on their input device of choice. Maybe a third of those could eventually find it with a character picker tool. Java started this (in the unicode era anyway -- yeah yeah, APL). The community quite sanely rejec…

> While it's definitely cute and amusing, this is exactly why languages that specify their source code in non-ascii encodings are a bad idea.

Clearly full Unicode-enabled source code is the future, just look at how amazing it can be: http://baldi.me/blog/emoji-in-sql

Re: Rust, Macros, λ-calculus/Church numerals, oh my

#47

Post by nixpulvis » Sat, Jun 08, 2019, 12:29 PM UTC

tempodox wrote: post #23

Another source code that demonstrates how things that are easy to write, read and understand in FP languages are a nightmare in Rust. Maybe making functional code indecipherable is not the best example of what Rust may actually be good for.

I'm actually finding the opposite. This is mapping very nicely to Rust. But of course not as nicely as it would if I could encode things as lambda terms in the language itself. I'm currently working on an impl of Fn for the Expression. Maybe it'll work out.

This code isn't really meant to be an easily digestible read. I don't make much effort to explain the church numerals for example, I just show that it works with a few tests.

I personally find a lot of good FP principles come into play in Rust quite frequently.

Re: Rust, Macros, λ-calculus/Church numerals, oh my

#48

Post by nixpulvis » Sat, Jun 08, 2019, 12:42 PM UTC

Amazing, 46 comments, all about my choosing to use the correct symbol for the macro. It's not like I choose some super misleading Unicode characters, like for example, how macOS smart quotes might change "foo" into “foo”.

Again, technically correct... maybe programming languages should match these kinds of quotes too.

But this is all more or less beside the point. I can type `λ!{x.x}` easily, since I have a Greek keyboard on my system (and a λ on my wrist, and a cat named π).

It's even more of a small deal as I've included the equivalent `abs!{x.e}` and `app!(e1,e2)` macros. In fact `λ!` and `γ!` are just macro "aliases".

Also, given the prominence of α-renaming, β-reduction, and η-reduction, I'm very glad I can use these symbols in Rust.

Re: Rust, Macros, λ-calculus/Church numerals, oh my

#49

Post by improbable22 » Sat, Jun 08, 2019, 12:48 PM UTC

xiphias2 wrote: post #16

llamathrowaway wrote: post #4

Earlier quoted context omitted.

Maybe it’s time for a plugin that does this (or maybe it already exists?): You press the backslash key, enter the name of the symbol, then press enter, and the symbol will show up in your buffer. Something like: \lambda -> λ \Lambda -> Λ \\ -> \ et cetra.

Atom in Julia Pro does this (with autocomletion), and I've been using it in practice to clarify math in my code. It's great in practice.

Also works in the Julia REPL, and jupyter notebooks. I'd hope that the tooling for any language which allows unicode variable names would support this.

Re: Rust, Macros, λ-calculus/Church numerals, oh my

#50

Post by improbable22 » Sat, Jun 08, 2019, 12:50 PM UTC

nurettin wrote: post #18

ajross wrote: post #2

While it's definitely cute and amusing, this is exactly why languages that specify their source code in non-ascii encodings are a bad idea. Fully 92.6% of working programmers have no idea how to produce a λ or γ on their input device of choice. Maybe a third of those could eventually find it with a character picker tool. Java started this (in the unicode era anyway -- yeah yeah, APL). The community quite sanely rejec…

I did not know how to produce greek letters until I read your comment and thought: why not just add the greek keyboard layout and press l, p and g?

My tip: on recent macs, if you have two keyboard layouts, there's an easy option to make caps lock switch them. (Great so long as you got a mac with a real escape key too...)