> If you ever want to confuse your coworkers, then one great way to abuse this syntax is by replacing the heredoc marker with an empty string
Maybe I am in favor of the death penalty after all
Weird Lexical Syntax
151–160 of 234 posts
Re: Weird Lexical Syntax
#152I don't think it's easy to write a good syntax coloring engine like the one in Vim. Syntax coloring has to handle context: different rules for material nested in certain ways. Vim's syntax higlighter lets you declare two kinds of items: matches and regions. Matches are simpler lexical rules, whereas regions have separate expressions for matching the start and end and middle. There are ways to exclude leading and trai…
> I don't think even Justine could develop that in an interview
Not so sure I’d put money on that opinion ;)
Re: Weird Lexical Syntax
#153Earlier quoted context omitted.
Indeed in some of the listed languages you can nest it like that, but in others (e.g. Python) you can't. I would guess they deliberately don't want to enable that and it's not a problem in their parser or something.
Even when nesting is disallowed, my point is that I find it preferable to not view it (and syntax-highlight it) as a “special string” with embedded magic, but as multiple string literals with just different delimiters that allow omitting the explicit concatenation operator, and normal expressions interspersed in between. I think it’s important to realize that it is really just very simple syntactic sugar for normal s…
While you're conceptually right, in practice I think it bears mentioning that in C# the two syntaxes compile differently. This is because C#’s target platform, the .NET Framework, has always had a function called `string.Format` that lets you write this:
var str = string.Format("{0} is {1} years old.", name, age);
Re: Weird Lexical Syntax
#154Earlier quoted context omitted.
Perl and Python stole it from Emacs Lisp, though Perl took it further. I'm not sure where Java stole it from, but nowadays Doxygen is pretty common for C code. Unfortunately this results in people thinking that Javadoc and Doxygen are substitutes for actual documentation like the Emacs Lisp Reference Manual, which cannot be generated from docstrings, because the organization of the source code is hopelessly inadequat…
> Emacs Lisp Reference Manual, which cannot be generated from docstrings, because the organization of the source code is hopelessly inadequate for a reference manual. Well, they're not doing themselves any favors by just willy nilly mixing C with "user-facing" defuns https://emba.gnu.org/emacs/emacs/-/blob/ed1d691184df4b50da6b... >. I was curious if they could benefit from "literate programming" since OrgMode is the…
I didn't mean that specifically the Emacs source code was not organized in the right way for a reference manual. I meant that C and Java source code in general isn't. And C++, which is actually where people use Doxygen more.
The Python standard library manual is also exemplary, and also necessarily organized differently from the source code.
Re: Weird Lexical Syntax
#155The final line number count is missing Julia. Based on the file in the repo, it would be at the bottom of the first column: between ld and R. Among the niceties listed here, the one I'd wish for Julia to have would be C#'s "However many quotes you put on the lefthand side, that's what'll be used to terminate the string at the other end". Documentation that talks about quoting would be so much easier to read (in sourc…
One nicety that Julia does have that I didn't know about (or had forgotten) is nested multi-line comments.
#= this one
has a #= nested
comment =# inside of it
and that works fine! =#Re: Weird Lexical Syntax
#156The author may have missed that lexing C is actually context-sensitive, i.e. you need a symbol table: https://en.wikipedia.org/wiki/Lexer_hack Of course, for syntax highlighting this is only relevant if you want to highlight the multiplication operator differently from the dereferencing operator, or declarations differently from expressions. More generally, however, I find it useful to highlight (say) types different…
I don't think the lexer hack is relevant in this instance. The lexer hack just refers to the ambiguity of `A * B` and whether that should be parsed as a variable declaration or an expression. If you're building a syntax tree, then this matters, but AFAICT all the author needs is a sequence of tokens and not a syntax tree. Maybe "parser hack" would be a better name for it.
Re: Weird Lexical Syntax
#157Earlier quoted context omitted.
You also don't need quotes around strings (barewords). So my $bar = x; should give the same result. Good luck with lexing that properly. https://perlmaven.com/barewords-in-perl
If you're writing anything approaching decent perl that won't be accepted.
"use strict" will prevent it and I think strict will be assumed/default soon.
Re: Weird Lexical Syntax
#158Some random things that the author seem to have missed: > but TypeScript, Swift, Kotlin, and Scala take string interpolation to the furthest extreme of encouraging actual code being embedded inside strings Many more languages support that: C# $"{x} plus {y} equals {x + y}" Python f"{x} plus {y} equals {x + y}" JavaScript `${x} plus ${y} equals ${x + y}` Ruby "#{x} plus #{y} equals #{x + y}" Shell "$x plus $y equals $…
Make :) echo "$(x) plus $(y) equals $(shell echo "$x+$y" | bc)"
Re: Weird Lexical Syntax
#159Re: Weird Lexical Syntax
#160Earlier quoted context omitted.
Could you review my comment on HN? Please educate me if there is something I haven’t understood, rather than downvoting my question.
The grandparent post is specifically about trigraphs. Saying something about trigraphs was the end-in-itself, trigraphs were chosen to illustrate something about trigraphs. So your question made no sense. Hope that helps.
Maybe the confusion was the other way, more like "why is that funny/interesting?"
An attempt to answer that: In English, mixing ?! at the end of a question is a way of indicating bewilderment. Like "What was that?!"