For templating purposes, consider allowing `...` as the parameter list of a function

[blerner]

In looking at some of the starter code provided to students, Joe and I have noticed "code" using ... like this:

fun update-x(...):
  ...
end

This code does not currently parse, because ... can't be used as a parameter list. Consequently, the entire starter file --- even if it's got some working code up at the top! --- is unusable just by clicking Run, which is not an ideal experience.

I don't know what I'd like the semantics of this to be, exactly, but my hunch is:

1. it should be syntactically allowed,

2. it should be a well-formedness error for such a function to not have at least one ... in the body of the function --- if you've figured out the body, I'd hope you've figured out the signature.

   • I'm wondering whether we should allow the body to be

     fun update-x(...):
       ... x + foobar + baz ...
     end
     

     with unknown names in the body, and not do scope-checking on such functions, since the idea might be to allow students to sketch out expressions and ideas they might think are relevant, and not penalize them for being incomplete so far.

3. it should be a dynamic error to call such a function, obviously, but I don't think it should be an arity error to call it with different numbers of arguments, since the whole point is the signature isn't well-defined yet. Probably something along the lines of the unfinished-template error we already have.

4. I don't know whether this will interact badly with a hypothetical future extension of Pyret that allows a varargs parameter in functions (since it's giving a semantics to ... in the parameter list), but I think it won't technically be ambiguous since a varargs list still needs a name preceding those dots.

[shriram]

Catching up. I like this proposal. I agree there's an issue with varargs, but we have two truly different kinds of indeterminacy (code not yet decided vs. actual args not yet decided). I think we're going to want ... to be available for HtDP-esque things, at least for tradition. That means we'll have to come up with a different syntax for varags and that's just fine.

[blerner]

Pinging on this -- it came up again today in discussion, and I'd like to think through this a bit more.

[blerner]

I'm not a fan of having two different tokens for the two indeterminacy sources you mention above. Suppose we said (this is purely speculation) that "unknown arguments" is written as fun foo(???):. Then an unknown function with unknown body and arguments would be

fun foo(???):
  ...
end
fun bar(???):
  ... x ...
end

and I don't know whether we're setting ourselves up for lexical confusion on when to use which token. If we do go with two distinct tokens, then maybe we also want to allow ??? as contracts, which would let us write scaffolding to say "Please fill in the contract, fill in the examples, and then fill in the arguments, and then fill in the body, in the following code:"

area-of-square :: ???
examples:
  ...
end
fun area-of-square(???):
  ...
end

(And notice again how the ??? and ... keep alternating :( )

[shriram]

Why not just rule out ... as a reserved token (with the editor turning … (single Unicode token) into ... (three ASCII dots)), and only permit ??? for all the indeterminacy examples in this thread? Thus, the early example would be

fun update-x(???):
  ??? x + foobar + baz ???
end

I know it looks a bit awkward to our eyes, used to ..., but ... seems too valuable to waste, and it already has another meaning (repetition of the previous element) in both math and Racket macros.

[blerner]

My objections are all small and subjective, but:

• I'm not convinced that we should optimize for Racket macros, or varargs functions -- neither of those seem like things we intended Pyret to solve.
• To our texting-familiar students, ... connotes "I'm waiting...", while ??? connotes "utter confusion"
• Changing ... would break a bunch of existing Bootstrap and Physics teachers' understanding, so we shouldn't do it lightly
• Frankly, I think ??? looks ugly :(

[shriram]

I anticipated about half those objections, and I don't disagree with any of them (actually, I agree to varying degrees with most).

Where does that leave you in terms of a plan of action?

[blerner]

Not sure. Having fun foo(...): ... end (with both uses of ... being intentional) doesn't seem to me to cause a syntactic or semantic ambiguity. I almost want to use (half facetiously) the token etc. for varargs, as in fun lots-of-strs(strs etc.): ... end (My main distaste for it is that I'd want the parameter name to be a plural noun, but plural nouns and etc. don't quite match up.)

[sorawee]

I dislike etc.. It's even more ugly than ??? aesthetically.

Python uses *args for varargs. So is Typed Racket ((Number * . -> . Number)). The nice thing is that it resembles the Kleene star: add as many arguments as you want. If we will ever support varargs, why don't we use it?

[blerner]

The star token is tricky in Pyret, because of the whitespace-surrounding rule for operators. I'm worried about tokenizing and parsing *args successfully, and I do not know what that would look like in our type signatures -- either standalone, or inline with function definitions...

[sorawee]

There are already LT vs LANGLE. Is it possible to have MUL and STAR similarly?

Another possibility: use args*. Allow * to be a valid id character as the last character. Then, raise a WF-error for all use of id* that is malformed.

(This doesn't address the type signature issue, though I think this could be one possibility? lam(xs* :: List<String>): xs end).

[blerner]

Yeah, that's a hack :-\ I actively want to avoid other whitespace-sensitive parsing wherever we can. (I've just never been super-confident in the handling of BAD-OPER and STAR, and BAD-OPER and LT and LANGLE, and other combos of space-sensitive and space-insensitive operators...)

Regardless of whether we can code this up, what would this syntax look like for signatures? I'm not a huge fan of xs* :: List<String>, because that's a lot of meaning hiding in that single star character! What if we just had a word there? varargs xs :: List<String>, or trailing xs :: List<String>?

[shriram]

Wait, wait. Why are we arguing about the varargs syntax? We'll deal with that when we get to it. It won't be ..., clearly.

[blerner]

Well, my initial message said I didn't know the full semantics, and your initial reply only had a detailed reply on varargs ;-) We got sidetracked.

[blerner]

As part of the discussion today: both of these two should work as well. The intent is "If we give a stubbed-out design recipe, there should be no syntax errors, and the first-run response should be complaining about an unfinished template/contract/whatever."

some-fun :: ...

examples:
  ...
end