I've had a realization that maybe point #2 isn't entirely a
showstopper. The reasoning being that the argument/first-class value
impedance mismatch in NetLogo is actually already a limitation of tasks
(e.g. `(run (task [crt ?1 ?2]) 1 [ pen-down ])` does not compile), so
adding an `apply` that works with the existing first-class values—while
not consistent with the language as a whole—/would be/ consistent with
the current power of tasks.
On 08/11/2015 12:28 AM, Jason Bertsche wrote:
Is there any sympathy for this?
There is; I agree that this is a desirable thing to have in the
language. However, I fear that the addition would be far from
trivial, unfortunately. Here some big issues that I see with
implementing this primitive:
*1) Primitives are not first-class values in NetLogo*
I don't know what the opposition is to the proposal in the ticket that
Seth linked, but if it involves not wanting to use tasks, this first
item should demonstrate why this problem essentially /has to//be/
solved with tasks.
First, we should decide what our hypothetical syntax for this
primitive should be. Maybe something like this:
`apply first ["apples"] ; should give us "a"`
This would be problematic in the current version of NetLogo, because
this would be interpreted as `apply (first ["apples"])` which is
presumably an error, or maybe results in `"apples"`—either way,
something undesirable. NetLogo's parsing rules mean that we would need
new syntax for converting a primitive into a first-class primitive of
some sort. Maybe something like this:
`apply (first) ["apples"]`
This syntax has the benefit of seeming consistent in a way with stuff
like `first (word "apples" "oranges") "bananas"`, where the
parentheses tell the primitive (`word`) to stop gobbling up terms and
treating them as arguments. However, this would create parsing
problems in the case of something like `apply (no-turtles) []`, since
`(no-turtles)` is already a perfectly valid NetLogo expression.
We could try this:
`apply [first] ["apples"]`
Might NetLogo get confused, trying to treat `[first]` as a list
literal? Maybe. Should the argument be forced to be a command
block/reporter block instead? If so, then we probably need an `apply`
*and* an `apply-report`, for command blocks and reporter blocks,
respectively. But that's still a problem, because command
blocks/reporter blocks can't take arguments, so they seem like the
wrong fit for this problem. Should we change them to take arguments?
Or do we add yet another meaning for the square brackets, specifically
for `apply`?
Maybe we could invent some totally new syntax for this (and somehow
not break old models, by using characters for this syntax that already
aren't acceptable characters to have in a NetLogo identifier—few as
they are), but, even if a good syntax were devised that wouldn't break
old models, the NetLogo code currently doesn't really have an internal
notion for a first-class primitive. Adding such a notion to NetLogo
would take a pretty large amount of work, and it's probably a bad
change to make, overall, given how many "first-class code" types
already exist internal to NetLogo. Instead, I think it makes a lot
more sense for `apply` to work solely on tasks. This brings us to the
other big problem I see.
*2) Not all primitive arguments are actually first class values
*
That might seem like a paradoxical statement, but I can assure you
that there's truth in what I've said!
A demonstration:
`apply (task [crt]) [1]`
So far, so good. `1` is totally a first-class value.
Ah, but `crt` can take a second argument. Let's try that out:
`apply (task [crt]) [1 [ pen-down ]]`
Okay, now we're in trouble. `crt`'s second argument is a command
block. Command blocks aren't first-class; they can only be passed to
certain primitives, and they can't be stored in `let`s or put into
lists. The same goes for reporter blocks and "reference types" (like
what `uphill`/`downhill` take as arguments), as well as "boolean
blocks" (like the second argument to `all?`), and "number blocks"
(like the second argument to `max-one-of`).
This situation is looking very daunting to me. One solution would be
to make those things first-class values, but it sounds terrifying to
me to change so many of these old, edge-casey, crufty types all into
first-class values, and there has definitely been a push in recent
years to /move away from/ that scary conglomeration of different block
types, rather than do anything to embrace it.
The correct solution to this, I think, is probably to tear all of the
"reference type" and "<x> block" stuff out of NetLogo altogether, and
replace all instances of those with tasks. Tragically, though, this
leaves us with a proposal that appears to make sense—though other
holes could probably be poked in it—but that would require quite a bit
of time to implement.
So... I'd be interested to see `apply` make it into the language at
some point, but my main concern here is the resource cost.
Furthermore, would all the effort that would go into implementing this
really be worth it for how much the userbase benefited from it?—I
think that's another good question to have answered before tackling
the addition of `apply`.
On 08/10/2015 09:42 PM, Alan Isaac wrote:
On Monday, August 10, 2015 at 6:59:01 PM UTC-4, Seth Tisue wrote:
see also https://github.com/NetLogo/NetLogo/issues/539
<https://github.com/NetLogo/NetLogo/issues/539>
I don't like the `apply` proposal as well as the `sequence` proposal,
but it points to the same issue, even if it offers a less general
solution.
The existence of the issue is the reason for proposing a new primitive.
Is there any sympathy for this?
Alan Isaac
--
You received this message because you are subscribed to the Google
Groups "netlogo-devel" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "netlogo-devel" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"netlogo-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
