Filter, Map, SortedBy #37
Conversation
| consume(T_IDENTIFIER)?.also { args.add(N_IDENTIFIER(it.string)) } | ||
| consume(T_COMMA) | ||
| } | ||
| while (nextAre(T_IDENTIFIER, T_ARROW)) { |
There was a problem hiding this comment.
Bugfix for parsing lambdas -- the argless form { ... } could not be parsed if it started with an identifier, for instance { x > 10 } -- the parser saw this as an incomplete arg declaration.
| data object Finished: Result | ||
| @JvmInline value class Suspend(val seconds: Int): Result | ||
| data class Finished(val v: Value?): Result | ||
| data class Suspend(val seconds: Int): Result |
There was a problem hiding this comment.
There was very little actual optimization value in making these jvminline value classes to begin with, so I'm not doing it here anymore.
| is VInt -> v.sortedBy { (it as VInt).v } | ||
| is VFloat -> v.sortedBy { (it as VFloat).v } | ||
| is VInt -> v.sortedBy { (it as? VInt)?.v ?: 0 } | ||
| is VFloat -> v.sortedBy { (it as? VFloat)?.v ?: 0f } |
There was a problem hiding this comment.
Unrelated bugfix for sorting mixed lists -- if you sort a list of mixed value types we do our best and assume you want them sorted by the value semantics of the first element.
| } | ||
|
|
||
| // Add a VM to the stack to run an exe. | ||
| fun push( | ||
| // Execute an exe immediately for a return value. The task cannot suspend. |
There was a problem hiding this comment.
Originally i was making a whole new Task to execute lambdas from the builtins, but I realized I could trick the existing Task into stopping at the depth of the new lambda exe and returning me the value.
Now that we have lambdas, adding built-in List.map/filter ops seemed like a no-brainer -- and it mostly was, but for one small problem.
To run these ops, we need to execute the given lambda for each element, and get a value back. This means a bare expression (parsed as EXPRSTATEMENT) should return its value (otherwise we'd have to explicitly 'return x'). But since these EXPRSTATEMENTs execute O_DISCARD to avoid cluttering the stack with their presumably-extraneous values, the value isn't there to be returned.
The fix I went with: whenever we O_DISCARD, we overwrite VM.exprValue with the discarded value -- the idea being that the last bare expression in a verb is considered the expression-value of that verb's execution. On an implied return (i.e. hitting end-of-code) we simply return this value. This lets us maintain stack cleanliness but still obtain a value from evaluating a verb, when we need to.
Actually running the lambdas is done in Task.executeLambda(), which simply pushes the lambda onto the stack and asks the Task to execute until that lambda pops off with a return value.