A "while" that returns the value of the last statement

[pedromj]

Many structures return the last value, which allows keeping a quite functional style code---in the style of lambda calculus reductions, of course. However, the while and for loops do not do this. Is there a design justification or just follows what Python does?

I am thinking in something like:

(require hyrule *)

(eval-when-compile
  (defmacro! retwhile [condition #* body]
    `(do
       (while ~condition
         ~@(lfor item (get body (slice 0 -1)) item)
         (setv ~g!result ~(get body -1)))
       ~g!result)))

(setv x 2)
(print (retwhile (< x 5) (setx x (+ x 1))))

Please, let me know your comments. Thank you very much.

[Kodiologist]

It was never clear to me what while should return (the last form of its body, or its else, or its condition?), nor when this would be useful. while seems like an imperative construct by nature.

As for for, its entire purpose is to be an imperative comprehension form. If you want to return values, that's what lfor and gfor are for.

By the way, (require hyrule *) is risky: if you upgrade Hyrule and new macros are added, they can shadow any non-macro objects of the same name that you define in your program.

[pedromj]

From my point of view, the nature of an expression (f a b c) is to be synthesized as a unique form. It is straightforward to see that (lfor x l x) should produce a list. My opinion is that (while c b) should produce (b), as if (b) is (do x y z) it produces (z).

Thank you for the warning about hyrule, I only use it in this way for testing small code. In production code I recommend to import/require everything expressely.

BTW, I do not like the separation of (import) and (require). What is the benefit? Why not do both with import?

[Kodiologist]

I'm not sure I understand your question. Suppose import and require were combined into one macro, as you seem to want; call it impreq. What exactly would (impreq foo [bar]) do, then? (Recall that a single module can have both a Python-level object of a given name and a macro of that name.) Would it be evaluated at compile-time, run-time, or both?

[pedromj]

+If there is a clash, something like (impreq foo [:macro bar]) or (impreq foo [:object bar]) would suffice. If there is no clash, there is no problem. The evaluation moment would be the same as it is now. Let's say that (impreq foo [:object bar]) is translated to (import foo [bar]) and (imprec foo [:macro bar]) is translated to (require foo [bar]). If there is no clash, the :objectand :macro can be guessed depending on what bar is.

[Kodiologist]

So if foo already had a function named bar and then added a macro named bar (perhaps also deleting the function), then all (impreq foo [bar]) forms would change to executing at compile-time and shadowing the function that the user meant to import. I think you could implement this behavior as a macro if you want it, but it sounds like a recipe for insanity to me. I've already seen users struggle a lot with issues like files that require macros that were changed. So that's why Hy's core macros are explicit about whether you're getting a Python-level object, a macro, or a reader macro.