Skip to content

Latest commit

 

History

History
154 lines (107 loc) · 4.6 KB

File metadata and controls

154 lines (107 loc) · 4.6 KB

Error messages

Now that we have positions on all expressions, we need to improve the error messages, make it save all positions of the errors while unwraping and then display them like in python. From inside to outside. It would also be great to make an error catching system that can take error type considerations, but that is for later.

Series expressions

After the expressions have been redone, I think we need to work on series expressions next. Maybe also add series functions, they can take one or more series along with attribute values. That way people can use the plugin system to do more things.

New primitives for task system

Remove the data and time format from the task system, they can still be used in attributes file, but the task system will no longer support them directly. You can use date/time values, and initial them by parsing strings. This will allow the use of operators like `-` without space in the expressions. And we can add syntax for the number range `1:20` instead of using it for the dates that are not used as much. We can make the range be a expression, so that we can insert variables instead of simple numbers.

And because we are dividing the attributes into primitives and others, the other formats like array and attrmap can now also be considered as expressions, so that you can insert variables and other expressions inside it.

This does increase the nested-ness of the expressions because everything is an expression now. So we need to look for ways to simplify it.

Maybe we need an intermediate data format (Abstract Syntax Tree?) after the tokenization is done, before the expression is pased completely.

This will also remove the need to have multiple types of tasks, as all of them can be expressions. We still need to be careful about the mutex problem. And avoid all crashes and send them as errors to the user. Hopefully all this change allows us to operate on any kinds of graph network, even the ones with loops.

We will have to provide mechanisms for users to check for loops. And of course add checks to crash the program if user is stuck in an infinite loop.

New expressions

Functions, array expr, attrmap expr

We might need intermediate representation that simply groups things based on the braces. So that we only have to parse inside of each braces once we have a complete expression.

This will decrease the amount of branch searching from nom.

Basically we will have Top level expression groups based on matching parenthesis and braces that will isolate, function calls, expression groups, context, loop, if-else blocks.

new keywords

Equivalent of the variables but returns the map instead

inputsmap (im) outputsmap (om) nodesmap (nm) leavesmap (lm) rootsmap (rm)

loop related keywords:

break continue progress (prog)

The progress keyword is used now to send the progress information, this removes the need to programmatically track the progress. The user can track progress now. Maybe we can add multiple progress steps later, but the user has the flexibility to calculate and use whatever system they use.

Context Expressions

The new syntax for the context based evaluation:

Simple variables will remain the same:

“`task env.xyz node.xyz root.y “`

And so on, the syntax sugar for the function call can also remain the same

“`task nodes.get_attr(“NAME”) “`

Now we have context based expressions that are enclosed in the `{}`:

For example this is equivalent to `env.name` “`task env { name } “`

The advantage of this system comes from the nesting ability:

“`task nodes { env.some_var + network {some_other_var + env.again } + node.xyz } “`

Or this pattern that previously required temporary variable assignment:

“`task nodes { inputs.somevar + output.other_var } “`

Context based eval

Expr Context should have

{Env, Node, Nodes, Network, Local, etc}

TaskContext reference (mut/not mut?)

Local variables (local variables should be local to the context, or function) Should we only make them available for functions?

h

trait Eval: Display + Clone { fn eval(self, ctx: &Ctx); fn eval_mut(self, ctx: &mut Ctx) { self.eval(ctx) } }

WithPos<T: Eval> { inner: T, pos: (usize, usize), }

struct Expression { ty: ExprType, ctx: ExprContext, }

enum ExprType { None, Value(Attribute), Result(ExprResult), BiOp(e), UniOp(e), Import(e), IfElse(e), While(e), Loop(e), ForEach(e), Progress(e), Array(e), ArrayGen(e), Map(e), MapGen(e), SetVar(e), Var(e), Render(e), WithContext(e), Range(e), UserError(e), Function(e), Silent(e), TryCatch(e), Return(e), Break(e), Continue, Multi(e), }