-
-
Notifications
You must be signed in to change notification settings - Fork 237
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feature: support referring to variables from outer tasks #351
Comments
another use case: suppose I want a list of 5 reporter tasks: the first one reports 0, the second reports 1, and so on. an attempt is |
The Berkeley Logo syntax is |
Sometimes the lack of named task inputs doesn't mean something is inexpressible, merely awkward/verbose. Take e.g. Travis's code at http://groups.yahoo.com/group/netlogo-users/message/16997 :
Since the outer loop is a |
it should probably be forbidden for task input names to shadow other identifiers, since we forbid shadowing everywhere else in the language |
Internally, our looping constructs currently mutate a single binding rather than establish a fresh binding for each iteration of the loop. Currently that fact is invisible to users since you can't close over a task input. But once we have named inputs, you should be able to close over them, so we'll need to make sure you're always closing over a fresh binding. Some languages make the opposite choice (exposing the mutable binding to be closed over), but these languages are to be derided and shunned for it, and we should not join their ranks. |
Fixed in hexy with the addition of |
@mrerrormessage did this happen? |
@SethTisue , that didn't happen. Just to confirm, we're talking about the behavior displayed in the following language test:
This test currently reports the second case (5). I'll see what I can do to fix this. Just as a note, while I was trying to construct this I found it was even more awkward than I expected in NetLogo since you can't introduce a But the example above actually is possible in NetLogo 5 using tasks, so this sounds like an actual semantic change, albeit a very minor one. Can you clarify whether that's what you mean? As another option:
This test passes. I should also note that it isn't symmetric with the first test as it isn't possible to set a lambda variable, which in itself may remove the possibility for this to become an issue. |
yes and reporter tasks too, so e.g.
ha. well, that's a bug in NetLogo 5. not a known bug afaicr. good catch! |
yes, this is covered already here on this ticket, see above about |
?
,?1
,?2
etc always refer to the innermost enclosing task, so you can't access the inputs of an outer task.In a command task, you can work around it use
let
in the outer task to give the task input a name. But it's awkward. And in the reporter case there's no reporter equivalent oflet
, so with reporter tasks, you get stuck.This is the biggest missing feature in tasks. (@joshcough and I were well aware of it all along. We just didn't have time to do anything about it for 5.0.)
consider e.g. this program:
currently it's impossible to write this in one procedure. if you try:
it doesn't work because the
?2
in the body of then-values
refers to the nonexistent second input to the n-values task, rather than the intended meaning where?2
refers to the second input to the enclosingmap
task. (and trying to dolet ditto task ...
first doesn't help.)attempting to write the Y combinator in NetLogo runs afoul of the same issue.
also, Uri received this feature request:
> Make tasks more general so that tasks can take tasks as input and
> produce tasks as output. This would involved control over the task
> variables.
and he confirms that it refers to this issue.
so, we have a hole in the language.
there are several possible ways we could address it. in increasing order of how difficult they would be to implement:
the easiest way would be to add
letreport
to the language:here the use of
let
is just for clarity; cramming it all into one command would work too@ToonTalk has said: "To use let inside a reporter is something I often want. If possible would be nice if it was also called 'let' rather than 'letreport' but maybe that's not feasible."
the next easiest way would be to add some kind of syntax for giving names to task inputs, instead of just numbers. something like
let ditto task [n x => n-values n [x]]
the hardest way would be to support commands inside the bodies of reporter tasks, something like:
The text was updated successfully, but these errors were encountered: