Displaying Prime Factors

[hostilefork]

Here are some more changes (for anyone keeping track of differences).

The rules for regularizing infix mean that the comparisons need adjustment:

n mod m = 0  -becomes-  0 = n mod m  -or-  (n mod m) = 0

1.0 * m * m > n  -becomes-  n < 1.0 * m * m  -or-  (1.0 * m * m) > n

I definitely prefer the uniformity, where x = ... acts the same as equal? x ...

---

UNTIL is now the arity-2 complement to WHILE. So if you want to stick with the current loop style with n = 1 as the last statement in the loop being the test, the construct is called INSIST.

(Personally I don't really like INSIST all that much because it's too easy to forget what you're doing by the time you reach the end of the loop. ATTEMPT and AGAIN are better, IMO, if you want to program in that style...and permit much more flexibility.)

---

@hostilefork

Also the locals-gathering FUNCTION is deprecated. There are simply too many dialect purposes for SET-WORD! that should not make locals. So explicit <local> definitions or LETs are needed:

prime-factors: func [n [integer!]][
    let m: 2 
    let s: 1 
    let a: copy []
    ...

Eventually, FUNC is scheduled to be a synonym for FUNCTION.

So there's a new option here which is to use a FENCE! as the body of your function:

prime-factors: func [n [integer!]] {
    m: 2 
    s: 1 
    a: copy []
    ...
}

Because the body is taken literally by FUNC, it can fold in the assignments, and won't make a new variable for n just because you use a top-level assignment like n:

That awareness is not something that nested FENCE! levels can do. So if you try and use more FENCE! in the function, they will create new variables. That includes for function locals if they have top-level assignments to that name...which may or may not be what you want.

(I'm still debating the escaping mechanism to say "don't create a new variable in this fence scope". it's very tempting to say that's $n:, and maybe with arity-1 BIND being committed to it's easy enough to say $ 'n: or bind 'n:, so that the $ sign is "underneath" the CHAIN!. I have discussed this before and came to the conclusion that the $ should be "above" but maybe there's some new thinking that could inform this differently.)

Using FENCE! is thus kind of something I see as more of an "expert feature" when you're trying to optimize code. LET is the more natural choice.