Home » Archived » B3 » better term than "void" wanted
| better term than "void" wanted [message #491989] |
Fri, 16 October 2009 22:03  |
 Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
Hi,
in the first version of the b3 DSL, we adopted the java "void" term to
describe that a build part is listed among the parts on which another
part depends, but where the result of collecting that part's built
result is not included.
The reason for doing so, is that the side effects of the action is
wanted e.g a reset type of operation that may produce some default
result that is unwanted in a particular situation. (Including the result
of an operation such as clear (that does not produce any result is find
- empty result has no effect).
The term "void" works find in this situation, but since it is also
possible to assign the non included result to a variable and in a
subsequent step include parts of the result it looks odd to write:
void a = sometype/someunit/1.0#somepart;
since to a java programmer this reads as it is "a" that is void".
Changing the order of the two does not help at all:
a = void sometype/someunit/1.0#somepart;
as this also looks like a is "void".
The context where the list is included is declarative in nature, so a
term that declares that the entry is "not included in result" is wanted.
The word "unincluded" is yet to be included [sic] in the English
language although there are 45000 google hits for it.
After some dictionary surfing I came up with a candidate list:
- suppress, suppressed (as in the meaning of "holding back")
- ditch, ditched (as in the meaning of "throw out", "evict" or "eject")
- conceal, concealed (as in "hide")
- cloak, cloaked (as in "made invisible")
- hide, hidden (as in "do not show in result")
As a Start Trek fan, I really like "cloak", but I think "hidden" is the
best choice as it is a more common English word.
I am changing the "void" term to "hidden". If others feel it should be
"void" or some better term please make your voice heard.
Regards
- henrik
|
|
|
| Re: better term than "void" wanted [message #492023 is a reply to message #491989] |
Sat, 17 October 2009 06:58  |
|
Hi Henrik,
As I recall it, the syntax:
void a = y
was put there to enable the actor to reference the xxx by alias even though it was not included in the larger group.
Question is, do we need that construct? Can't we just prohibit that it and instead accomplish the same thing like this:
group xyz = { x, void y, z }
group aliasedY { b = xyz, a = y }
now the actor can access both groups and the order of evaluation is still x, y, z. The added a = y will not cause yet
another execution of y.
Regards,
Thomas Hallgren
On 10/17/2009 12:03 AM, Henrik Lindberg wrote:
> Hi,
> in the first version of the b3 DSL, we adopted the java "void" term to
> describe that a build part is listed among the parts on which another
> part depends, but where the result of collecting that part's built
> result is not included.
>
> The reason for doing so, is that the side effects of the action is
> wanted e.g a reset type of operation that may produce some default
> result that is unwanted in a particular situation. (Including the result
> of an operation such as clear (that does not produce any result is find
> - empty result has no effect).
>
> The term "void" works find in this situation, but since it is also
> possible to assign the non included result to a variable and in a
> subsequent step include parts of the result it looks odd to write:
>
> void a = sometype/someunit/1.0#somepart;
>
> since to a java programmer this reads as it is "a" that is void".
> Changing the order of the two does not help at all:
>
> a = void sometype/someunit/1.0#somepart;
>
> as this also looks like a is "void".
>
> The context where the list is included is declarative in nature, so a
> term that declares that the entry is "not included in result" is wanted.
> The word "unincluded" is yet to be included [sic] in the English
> language although there are 45000 google hits for it.
>
> After some dictionary surfing I came up with a candidate list:
>
> - suppress, suppressed (as in the meaning of "holding back")
> - ditch, ditched (as in the meaning of "throw out", "evict" or "eject")
> - conceal, concealed (as in "hide")
> - cloak, cloaked (as in "made invisible")
> - hide, hidden (as in "do not show in result")
>
> As a Start Trek fan, I really like "cloak", but I think "hidden" is the
> best choice as it is a more common English word.
>
> I am changing the "void" term to "hidden". If others feel it should be
> "void" or some better term please make your voice heard.
>
> Regards
> - henrik
|
|
|
| Re: better term than "void" wanted [message #492024 is a reply to message #491989] |
Sat, 17 October 2009 07:32 |
|
Hi Henrik,
As I recall it, the syntax:
void a = y
was put there to enable the actor to reference the y by alias even though it was not included in the larger group.
Question is, do we need that construct? Can't we just prohibit that syntax and instead accomplish the same thing like this:
group xyz = { x, void y, z }
group aliasedY { b = xyz, a = y }
Now the actor can access both groups and the order of evaluation is still x, y, z. The added a = y will not cause yet
another execution of y.
Regards,
Thomas Hallgren
On 10/17/2009 12:03 AM, Henrik Lindberg wrote:
> Hi,
> in the first version of the b3 DSL, we adopted the java "void" term to
> describe that a build part is listed among the parts on which another
> part depends, but where the result of collecting that part's built
> result is not included.
>
> The reason for doing so, is that the side effects of the action is
> wanted e.g a reset type of operation that may produce some default
> result that is unwanted in a particular situation. (Including the result
> of an operation such as clear (that does not produce any result is find
> - empty result has no effect).
>
> The term "void" works find in this situation, but since it is also
> possible to assign the non included result to a variable and in a
> subsequent step include parts of the result it looks odd to write:
>
> void a = sometype/someunit/1.0#somepart;
>
> since to a java programmer this reads as it is "a" that is void".
> Changing the order of the two does not help at all:
>
> a = void sometype/someunit/1.0#somepart;
>
> as this also looks like a is "void".
>
> The context where the list is included is declarative in nature, so a
> term that declares that the entry is "not included in result" is wanted.
> The word "unincluded" is yet to be included [sic] in the English
> language although there are 45000 google hits for it.
>
> After some dictionary surfing I came up with a candidate list:
>
> - suppress, suppressed (as in the meaning of "holding back")
> - ditch, ditched (as in the meaning of "throw out", "evict" or "eject")
> - conceal, concealed (as in "hide")
> - cloak, cloaked (as in "made invisible")
> - hide, hidden (as in "do not show in result")
>
> As a Start Trek fan, I really like "cloak", but I think "hidden" is the
> best choice as it is a more common English word.
>
> I am changing the "void" term to "hidden". If others feel it should be
> "void" or some better term please make your voice heard.
>
> Regards
> - henrik
|
|
|
| Re: better term than "void" wanted [message #492038 is a reply to message #492024] |
Sat, 17 October 2009 11:49 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
Nah, that is to heavy. If you want to do something with the alias in the
same context you have to use the longer "sometype/somename/range" in an
expression to get hold of it - when making changes you have to remember
to change in both places (or complicate it by using property expansion
in the declarations of requirements).
I think the word "hidden" is better.
One alternative that I thought about was to do the "opposite" - the
requirements is either included in the result OR assigned to a variable.
If the value of the assigned element should be included, then an expr is
used to include it.
group xyz { x/x/x; y = y/y/y/; z = z/z/z; } - results in x and z
if it should also be included I see two options:
group { x/x/x; keep y = y/y/y; z = z/z/z; }
or
group { x/x/x; y = y/y/y; expr y; z = z/z/z; }
I like the second, as it does not require a keyword.
I am not sure which I like best.
- henrik
On 10/17/09 9:32 AM, Thomas Hallgren wrote:
> Hi Henrik,
> As I recall it, the syntax:
>
> void a = y
>
> was put there to enable the actor to reference the y by alias even
> though it was not included in the larger group. Question is, do we need
> that construct? Can't we just prohibit that syntax and instead
> accomplish the same thing like this:
>
> group xyz = { x, void y, z }
>
> group aliasedY { b = xyz, a = y }
>
> Now the actor can access both groups and the order of evaluation is
> still x, y, z. The added a = y will not cause yet another execution of y.
>
> Regards,
> Thomas Hallgren
>
> On 10/17/2009 12:03 AM, Henrik Lindberg wrote:
>> Hi,
>> in the first version of the b3 DSL, we adopted the java "void" term to
>> describe that a build part is listed among the parts on which another
>> part depends, but where the result of collecting that part's built
>> result is not included.
>>
>> The reason for doing so, is that the side effects of the action is
>> wanted e.g a reset type of operation that may produce some default
>> result that is unwanted in a particular situation. (Including the result
>> of an operation such as clear (that does not produce any result is find
>> - empty result has no effect).
>>
>> The term "void" works find in this situation, but since it is also
>> possible to assign the non included result to a variable and in a
>> subsequent step include parts of the result it looks odd to write:
>>
>> void a = sometype/someunit/1.0#somepart;
>>
>> since to a java programmer this reads as it is "a" that is void".
>> Changing the order of the two does not help at all:
>>
>> a = void sometype/someunit/1.0#somepart;
>>
>> as this also looks like a is "void".
>>
>> The context where the list is included is declarative in nature, so a
>> term that declares that the entry is "not included in result" is wanted.
>> The word "unincluded" is yet to be included [sic] in the English
>> language although there are 45000 google hits for it.
>>
>> After some dictionary surfing I came up with a candidate list:
>>
>> - suppress, suppressed (as in the meaning of "holding back")
>> - ditch, ditched (as in the meaning of "throw out", "evict" or "eject")
>> - conceal, concealed (as in "hide")
>> - cloak, cloaked (as in "made invisible")
>> - hide, hidden (as in "do not show in result")
>>
>> As a Start Trek fan, I really like "cloak", but I think "hidden" is the
>> best choice as it is a more common English word.
>>
>> I am changing the "void" term to "hidden". If others feel it should be
>> "void" or some better term please make your voice heard.
>>
>> Regards
>> - henrik
>
|
|
|
| Re: better term than "void" wanted [message #492040 is a reply to message #492024] |
Sat, 17 October 2009 13:12 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
One more reason why alias should be set in context, and why it is
valuable to do both at the same time
We allow a part to be evaluated in a defined closure. Using an alias
gets a pointer to that particular result. A new reference to the same
part may have a different closure.
So, to get exactly the same material, references must specify the same
closure.
ie.
The only thing wrong with the construct was the misleading word "void".
- henrik
On 10/17/09 9:32 AM, Thomas Hallgren wrote:
> Hi Henrik,
> As I recall it, the syntax:
>
> void a = y
>
> was put there to enable the actor to reference the y by alias even
> though it was not included in the larger group. Question is, do we need
> that construct? Can't we just prohibit that syntax and instead
> accomplish the same thing like this:
>
> group xyz = { x, void y, z }
>
> group aliasedY { b = xyz, a = y }
>
> Now the actor can access both groups and the order of evaluation is
> still x, y, z. The added a = y will not cause yet another execution of y.
>
> Regards,
> Thomas Hallgren
>
> On 10/17/2009 12:03 AM, Henrik Lindberg wrote:
>> Hi,
>> in the first version of the b3 DSL, we adopted the java "void" term to
>> describe that a build part is listed among the parts on which another
>> part depends, but where the result of collecting that part's built
>> result is not included.
>>
>> The reason for doing so, is that the side effects of the action is
>> wanted e.g a reset type of operation that may produce some default
>> result that is unwanted in a particular situation. (Including the result
>> of an operation such as clear (that does not produce any result is find
>> - empty result has no effect).
>>
>> The term "void" works find in this situation, but since it is also
>> possible to assign the non included result to a variable and in a
>> subsequent step include parts of the result it looks odd to write:
>>
>> void a = sometype/someunit/1.0#somepart;
>>
>> since to a java programmer this reads as it is "a" that is void".
>> Changing the order of the two does not help at all:
>>
>> a = void sometype/someunit/1.0#somepart;
>>
>> as this also looks like a is "void".
>>
>> The context where the list is included is declarative in nature, so a
>> term that declares that the entry is "not included in result" is wanted.
>> The word "unincluded" is yet to be included [sic] in the English
>> language although there are 45000 google hits for it.
>>
>> After some dictionary surfing I came up with a candidate list:
>>
>> - suppress, suppressed (as in the meaning of "holding back")
>> - ditch, ditched (as in the meaning of "throw out", "evict" or "eject")
>> - conceal, concealed (as in "hide")
>> - cloak, cloaked (as in "made invisible")
>> - hide, hidden (as in "do not show in result")
>>
>> As a Start Trek fan, I really like "cloak", but I think "hidden" is the
>> best choice as it is a more common English word.
>>
>> I am changing the "void" term to "hidden". If others feel it should be
>> "void" or some better term please make your voice heard.
>>
>> Regards
>> - henrik
>
|
|
|
| Re: better term than "void" wanted [message #492041 is a reply to message #492038] |
Sat, 17 October 2009 13:45 |
|
On 10/17/2009 01:49 PM, Henrik Lindberg wrote:
> Nah, that is to heavy. If you want to do something with the alias in the
> same context you have to use the longer "sometype/somename/range" in an
> expression to get hold of it - when making changes you have to remember
> to change in both places (or complicate it by using property expansion
> in the declarations of requirements).
>
Given the nature of the problem, I don't think it matters. I think the use of void in conjunction with the need of an
alias is *extremely* rare. So adding special support for it in the syntax is not that necessary.
If the expression is too complex, just put it in a group of its own.
> I think the word "hidden" is better.
>
Yes, if we do support your syntax I agree but I still vote for skipping that option altogether and use void.
- thomas
|
|
| |
| Re: better term than "void" wanted [message #492079 is a reply to message #492050] |
Sun, 18 October 2009 07:04 |
|
On 10/17/2009 07:32 PM, Henrik Lindberg wrote:
> I see it as the single mechanism to be used to get both
> declarative requirements and processing of what these requirements return.
>
> Can you please restate the example below using the mechanism you propose
> (the statement below works in both a group part, and in group inside an
> action):
>
> group xyz {
> {
> x/x/x;
> hidden y = y/y/y with { d='d'; }
> expr (Part(y):processed();
> z/z/z;
> } with { c='c'; };
> }
>
You make aliases available to expressions in the same group. Not sure I'm comfortable with that. It makes it harder to
compute in which order things can be evaluated and in some respect turns the declaration into a procedural language.
To make the closure and order of evaluation more clear and at the same time remove the need for both 'void' and
'hidden', we could instead allow parts in the with clause, i.e.:
group xyz {
{
x/x/x;
expr (Part(y):processed();
z/z/z;
} with {
c = 'c';
y = y/y/y with { d='d'; };
}
}
if the order is significant, split it into two groups:
group ygroup {
{ expr (Part(y):processed(); }
} with { y = y/y/y with { d='d'; };
}
sequential group xyz {
{
x/x/x;
ygroup;
z/z/z;
}
} with { c = 'c'; }
}
What do you think about that?
- thomas
|
|
|
| Re: better term than "void" wanted [message #492097 is a reply to message #492079] |
Sun, 18 October 2009 16:15 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
New proposal at the end... but comments inline...
On 10/18/09 9:04 AM, Thomas Hallgren wrote:
>> group xyz {
>> {
>> x/x/x;
>> hidden y = y/y/y with { d='d'; }
>> expr (Part(y):processed();
>> z/z/z;
>> } with { c='c'; };
>> }
>>
> You make aliases available to expressions in the same group. Not sure
> I'm comfortable with that. It makes it harder to compute in which order
> things can be evaluated and in some respect turns the declaration into a
> procedural language.
>
Agree it is a bit of a mix, and something I don't really like. The idea
however was that the expr statements would not be included in the
calculation of dependencies, evaluation order and actually building the
content. Otherwise the problems you state are very real. As I saw it,
all of the declarative statements would be processed first, their
results would then be collected in the order they are stated, and at
that point would the expr statements be evaluated and the results added
to the resulting path group. No confusion, no "procedural language" as
the expressions do not allow assignment.
> To make the closure and order of evaluation more clear and at the same
> time remove the need for both 'void' and 'hidden', we could instead
> allow parts in the with clause, i.e.:
>
> group xyz {
> {
> x/x/x;
> expr (Part(y):processed();
> z/z/z;
> } with {
> c = 'c';
> y = y/y/y with { d='d'; };
> }
> }
>
Problem here is that the statement y = y/y/y would need to be taken into
consideration when evalutating the group. The assignments in the 'with'
clause are properties (they have to be in a properties clause which I
left out by mistake in my original example), so it should be
properties{ c = 'c'; y = "y/y/y"; }
or
properties { c = 'c'; d = 'd'; y = Part("y/y/y"); }
or there must be an additional clause to have a declarative scope where
y/y/y is understood. A nested group {} ??!? (yuck).
> if the order is significant, split it into two groups:
>
> group ygroup {
> { expr (Part(y):processed(); }
> } with { y = y/y/y with { d='d'; };
> }
>
> sequential group xyz {
> {
> x/x/x;
> ygroup;
> z/z/z;
> }
> } with { c = 'c'; }
> }
>
> What do you think about that?
>
I am rethinking everything again :) and propose that my original example
should be written:
group xyz {
{ x/x/x; processedY; z/z/z; } with { properties{c='c';} };
}
private action processedY {
group { y = y/y/y with ( properties {d='d';}; }
layout { expr Part(y):processed(); }
}
i.e.
- No expressions allowed in groups (part group, or action input group).
- 'expr' is used only in artifacts, and in an action layout
- aliases in a part group are only available in the group's postcondition
- the combination void/alias do make sense - and I persist in that I
think it should be called "hidden" :)
- If an action does not have an actor, the layout is simply constructed
out of expr statements (some default Actor is used behind the scenes to
answer questions about 'uptodate' state and similar Actor duties).
I like the solution above as it keeps the declarative group statement
clean, and that (as Thomas proposed earlier) that processing of results
are done with actions.
I hope you like the proposal too.
(And now, I am very tempted to provide the ability to do some procedural
programming in the action without having to plug in an actor, but it
something we can skip for the time being. )
Regards
- henrik
|
|
| |
| Re: better term than "void" wanted [message #492123 is a reply to message #492097] |
Sun, 18 October 2009 21:01 |
|
On 10/18/2009 06:15 PM, Henrik Lindberg wrote:
> New proposal at the end... but comments inline...
> ... or there must be an additional clause to have a declarative scope where
> y/y/y is understood. A nested group {} ??!? (yuck).
>
Yes, i realized this too some time after I sent my post. And i concur. Yuck.
> I am rethinking everything again :) and propose that my original example
> should be written:
>
> group xyz {
> { x/x/x; processedY; z/z/z; } with { properties{c='c';} };
> }
> private action processedY {
> group { y = y/y/y with ( properties {d='d';}; }
> layout { expr Part(y):processed(); }
> }
>
> i.e.
>
> - No expressions allowed in groups (part group, or action input group).
Great. Never really liked them :-)
> - 'expr' is used only in artifacts, and in an action layout
Because the layout is evaluated after the group so it uses the same context as an actor would. Only difference being,
the actor in this case is a predefined method on a part. That makes sense. But in some sense, I would be more
comfortable with a proper actor here, even if that actor only evaluates the expression. How do you describe the
up-to-date semantics (getting back to this, read-on)?
> - aliases in a part group are only available in the group's postcondition
and in it's layout obviously?
> - the combination void/alias do make sense - and I persist in that I
> think it should be called "hidden" :)
not sure I grok that. How does it make sense if you're only permitted to use aliases in the postcondition/layout? void
in a layout maybe, but combined with alias? How would you use that? Are you suggesting that we can declare aliases in
the layout too? IMO, that would put us back to the unclean more procedural approach again.
> - If an action does not have an actor, the layout is simply constructed
> out of expr statements (some default Actor is used behind the scenes to
> answer questions about 'uptodate' state and similar Actor duties).
>
How can something behind the scenes predict a sane default for what an arbitrary expression is doing? I think you need
the full actor semantics and declare that explicitly.
> I like the solution above as it keeps the declarative group statement
> clean, and that (as Thomas proposed earlier) that processing of results
> are done with actions.
>
> I hope you like the proposal too.
>
We're getting there :-)
> (And now, I am very tempted to provide the ability to do some procedural
> programming in the action without having to plug in an actor, but it
> something we can skip for the time being. )
>
JavaScript anyone? Rhino is actually part of Java 1.6 now:
http://java.sun.com/javase/6/docs/technotes/guides/scripting /index.html
Actually, I think we need something like that. I also think that once we have it, we will see that the need for more
advanced expressions in the rest of the declaration will be more or less eliminated and we get a much clearer separation
between the build model and the actors that do the real work.
- thomas
|
|
|
| Re: better term than "void" wanted [message #492130 is a reply to message #492123] |
Sun, 18 October 2009 23:02 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
Comments inline.
On 10/18/09 11:01 PM, Thomas Hallgren wrote:
>> I am rethinking everything again :) and propose that my original example
>> should be written:
>>
>> group xyz {
>> { x/x/x; processedY; z/z/z; } with { properties{c='c';} };
>> }
>> private action processedY {
>> group { y = y/y/y with ( properties {d='d';}; }
>> layout { expr Part(y):processed(); }
>> }
>>
>> i.e.
>>
>> - No expressions allowed in groups (part group, or action input group).
>
> Great. Never really liked them :-)
>
Consider them gone.
>> - 'expr' is used only in artifacts, and in an action layout
>
> Because the layout is evaluated after the group so it uses the same
> context as an actor would. Only difference being, the actor in this case
> is a predefined method on a part. That makes sense. But in some sense, I
> would be more comfortable with a proper actor here, even if that actor
> only evaluates the expression. How do you describe the up-to-date
> semantics (getting back to this, read-on)?
>
>> - aliases in a part group are only available in the group's postcondition
>
> and in it's layout obviously?
>
No, a *part* group does not have a layout. An action has a layout.
So, for a group, the aliases can only be used for one thing - to assert
things in the group's postcondition.
>> - the combination void/alias do make sense - and I persist in that I
>> think it should be called "hidden" :)
>
> not sure I grok that. How does it make sense if you're only permitted to
> use aliases in the postcondition/layout? void in a layout maybe, but
> combined with alias? How would you use that? Are you suggesting that we
> can declare aliases in the layout too? IMO, that would put us back to
> the unclean more procedural approach again.
>
The need is there if a void part is referenced in a part group, and an
assertion is wanted to make sure the evaluation of that part had the
desired effect and that the assert needs access to the content of the
result of that particular evaluation (unless there is another way of
finding the exact same result).
The same is true in actions, since expressions would be allowed in
layouts. A part is stated in the action's group to get it evaluated, it
is marked void since the action should not see it. An expression in the
layout directs what should happen to it, and where in the result it
should be placed.
The alternative would be to have an extra action that returns an empty
path group vector, but that sets annotations that the receiver of the
empty path group vector can make use of.
>> - If an action does not have an actor, the layout is simply constructed
>> out of expr statements (some default Actor is used behind the scenes to
>> answer questions about 'uptodate' state and similar Actor duties).
>>
> How can something behind the scenes predict a sane default for what an
> arbitrary expression is doing? I think you need the full actor semantics
> and declare that explicitly.
>
What are the responsibilities of the actor besides: ?
- transforming input to output (in a context)
- reporting if the output is "uptodate" wrt. the input (and context)
A declaration of an "up to date" policy would be needed. Which is needed
with many actors as well - I said I wanted to push this to the actor
because in some cases (well written and special purpose actors) would
know if a result is up to date based on the input. But some actors may
not have a clue - say an actor that can execute shell scripts. It can
not know what the action it is invoking is doing. Something else must
declare the uptodate policy - even if it is the Actors duty to act on
the declaration.
Using expr to construct the layout is therefore no different. It is just
a mechanism to avoid having to write an ANT script, or a new actor in
order to do some typical/frequent/wanted processing (include/exclude
filtering, union, intersection, copy, replace a file built the default
way with a specially processed file, etc.)
What I am suggesting is that a handful of operations on String, Path,
Part, and Unit are part of the model, and these expressions/calls are
just as "declarative" as the rest of the model... only that it is
natural to state them as expressions e.g.
Part:union(...a,b):include(pattern="^org.myorg*");
As opposed to declaring something like:
private actor union_a_b Actor PartUnionProcessor() {
group{ a; b; }
layout { processed/union_a_b/; }
}
private actor includeMyOrg_a_b Actor PartIncludeProcessor() {
group { union_a_b; }
layout { processed/includeMyOrg_a_b/; }
}
Stating the above differently: There are certain executable features in
the b3 model that are accessible from the b3 file. (We discussed having
the things like Part, Path, String be extensible, but that is not really
required, we can control and define exactly what is available in the model).
Actually, I think I was wrong before in stating that expr's alone in the
action's layout would be enough. There is nothing stating what should
actually happen with the result. My example implied a copy, but that was
not stated - the expr just results in paths, parts, etc. In order to
make it work, declaring that a Copy actor should to the work would be
required.
>> (And now, I am very tempted to provide the ability to do some procedural
>> programming in the action without having to plug in an actor, but it
>> something we can skip for the time being. )
>>
> JavaScript anyone? Rhino is actually part of Java 1.6 now:
> http://java.sun.com/javase/6/docs/technotes/guides/scripting /index.html
>
> Actually, I think we need something like that. I also think that once we
> have it, we will see that the need for more advanced expressions in the
> rest of the declaration will be more or less eliminated and we get a
> much clearer separation between the build model and the actors that do
> the real work.
>
Agree to that. We should not invent a new GPL. I also don't think we
should include the actual script text in the b3 file. Instead there
could be a JavaScript Actor, a Python actor, etc. using the JSR 233
mechanism to communicate with the scripting environment. This way, it is
up to the users of b3 to decide what they want to use for writing actors
(java, Javascript or something else).
From b3's perspective the Actor is a leaf declaration that means "I
want x to happen - don't know how X is done".
The issues with including the scripting code in the b3 file is naturally
that b3 would have to understand it or treat it as "just text". I think
neither is very good - better to push it off and let regular tooling for
the specific language deal with the actor code.
- henrik
|
|
|
| Re: better term than "void" wanted [message #492154 is a reply to message #492130] |
Mon, 19 October 2009 07:17 |
|
Hi Henrik,
I have a different perspective regarding scripting. Probably because one major source of irritation when looking at
cspecs is that you just have to look at other files (ant-scripts) as well in order to understand it. I realize that
there would be some difficulties in parsing but I still think it would be terrific if we could:
1. Decide that b3 indeed does support JavaScript.
2. Make the parser understand JavaScript.
Another reason include getting rid of non-boolean expressions so that we have a clean declarative language. More on that
in comments inline.
>>> I am rethinking everything again :) and propose that my original example
>>> should be written:
>>>
>>> group xyz {
>>> { x/x/x; processedY; z/z/z; } with { properties{c='c';} };
>>> }
>>> private action processedY {
>>> group { y = y/y/y with ( properties {d='d';}; }
>>> layout { expr Part(y):processed(); }
>>> }
>>>
Let's assume we have JavaScript:
group xyz {
{ x/x/x; processedY; z/z/z; } with { properties{c='c';} };
}
private action processedY { // No actor declared means default = JavaScript
group { y = y/y/y } with { properties { d = 'd'; } }
script { return y.processed(); } // Not sure 'script' is the best term here.
}
>>> - the combination void/alias do make sense - and I persist in that I
>>> think it should be called "hidden" :)
>>
>> not sure I grok that. How does it make sense if you're only permitted to
>> use aliases in the postcondition/layout? void in a layout maybe, but
>> combined with alias? How would you use that? Are you suggesting that we
>> can declare aliases in the layout too? IMO, that would put us back to
>> the unclean more procedural approach again.
>>
> The need is there if a void part is referenced in a part group, and an
> assertion is wanted to make sure the evaluation of that part had the
> desired effect and that the assert needs access to the content of the
> result of that particular evaluation (unless there is another way of
> finding the exact same result).
>
> The same is true in actions, since expressions would be allowed in
> layouts. A part is stated in the action's group to get it evaluated, it
> is marked void since the action should not see it. An expression in the
> layout directs what should happen to it, and where in the result it
> should be placed.
>
> The alternative would be to have an extra action that returns an empty
> path group vector, but that sets annotations that the receiver of the
> empty path group vector can make use of.
>
Another alternative:
action x {
group { a = { xxx }; b = { yyy } }
postcondition { // something that involves b }
script { return a; }
}
which is equivalent to:
group x {
group { a = { xxx }; hidden b = { yyy } }
postcondition { // something that involves b }
}
>> How can something behind the scenes predict a sane default for what an
>> arbitrary expression is doing? I think you need the full actor semantics
>> and declare that explicitly.
>>
> What are the responsibilities of the actor besides: ?
> - transforming input to output (in a context)
> - reporting if the output is "uptodate" wrt. the input (and context)
>
> A declaration of an "up to date" policy would be needed. Which is needed
> with many actors as well
>
Are you suggesting that groups need up-to-date policies? I was under the impression that a group was an aggregation of
things that had already been declared. Nothing more.
> - I said I wanted to push this to the actor
> because in some cases (well written and special purpose actors) would
> know if a result is up to date based on the input. But some actors may
> not have a clue - say an actor that can execute shell scripts. It can
> not know what the action it is invoking is doing. Something else must
> declare the uptodate policy - even if it is the Actors duty to act on
> the declaration.
>
> Using expr to construct the layout is therefore no different. It is just
> a mechanism to avoid having to write an ANT script, or a new actor in
> order to do some typical/frequent/wanted processing (include/exclude
> filtering, union, intersection, copy, replace a file built the default
> way with a specially processed file, etc.)
>
> What I am suggesting is that a handful of operations on String, Path,
> Part, and Unit are part of the model, and these expressions/calls are
> just as "declarative" as the rest of the model... only that it is
> natural to state them as expressions e.g.
>
> Part:union(...a,b):include(pattern="^org.myorg*");
>
> As opposed to declaring something like:
>
> private actor union_a_b Actor PartUnionProcessor() {
> group{ a; b; }
> layout { processed/union_a_b/; }
> }
> private actor includeMyOrg_a_b Actor PartIncludeProcessor() {
> group { union_a_b; }
> layout { processed/includeMyOrg_a_b/; }
> }
>
> Stating the above differently: There are certain executable features in
> the b3 model that are accessible from the b3 file. (We discussed having
> the things like Part, Path, String be extensible, but that is not really
> required, we can control and define exactly what is available in the
> model).
>
> Actually, I think I was wrong before in stating that expr's alone in the
> action's layout would be enough. There is nothing stating what should
> actually happen with the result. My example implied a copy, but that was
> not stated - the expr just results in paths, parts, etc. In order to
> make it work, declaring that a Copy actor should to the work would be
> required.
>
I think that is taking things in the wrong direction. The declaration gets fuzzy and hard to maintain. Your example can
be written:
action foo {
group { a = ...; b = ...; }
script { return a.union(b).include("^org.myorg*") }
}
I don't consider the group a place to execute things (declarative in nature or not). It's merely an aggregation of
things that are already declared. If you want to perform something with that, then an action should be used. Always.
That's why the distinction was put there in the fist place.
I'm fine with that boolean filters can use a generic expression language in a group ('when' expressions), but I'm very
reluctant to take the evaluation power beyond that. It just obstructs/complicates the whole model. Using expressions to
produce new parts in a group is not a good thing IMO.
You advocate 'declarative calls/expressions', but what you are actually suggesting is an extendable mechanism that can
be made to perform just about anything. If it was just declarative, then we would add the declarations to the model
itself but we can't do that because we cannot really predict what it is that we want. IMO, we then have an actor and the
only problem is that it's too cumbersome to write one.
So, the Axiom could be:
If it's declarative, then the DSL syntax should support it. 'intersect' and 'union' could be considered for instance.
If we don't want the syntax support, then it should go into an actor.
> ... From b3's perspective the Actor is a leaf declaration that means "I
> want x to happen - don't know how X is done".
>
That was one of the ideas with Buckminster too. That, IMO unfortunate decision, has been our primary source of
fragmentation ever since and is also the primary source of obfuscation. It is difficult on the verge to impossible to
follow what a CSPEC is all about. It's hard to get an overview and see what values goes where and how they are acted
upon. You always need additional artifacts.
> The issues with including the scripting code in the b3 file is naturally
> that b3 would have to understand it or treat it as "just text". I think
> neither is very good - better to push it off and let regular tooling for
> the specific language deal with the actor code.
>
Is JavaScript really that different from the rest? I would have thought that our parser could be made to understand JS.
At least well enough to collect it in a syntax tree and then pass it off to Rhino for real validation.
- thomas
|
|
| | |
| Re: better term than "void" wanted [message #492199 is a reply to message #492154] |
Mon, 19 October 2009 12:34 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
On 10/19/09 9:17 AM, Thomas Hallgren wrote:
> Hi Henrik,
> I have a different perspective regarding scripting. Probably because one
> major source of irritation when looking at cspecs is that you just have
> to look at other files (ant-scripts) as well in order to understand it.
> I realize that there would be some difficulties in parsing but I still
> think it would be terrific if we could:
>
> 1. Decide that b3 indeed does support JavaScript.
> 2. Make the parser understand JavaScript.
>
> Another reason include getting rid of non-boolean expressions so that we
> have a clean declarative language. More on that in comments inline.
>
Agree. I want to get rid of the requirement that for every thing you
want to do, you have to write yet another file. That sucks.
I would need to change a couple of things in the syntax to make it
comply with JS. JS, just as b3 allows members/features to have funny
names. In JS the syntax is xxx['funny name'], where we choose to use
xxx."funny name". b3 uses ":" instead of "." - to comply with JS this
also means that a name with a period "." needs to be handled as a funny
name.
Other than that, there should not be difficult to add the JS
complementary syntax to the parser.
It makes constructing the debugger a bit more interesting, but also more
valuable, as you need to be able to step through the JS logic in a JS actor.
>>>> I am rethinking everything again :) and propose that my original
>>>> example
>>>> should be written:
>>>>
>>>> group xyz {
>>>> { x/x/x; processedY; z/z/z; } with { properties{c='c';} };
>>>> }
>>>> private action processedY {
>>>> group { y = y/y/y with ( properties {d='d';}; }
>>>> layout { expr Part(y):processed(); }
>>>> }
>>>>
> Let's assume we have JavaScript:
>
> group xyz {
> { x/x/x; processedY; z/z/z; } with { properties{c='c';} };
> }
>
> private action processedY { // No actor declared means default = JavaScript
> group { y = y/y/y } with { properties { d = 'd'; } }
> script { return y.processed(); } // Not sure 'script' is the best term
> here.
> }
>
Agree - the actor body is embedded. We probably want to have the JS be
an implementation of the Actor interface. This way, it is possible to
implement also the uptodate policy method, and whatever else needs to be
handled. Maybe we want to expose those methods in b3 - as opposed to
having one script where 'this' is used and the developer has to add the
method definitions. (Let's discuss that in a separate thread...)
>>>> - the combination void/alias do make sense - and I persist in that I
>>>> think it should be called "hidden" :)
> Another alternative:
>
> action x {
> group { a = { xxx }; b = { yyy } }
> postcondition { // something that involves b }
> script { return a; }
> }
>
> which is equivalent to:
>
> group x {
> group { a = { xxx }; hidden b = { yyy } }
> postcondition { // something that involves b }
> }
>
That is fine, when the script is explicit 'hidden' is not needed, the
script can just pick what it needs. The only time hidden is needed is
when an external Actor is used, and its API uses the entire group.
The same is also true in a part group (i.e. not an action), where the
postcondition needs access to a hidden/void part.
>>> How can something behind the scenes predict a sane default for what an
>>> arbitrary expression is doing? I think you need the full actor semantics
>>> and declare that explicitly.
>>>
>> What are the responsibilities of the actor besides: ?
>> - transforming input to output (in a context)
>> - reporting if the output is "uptodate" wrt. the input (and context)
>>
>> A declaration of an "up to date" policy would be needed. Which is needed
>> with many actors as well
> >
> Are you suggesting that groups need up-to-date policies? I was under the
> impression that a group was an aggregation of things that had already
> been declared. Nothing more.
>
No, I am suggesting that an action needs an uptodate policy.
The keyword group is used both for a "part group", and for the action's
"input group", and the syntax inside a group should preferably be the
same in both cases.
The action needs the uptodate policy as its output is not the same as
its input...
> Your example can be written:
> action foo {
> group { a = ...; b = ...; }
> script { return a.union(b).include("^org.myorg*") }
> }
>
I like that. When using a script, it is clear that it returns something
that has the correct return type.
For external actors it is different. But for those, any processing can
be done in another action that is used as input to the action with the
external actor. Likewise if processing is needed after the external
actor has done its job.
I think I would prefer if the syntax stated that an actor or a script
could be used. The declaration in the action's preamble is still valid,
as it declares the actor class, and initialization (although that could
be moved into the body).
I can also imagine that one Actor class has several methods, so you want
to pick one of them.
i.e. something like
'script' '{' js-statements* '}' | 'actor' ':' method=ID
> I don't consider the group a place to execute things (declarative in
> nature or not). It's merely an aggregation of things that are already
> declared. If you want to perform something with that, then an action
> should be used. Always. That's why the distinction was put there in the
> fist place.
>
This is a confusion over group being both a "part group" and an "input
group". The suggestion was not to have expr in group's at all but to put
them in the layout.
> I'm fine with that boolean filters can use a generic expression language
> in a group ('when' expressions), but I'm very reluctant to take the
> evaluation power beyond that. It just obstructs/complicates the whole
> model. Using expressions to produce new parts in a group is not a good
> thing IMO.
>
Agree - that is why I said that they should be removed :)
> You advocate 'declarative calls/expressions', but what you are actually
> suggesting is an extendable mechanism that can be made to perform just
> about anything. If it was just declarative, then we would add the
> declarations to the model itself but we can't do that because we cannot
> really predict what it is that we want. IMO, we then have an actor and
> the only problem is that it's too cumbersome to write one.
>
I am advocating them in artifacts, and layout. Not in groups.
Scripts in actors removes the need to have them in layout.
> So, the Axiom could be:
> If it's declarative, then the DSL syntax should support it. 'intersect'
> and 'union' could be considered for instance.
> If we don't want the syntax support, then it should go into an actor.
>
Although it looks "sexy" to support set operations in group syntax. I
think that is not used that often, and could just as well be used in an
action as it is easy to specify using scripting.
>> ... From b3's perspective the Actor is a leaf declaration that means "I
>> want x to happen - don't know how X is done".
>>
> That was one of the ideas with Buckminster too. That, IMO unfortunate
> decision, has been our primary source of fragmentation ever since and is
> also the primary source of obfuscation. It is difficult on the verge to
> impossible to follow what a CSPEC is all about. It's hard to get an
> overview and see what values goes where and how they are acted upon. You
> always need additional artifacts.
>
BRANCH ON $B AND COMEFROM $A;
I want to get rid of all of those issues as much as possible.
- b3 should have the power to express most operations
- no magic "input" and "output"
As a consequence. Look at use of an external Actor compared to a script.
Why not declare what should be sent to the actor as named parameters. I
think that would help reduce the confusion.
> Is JavaScript really that different from the rest? I would have thought
> that our parser could be made to understand JS. At least well enough to
> collect it in a syntax tree and then pass it off to Rhino for real
> validation.
Have to take a look at JS again, you may be right. There are some
implications on the rest of the syntax thought (as I noted earlier). I
think we should strive to have the same syntax everywhere for common
concepts.
- henrik
|
|
|
| Re: better term than "void" wanted [message #582121 is a reply to message #491989] |
Sat, 17 October 2009 07:32 |
|
Hi Henrik,
As I recall it, the syntax:
void a = y
was put there to enable the actor to reference the y by alias even though it was not included in the larger group.
Question is, do we need that construct? Can't we just prohibit that syntax and instead accomplish the same thing like this:
group xyz = { x, void y, z }
group aliasedY { b = xyz, a = y }
Now the actor can access both groups and the order of evaluation is still x, y, z. The added a = y will not cause yet
another execution of y.
Regards,
Thomas Hallgren
On 10/17/2009 12:03 AM, Henrik Lindberg wrote:
> Hi,
> in the first version of the b3 DSL, we adopted the java "void" term to
> describe that a build part is listed among the parts on which another
> part depends, but where the result of collecting that part's built
> result is not included.
>
> The reason for doing so, is that the side effects of the action is
> wanted e.g a reset type of operation that may produce some default
> result that is unwanted in a particular situation. (Including the result
> of an operation such as clear (that does not produce any result is find
> - empty result has no effect).
>
> The term "void" works find in this situation, but since it is also
> possible to assign the non included result to a variable and in a
> subsequent step include parts of the result it looks odd to write:
>
> void a = sometype/someunit/1.0#somepart;
>
> since to a java programmer this reads as it is "a" that is void".
> Changing the order of the two does not help at all:
>
> a = void sometype/someunit/1.0#somepart;
>
> as this also looks like a is "void".
>
> The context where the list is included is declarative in nature, so a
> term that declares that the entry is "not included in result" is wanted.
> The word "unincluded" is yet to be included [sic] in the English
> language although there are 45000 google hits for it.
>
> After some dictionary surfing I came up with a candidate list:
>
> - suppress, suppressed (as in the meaning of "holding back")
> - ditch, ditched (as in the meaning of "throw out", "evict" or "eject")
> - conceal, concealed (as in "hide")
> - cloak, cloaked (as in "made invisible")
> - hide, hidden (as in "do not show in result")
>
> As a Start Trek fan, I really like "cloak", but I think "hidden" is the
> best choice as it is a more common English word.
>
> I am changing the "void" term to "hidden". If others feel it should be
> "void" or some better term please make your voice heard.
>
> Regards
> - henrik
|
|
|
| Re: better term than "void" wanted [message #582132 is a reply to message #492024] |
Sat, 17 October 2009 11:49 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
Nah, that is to heavy. If you want to do something with the alias in the
same context you have to use the longer "sometype/somename/range" in an
expression to get hold of it - when making changes you have to remember
to change in both places (or complicate it by using property expansion
in the declarations of requirements).
I think the word "hidden" is better.
One alternative that I thought about was to do the "opposite" - the
requirements is either included in the result OR assigned to a variable.
If the value of the assigned element should be included, then an expr is
used to include it.
group xyz { x/x/x; y = y/y/y/; z = z/z/z; } - results in x and z
if it should also be included I see two options:
group { x/x/x; keep y = y/y/y; z = z/z/z; }
or
group { x/x/x; y = y/y/y; expr y; z = z/z/z; }
I like the second, as it does not require a keyword.
I am not sure which I like best.
- henrik
On 10/17/09 9:32 AM, Thomas Hallgren wrote:
> Hi Henrik,
> As I recall it, the syntax:
>
> void a = y
>
> was put there to enable the actor to reference the y by alias even
> though it was not included in the larger group. Question is, do we need
> that construct? Can't we just prohibit that syntax and instead
> accomplish the same thing like this:
>
> group xyz = { x, void y, z }
>
> group aliasedY { b = xyz, a = y }
>
> Now the actor can access both groups and the order of evaluation is
> still x, y, z. The added a = y will not cause yet another execution of y.
>
> Regards,
> Thomas Hallgren
>
> On 10/17/2009 12:03 AM, Henrik Lindberg wrote:
>> Hi,
>> in the first version of the b3 DSL, we adopted the java "void" term to
>> describe that a build part is listed among the parts on which another
>> part depends, but where the result of collecting that part's built
>> result is not included.
>>
>> The reason for doing so, is that the side effects of the action is
>> wanted e.g a reset type of operation that may produce some default
>> result that is unwanted in a particular situation. (Including the result
>> of an operation such as clear (that does not produce any result is find
>> - empty result has no effect).
>>
>> The term "void" works find in this situation, but since it is also
>> possible to assign the non included result to a variable and in a
>> subsequent step include parts of the result it looks odd to write:
>>
>> void a = sometype/someunit/1.0#somepart;
>>
>> since to a java programmer this reads as it is "a" that is void".
>> Changing the order of the two does not help at all:
>>
>> a = void sometype/someunit/1.0#somepart;
>>
>> as this also looks like a is "void".
>>
>> The context where the list is included is declarative in nature, so a
>> term that declares that the entry is "not included in result" is wanted.
>> The word "unincluded" is yet to be included [sic] in the English
>> language although there are 45000 google hits for it.
>>
>> After some dictionary surfing I came up with a candidate list:
>>
>> - suppress, suppressed (as in the meaning of "holding back")
>> - ditch, ditched (as in the meaning of "throw out", "evict" or "eject")
>> - conceal, concealed (as in "hide")
>> - cloak, cloaked (as in "made invisible")
>> - hide, hidden (as in "do not show in result")
>>
>> As a Start Trek fan, I really like "cloak", but I think "hidden" is the
>> best choice as it is a more common English word.
>>
>> I am changing the "void" term to "hidden". If others feel it should be
>> "void" or some better term please make your voice heard.
>>
>> Regards
>> - henrik
>
|
|
|
| Re: better term than "void" wanted [message #582721 is a reply to message #492024] |
Sat, 17 October 2009 13:12 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
One more reason why alias should be set in context, and why it is
valuable to do both at the same time
We allow a part to be evaluated in a defined closure. Using an alias
gets a pointer to that particular result. A new reference to the same
part may have a different closure.
So, to get exactly the same material, references must specify the same
closure.
ie.
The only thing wrong with the construct was the misleading word "void".
- henrik
On 10/17/09 9:32 AM, Thomas Hallgren wrote:
> Hi Henrik,
> As I recall it, the syntax:
>
> void a = y
>
> was put there to enable the actor to reference the y by alias even
> though it was not included in the larger group. Question is, do we need
> that construct? Can't we just prohibit that syntax and instead
> accomplish the same thing like this:
>
> group xyz = { x, void y, z }
>
> group aliasedY { b = xyz, a = y }
>
> Now the actor can access both groups and the order of evaluation is
> still x, y, z. The added a = y will not cause yet another execution of y.
>
> Regards,
> Thomas Hallgren
>
> On 10/17/2009 12:03 AM, Henrik Lindberg wrote:
>> Hi,
>> in the first version of the b3 DSL, we adopted the java "void" term to
>> describe that a build part is listed among the parts on which another
>> part depends, but where the result of collecting that part's built
>> result is not included.
>>
>> The reason for doing so, is that the side effects of the action is
>> wanted e.g a reset type of operation that may produce some default
>> result that is unwanted in a particular situation. (Including the result
>> of an operation such as clear (that does not produce any result is find
>> - empty result has no effect).
>>
>> The term "void" works find in this situation, but since it is also
>> possible to assign the non included result to a variable and in a
>> subsequent step include parts of the result it looks odd to write:
>>
>> void a = sometype/someunit/1.0#somepart;
>>
>> since to a java programmer this reads as it is "a" that is void".
>> Changing the order of the two does not help at all:
>>
>> a = void sometype/someunit/1.0#somepart;
>>
>> as this also looks like a is "void".
>>
>> The context where the list is included is declarative in nature, so a
>> term that declares that the entry is "not included in result" is wanted.
>> The word "unincluded" is yet to be included [sic] in the English
>> language although there are 45000 google hits for it.
>>
>> After some dictionary surfing I came up with a candidate list:
>>
>> - suppress, suppressed (as in the meaning of "holding back")
>> - ditch, ditched (as in the meaning of "throw out", "evict" or "eject")
>> - conceal, concealed (as in "hide")
>> - cloak, cloaked (as in "made invisible")
>> - hide, hidden (as in "do not show in result")
>>
>> As a Start Trek fan, I really like "cloak", but I think "hidden" is the
>> best choice as it is a more common English word.
>>
>> I am changing the "void" term to "hidden". If others feel it should be
>> "void" or some better term please make your voice heard.
>>
>> Regards
>> - henrik
>
|
|
|
| Re: better term than "void" wanted [message #582736 is a reply to message #492038] |
Sat, 17 October 2009 13:45 |
|
On 10/17/2009 01:49 PM, Henrik Lindberg wrote:
> Nah, that is to heavy. If you want to do something with the alias in the
> same context you have to use the longer "sometype/somename/range" in an
> expression to get hold of it - when making changes you have to remember
> to change in both places (or complicate it by using property expansion
> in the declarations of requirements).
>
Given the nature of the problem, I don't think it matters. I think the use of void in conjunction with the need of an
alias is *extremely* rare. So adding special support for it in the syntax is not that necessary.
If the expression is too complex, just put it in a group of its own.
> I think the word "hidden" is better.
>
Yes, if we do support your syntax I agree but I still vote for skipping that option altogether and use void.
- thomas
|
|
| |
| Re: better term than "void" wanted [message #582764 is a reply to message #492050] |
Sun, 18 October 2009 07:04 |
|
On 10/17/2009 07:32 PM, Henrik Lindberg wrote:
> I see it as the single mechanism to be used to get both
> declarative requirements and processing of what these requirements return.
>
> Can you please restate the example below using the mechanism you propose
> (the statement below works in both a group part, and in group inside an
> action):
>
> group xyz {
> {
> x/x/x;
> hidden y = y/y/y with { d='d'; }
> expr (Part(y):processed();
> z/z/z;
> } with { c='c'; };
> }
>
You make aliases available to expressions in the same group. Not sure I'm comfortable with that. It makes it harder to
compute in which order things can be evaluated and in some respect turns the declaration into a procedural language.
To make the closure and order of evaluation more clear and at the same time remove the need for both 'void' and
'hidden', we could instead allow parts in the with clause, i.e.:
group xyz {
{
x/x/x;
expr (Part(y):processed();
z/z/z;
} with {
c = 'c';
y = y/y/y with { d='d'; };
}
}
if the order is significant, split it into two groups:
group ygroup {
{ expr (Part(y):processed(); }
} with { y = y/y/y with { d='d'; };
}
sequential group xyz {
{
x/x/x;
ygroup;
z/z/z;
}
} with { c = 'c'; }
}
What do you think about that?
- thomas
|
|
|
| Re: better term than "void" wanted [message #582777 is a reply to message #492079] |
Sun, 18 October 2009 16:15 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
New proposal at the end... but comments inline...
On 10/18/09 9:04 AM, Thomas Hallgren wrote:
>> group xyz {
>> {
>> x/x/x;
>> hidden y = y/y/y with { d='d'; }
>> expr (Part(y):processed();
>> z/z/z;
>> } with { c='c'; };
>> }
>>
> You make aliases available to expressions in the same group. Not sure
> I'm comfortable with that. It makes it harder to compute in which order
> things can be evaluated and in some respect turns the declaration into a
> procedural language.
>
Agree it is a bit of a mix, and something I don't really like. The idea
however was that the expr statements would not be included in the
calculation of dependencies, evaluation order and actually building the
content. Otherwise the problems you state are very real. As I saw it,
all of the declarative statements would be processed first, their
results would then be collected in the order they are stated, and at
that point would the expr statements be evaluated and the results added
to the resulting path group. No confusion, no "procedural language" as
the expressions do not allow assignment.
> To make the closure and order of evaluation more clear and at the same
> time remove the need for both 'void' and 'hidden', we could instead
> allow parts in the with clause, i.e.:
>
> group xyz {
> {
> x/x/x;
> expr (Part(y):processed();
> z/z/z;
> } with {
> c = 'c';
> y = y/y/y with { d='d'; };
> }
> }
>
Problem here is that the statement y = y/y/y would need to be taken into
consideration when evalutating the group. The assignments in the 'with'
clause are properties (they have to be in a properties clause which I
left out by mistake in my original example), so it should be
properties{ c = 'c'; y = "y/y/y"; }
or
properties { c = 'c'; d = 'd'; y = Part("y/y/y"); }
or there must be an additional clause to have a declarative scope where
y/y/y is understood. A nested group {} ??!? (yuck).
> if the order is significant, split it into two groups:
>
> group ygroup {
> { expr (Part(y):processed(); }
> } with { y = y/y/y with { d='d'; };
> }
>
> sequential group xyz {
> {
> x/x/x;
> ygroup;
> z/z/z;
> }
> } with { c = 'c'; }
> }
>
> What do you think about that?
>
I am rethinking everything again :) and propose that my original example
should be written:
group xyz {
{ x/x/x; processedY; z/z/z; } with { properties{c='c';} };
}
private action processedY {
group { y = y/y/y with ( properties {d='d';}; }
layout { expr Part(y):processed(); }
}
i.e.
- No expressions allowed in groups (part group, or action input group).
- 'expr' is used only in artifacts, and in an action layout
- aliases in a part group are only available in the group's postcondition
- the combination void/alias do make sense - and I persist in that I
think it should be called "hidden" :)
- If an action does not have an actor, the layout is simply constructed
out of expr statements (some default Actor is used behind the scenes to
answer questions about 'uptodate' state and similar Actor duties).
I like the solution above as it keeps the declarative group statement
clean, and that (as Thomas proposed earlier) that processing of results
are done with actions.
I hope you like the proposal too.
(And now, I am very tempted to provide the ability to do some procedural
programming in the action without having to plug in an actor, but it
something we can skip for the time being. )
Regards
- henrik
|
|
| |
| Re: better term than "void" wanted [message #582801 is a reply to message #492097] |
Sun, 18 October 2009 21:01 |
|
On 10/18/2009 06:15 PM, Henrik Lindberg wrote:
> New proposal at the end... but comments inline...
> ... or there must be an additional clause to have a declarative scope where
> y/y/y is understood. A nested group {} ??!? (yuck).
>
Yes, i realized this too some time after I sent my post. And i concur. Yuck.
> I am rethinking everything again :) and propose that my original example
> should be written:
>
> group xyz {
> { x/x/x; processedY; z/z/z; } with { properties{c='c';} };
> }
> private action processedY {
> group { y = y/y/y with ( properties {d='d';}; }
> layout { expr Part(y):processed(); }
> }
>
> i.e.
>
> - No expressions allowed in groups (part group, or action input group).
Great. Never really liked them :-)
> - 'expr' is used only in artifacts, and in an action layout
Because the layout is evaluated after the group so it uses the same context as an actor would. Only difference being,
the actor in this case is a predefined method on a part. That makes sense. But in some sense, I would be more
comfortable with a proper actor here, even if that actor only evaluates the expression. How do you describe the
up-to-date semantics (getting back to this, read-on)?
> - aliases in a part group are only available in the group's postcondition
and in it's layout obviously?
> - the combination void/alias do make sense - and I persist in that I
> think it should be called "hidden" :)
not sure I grok that. How does it make sense if you're only permitted to use aliases in the postcondition/layout? void
in a layout maybe, but combined with alias? How would you use that? Are you suggesting that we can declare aliases in
the layout too? IMO, that would put us back to the unclean more procedural approach again.
> - If an action does not have an actor, the layout is simply constructed
> out of expr statements (some default Actor is used behind the scenes to
> answer questions about 'uptodate' state and similar Actor duties).
>
How can something behind the scenes predict a sane default for what an arbitrary expression is doing? I think you need
the full actor semantics and declare that explicitly.
> I like the solution above as it keeps the declarative group statement
> clean, and that (as Thomas proposed earlier) that processing of results
> are done with actions.
>
> I hope you like the proposal too.
>
We're getting there :-)
> (And now, I am very tempted to provide the ability to do some procedural
> programming in the action without having to plug in an actor, but it
> something we can skip for the time being. )
>
JavaScript anyone? Rhino is actually part of Java 1.6 now:
http://java.sun.com/javase/6/docs/technotes/guides/scripting /index.html
Actually, I think we need something like that. I also think that once we have it, we will see that the need for more
advanced expressions in the rest of the declaration will be more or less eliminated and we get a much clearer separation
between the build model and the actors that do the real work.
- thomas
|
|
|
| Re: better term than "void" wanted [message #582815 is a reply to message #492123] |
Sun, 18 October 2009 23:02 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
Comments inline.
On 10/18/09 11:01 PM, Thomas Hallgren wrote:
>> I am rethinking everything again :) and propose that my original example
>> should be written:
>>
>> group xyz {
>> { x/x/x; processedY; z/z/z; } with { properties{c='c';} };
>> }
>> private action processedY {
>> group { y = y/y/y with ( properties {d='d';}; }
>> layout { expr Part(y):processed(); }
>> }
>>
>> i.e.
>>
>> - No expressions allowed in groups (part group, or action input group).
>
> Great. Never really liked them :-)
>
Consider them gone.
>> - 'expr' is used only in artifacts, and in an action layout
>
> Because the layout is evaluated after the group so it uses the same
> context as an actor would. Only difference being, the actor in this case
> is a predefined method on a part. That makes sense. But in some sense, I
> would be more comfortable with a proper actor here, even if that actor
> only evaluates the expression. How do you describe the up-to-date
> semantics (getting back to this, read-on)?
>
>> - aliases in a part group are only available in the group's postcondition
>
> and in it's layout obviously?
>
No, a *part* group does not have a layout. An action has a layout.
So, for a group, the aliases can only be used for one thing - to assert
things in the group's postcondition.
>> - the combination void/alias do make sense - and I persist in that I
>> think it should be called "hidden" :)
>
> not sure I grok that. How does it make sense if you're only permitted to
> use aliases in the postcondition/layout? void in a layout maybe, but
> combined with alias? How would you use that? Are you suggesting that we
> can declare aliases in the layout too? IMO, that would put us back to
> the unclean more procedural approach again.
>
The need is there if a void part is referenced in a part group, and an
assertion is wanted to make sure the evaluation of that part had the
desired effect and that the assert needs access to the content of the
result of that particular evaluation (unless there is another way of
finding the exact same result).
The same is true in actions, since expressions would be allowed in
layouts. A part is stated in the action's group to get it evaluated, it
is marked void since the action should not see it. An expression in the
layout directs what should happen to it, and where in the result it
should be placed.
The alternative would be to have an extra action that returns an empty
path group vector, but that sets annotations that the receiver of the
empty path group vector can make use of.
>> - If an action does not have an actor, the layout is simply constructed
>> out of expr statements (some default Actor is used behind the scenes to
>> answer questions about 'uptodate' state and similar Actor duties).
>>
> How can something behind the scenes predict a sane default for what an
> arbitrary expression is doing? I think you need the full actor semantics
> and declare that explicitly.
>
What are the responsibilities of the actor besides: ?
- transforming input to output (in a context)
- reporting if the output is "uptodate" wrt. the input (and context)
A declaration of an "up to date" policy would be needed. Which is needed
with many actors as well - I said I wanted to push this to the actor
because in some cases (well written and special purpose actors) would
know if a result is up to date based on the input. But some actors may
not have a clue - say an actor that can execute shell scripts. It can
not know what the action it is invoking is doing. Something else must
declare the uptodate policy - even if it is the Actors duty to act on
the declaration.
Using expr to construct the layout is therefore no different. It is just
a mechanism to avoid having to write an ANT script, or a new actor in
order to do some typical/frequent/wanted processing (include/exclude
filtering, union, intersection, copy, replace a file built the default
way with a specially processed file, etc.)
What I am suggesting is that a handful of operations on String, Path,
Part, and Unit are part of the model, and these expressions/calls are
just as "declarative" as the rest of the model... only that it is
natural to state them as expressions e.g.
Part:union(...a,b):include(pattern="^org.myorg*");
As opposed to declaring something like:
private actor union_a_b Actor PartUnionProcessor() {
group{ a; b; }
layout { processed/union_a_b/; }
}
private actor includeMyOrg_a_b Actor PartIncludeProcessor() {
group { union_a_b; }
layout { processed/includeMyOrg_a_b/; }
}
Stating the above differently: There are certain executable features in
the b3 model that are accessible from the b3 file. (We discussed having
the things like Part, Path, String be extensible, but that is not really
required, we can control and define exactly what is available in the model).
Actually, I think I was wrong before in stating that expr's alone in the
action's layout would be enough. There is nothing stating what should
actually happen with the result. My example implied a copy, but that was
not stated - the expr just results in paths, parts, etc. In order to
make it work, declaring that a Copy actor should to the work would be
required.
>> (And now, I am very tempted to provide the ability to do some procedural
>> programming in the action without having to plug in an actor, but it
>> something we can skip for the time being. )
>>
> JavaScript anyone? Rhino is actually part of Java 1.6 now:
> http://java.sun.com/javase/6/docs/technotes/guides/scripting /index.html
>
> Actually, I think we need something like that. I also think that once we
> have it, we will see that the need for more advanced expressions in the
> rest of the declaration will be more or less eliminated and we get a
> much clearer separation between the build model and the actors that do
> the real work.
>
Agree to that. We should not invent a new GPL. I also don't think we
should include the actual script text in the b3 file. Instead there
could be a JavaScript Actor, a Python actor, etc. using the JSR 233
mechanism to communicate with the scripting environment. This way, it is
up to the users of b3 to decide what they want to use for writing actors
(java, Javascript or something else).
From b3's perspective the Actor is a leaf declaration that means "I
want x to happen - don't know how X is done".
The issues with including the scripting code in the b3 file is naturally
that b3 would have to understand it or treat it as "just text". I think
neither is very good - better to push it off and let regular tooling for
the specific language deal with the actor code.
- henrik
|
|
|
| Re: better term than "void" wanted [message #582910 is a reply to message #492130] |
Mon, 19 October 2009 07:17 |
|
Hi Henrik,
I have a different perspective regarding scripting. Probably because one major source of irritation when looking at
cspecs is that you just have to look at other files (ant-scripts) as well in order to understand it. I realize that
there would be some difficulties in parsing but I still think it would be terrific if we could:
1. Decide that b3 indeed does support JavaScript.
2. Make the parser understand JavaScript.
Another reason include getting rid of non-boolean expressions so that we have a clean declarative language. More on that
in comments inline.
>>> I am rethinking everything again :) and propose that my original example
>>> should be written:
>>>
>>> group xyz {
>>> { x/x/x; processedY; z/z/z; } with { properties{c='c';} };
>>> }
>>> private action processedY {
>>> group { y = y/y/y with ( properties {d='d';}; }
>>> layout { expr Part(y):processed(); }
>>> }
>>>
Let's assume we have JavaScript:
group xyz {
{ x/x/x; processedY; z/z/z; } with { properties{c='c';} };
}
private action processedY { // No actor declared means default = JavaScript
group { y = y/y/y } with { properties { d = 'd'; } }
script { return y.processed(); } // Not sure 'script' is the best term here.
}
>>> - the combination void/alias do make sense - and I persist in that I
>>> think it should be called "hidden" :)
>>
>> not sure I grok that. How does it make sense if you're only permitted to
>> use aliases in the postcondition/layout? void in a layout maybe, but
>> combined with alias? How would you use that? Are you suggesting that we
>> can declare aliases in the layout too? IMO, that would put us back to
>> the unclean more procedural approach again.
>>
> The need is there if a void part is referenced in a part group, and an
> assertion is wanted to make sure the evaluation of that part had the
> desired effect and that the assert needs access to the content of the
> result of that particular evaluation (unless there is another way of
> finding the exact same result).
>
> The same is true in actions, since expressions would be allowed in
> layouts. A part is stated in the action's group to get it evaluated, it
> is marked void since the action should not see it. An expression in the
> layout directs what should happen to it, and where in the result it
> should be placed.
>
> The alternative would be to have an extra action that returns an empty
> path group vector, but that sets annotations that the receiver of the
> empty path group vector can make use of.
>
Another alternative:
action x {
group { a = { xxx }; b = { yyy } }
postcondition { // something that involves b }
script { return a; }
}
which is equivalent to:
group x {
group { a = { xxx }; hidden b = { yyy } }
postcondition { // something that involves b }
}
>> How can something behind the scenes predict a sane default for what an
>> arbitrary expression is doing? I think you need the full actor semantics
>> and declare that explicitly.
>>
> What are the responsibilities of the actor besides: ?
> - transforming input to output (in a context)
> - reporting if the output is "uptodate" wrt. the input (and context)
>
> A declaration of an "up to date" policy would be needed. Which is needed
> with many actors as well
>
Are you suggesting that groups need up-to-date policies? I was under the impression that a group was an aggregation of
things that had already been declared. Nothing more.
> - I said I wanted to push this to the actor
> because in some cases (well written and special purpose actors) would
> know if a result is up to date based on the input. But some actors may
> not have a clue - say an actor that can execute shell scripts. It can
> not know what the action it is invoking is doing. Something else must
> declare the uptodate policy - even if it is the Actors duty to act on
> the declaration.
>
> Using expr to construct the layout is therefore no different. It is just
> a mechanism to avoid having to write an ANT script, or a new actor in
> order to do some typical/frequent/wanted processing (include/exclude
> filtering, union, intersection, copy, replace a file built the default
> way with a specially processed file, etc.)
>
> What I am suggesting is that a handful of operations on String, Path,
> Part, and Unit are part of the model, and these expressions/calls are
> just as "declarative" as the rest of the model... only that it is
> natural to state them as expressions e.g.
>
> Part:union(...a,b):include(pattern="^org.myorg*");
>
> As opposed to declaring something like:
>
> private actor union_a_b Actor PartUnionProcessor() {
> group{ a; b; }
> layout { processed/union_a_b/; }
> }
> private actor includeMyOrg_a_b Actor PartIncludeProcessor() {
> group { union_a_b; }
> layout { processed/includeMyOrg_a_b/; }
> }
>
> Stating the above differently: There are certain executable features in
> the b3 model that are accessible from the b3 file. (We discussed having
> the things like Part, Path, String be extensible, but that is not really
> required, we can control and define exactly what is available in the
> model).
>
> Actually, I think I was wrong before in stating that expr's alone in the
> action's layout would be enough. There is nothing stating what should
> actually happen with the result. My example implied a copy, but that was
> not stated - the expr just results in paths, parts, etc. In order to
> make it work, declaring that a Copy actor should to the work would be
> required.
>
I think that is taking things in the wrong direction. The declaration gets fuzzy and hard to maintain. Your example can
be written:
action foo {
group { a = ...; b = ...; }
script { return a.union(b).include("^org.myorg*") }
}
I don't consider the group a place to execute things (declarative in nature or not). It's merely an aggregation of
things that are already declared. If you want to perform something with that, then an action should be used. Always.
That's why the distinction was put there in the fist place.
I'm fine with that boolean filters can use a generic expression language in a group ('when' expressions), but I'm very
reluctant to take the evaluation power beyond that. It just obstructs/complicates the whole model. Using expressions to
produce new parts in a group is not a good thing IMO.
You advocate 'declarative calls/expressions', but what you are actually suggesting is an extendable mechanism that can
be made to perform just about anything. If it was just declarative, then we would add the declarations to the model
itself but we can't do that because we cannot really predict what it is that we want. IMO, we then have an actor and the
only problem is that it's too cumbersome to write one.
So, the Axiom could be:
If it's declarative, then the DSL syntax should support it. 'intersect' and 'union' could be considered for instance.
If we don't want the syntax support, then it should go into an actor.
> ... From b3's perspective the Actor is a leaf declaration that means "I
> want x to happen - don't know how X is done".
>
That was one of the ideas with Buckminster too. That, IMO unfortunate decision, has been our primary source of
fragmentation ever since and is also the primary source of obfuscation. It is difficult on the verge to impossible to
follow what a CSPEC is all about. It's hard to get an overview and see what values goes where and how they are acted
upon. You always need additional artifacts.
> The issues with including the scripting code in the b3 file is naturally
> that b3 would have to understand it or treat it as "just text". I think
> neither is very good - better to push it off and let regular tooling for
> the specific language deal with the actor code.
>
Is JavaScript really that different from the rest? I would have thought that our parser could be made to understand JS.
At least well enough to collect it in a syntax tree and then pass it off to Rhino for real validation.
- thomas
|
|
| | |
| Re: better term than "void" wanted [message #582964 is a reply to message #492154] |
Mon, 19 October 2009 12:34 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
On 10/19/09 9:17 AM, Thomas Hallgren wrote:
> Hi Henrik,
> I have a different perspective regarding scripting. Probably because one
> major source of irritation when looking at cspecs is that you just have
> to look at other files (ant-scripts) as well in order to understand it.
> I realize that there would be some difficulties in parsing but I still
> think it would be terrific if we could:
>
> 1. Decide that b3 indeed does support JavaScript.
> 2. Make the parser understand JavaScript.
>
> Another reason include getting rid of non-boolean expressions so that we
> have a clean declarative language. More on that in comments inline.
>
Agree. I want to get rid of the requirement that for every thing you
want to do, you have to write yet another file. That sucks.
I would need to change a couple of things in the syntax to make it
comply with JS. JS, just as b3 allows members/features to have funny
names. In JS the syntax is xxx['funny name'], where we choose to use
xxx."funny name". b3 uses ":" instead of "." - to comply with JS this
also means that a name with a period "." needs to be handled as a funny
name.
Other than that, there should not be difficult to add the JS
complementary syntax to the parser.
It makes constructing the debugger a bit more interesting, but also more
valuable, as you need to be able to step through the JS logic in a JS actor.
>>>> I am rethinking everything again :) and propose that my original
>>>> example
>>>> should be written:
>>>>
>>>> group xyz {
>>>> { x/x/x; processedY; z/z/z; } with { properties{c='c';} };
>>>> }
>>>> private action processedY {
>>>> group { y = y/y/y with ( properties {d='d';}; }
>>>> layout { expr Part(y):processed(); }
>>>> }
>>>>
> Let's assume we have JavaScript:
>
> group xyz {
> { x/x/x; processedY; z/z/z; } with { properties{c='c';} };
> }
>
> private action processedY { // No actor declared means default = JavaScript
> group { y = y/y/y } with { properties { d = 'd'; } }
> script { return y.processed(); } // Not sure 'script' is the best term
> here.
> }
>
Agree - the actor body is embedded. We probably want to have the JS be
an implementation of the Actor interface. This way, it is possible to
implement also the uptodate policy method, and whatever else needs to be
handled. Maybe we want to expose those methods in b3 - as opposed to
having one script where 'this' is used and the developer has to add the
method definitions. (Let's discuss that in a separate thread...)
>>>> - the combination void/alias do make sense - and I persist in that I
>>>> think it should be called "hidden" :)
> Another alternative:
>
> action x {
> group { a = { xxx }; b = { yyy } }
> postcondition { // something that involves b }
> script { return a; }
> }
>
> which is equivalent to:
>
> group x {
> group { a = { xxx }; hidden b = { yyy } }
> postcondition { // something that involves b }
> }
>
That is fine, when the script is explicit 'hidden' is not needed, the
script can just pick what it needs. The only time hidden is needed is
when an external Actor is used, and its API uses the entire group.
The same is also true in a part group (i.e. not an action), where the
postcondition needs access to a hidden/void part.
>>> How can something behind the scenes predict a sane default for what an
>>> arbitrary expression is doing? I think you need the full actor semantics
>>> and declare that explicitly.
>>>
>> What are the responsibilities of the actor besides: ?
>> - transforming input to output (in a context)
>> - reporting if the output is "uptodate" wrt. the input (and context)
>>
>> A declaration of an "up to date" policy would be needed. Which is needed
>> with many actors as well
> >
> Are you suggesting that groups need up-to-date policies? I was under the
> impression that a group was an aggregation of things that had already
> been declared. Nothing more.
>
No, I am suggesting that an action needs an uptodate policy.
The keyword group is used both for a "part group", and for the action's
"input group", and the syntax inside a group should preferably be the
same in both cases.
The action needs the uptodate policy as its output is not the same as
its input...
> Your example can be written:
> action foo {
> group { a = ...; b = ...; }
> script { return a.union(b).include("^org.myorg*") }
> }
>
I like that. When using a script, it is clear that it returns something
that has the correct return type.
For external actors it is different. But for those, any processing can
be done in another action that is used as input to the action with the
external actor. Likewise if processing is needed after the external
actor has done its job.
I think I would prefer if the syntax stated that an actor or a script
could be used. The declaration in the action's preamble is still valid,
as it declares the actor class, and initialization (although that could
be moved into the body).
I can also imagine that one Actor class has several methods, so you want
to pick one of them.
i.e. something like
'script' '{' js-statements* '}' | 'actor' ':' method=ID
> I don't consider the group a place to execute things (declarative in
> nature or not). It's merely an aggregation of things that are already
> declared. If you want to perform something with that, then an action
> should be used. Always. That's why the distinction was put there in the
> fist place.
>
This is a confusion over group being both a "part group" and an "input
group". The suggestion was not to have expr in group's at all but to put
them in the layout.
> I'm fine with that boolean filters can use a generic expression language
> in a group ('when' expressions), but I'm very reluctant to take the
> evaluation power beyond that. It just obstructs/complicates the whole
> model. Using expressions to produce new parts in a group is not a good
> thing IMO.
>
Agree - that is why I said that they should be removed :)
> You advocate 'declarative calls/expressions', but what you are actually
> suggesting is an extendable mechanism that can be made to perform just
> about anything. If it was just declarative, then we would add the
> declarations to the model itself but we can't do that because we cannot
> really predict what it is that we want. IMO, we then have an actor and
> the only problem is that it's too cumbersome to write one.
>
I am advocating them in artifacts, and layout. Not in groups.
Scripts in actors removes the need to have them in layout.
> So, the Axiom could be:
> If it's declarative, then the DSL syntax should support it. 'intersect'
> and 'union' could be considered for instance.
> If we don't want the syntax support, then it should go into an actor.
>
Although it looks "sexy" to support set operations in group syntax. I
think that is not used that often, and could just as well be used in an
action as it is easy to specify using scripting.
>> ... From b3's perspective the Actor is a leaf declaration that means "I
>> want x to happen - don't know how X is done".
>>
> That was one of the ideas with Buckminster too. That, IMO unfortunate
> decision, has been our primary source of fragmentation ever since and is
> also the primary source of obfuscation. It is difficult on the verge to
> impossible to follow what a CSPEC is all about. It's hard to get an
> overview and see what values goes where and how they are acted upon. You
> always need additional artifacts.
>
BRANCH ON $B AND COMEFROM $A;
I want to get rid of all of those issues as much as possible.
- b3 should have the power to express most operations
- no magic "input" and "output"
As a consequence. Look at use of an external Actor compared to a script.
Why not declare what should be sent to the actor as named parameters. I
think that would help reduce the confusion.
> Is JavaScript really that different from the rest? I would have thought
> that our parser could be made to understand JS. At least well enough to
> collect it in a syntax tree and then pass it off to Rhino for real
> validation.
Have to take a look at JS again, you may be right. There are some
implications on the rest of the syntax thought (as I noted earlier). I
think we should strive to have the same syntax everywhere for common
concepts.
- henrik
|
|
|
Goto Forum:
Current Time: Fri Apr 26 00:13:00 GMT 2024
Powered by FUDForum. Page generated in 0.06687 seconds |
] 
Search
Help
Register
Login
Home
