[HN Gopher] Analog - An analogous, indented syntax for the Rust ...
___________________________________________________________________
Analog - An analogous, indented syntax for the Rust programming
language
Author : asvln
Score : 45 points
Date : 2021-09-19 14:29 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| zengid wrote:
| This is a neat experiment, kind of making Rust look more like f#
| or haskel. I admit that Rust can get a little verbose, so I'm
| happy to see folks taking a fresh perspective towards it.
|
| While I like `^` for marking mutability, other things might not
| need to be so abstract (`=:` instead of `fn`) or re-purposed,
| like using `|i|` for loops instead of a Rust closure.
| zozbot234 wrote:
| Rust does get a little verbose, but this syntax proposal isn't
| doing much to simplify it either. It's mostly a lexical choice
| of symbols over reserved words, but the amount of separate
| symbols is IMHO a bit too high for comfort. (The choice of
| semantic indentation leads to additional drawbacks when
| copy/pasting code.)
|
| Reserved words may be inelegant in principle (since they
| intrude on the namespace for identifiers), but at least they're
| easier to type on most keyboards. And Rust seems to be going
| for a rather minimalistic syntax already. It's certainly not as
| verbose as languages in the BASIC, Pascal or Ada lineage, let
| alone Cobol.
| bscphil wrote:
| > I admit that Rust can get a little verbose
|
| Heh. As a self-taught developer with a dumb ape brain, if
| anything I wish it was _more_ consistently verbose. I 've read
| through the Rust book and tutorials multiple times, and I've
| still not been able to wrap my brain around how lifetimes work.
| Personally I think the incomprehensible <a'> syntax has a lot
| to do with that. I'd love to see a kind of pseudocode that
| compiles to rust simply for the purpose of making it easier to
| learn the real language.
|
| Maybe you're thinking "wait, lifetimes are easy, you just..."
| but I think the reality is probably that most people who want
| to learn programming on their own, don't have a job in the
| field, and have never had a compsci class are going to have
| trouble wrapping their heads around the concepts. I can write
| good Python code. I can write safe C code (because it's easy to
| understand _explicit_ allocation and freeing of memory), but I
| 've never been able to make lifetimes work in my head. The
| complexity of rustc's error messages doesn't help much either,
| last time I tried it.
| zozbot234 wrote:
| If anything, lifetimes are one key part of Rust where I don't
| really see how a different syntax would help. The <'a> and
| &'a syntax is nicely self-contained, but the semantics can be
| obscure to novices.
| kator wrote:
| My first impression was "Oh, CoffeeScript for Rust".
|
| What is the goal of this specification? Maybe I missed it in the
| point. Also the name might be a bit challenging considering the
| overall footprint and overloaded nature already of the word
| `analog`.
| lostdog wrote:
| I feel a sense of relief when working in a language where you can
| paste some code, hit autoformat, and not worry if any lines might
| have been accidentally added or removed from a for, if, or while
| block.
| andi999 wrote:
| Looking at python here...
| rappatic wrote:
| This is gross
| dang wrote:
| " _Please don 't post shallow dismissals, especially of other
| people's work. A good critical comment teaches us something._"
|
| https://news.ycombinator.com/newsguidelines.html
| ibraheemdev wrote:
| There was a pre-proccessor for Rust without curly brackets that I
| can't seem to find now... It actually looked very nice. The two
| biggest changes I would probably make are square brackets for
| generics, and in-band lifetimes everywhere.
| nixpulvis wrote:
| Oh cool, let's make a (mostly) ergonomic language and throw it
| away for the sake of a few keystrokes.
|
| Scope is a lie anyway, right!?
|
| I'm glad to see they didn't start implementing anything.
| dang wrote:
| " _Please don 't post shallow dismissals, especially of other
| people's work. A good critical comment teaches us something._"
|
| " _Don 't be snarky._"
|
| https://news.ycombinator.com/newsguidelines.html
| [deleted]
| codesections wrote:
| This is great! Its amazing how much more readable programming
| languages get when they drop the visual noise created by
| unnecessary keywords - there's a _reason_ math is so much easier
| to understand when it 's expressed with symbols than with words,
| and it's very surprising how few programming languages recognize
| that.
|
| (I notice a few comments describing this syntax as _less_
| readable. My first thought was that these comments were sarcastic
| /trolling, but I've concluded that they're serious - but written
| by programmers who think _very_ differently than I do!)
| Zababa wrote:
| > (I notice a few comments describing this syntax as less
| readable. My first thought was that these comments were
| sarcastic/trolling, but I've concluded that they're serious -
| but written by programmers who think very differently than I
| do!)
|
| I think you have to take into account familiarity here. Rust
| uses "fn" for functions, which is really short (the same as :=
| really), but it's easy to see how it's the short version of
| "function". On the other hand, := is assignment in some
| languages (usually Pascal descendants), and is used for
| "definition" in BDNF. That makes it hard to map it to
| "function".
| brundolf wrote:
| > there's a reason math is so much easier to understand when
| it's expressed with symbols than with words
|
| Had to do a double-take to make sure this wasn't /s
|
| It's my opinion that the use of random symbols is the primary
| reason math is so _inaccessible_. It is for me, and anecdotally
| I 've heard dozens of others say the same thing. The only
| imaginable benefit I can see to using symbols is that they're
| easier to write quickly on a chalkboard.
| olvy0 wrote:
| I completely agree. For me it's less readable. I also think
| math is less accessible due to its use of random symbols that
| are context-dependent.
|
| "Readability" is a highly, highly subjective matter, and
| depends on one's education, background, knowledge, experience
| etc. People seem to use it as a shorthand for "math-like
| shorthand", but that's not what I mean when I say readable,
| it's like we speak in a different language.
|
| Personally I find the adjective "readable" a major trigger,
| it seems to be thrown around by people who are either
| trolling or who seem to live in a kind of a social (online)
| bubble and don't know anyone else with a even a slightly
| different background. This is always slightly shocking to me.
| ilaksh wrote:
| Right. It's not just that they are random symbols. They are
| also inherently obscure symbols.
|
| But just bad as or maybe worse are the variable names which
| are random, short, and completely non-descriptive. If you
| compare it to source-code, it's like the worst code ever
| written.
| wrs wrote:
| Does this mean you prefer Ada or COBOL to C or JavaScript?
| All symbols (and words!) are "random" if you haven't learned
| what they mean. I remember when I transitioned from BASIC to
| C (this was a while ago) it seemed ridiculously terse and
| full of crazy punctuation, but C-like syntax is now
| considered "accessible".
| johnisgood wrote:
| I am a crazy one, I like both Ada and C!
| joppy wrote:
| The other huge benefit to symbols is that they are compact,
| and recognising patterns or performing symbolic manipulation
| is much easier when everything is shorter and closer
| together. Mathematics also uses a two-dimensional layout in
| some places (integrals, fractions), with very well-chosen and
| suggestive notation, which would be lost completely going to
| words.
| dhosek wrote:
| I remember sitting in the hallway of the building with the
| math department waiting for a class to start and picking up a
| booklet on a table with a style guide for writing mathematics
| and it specifically advised using words in place of symbols,
| e.g., preferring "for all _x_ in the integers" over "[?] _x_
| [?] R."
| dhosek wrote:
| D'oh, not integers, reals. Sigh.
| mkl wrote:
| I'm not a Rust programmer, but I can read and mostly understand
| the Rust code I've seen. This by comparison is incomprehensible
| to me. Your analogy to maths doesn't seem to hold up, because I
| am a mathematician, and still find this syntax unreadable. To
| me it is almost the definition of "visual noise", as it doesn't
| use words where maths would, and contains many extra redundant-
| seeming symbols maths would omit. I also really like Python's
| indentation syntax, so I have no objection to that in
| principle.
|
| Take these three lines from the README example:
| |?| ^door <= 100 ^door_open[door - 1]
| !^door_open[door - 1] ^door += pass;
|
| Without the docs I don't have any idea what this does. Even
| with the docs it makes very little sense to me. |?| seems to
| start a loop, but it doesn't seem to be in the documentation
| (the closest thing is |??| for "while"). ^ means mutability,
| but is needed in the first line for some reason even though no
| mutation is happening? (Or is mutation happening? <= doesn't
| seem to have changed meaning though.) But then ^ is not needed
| on the mutable "door" in the second line? What does the second
| line do? It's not assignment, according to the docs, because
| that is a very un-mathematical prefix thing (but everything
| else, including other assignments like +=, is infix?). It seems
| to be just two expressions next to each other, and the docs
| don't seem to say that's meaningful. Why does the third line
| have a ;, but not the second? Is the second line somehow part
| of a statement finished on the third (which isn't indented)? Is
| the second line a ?-less condition affecting the third?
|
| I am not being sarcastic or trolling. I genuinely don't
| understand this. The assumptions I'm aware of making are (1)
| the documentation covers everything new in the new syntax, and
| (2) the example in the README is valid code in the new syntax.
|
| Serious question: do you understand these "much more readable"
| three lines?
| reificator wrote:
| > _(I notice a few comments describing this syntax as less
| readable. My first thought was that these comments were
| sarcastic /trolling, but I've concluded that they're serious -
| but written by programmers who think very differently than I
| do!)_
|
| Don't worry, I assumed the exact same about your comment. I
| still have to remind myself sometimes that people use Python
| because they think it's _easier_ to reason about.
| kbenson wrote:
| Math is easier to understand with symbols if you've been
| trained in what all the symbols and syntax means, and virtually
| impossible to understand if you haven't. This is easy to miss
| because for the most part we have one unified syntax taught in
| most the world.
|
| Words may not be the optimal format to express equations, but
| are the lowest denominator that would allow everyone to
| understand if they knew the concepts.
|
| That should illuminate why your opinion and other people's
| opinion of this differ. You likely each have different
| _relative_ opinions and skills reading syntaxes like this.
| avmich wrote:
| I think you're too categorical. We don't only use words in
| written communication - there are pictures and symbols too,
| so restricting ourselves to spoken words in largely symbolic
| activity seems a disadvantage. For both math and programming
| it makes sense to invest into training of symbols and then
| get to the matter with expanded toolset, rather than keep
| using something more similar to COBOL. Tools are important
| for the progress.
|
| It's not a random event that digits - essentially symbols for
| numbers - were invented millennia ago.
| kbenson wrote:
| I wasn't making a case that words are better than symbols,
| only that there's always a trade off between representing
| something using existing known syntax and a somewhat less
| known but more concise and exact syntax, and that tradeoff
| is largely defined by how familiar your target audience is
| with that syntax.
|
| C-like syntaxes are more popular than lisp syntax(for
| example) not because it's inherently better but because
| most people have some exposure to it at this point through
| other languages they have been exposed to. Interestingly,
| that actually does make it inherently better _in some
| aspects_ when choosing a syntax to adopt, such as
| learnability. For the person that only knows C and the
| person that only knows Lisp, which might have an easier
| time with the average rust program? What about someone that
| only knows Prolog?
|
| The issue is not about only using words, the issue is about
| using things your audience already knows. People use
| numbers in letters not just because words are less
| convenient, but because words are less convenient and they
| know the people on the other end know Arabic numerals so
| that's a valid medium to rely on.
|
| For programming languages it's less that words are better
| and more that there are either different or conflicting
| meanings for many symbols leading to confusion for those
| that deal with multiple languages or are new to the current
| language, so time needs to be taken to internalize what
| they mean in this new context. That doesn't make them bad
| or worse than words, but often they necessarily are less
| obvious in meaning to those new to the language to benefit
| those that are more familiar or experts.
| void_mint wrote:
| > Math is easier to understand with symbols if you've been
| trained in what all the symbols and syntax means, and
| virtually impossible to understand if you haven't.
|
| I haven't and it continues to be a massive source of shame.
| Maybe today's the day I do something about it.
| potiuper wrote:
| Where is the source code or release?
| robocat wrote:
| It is so frustrating seeing someone work so cleverly to create a
| new syntax but restricting themselves to ASCII; I know the
| reasons why of course.
|
| The semantic meaning of the 32 ASCII non-whitespace punctuation
| characters are so tragically overloaded between languages (with
| subtle, major, or even contradicting meanings).
|
| The difference in meanings of ASCII characters usually varies
| within a language or requires "digraphs" like _:=_ or "trigraphs"
| like _< =>_ and I laugh at our ancestors* using 6-bit* trigraphs
| (then I feel shamed that we have only progressed to 7 bit
| trigraphs).
|
| * poetic facts + punctuation.
|
| PPS: Any recommendations for a reliable swype keyboard for iPad
| that also accesses common Unicode characters such as dagger? I
| find Gboard on Android to be far superior to the Apple virtual
| keyboard.
| lpointal wrote:
| Readability note: 0
| dang wrote:
| " _Please don 't post shallow dismissals, especially of other
| people's work. A good critical comment teaches us something._"
|
| https://news.ycombinator.com/newsguidelines.html
| nextaccountic wrote:
| What's sorely lacking is a comparison of identical Rust and
| Analog pieces of code, side by side
| xtagon wrote:
| The src directory is empty. Is there no implementation, this is
| just a specification?
| chrismorgan wrote:
| I'm curious:
|
| * Why?
|
| * You've made two mostly independent major changes in the syntax:
| to depend on significant indentation, and to switch from keywords
| to symbols. Why both, rather than just indentation while keeping
| it otherwise as familiar as possible?
|
| * Why change lifetimes from ' to `? (Nothing obviously collides
| with keeping it '.)
|
| * Why change closures from || to //? (You've then reused | for
| other things, but why not the other way round?)
|
| * What does the word "analogous" mean here? (I don't believe it
| can be the normal English sense I'm used to because that requires
| something in the syntax to be compared _to_ --I'm not sure what
| the proper grammatical term is on the adjective, but it's like
| the distinction between intransitive and transitive verbs, with
| the sense I know being strictly transitive (by analogy) but you
| using it intransitively (as it were).)
|
| Finally, macros are a knell for alternative syntaxes like this:
| it's not possible to make them work interoperably, because macros
| consume Rust token trees, but can interpret the body however they
| like, and you can't reliably detect what they're trying to do, so
| you can't compensate. In your println! example, you are
| apparently saying it must translate the body from Analog to Rust,
| which would work in that instance because it's largely consuming
| Rust language syntax (though named arguments add a little fun);
| but in your json! example, it needs to _not_ perform any such
| translations, because json! doesn't consume Rust _syntax_.
| (Perhaps in that specific instance the translation would be
| harmless, but it's trivial to show macros where that's not the
| case.) Attribute macros will be OK, and you _might_ be able to
| get _most_ structural macros working, but many structural macros
| (especially those that deal with token trees) and all non-
| attribute procedural macros are going to be a dead loss. I'm
| afraid I see only three solutions for macros in such an
| alternative syntaxes: (a) give up on interoperability, and
| maintain a completely distinct macro system; (b) have macro
| bodies always be in Rust syntax, which would break your very
| first example's use of println!; or (c) on macros where there is
| any uncertainty, require what basically amounts to FFI bindings,
| which the language could provide for the standard library but
| it'd mean pain for calling macros from third-party crates, and
| could basically entail falling back to Rust syntax in complex
| cases. Hmm... that's actually interesting to think about, as the
| uncertain nature of macros _already_ causes some trouble for
| developer tooling. (rust-analyzer works well with structural
| macros, but can't cope very well with most procedural macros, and
| something along these lines could actually be genuinely useful.)
| codesections wrote:
| > Why change closures from || to //? (You've then reused | for
| other things, but why not the other way round?)
|
| Just guessing, but I bet it's to create a parallelism between
| // (closure) and \\\ (closure that moves). If closures were ||,
| there wouldn't be quite as much of a same-but-different feeling
| as you get with slash & backslash.
| NegativeLatency wrote:
| As someone who thinks they probably have dyslexia the
| difference between slash and backslash is very hard for me to
| tell, but easy to differentiate from pipe. (One is straight
| the others are slanted, who knows which slant is which)
| dhosek wrote:
| I'm not sure that's a dyslexia-specific thing. Back when
| the web started getting mainstream traction and it was
| notable to see URLs in TV commercials (ca 1994-5), I
| remember roughly half of the radio ads that mentioned URLs
| would say, "h-t-t-p-colon-backslash-backslash..."
| djur wrote:
| I think that's just because people couldn't remember
| which was "slash" and which was "backslash", and in the
| DOS/Windows world, you were more likely to hear
| references to "backslash". Browsers quickly started
| silently fixing inappropriate backslashes, so people
| never had to learn which was which.
| brundolf wrote:
| I assume by "analogous" they mean "the AST can be translated
| one-to-one without context or extra steps"
| junon wrote:
| For those reading, this appears to be vaporware. The idea is in
| the readme, but it's not been built yet.
|
| Also, OP, you cannot post your own stuff to HN without "Show HN:"
| at the beginning of your title.
| gpm wrote:
| I don't believe this is correct
|
| > Off topic: blog posts, sign-up pages, newsletters, lists, and
| other reading material. Those can't be tried out, so can't be
| Show HNs. Make a regular submission instead.
|
| https://news.ycombinator.com/newsfaq.html
|
| Judging by your first sentence it is correct for it to not be a
| show hn.
| [deleted]
| pvg wrote:
| Show HN has its own rules and you don't have to use it to show
| hn your own work.
|
| https://news.ycombinator.com/showhn.html
| [deleted]
| tyfighter wrote:
| Dangling parens? This is terrible.
| avmich wrote:
| You should try working with APL family of languages, dangling
| parens likely won't bother you after that.
| SomeCallMeTim wrote:
| The biggest downside to Python's popularity is the uber-fans'
| tendency to think it's a Good Idea to wreck other languages
| with significant whitespace. Like CoffeeScript.
|
| So far I believe every such attempt has ultimately failed. Like
| CoffeeScript.
|
| This seems to be a particularly execrable example of that
| phenomenon.
| dang wrote:
| " _Please don 't post shallow dismissals, especially of other
| people's work. A good critical comment teaches us something._"
|
| https://news.ycombinator.com/newsguidelines.html
| Zababa wrote:
| See? Rust's original syntax isn't that bad!
| aappleby wrote:
| Code is read far more often than it is written. Optimize for
| readability.
___________________________________________________________________
(page generated 2021-09-19 23:02 UTC)