prompt, label, and return

[uvtc]

I'm trying to better understand how prompt, label, and return work.

JanetDocs links: prompt, label, and return

@sogaiu (in a separate discussion) has pointed out that label is actually implemented in terms of prompt.

@bakpakin has pointed out to me on chat that label is lexically-scoped.

Maybe to start off with: why is prompt called "prompt"? I'm not understanding the meaning here. (That is, it's not, say, prompting me for input). What is the rationale for prompt?

Why is label then named "label"? I've seen labels that I can goto to (I think Perl has these). Is it meant to mean that?

In the docs for prompt it says i can return to the checkpoint (a keyword), but in the JanetDocs example that makes me think that the loop would run again. However, instead of that it breaks out. What does "return to" mean in the docs for prompt?

[sogaiu]

I think the prompt example from janetdocs is currently:

(print
  (prompt :a 
          (for i 0 1000000000000 
            (print (string "i=" i))
            (if (= i 2) 
                (return :a 10)))))

the loop would run again

Here are some alternate ways to interpret things:

• (return :a 10) could mean "return to the area designated by (prompt :a ...)". If one takes that to mean right after the closing paren of (prompt :a ...) then I think the current behavior makes sense.
• Another interpretation might be "make the return value of (prompt :a ...) whatever is indicated by (return :a ...) -- i.e. what comes after :a in (return :a ...) is what is used as the return value for (prompt :a ...). This seems pretty close to how things might be seen in C, Java, etc. -- i.e. return is used within function definitions to indicate what the return value of the whole function is.

Regarding naming, perhaps there is only one person who knows the reasoning / history, but here's some speculation.

This document offers some support for a connection between label and goto:

Labels are used to branch to using goto statements in C and wide variety of other languages. In Java labels are used to exit (break) a named loop, or skip (continue) iterations of a named loop. In BASIC and FORTRAN labels are used to indicate the boundaries of a block of code to be executed. The term labels is mostly universal across languages, except in COBOL, their labels are called paragraph names.

Regarding prompt, I think this may be related to delimited continuations. Here's something from StackOverlfow about it:

With delimited continuations, you can capture only a certain portion of the continuation. The parts of the evaluation that are actually captured are delimited by prompts, which act like markers along the current continuation that specify how much of the continuation to capture.

[uvtc]

Thanks, @sogaiu .

Is the idea that you can have multiple return expressions inside a given prompt (or label)?

Can anyone provide an example where:

• you should use prompt rather than label, and
• you should use label rather than prompt?

[sogaiu]

I have used multiple return expressions before, see for example: https://github.com/kanaka/mal/blob/dba7cd34bdf80c89dfb27c62f38d47221023669a/impls/janet/stepA_mal.janet#L107-L115

As I understand it, that is one use. Breaking out of nested loops seems like another. Perhaps there are other uses too.

Regarding use of prompt vs label, I've wondered the same thing :)

May be the following from the official test suite will shed some light on the matter:

janet/test/suite0008.janet

Lines 86 to 100 in d7ea122

	(defn- inner-loop
	[i]
	(if (= i 5)
	(return :a 10)))
	(assert (= 10 (prompt :a (for i 0 10 (inner-loop i)))) "prompt 2")
	(defn- inner-loop2
	[i]
	(try
	(if (= i 5)
	(error 10))
	([err] (return :a err))))
	(assert (= 10 (prompt :a (for i 0 10 (inner-loop2 i)))) "prompt 3")

As I understand it, that kind of thing (i.e. the return form is not in the same function definition as the corresponding prompt form) wouldn't be doable with label, but I may be off on that.

Currently, the docstring for label says:

Set a label point that is lexically scoped. Name should be a symbol that will be bound to the label.

Perhaps the bit about lexically scoped is related to the above examples (as in, those are examples where lexical scoping is not going on for the "label" -- apart from the use of keywords vs symbols).

---

The following label example from the same test file might also be worth examining:

janet/test/suite0008.janet

Lines 77 to 82 in d7ea122

	(defn recur
	[lab x y]
	(when (= x y) (return lab :done))
	(def res (label newlab (recur (or lab newlab) (+ x 1) y)))
	(if lab :oops res))
	(assert (= :done (recur nil 0 10)) "label 2")

Note where the label is located in relation to return along with the uses of lab and newlab.

[uvtc]

@sogaiu , thank you for all the info!

I see what you mean about how, for prompt, the return can be in a function that it calls (so, not in lexical scope).

Ah, yes, the test suite is a good place to mine for examples.

Hm. In that example from suite0008.janet:77, the return is used before the label expression.

Thanks for the links (above as well). Regarding the description of prompt up there, to me, it sounds like the "prompt" is the effective bottom of the call stack (in the context of this "captured continuation"), and the prompt tag is a label for it.

I think I probably need to learn and practice more with Janet macros, and also fibers, and then the source for prompt will be more understandable to me.

Still though, I'd like to get a sense for when it makes sense to use prompt and label. I get the feeling that, for now, when faced with a situation where I want to return early (or have multiple breaks from a loop), maybe a good strategy is to look for some other, functional, way to accomplish the same thing. Does that sound about right?

[sogaiu]

Regarding:

I get the feeling that, for now, when faced with a situation where I want to return early (or have multiple breaks from a loop), maybe a good strategy is to look for some other, functional, way to accomplish the same thing. Does that sound about right?

That reminds me of the following bit from the website docs "Special Forms" page about break:

The break special form is most useful as a low level construct for macros. You should try to avoid using it in handwritten code, although it can be very useful for handling early exit conditions without requiring deeply indented code (try the cond macro first, though).

Specifically, the last sentence sounds similar.

As an aside, when I have time, I tend to favor code I find comprehensible (a criteria that can yield different results depending on who applies it, IME). As an example, one of the things I like about Janet is that one can use def instead of let in some circumstances. To me the extra indentation from let can hinder my understanding in some cases (e.g. work against trying to keep things under 80 columns), but as I understand it other folks feel quite differently about this. Anyway, if you do end up with more than one way to achieve the same end may be you can compare them to see what you think might be more maintainable / comprehensible.

[taoeffect]

This is one aspect of Janet that is really frustrating me right now.

I want a simple way to break out of an each loop with a value, but there doesn't seem to be one.

It would make sense to use (break x), but that doesn't work.

Then this prompt/label stuff is to be used with return, and is also quite mysterious. Why does prompt/label take only a single label? How do you use it with multiple labels?

And again, how do you break out of a loop with a value?

There really are no good docs on this, and it seems like it should be under the control flow section.

[sogaiu]

Here are some examples of using prompt and return with loops:

(prompt :fun
  (for i 0 2
    (when (pos? i)
      (return :fun i))))
# =>
1

(prompt :here
  (for i 0 2
    (for j 0 2
      (when (and (pos? i) (pos? j))
        (return :here [i j])))))
# =>
[1 1]

One way to capture a value might be:

(def value
  (prompt :fun
    (for i 0 2
      (when (pos? i)
        (return :fun i)))))
# =>
1

value
# =>
1

I think using set with var might be another approach.

---

There really are no good docs on this, and it seems like it should be under the control flow section.

Yes, it might be that the website docs don't explain how this might be done.

As mentioned earlier in this discussion though:

That reminds me of the following bit from the website docs "Special Forms" page about break:

The break special form is most useful as a low level construct for macros. You should try to avoid using it in handwritten code, although it can be very useful for handling early exit conditions without requiring deeply indented code (try the cond macro first, though).

So it might be that, at least at one point, there was general encouragement to try to find other ways to accomplish one's goals. That's not to say that the website docs might not benefit from some appropriate modifications, just speculating on the current state of things.

FWIW, I worked a bit on getting break to support returning a value a bit back with bakpakin but the work is not finished. It looked promising but there was at least one known case that wasn't being handled and I've not been able to get back to it. Not sure if / when it will be supported, but just mentioning that I can relate to wanting the functionality.

---

BTW, the discussions here at GH are much less active recently and a number of us hang out at a Zulip instance for Janet mentioned below here. If that kind of thing works for you, may be you'd be interested in taking a look?

[taoeffect]

Thanks, I joined the Zulip!