hddqsb

A clarification: Tail call optimisation in Emacs is not tied specifically to `named-let`, but it is tied to `cl-labels` (which `named-let` uses internally). Normal functions declared using `defun` don't currently support tail call optimisation.

(The tail call optimisation was only added to `cl-labels` recently, in Emacs 28.1: https://github.com/emacs-mirror/emacs/commit/29c7f8c915c3889...)

------------

The author confuses "apply" and "reduce" (aka "fold").

- `apply` calls a function once, passing it all the specified args. It is very similar to `funcall`, except the last argument of `apply` is a list of args.

- `reduce` repeatedly calls a function on an accumulator and each element of a list.

Examples:

    (vector 1 2 3 4)
    => [1 2 3 4]

    (funcall 'vector 1 2 3 4)
    => [1 2 3 4]

    (apply 'vector 1 2 (list 3 4))
    => [1 2 3 4]

    (seq-reduce 'vector (list 1 2 3 4) 0)
    => [[[[0 1] 2] 3] 4]

------------

Also, the way the author's implementation guesses the initial value is awful. The standard practice is to either ask the caller to explicitly provide the initial value (which is what `seq-reduce` does), or to use the first element of the list as the initial value.

(The latter has the advantage of being simpler to use, since the programmer doesn't need to find the correct identity element that needs to be passed as the initial value (e.g. for + the identity is 0, but for * the identity is 1). The disadvantage is that it fails on empty lists. Also, in statically-typed languages it can only supports binary operators, so it is not as powerful as the version that takes an explicit initial value.)

Please don't rewrite it on my account (I'd just mention laziness and fix the `if` bug since it's trivial: https://github.com/utdemir/nixlisp/blob/4e0eec383363df72b7b4..., the comment already says the right thing). It would be interesting to see the "bork" examples if you still have them on hand (I'd even put them in the README).

It was fun to play with, thanks for making and publishing!

(The only situation where `define` might be considered "impure" is if it was used to redefine a variable that already existed in the same scope; and even then, it could still be considered "pure" as long as it created a new variable instead of mutating the original variable.)

1. You should make it clear in the README that this uses lazy evaluation, because most Lisps use strict evaluation.

2. `lambda` should have an implicit `begin` around its body to allow multiple forms, e.g.

    (lambda ()
      (define x 1)
      (+ x x))

3. The behaviour of the top-level forms changes when they are wrapped in `begin`. For example, the program

    (car 1)
    2

4. Since this dialect is pure (no side effects), it should be a syntax error if a non-final form in a `begin` expression expands to some expression which is not a declaration. For example,

    (defun f (x)
      (g x)
      (h x))

In the same vein, you could make it a syntax error if the final form in a `begin` expression is `define` (and likewise for the forms in an `if`).

5. The way `if` handles values other than true/false is backwards compared to most Lisps (and based on the comments in the code I think it's an accident). For example

    (if "foo" "first" "second")

To me, "code quality" means something very different (well-written, readable, maintainable, etc.; Wikipedia calls this "software structural quality"). According to this definition, "code quality" may be correlated with the number of bugs (hopefully with a negative correlation!) but the two are very different things.

And I'd like to boost @kragen's comment (https://news.ycombinator.com/item?id=33566329#33579042, toned down):

> haldar's summary is ... incorrect ...

> the paper finds that faults (and wmc (methods per class), cbo (coupling between object classes), response for a class (rfc), number of methods added (nma), etc.), correlate to class size (non-comment source lines of code), not program size

> Thus you can use up all available memory in approx. 64 quick steps by: ...

I disagree. If the editor uses a very basic implementation, then "Undo to beginning" would probably require the user to perform multiple undo steps, in which case the memory usage would be linear in the number of steps rather than exponential. If the editor supports "Undo to beginning" as a single operation, then it would be reasonable to expect a more sophisticated implementation that does it efficiently -- memory usage can be reduced by sharing the repeated sections of the undo/redo stacks, and it is possible to efficiently skip over undo-redo sequences by recording which states are identical. Exponential memory usage would be indicative of a lazy programmer rather than a fundamental issue with the GRUQ-orithm :)

To illustrate how horrible this is, I'll continue the example: When you paste that something, you get state4. Suppose you then wanted to copy something from state1. Without the "window shopping" optimisation, you would have to go state4,state3,state2,state3,state2,state1, copy, state2,state3,state2,state3,state4, paste.

If you then wanted to copy something from state0, it would take 34 steps!

The ad's ID is DChcSEwiPvfuL-YX7AhVmkmYCHUXQC1wYABAAGgJzbQ (displayed when reporting it), the display URL is https://www.gimp.org/ and the final location after clicking the ad is https[:]//gilimp[.]org/ (with no intermediate redirects via gimp.org).

Update: The DNS records for gilimp.org have been deleted. Archived snapshot: https://web.archive.org/web/20221029152445/https://gilimp.or....

-------------

Original comment:

The Reddit user says the ad's display URL was different from landing page URL. If that's the case it is particularly concerning. I believe Google Ads only allows the advertiser to set the path component of the display URL, and takes the domain from the landing page (real) URL; so it's unclear how the mismatch could happen.

Maybe the Reddit user took the screenshot on a separate occasion from when they clicked the malicious link, and the ad changed in that time (currently I can see an ad for GIMP, and it links to the official domain, and the linked Twitter thread linked by @pmoriarty says the attacker is actively changing things). The only other explanation I can think of is that the official GIMP website has an open redirect vulnerability.

`-h` and `--help` are fine. But `help` and `h` should only display the help if the script has subcommands (like `git`, which has `git commit` as a subcommand). Scripts that don't have subcommands should treat `h` and `help` as regular arguments -- imagine if `cp h h.bak` displayed a help message instead of copying the file named "h"!

I wouldn't encourage `-help` for displaying the help because it conflicts with the syntax for a group of single-letter options (though if `-h` displays the help, there is no legitimate reason for grouping `-h` with other options).

And ideally scripts that support both option and non-option arguments should allow `--` to separate them (e.g. `rm -- --help` removes the file called "--help"). But parsing options is complicated and probably out of scope for this article.

> If appropriate, change to the script’s directory close to the start of the script. And it’s usually always appropriate.

This is very problematic if the script accepts paths as arguments, because the user would (rightly) expect paths to be interpreted relative to the original working directory rather than the script's location. A more robust approach is to compute the script's location and store it in a variable, then explicitly prepend this variable when you want paths to be relative to the script's location.

(Note that the colours will change because of the way the code is written. Also, it will require more computation, so it's probably a good idea to only increase maxIterations when zoomed in.)

    for i in 1 2 3 4 5; { echo $i; }
    for ((i=1;i<=5;i++)) { echo $i; }

Aside: [[ -v x ]] tests if the variable x is set. It should probably be [[ x -ne 0 ]] to match the example from the parent.

Works for me...

    $ echo $0 # determine current shell (alternative: "ps -p $$")
    bash
    $ echo {01..100..20}
    001 021 041 061 081

    $ n=5
    $ echo {1..$n}
    {1..5}
    # intended output: 1 2 3 4 5

For completeness, here is a POSIX sh approach that doesn't require `seq` (in fact I notice this is what your "Uber Fancy" version uses internally):

    i=1
    while [ "$i" -le 5 ]; do
        echo "$i"
        i="$((i+1))"
    done

To quote a really important comment posted by Eduardo Vasquez on the article:

> [...] all those formulas of derivatives and primitives of trig functions in standard calculus books assume that arguments are expressed in radians. Say, the derivative of sin(x) w.r.t. x is cos(x) --- that is only true if x is in radians. Otherwise, you would get an extra factor, due to the chain rule. [...]

(There are a few comments here that point this out, but they are nested pretty deep so I thought it was worth repeating.)

[1]: https://github.com/python/cpython/blob/a4ac14faa5c2be433738d...

I'm only half joking :)

To elaborate: The variable names "ACC" and "RES" suggest the predicate should be viewed as a left fold, because when the predicate is viewed as a right fold the meanings of the variables are flipped.

An NFA / DFA would be a perfectly valid way to implement an efficient matcher, but it's not the only way.

For example, memoization (https://news.ycombinator.com/item?id=32434412#32436442) can be easily shown to have time complexity O(P * T) where P = len(pattern) and T = len(text), which is the same as a basic NFA implementation.

In the case of the Redis code, my proposed fix requires much less code and memory than memoization or an NFA, and has time complexity O(P * T). It's slightly harder to prove this bound; here is a sketch of the proof:

Matching against a pattern fragment that does not contain "*" takes O(len(pattern_fragment)).

When a call to stringmatchlen() encounters a wildcard, it may recurse O(T) times (and then it returns). Each recursive call can be classified either "leaf" (if there is a match failure before the next wildcard) or "full" (if the match reaches the next wildcard).

The insight I described leads to at most one "full" call at each level of the recursion (i.e. for each wildcard in the pattern). So for a particular pattern fragment, the number of "leaf" calls that process it is O(T). Hence the overall time complexity is O(P * T).

@grumple pointed out that throwaway accounts that can't be easily linked to the poster are essential to some reddit communities, which may play a part in why this feature is still available.