Using this form can help getting rid of @args and allow mixing dependencies
But this needs to disambiguate the case when goal is named @name
But not that simple… what about literal values?
"${VAR}" but only this form, not "aaa${VAR} bbb"
VAR, literal values must be quoted (with single quotes or dollar-single quotes to disallow substitutions)
Q. Do we even need keyword @args?
Looks like we don’t need it to disambiguate. BUT this complicates resolution.
Q. Do we need keyword @params?
Looks like yes
for consistency
for ease of parsing
Q. Do we allow to include parameterized goal in @depends_on together with other goals? Or only single?
No. @args will be only allowed in pos=3. All items afterwards are considered args.
Q. Shall we restrict the param name to Name123? [A-Z][A-Za-z0-9_]*
This might be good idea / convention.
Q. Can we make parameterized goals resolution during parsing? We might need to know the number of params for a goal which is not available yet, since goal may come later.
Looks like this is only possible if we restrict the syntax to
@depends_on param_goal @args 'hello'
I.e. when @args is at pos=3
@depends_on param_goal ( 'hello' A 'world' ) # needs more parsing
Q. Allow calling parameterized goal from CLI?
No
Q. Allow listing PG?
No.
What about “instantiated” goals?
Q. Loops detection.
Based on goal name only? I.e. disallow depending PG on itself in any way.
Q. What can be @args VAR?
Only:
what’s in @define
any VAR in @params of this goal
All other cases must cause error.
Q. Mechanism for "instantiation"
Also here. Need to adjust -d option. Should list instantiated goals in form
pg1 @args 'hello'
pg2 @args 'hello' $'with \''
nonpg
Build tree no-params : detect loops
Build tree non-instantiated
Instantiate. How?
On encounter @depends_on generate instantiated? But this needs to go in-depth.
Parameterized goals
The idea for this is inspired by #112. This should be much better and more generic alternative to #96.
This should allow such rewrite.
Related to this. Obviously this is being revised.
Q. Default values.
No
Q. Optional values.
No
Q. How to pass var argument?
@VAR
@args
and allow mixing dependencies@name
"${VAR}"
but only this form, not"aaa${VAR} bbb"
VAR
, literal values must be quoted (with single quotes or dollar-single quotes to disallow substitutions)Q. Do we even need keyword
@args
?Looks like we don’t need it to disambiguate. BUT this complicates resolution.
Q. Do we need keyword
@params
?Looks like yes
Q. Do we allow to include parameterized goal in
@depends_on
together with other goals? Or only single?No.
@args
will be only allowed in pos=3. All items afterwards are considered args.Q. Shall we restrict the param name to Name123?
[A-Z][A-Za-z0-9_]*
This might be good idea / convention.
Q. Can we make parameterized goals resolution during parsing? We might need to know the number of params for a goal which is not available yet, since goal may come later.
Looks like this is only possible if we restrict the syntax to
I.e. when
@args
is at pos=3Q. Allow calling parameterized goal from CLI?
No
Q. Allow listing PG?
No. What about “instantiated” goals?
Q. Loops detection.
Based on goal name only? I.e. disallow depending PG on itself in any way.
Q. What can be
@args VAR
?Only:
@define
@params
of this goal All other cases must cause error.Q. Mechanism for "instantiation"
Also here. Need to adjust
-d
option. Should list instantiated goals in formpg1 @args 'hello'
pg2 @args 'hello' $'with \''
nonpg
On encounter
@depends_on
generate instantiated? But this needs to go in-depth.