Home » Archived » B3 » repository syntax
| repository syntax [message #534519] |
Wed, 19 May 2010 12:08  |
 Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
Have worked on the syntax of repository declaration. When Thomas and I
reviewed the original proposal, it became apparent that the various
initialization elements did not follow a common set of easily deductible
rules (it was more like "make it really easy to write what is most common").
So, I played around with some rules, the idea we had during the review was:
- Use ':' instead of '='
- Use ': singleValue' for single values
- Use '[ value, value]' for list
- Use '{ ... }' for compound
Sample
------
repositories {
cvs my_cvs_3 {
connection : "http://abc.org" ;
branches [
aBranchCalledWanda,
main {
timestamp : "20100516213854+0200";
update-policy : no-update;
include [ "some/path/or.complex.name",
"some/path/or.complex.name",
aName ];
exclude [ ~/.*/ ,
~/.*/,
my_name.exactly,
"some/path/or.complex.name"]; }
];
}
}
Having rewritten some of the previous syntax into this, I found several
things that I did not like - so here is take 2:
Take 2
------
- no grouping "repositories", just state them one after another, the
order is not important anyway.
- use more keywords (having a list of predicates where the
differentiator is if it is a regexp or not is not very readable (and
prevents the use of SimplePattern).
- instead of list with just "," between elements, repeat the keyword
(much easier to read, esp. when list is longer and elements are not uniform)
- Assignment (with ':' or '=') is unnecessary and mostly clutters the
specification. I found this to be quite irritating when using code
completion (an extra step always required before fully understanding
what the keyword stands for.
- each 'statement' ends with ';' for elements that have a single value,
and with '}' when a block is/can used. I.e. when a block can be used but
nothing is specified, the element ends with '{}' I think this is clearer
as it indicates that there is potentially more stuff, and since it is
empty there are some additional defaults. I think this is a good hint.
repository cvs my_cvs_4 {
connection "http://abc.org" ;
branch aBranchCalledWanda { }
branch aBranchAlsoCalledWanda { }
branch main {
timestamp "20100516213854+0200";
update-policy no-update;
include {
name "some/path/or.complex.name" ;
name aName ;
pattern "*.middle.*" ;
}
exclude {
pattern ~/.*apa/ ;
pattern ~/.*bepa/ ;
name aBadName;
}
}
I think is is more readable, esp, when there is no syntax coloring to
aid the reader.
Regards
- henrik
|
|
|
| Re: repository syntax [message #534548 is a reply to message #534519] |
Wed, 19 May 2010 11:13  |
|
On 2010-05-19 14:08, Henrik Lindberg wrote:
> repository cvs my_cvs_4 {
> connection "http://abc.org" ;
> branch aBranchCalledWanda { }
> branch aBranchAlsoCalledWanda { }
> branch main {
> timestamp "20100516213854+0200";
> update-policy no-update;
> include {
> name "some/path/or.complex.name" ;
> name aName ;
> pattern "*.middle.*" ;
> }
> exclude {
> pattern ~/.*apa/ ;
> pattern ~/.*bepa/ ;
> name aBadName;
> }
> }
>
What happens if I write:
repository cvs my_cvs_4 {
branch aBranchCalledWanda { }
connection "http://abc.org" ;
branch aBranchAlsoCalledWanda { }
?
IMO, if you don't use a list for the branches, it becomes less clear
that the order actually matters. If it matters, then does it also matter
if I write branches before connection? If not, then the ordering is
inconsistent.
- thomas
|
|
|
| Re: repository syntax [message #534549 is a reply to message #534548] |
Wed, 19 May 2010 13:32 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
The syntax is (currently):
Repository returns build::Repository : {build::Repository}
(documentation = DOCUMENTATION)?
"repository" handlerType = ID name = ID '{'
("connection" address = STRING ';')?
(options += RepoOption)*
(branches += Branch)*
'}'
;
Connection comes first since it is almost always required (the only
exception would be some internal repository like "workspace" or
"execution stack" so I left it optional).
It is also needed to properly validate other things (at least some
advanced options where the options are valid or not depending on what
the connection address looks like.
As you point out, the order of the branches are important, and I
therefore placed them last. I could wrap them in a "branches { }" if you
think that makes it clearer that the order matters. Only downside is if
a single branch is required:
branches { branch { } }
Wrapping the in a block gives an opportunity to state that it is
actually a search as opposed to a mere declaration of existence of a branch.
Something like:
search-branches { branch ...}
- henrik
On 5/19/10 1:13 PM, Thomas Hallgren wrote:
> On 2010-05-19 14:08, Henrik Lindberg wrote:
>> repository cvs my_cvs_4 {
>> connection "http://abc.org" ;
>> branch aBranchCalledWanda { }
>> branch aBranchAlsoCalledWanda { }
>> branch main {
>> timestamp "20100516213854+0200";
>> update-policy no-update;
>> include {
>> name "some/path/or.complex.name" ;
>> name aName ;
>> pattern "*.middle.*" ;
>> }
>> exclude {
>> pattern ~/.*apa/ ;
>> pattern ~/.*bepa/ ;
>> name aBadName;
>> }
>> }
>>
> What happens if I write:
>
> repository cvs my_cvs_4 {
> branch aBranchCalledWanda { }
> connection "http://abc.org" ;
> branch aBranchAlsoCalledWanda { }
>
> ?
As noted above, this is not allowed, all branches are placed last.
>
> IMO, if you don't use a list for the branches, it becomes less clear
> that the order actually matters. If it matters, then does it also matter
> if I write branches before connection? If not, then the ordering is
> inconsistent.
>
> - thomas
|
|
|
| Re: repository syntax [message #534560 is a reply to message #534549] |
Wed, 19 May 2010 14:03 |
|
I still think it's a bit inconsistent. You remove 'repositories' since order doesn't matter. For 'branches' though, it
indeed does matter. I'm not in favor of repeating the 'branch'. It's more to type and the syntax is more unclear. The
argument about more to type is true for 'repositories' as well as soon as you have more then one.
- thomas
On 05/19/2010 03:32 PM, Henrik Lindberg wrote:
> The syntax is (currently):
>
> Repository returns build::Repository : {build::Repository}
> (documentation = DOCUMENTATION)?
> "repository" handlerType = ID name = ID '{'
> ("connection" address = STRING ';')?
> (options += RepoOption)*
> (branches += Branch)*
> '}'
> ;
>
> Connection comes first since it is almost always required (the only
> exception would be some internal repository like "workspace" or
> "execution stack" so I left it optional).
> It is also needed to properly validate other things (at least some
> advanced options where the options are valid or not depending on what
> the connection address looks like.
>
> As you point out, the order of the branches are important, and I
> therefore placed them last. I could wrap them in a "branches { }" if you
> think that makes it clearer that the order matters. Only downside is if
> a single branch is required:
>
> branches { branch { } }
>
> Wrapping the in a block gives an opportunity to state that it is
> actually a search as opposed to a mere declaration of existence of a
> branch.
>
> Something like:
>
> search-branches { branch ...}
>
>
> - henrik
>
> On 5/19/10 1:13 PM, Thomas Hallgren wrote:
>> On 2010-05-19 14:08, Henrik Lindberg wrote:
>>> repository cvs my_cvs_4 {
>>> connection "http://abc.org" ;
>>> branch aBranchCalledWanda { }
>>> branch aBranchAlsoCalledWanda { }
>>> branch main {
>>> timestamp "20100516213854+0200";
>>> update-policy no-update;
>>> include {
>>> name "some/path/or.complex.name" ;
>>> name aName ;
>>> pattern "*.middle.*" ;
>>> }
>>> exclude {
>>> pattern ~/.*apa/ ;
>>> pattern ~/.*bepa/ ;
>>> name aBadName;
>>> }
>>> }
>>>
>> What happens if I write:
>>
>> repository cvs my_cvs_4 {
>> branch aBranchCalledWanda { }
>> connection "http://abc.org" ;
>> branch aBranchAlsoCalledWanda { }
>>
>> ?
> As noted above, this is not allowed, all branches are placed last.
>
>>
>> IMO, if you don't use a list for the branches, it becomes less clear
>> that the order actually matters. If it matters, then does it also matter
>> if I write branches before connection? If not, then the ordering is
>> inconsistent.
>>
>> - thomas
>
|
|
|
| Re: repository syntax [message #534561 is a reply to message #534560] |
Wed, 19 May 2010 14:17 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
On 5/19/10 4:03 PM, Thomas Hallgren wrote:
> I still think it's a bit inconsistent. You remove 'repositories' since
> order doesn't matter. For 'branches' though, it indeed does matter. I'm
> not in favor of repeating the 'branch'. It's more to type and the syntax
> is more unclear. The argument about more to type is true for
> 'repositories' as well as soon as you have more then one.
>
uh,
I think it should be like this:
Repository returns build::Repository : {build::Repository}
(documentation = DOCUMENTATION)?
"repository" handlerType = ID name = ID '{'
("connection" address = STRING ';')?
(options += RepoOption)*
("search-branches" '{' (branches += Branch)* '}')
'}'
;
i.e. I agree with you about branches being in a separate block. The note
about "more to type" was the only downside I could think of, but I don't
think it matters, when someone are writing a b3 script I expect
judicious use of content-assist anyway...
I can relax the order of options and branches if you think it is of
value, but I think I want to keep the connection first.
- henrik
> - thomas
>
> On 05/19/2010 03:32 PM, Henrik Lindberg wrote:
>> The syntax is (currently):
>>
>> Repository returns build::Repository : {build::Repository}
>> (documentation = DOCUMENTATION)?
>> "repository" handlerType = ID name = ID '{'
>> ("connection" address = STRING ';')?
>> (options += RepoOption)*
>> (branches += Branch)*
>> '}'
>> ;
>>
>> Connection comes first since it is almost always required (the only
>> exception would be some internal repository like "workspace" or
>> "execution stack" so I left it optional).
>> It is also needed to properly validate other things (at least some
>> advanced options where the options are valid or not depending on what
>> the connection address looks like.
>>
>> As you point out, the order of the branches are important, and I
>> therefore placed them last. I could wrap them in a "branches { }" if you
>> think that makes it clearer that the order matters. Only downside is if
>> a single branch is required:
>>
>> branches { branch { } }
>>
>> Wrapping the in a block gives an opportunity to state that it is
>> actually a search as opposed to a mere declaration of existence of a
>> branch.
>>
>> Something like:
>>
>> search-branches { branch ...}
>>
>>
>> - henrik
>>
>> On 5/19/10 1:13 PM, Thomas Hallgren wrote:
>>> On 2010-05-19 14:08, Henrik Lindberg wrote:
>>>> repository cvs my_cvs_4 {
>>>> connection "http://abc.org" ;
>>>> branch aBranchCalledWanda { }
>>>> branch aBranchAlsoCalledWanda { }
>>>> branch main {
>>>> timestamp "20100516213854+0200";
>>>> update-policy no-update;
>>>> include {
>>>> name "some/path/or.complex.name" ;
>>>> name aName ;
>>>> pattern "*.middle.*" ;
>>>> }
>>>> exclude {
>>>> pattern ~/.*apa/ ;
>>>> pattern ~/.*bepa/ ;
>>>> name aBadName;
>>>> }
>>>> }
>>>>
>>> What happens if I write:
>>>
>>> repository cvs my_cvs_4 {
>>> branch aBranchCalledWanda { }
>>> connection "http://abc.org" ;
>>> branch aBranchAlsoCalledWanda { }
>>>
>>> ?
>> As noted above, this is not allowed, all branches are placed last.
>>
>>>
>>> IMO, if you don't use a list for the branches, it becomes less clear
>>> that the order actually matters. If it matters, then does it also matter
>>> if I write branches before connection? If not, then the ordering is
>>> inconsistent.
>>>
>>> - thomas
>>
>
|
|
|
| Re: repository syntax [message #534584 is a reply to message #534561] |
Wed, 19 May 2010 15:21 |
|
What I meant with more to typing was the difference between:
repositories {
xxx;
yyy;
zzz;
}
and:
repository xxx;
repository yyy;
repository zzz;
I liked the fact that they were grouped together into one list element, regardless of if the order has significance or
not. I also think that
search-branches : [ x, y, z ];
is different from:
search-branches { x; y; z; }
in that the former clearly declares a named ordered list of things whereas the latter comes through more as type
declaration that isn't attached to anything.
I would feel much more at home if we used:
type { a:v; b:v; c:v; }
as a definition of a anonymous structure of 'type' with the members 'a', 'b', and 'c'. whereas:
[ a, b, c, ]
declares an anonymous list of things. Naming is then done with:
name : [ a, b, c, ];
or
name : type { a : v; b : v; c : v; };
(which is consistent with the structure members so it can be applied recursively).
Apply this to your initial example:
repositories : [
cvs {
id : my_cvs_3;
connection : "http://abc.org" ;
branches [
aBranchCalledWanda,
main {
timestamp : "20100516213854+0200";
update-policy : no-update;
include : [
"some/path/or.complex.name",
"some/path/or.complex.name",
aName
];
exclude : [
~/.*/ ,
~/.*/,
my_name.exactly,
"some/path/or.complex.name"
];
}
];
}
];
I would also assume that member names are unique within a structure (I'm not fond of implicitly creating list when
members are repeated, would much rather see a 'member already defined' syntax error). So if we were to change the
'exclude', then this would not work:
include {
name "some/path/or.complex.name" ;
name aName ;
pattern "*.middle.*" ;
}
exclude {
pattern ~/.*apa/ ;
pattern ~/.*bepa/ ;
name aBadName;
}
this however would:
include : match {
names [ "some/path/or.complex.name", aName ];
patterns [ ~/.*middle.*/ ];
};
exclude : match {
patterns [ ~/.*apa/, ~/.*bepa/ ];
names [ aBadName ];
};
- thomas
|
|
|
| Re: repository syntax [message #534591 is a reply to message #534584] |
Wed, 19 May 2010 15:38 |
|
The example was a bit inconsistent. Here's another try:
repositories : [
cvs {
id : my_cvs_3;
connection : "http://abc.org" ;
branches : [
branch { id : aBranchCalledWanda },
branch {
id : main;
timestamp : "20100516213854+0200";
update-policy : no-update;
include : [
"some/path/or.complex.name",
"some/path/or.complex.name",
aName
];
exclude : [
~/.*/ ,
~/.*/,
my_name.exactly,
"some/path/or.complex.name"
];
}
];
}
];
syntax can the be improved further by allowing an alternative syntax for
type {
id : name
...
}
as:
type name {
...
}
repositories : [
cvs my_cvs_3 {
connection : "http://abc.org" ;
branches : [
branch aBranchCalledWanda {},
branch main {
timestamp : "20100516213854+0200";
update-policy : no-update;
include : [
"some/path/or.complex.name",
"some/path/or.complex.name",
aName
];
exclude : [
~/.*/ ,
~/.*/,
my_name.exactly,
"some/path/or.complex.name"
];
}
];
}
];
which is fairly similar to the initial example. There are some subtle differences to make the syntax consistent.
- thomas
On 05/19/2010 05:21 PM, Thomas Hallgren wrote:
> What I meant with more to typing was the difference between:
>
> repositories {
> xxx;
> yyy;
> zzz;
> }
>
> and:
>
> repository xxx;
> repository yyy;
> repository zzz;
>
> I liked the fact that they were grouped together into one list element,
> regardless of if the order has significance or not. I also think that
>
> search-branches : [ x, y, z ];
>
> is different from:
>
> search-branches { x; y; z; }
>
> in that the former clearly declares a named ordered list of things
> whereas the latter comes through more as type declaration that isn't
> attached to anything.
>
> I would feel much more at home if we used:
>
> type { a:v; b:v; c:v; }
>
> as a definition of a anonymous structure of 'type' with the members 'a',
> 'b', and 'c'. whereas:
>
> [ a, b, c, ]
>
> declares an anonymous list of things. Naming is then done with:
>
> name : [ a, b, c, ];
>
> or
>
> name : type { a : v; b : v; c : v; };
>
> (which is consistent with the structure members so it can be applied
> recursively).
>
>
> Apply this to your initial example:
>
> repositories : [
> cvs {
> id : my_cvs_3;
> connection : "http://abc.org" ;
> branches [
> aBranchCalledWanda,
> main {
> timestamp : "20100516213854+0200";
> update-policy : no-update;
> include : [
> "some/path/or.complex.name",
> "some/path/or.complex.name",
> aName
> ];
> exclude : [
> ~/.*/ ,
> ~/.*/,
> my_name.exactly,
> "some/path/or.complex.name"
> ];
> }
> ];
> }
> ];
>
> I would also assume that member names are unique within a structure (I'm
> not fond of implicitly creating list when members are repeated, would
> much rather see a 'member already defined' syntax error). So if we were
> to change the 'exclude', then this would not work:
>
> include {
> name "some/path/or.complex.name" ;
> name aName ;
> pattern "*.middle.*" ;
> }
> exclude {
> pattern ~/.*apa/ ;
> pattern ~/.*bepa/ ;
> name aBadName;
> }
>
> this however would:
>
>
> include : match {
> names [ "some/path/or.complex.name", aName ];
> patterns [ ~/.*middle.*/ ];
> };
>
> exclude : match {
> patterns [ ~/.*apa/, ~/.*bepa/ ];
> names [ aBadName ];
> };
>
> - thomas
|
|
|
| Re: repository syntax [message #534655 is a reply to message #534591] |
Wed, 19 May 2010 18:17 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
Your last suggestion is a clear improvement on what we came up with
during our meeting.
In addition, I would like to use the "names" and "patterns" as you
suggested.
I can try to implement that and see what it feels/looks like.
It still has the irritating "syntactical embelishments" that are not
required, and that only makes sense once you understand the difference,
I think people are confused over how to delimit things with even the
simplest syntax - so I wanted to avoid using anything but ; and {}
But, let's try it anyway... (I mean, I did like it when I came up with
the idea ;)
There is one ambiguity, but I think it only prevents short hand notation
- this is ambiguous:
something ':' Expression
something ':' '[' ExpressionList ']'
since an Expression in itself can be a list of some type. By not
allowing such constructs - i.e. something is a simple expression
(possibly a list of say integers), or a list with some special syntax.
- henrik
On 5/19/10 5:38 PM, Thomas Hallgren wrote:
> The example was a bit inconsistent. Here's another try:
>
> repositories : [
> cvs {
> id : my_cvs_3;
> connection : "http://abc.org" ;
> branches : [
> branch { id : aBranchCalledWanda },
> branch {
> id : main;
> timestamp : "20100516213854+0200";
> update-policy : no-update;
> include : [
> "some/path/or.complex.name",
> "some/path/or.complex.name",
> aName
> ];
> exclude : [
> ~/.*/ ,
> ~/.*/,
> my_name.exactly,
> "some/path/or.complex.name"
> ];
> }
> ];
> }
> ];
>
> syntax can the be improved further by allowing an alternative syntax for
>
> type {
> id : name
> ...
> }
>
> as:
>
> type name {
> ...
> }
>
> repositories : [
> cvs my_cvs_3 {
> connection : "http://abc.org" ;
> branches : [
> branch aBranchCalledWanda {},
> branch main {
> timestamp : "20100516213854+0200";
> update-policy : no-update;
> include : [
> "some/path/or.complex.name",
> "some/path/or.complex.name",
> aName
> ];
> exclude : [
> ~/.*/ ,
> ~/.*/,
> my_name.exactly,
> "some/path/or.complex.name"
> ];
> }
> ];
> }
> ];
>
> which is fairly similar to the initial example. There are some subtle
> differences to make the syntax consistent.
>
> - thomas
>
>
> On 05/19/2010 05:21 PM, Thomas Hallgren wrote:
>> What I meant with more to typing was the difference between:
>>
>> repositories {
>> xxx;
>> yyy;
>> zzz;
>> }
>>
>> and:
>>
>> repository xxx;
>> repository yyy;
>> repository zzz;
>>
>> I liked the fact that they were grouped together into one list element,
>> regardless of if the order has significance or not. I also think that
>>
>> search-branches : [ x, y, z ];
>>
>> is different from:
>>
>> search-branches { x; y; z; }
>>
>> in that the former clearly declares a named ordered list of things
>> whereas the latter comes through more as type declaration that isn't
>> attached to anything.
>>
>> I would feel much more at home if we used:
>>
>> type { a:v; b:v; c:v; }
>>
>> as a definition of a anonymous structure of 'type' with the members 'a',
>> 'b', and 'c'. whereas:
>>
>> [ a, b, c, ]
>>
>> declares an anonymous list of things. Naming is then done with:
>>
>> name : [ a, b, c, ];
>>
>> or
>>
>> name : type { a : v; b : v; c : v; };
>>
>> (which is consistent with the structure members so it can be applied
>> recursively).
>>
>>
>> Apply this to your initial example:
>>
>> repositories : [
>> cvs {
>> id : my_cvs_3;
>> connection : "http://abc.org" ;
>> branches [
>> aBranchCalledWanda,
>> main {
>> timestamp : "20100516213854+0200";
>> update-policy : no-update;
>> include : [
>> "some/path/or.complex.name",
>> "some/path/or.complex.name",
>> aName
>> ];
>> exclude : [
>> ~/.*/ ,
>> ~/.*/,
>> my_name.exactly,
>> "some/path/or.complex.name"
>> ];
>> }
>> ];
>> }
>> ];
>>
>> I would also assume that member names are unique within a structure (I'm
>> not fond of implicitly creating list when members are repeated, would
>> much rather see a 'member already defined' syntax error). So if we were
>> to change the 'exclude', then this would not work:
>>
>> include {
>> name "some/path/or.complex.name" ;
>> name aName ;
>> pattern "*.middle.*" ;
>> }
>> exclude {
>> pattern ~/.*apa/ ;
>> pattern ~/.*bepa/ ;
>> name aBadName;
>> }
>>
>> this however would:
>>
>>
>> include : match {
>> names [ "some/path/or.complex.name", aName ];
>> patterns [ ~/.*middle.*/ ];
>> };
>>
>> exclude : match {
>> patterns [ ~/.*apa/, ~/.*bepa/ ];
>> names [ aBadName ];
>> };
>>
>> - thomas
>
|
|
|
| Re: repository syntax [message #534962 is a reply to message #534655] |
Thu, 20 May 2010 19:45 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
Working on the syntax again using the latest ideas.
Here is how I just defined "repository"
Repository returns build::Repository : {build::Repository}
(documentation = DOCUMENTATION)?
"repository" handlerType = ID name = ID
((':' "connection" ':' address = STRING ';')
|('{'
("connection" ':' address = STRING ';')?
(options += RepoOption)*
("branches" ':' '[' (branches += Branch) (',' branches += Branch)* ']')?
'}')
)
;
This means that it is possible to use a short form for repositories
where all that is needed is the type, name and address. Like this:
repository p2 platformRepo : connection : "http://dev.myorg.com/repo1";
The rationale is that following a definition it is possible to specify
'one thing' after a ':', or multiple things enclosed in '{'. These are
equivalent:
repository p2 platformRepo : connection : "http://dev.myorg.com/repo1";
repository p2 platformRepo {
connection : "http://dev.myorg.com/repo1";
// ...
}
But the later allows specification of more things.
This is consistent with the rest of the syntax in b3 - compare with:
function square(a, b) : a * b;
function square(a, b) { a * b; }
function oneTwoThree() : [1, 2, 3];
function oneTwoThree : [1, 2, 3];
(Continuing with Branches now...)
Regards
- henrik
|
|
|
| Re: repository syntax [message #534967 is a reply to message #534962] |
Thu, 20 May 2010 19:58 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
I am changing the following:
address = STRING ';'
to
address = Expression ';'
so that it is possible to use properties etc.
I can still provide code completion and suggest a simple string address.
The only thing not possible to do at edit time is to validate the
repository options against the address if it is something else than a
literal string. One can imagine that a particular protocoll for a
particular repository type *may* want to do this, but it is however
possible to issue a warning (for those repository types that so
requires) that full validation is deferred until runtime (which by the
way is always the case wrt the address itself :))
- henrik
On 5/20/10 9:45 PM, Henrik Lindberg wrote:
> Working on the syntax again using the latest ideas.
> Here is how I just defined "repository"
>
> Repository returns build::Repository : {build::Repository}
> (documentation = DOCUMENTATION)?
> "repository" handlerType = ID name = ID
> ((':' "connection" ':' address = STRING ';')
> |('{'
> ("connection" ':' address = STRING ';')?
> (options += RepoOption)*
> ("branches" ':' '[' (branches += Branch) (',' branches += Branch)* ']')?
> '}')
> )
> ;
>
> This means that it is possible to use a short form for repositories
> where all that is needed is the type, name and address. Like this:
>
> repository p2 platformRepo : connection : "http://dev.myorg.com/repo1";
>
> The rationale is that following a definition it is possible to specify
> 'one thing' after a ':', or multiple things enclosed in '{'. These are
> equivalent:
>
> repository p2 platformRepo : connection : "http://dev.myorg.com/repo1";
> repository p2 platformRepo {
> connection : "http://dev.myorg.com/repo1";
> // ...
> }
>
> But the later allows specification of more things.
> This is consistent with the rest of the syntax in b3 - compare with:
>
> function square(a, b) : a * b;
> function square(a, b) { a * b; }
>
> function oneTwoThree() : [1, 2, 3];
> function oneTwoThree : [1, 2, 3];
>
> (Continuing with Branches now...)
> Regards
> - henrik
>
|
|
|
| Re: repository syntax [message #534971 is a reply to message #534967] |
Thu, 20 May 2010 20:30 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
And I missed a terminating ';' after branches : [ ]
- henrik
On 5/20/10 9:58 PM, Henrik Lindberg wrote:
> I am changing the following:
> address = STRING ';'
> to
> address = Expression ';'
>
> so that it is possible to use properties etc.
>
> I can still provide code completion and suggest a simple string address.
> The only thing not possible to do at edit time is to validate the
> repository options against the address if it is something else than a
> literal string. One can imagine that a particular protocoll for a
> particular repository type *may* want to do this, but it is however
> possible to issue a warning (for those repository types that so
> requires) that full validation is deferred until runtime (which by the
> way is always the case wrt the address itself :))
>
> - henrik
>
> On 5/20/10 9:45 PM, Henrik Lindberg wrote:
>> Working on the syntax again using the latest ideas.
>> Here is how I just defined "repository"
>>
>> Repository returns build::Repository : {build::Repository}
>> (documentation = DOCUMENTATION)?
>> "repository" handlerType = ID name = ID
>> ((':' "connection" ':' address = STRING ';')
>> |('{'
>> ("connection" ':' address = STRING ';')?
>> (options += RepoOption)*
>> ("branches" ':' '[' (branches += Branch) (',' branches += Branch)* ']')?
>> '}')
>> )
>> ;
>>
>> This means that it is possible to use a short form for repositories
>> where all that is needed is the type, name and address. Like this:
>>
>> repository p2 platformRepo : connection : "http://dev.myorg.com/repo1";
>>
>> The rationale is that following a definition it is possible to specify
>> 'one thing' after a ':', or multiple things enclosed in '{'. These are
>> equivalent:
>>
>> repository p2 platformRepo : connection : "http://dev.myorg.com/repo1";
>> repository p2 platformRepo {
>> connection : "http://dev.myorg.com/repo1";
>> // ...
>> }
>>
>> But the later allows specification of more things.
>> This is consistent with the rest of the syntax in b3 - compare with:
>>
>> function square(a, b) : a * b;
>> function square(a, b) { a * b; }
>>
>> function oneTwoThree() : [1, 2, 3];
>> function oneTwoThree : [1, 2, 3];
>>
>> (Continuing with Branches now...)
>> Regards
>> - henrik
>>
>
|
|
|
| Re: repository syntax [message #606993 is a reply to message #534519] |
Wed, 19 May 2010 11:13 |
|
On 2010-05-19 14:08, Henrik Lindberg wrote:
> repository cvs my_cvs_4 {
> connection "http://abc.org" ;
> branch aBranchCalledWanda { }
> branch aBranchAlsoCalledWanda { }
> branch main {
> timestamp "20100516213854+0200";
> update-policy no-update;
> include {
> name "some/path/or.complex.name" ;
> name aName ;
> pattern "*.middle.*" ;
> }
> exclude {
> pattern ~/.*apa/ ;
> pattern ~/.*bepa/ ;
> name aBadName;
> }
> }
>
What happens if I write:
repository cvs my_cvs_4 {
branch aBranchCalledWanda { }
connection "http://abc.org" ;
branch aBranchAlsoCalledWanda { }
?
IMO, if you don't use a list for the branches, it becomes less clear
that the order actually matters. If it matters, then does it also matter
if I write branches before connection? If not, then the ordering is
inconsistent.
- thomas
|
|
|
| Re: repository syntax [message #608069 is a reply to message #534548] |
Wed, 19 May 2010 13:32 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
The syntax is (currently):
Repository returns build::Repository : {build::Repository}
(documentation = DOCUMENTATION)?
"repository" handlerType = ID name = ID '{'
("connection" address = STRING ';')?
(options += RepoOption)*
(branches += Branch)*
'}'
;
Connection comes first since it is almost always required (the only
exception would be some internal repository like "workspace" or
"execution stack" so I left it optional).
It is also needed to properly validate other things (at least some
advanced options where the options are valid or not depending on what
the connection address looks like.
As you point out, the order of the branches are important, and I
therefore placed them last. I could wrap them in a "branches { }" if you
think that makes it clearer that the order matters. Only downside is if
a single branch is required:
branches { branch { } }
Wrapping the in a block gives an opportunity to state that it is
actually a search as opposed to a mere declaration of existence of a branch.
Something like:
search-branches { branch ...}
- henrik
On 5/19/10 1:13 PM, Thomas Hallgren wrote:
> On 2010-05-19 14:08, Henrik Lindberg wrote:
>> repository cvs my_cvs_4 {
>> connection "http://abc.org" ;
>> branch aBranchCalledWanda { }
>> branch aBranchAlsoCalledWanda { }
>> branch main {
>> timestamp "20100516213854+0200";
>> update-policy no-update;
>> include {
>> name "some/path/or.complex.name" ;
>> name aName ;
>> pattern "*.middle.*" ;
>> }
>> exclude {
>> pattern ~/.*apa/ ;
>> pattern ~/.*bepa/ ;
>> name aBadName;
>> }
>> }
>>
> What happens if I write:
>
> repository cvs my_cvs_4 {
> branch aBranchCalledWanda { }
> connection "http://abc.org" ;
> branch aBranchAlsoCalledWanda { }
>
> ?
As noted above, this is not allowed, all branches are placed last.
>
> IMO, if you don't use a list for the branches, it becomes less clear
> that the order actually matters. If it matters, then does it also matter
> if I write branches before connection? If not, then the ordering is
> inconsistent.
>
> - thomas
|
|
|
| Re: repository syntax [message #608070 is a reply to message #534549] |
Wed, 19 May 2010 14:03 |
|
I still think it's a bit inconsistent. You remove 'repositories' since order doesn't matter. For 'branches' though, it
indeed does matter. I'm not in favor of repeating the 'branch'. It's more to type and the syntax is more unclear. The
argument about more to type is true for 'repositories' as well as soon as you have more then one.
- thomas
On 05/19/2010 03:32 PM, Henrik Lindberg wrote:
> The syntax is (currently):
>
> Repository returns build::Repository : {build::Repository}
> (documentation = DOCUMENTATION)?
> "repository" handlerType = ID name = ID '{'
> ("connection" address = STRING ';')?
> (options += RepoOption)*
> (branches += Branch)*
> '}'
> ;
>
> Connection comes first since it is almost always required (the only
> exception would be some internal repository like "workspace" or
> "execution stack" so I left it optional).
> It is also needed to properly validate other things (at least some
> advanced options where the options are valid or not depending on what
> the connection address looks like.
>
> As you point out, the order of the branches are important, and I
> therefore placed them last. I could wrap them in a "branches { }" if you
> think that makes it clearer that the order matters. Only downside is if
> a single branch is required:
>
> branches { branch { } }
>
> Wrapping the in a block gives an opportunity to state that it is
> actually a search as opposed to a mere declaration of existence of a
> branch.
>
> Something like:
>
> search-branches { branch ...}
>
>
> - henrik
>
> On 5/19/10 1:13 PM, Thomas Hallgren wrote:
>> On 2010-05-19 14:08, Henrik Lindberg wrote:
>>> repository cvs my_cvs_4 {
>>> connection "http://abc.org" ;
>>> branch aBranchCalledWanda { }
>>> branch aBranchAlsoCalledWanda { }
>>> branch main {
>>> timestamp "20100516213854+0200";
>>> update-policy no-update;
>>> include {
>>> name "some/path/or.complex.name" ;
>>> name aName ;
>>> pattern "*.middle.*" ;
>>> }
>>> exclude {
>>> pattern ~/.*apa/ ;
>>> pattern ~/.*bepa/ ;
>>> name aBadName;
>>> }
>>> }
>>>
>> What happens if I write:
>>
>> repository cvs my_cvs_4 {
>> branch aBranchCalledWanda { }
>> connection "http://abc.org" ;
>> branch aBranchAlsoCalledWanda { }
>>
>> ?
> As noted above, this is not allowed, all branches are placed last.
>
>>
>> IMO, if you don't use a list for the branches, it becomes less clear
>> that the order actually matters. If it matters, then does it also matter
>> if I write branches before connection? If not, then the ordering is
>> inconsistent.
>>
>> - thomas
>
|
|
|
| Re: repository syntax [message #608072 is a reply to message #534560] |
Wed, 19 May 2010 14:17 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
On 5/19/10 4:03 PM, Thomas Hallgren wrote:
> I still think it's a bit inconsistent. You remove 'repositories' since
> order doesn't matter. For 'branches' though, it indeed does matter. I'm
> not in favor of repeating the 'branch'. It's more to type and the syntax
> is more unclear. The argument about more to type is true for
> 'repositories' as well as soon as you have more then one.
>
uh,
I think it should be like this:
Repository returns build::Repository : {build::Repository}
(documentation = DOCUMENTATION)?
"repository" handlerType = ID name = ID '{'
("connection" address = STRING ';')?
(options += RepoOption)*
("search-branches" '{' (branches += Branch)* '}')
'}'
;
i.e. I agree with you about branches being in a separate block. The note
about "more to type" was the only downside I could think of, but I don't
think it matters, when someone are writing a b3 script I expect
judicious use of content-assist anyway...
I can relax the order of options and branches if you think it is of
value, but I think I want to keep the connection first.
- henrik
> - thomas
>
> On 05/19/2010 03:32 PM, Henrik Lindberg wrote:
>> The syntax is (currently):
>>
>> Repository returns build::Repository : {build::Repository}
>> (documentation = DOCUMENTATION)?
>> "repository" handlerType = ID name = ID '{'
>> ("connection" address = STRING ';')?
>> (options += RepoOption)*
>> (branches += Branch)*
>> '}'
>> ;
>>
>> Connection comes first since it is almost always required (the only
>> exception would be some internal repository like "workspace" or
>> "execution stack" so I left it optional).
>> It is also needed to properly validate other things (at least some
>> advanced options where the options are valid or not depending on what
>> the connection address looks like.
>>
>> As you point out, the order of the branches are important, and I
>> therefore placed them last. I could wrap them in a "branches { }" if you
>> think that makes it clearer that the order matters. Only downside is if
>> a single branch is required:
>>
>> branches { branch { } }
>>
>> Wrapping the in a block gives an opportunity to state that it is
>> actually a search as opposed to a mere declaration of existence of a
>> branch.
>>
>> Something like:
>>
>> search-branches { branch ...}
>>
>>
>> - henrik
>>
>> On 5/19/10 1:13 PM, Thomas Hallgren wrote:
>>> On 2010-05-19 14:08, Henrik Lindberg wrote:
>>>> repository cvs my_cvs_4 {
>>>> connection "http://abc.org" ;
>>>> branch aBranchCalledWanda { }
>>>> branch aBranchAlsoCalledWanda { }
>>>> branch main {
>>>> timestamp "20100516213854+0200";
>>>> update-policy no-update;
>>>> include {
>>>> name "some/path/or.complex.name" ;
>>>> name aName ;
>>>> pattern "*.middle.*" ;
>>>> }
>>>> exclude {
>>>> pattern ~/.*apa/ ;
>>>> pattern ~/.*bepa/ ;
>>>> name aBadName;
>>>> }
>>>> }
>>>>
>>> What happens if I write:
>>>
>>> repository cvs my_cvs_4 {
>>> branch aBranchCalledWanda { }
>>> connection "http://abc.org" ;
>>> branch aBranchAlsoCalledWanda { }
>>>
>>> ?
>> As noted above, this is not allowed, all branches are placed last.
>>
>>>
>>> IMO, if you don't use a list for the branches, it becomes less clear
>>> that the order actually matters. If it matters, then does it also matter
>>> if I write branches before connection? If not, then the ordering is
>>> inconsistent.
>>>
>>> - thomas
>>
>
|
|
|
| Re: repository syntax [message #608073 is a reply to message #534561] |
Wed, 19 May 2010 15:21 |
|
What I meant with more to typing was the difference between:
repositories {
xxx;
yyy;
zzz;
}
and:
repository xxx;
repository yyy;
repository zzz;
I liked the fact that they were grouped together into one list element, regardless of if the order has significance or
not. I also think that
search-branches : [ x, y, z ];
is different from:
search-branches { x; y; z; }
in that the former clearly declares a named ordered list of things whereas the latter comes through more as type
declaration that isn't attached to anything.
I would feel much more at home if we used:
type { a:v; b:v; c:v; }
as a definition of a anonymous structure of 'type' with the members 'a', 'b', and 'c'. whereas:
[ a, b, c, ]
declares an anonymous list of things. Naming is then done with:
name : [ a, b, c, ];
or
name : type { a : v; b : v; c : v; };
(which is consistent with the structure members so it can be applied recursively).
Apply this to your initial example:
repositories : [
cvs {
id : my_cvs_3;
connection : "http://abc.org" ;
branches [
aBranchCalledWanda,
main {
timestamp : "20100516213854+0200";
update-policy : no-update;
include : [
"some/path/or.complex.name",
"some/path/or.complex.name",
aName
];
exclude : [
~/.*/ ,
~/.*/,
my_name.exactly,
"some/path/or.complex.name"
];
}
];
}
];
I would also assume that member names are unique within a structure (I'm not fond of implicitly creating list when
members are repeated, would much rather see a 'member already defined' syntax error). So if we were to change the
'exclude', then this would not work:
include {
name "some/path/or.complex.name" ;
name aName ;
pattern "*.middle.*" ;
}
exclude {
pattern ~/.*apa/ ;
pattern ~/.*bepa/ ;
name aBadName;
}
this however would:
include : match {
names [ "some/path/or.complex.name", aName ];
patterns [ ~/.*middle.*/ ];
};
exclude : match {
patterns [ ~/.*apa/, ~/.*bepa/ ];
names [ aBadName ];
};
- thomas
|
|
|
| Re: repository syntax [message #608075 is a reply to message #534584] |
Wed, 19 May 2010 15:38 |
|
The example was a bit inconsistent. Here's another try:
repositories : [
cvs {
id : my_cvs_3;
connection : "http://abc.org" ;
branches : [
branch { id : aBranchCalledWanda },
branch {
id : main;
timestamp : "20100516213854+0200";
update-policy : no-update;
include : [
"some/path/or.complex.name",
"some/path/or.complex.name",
aName
];
exclude : [
~/.*/ ,
~/.*/,
my_name.exactly,
"some/path/or.complex.name"
];
}
];
}
];
syntax can the be improved further by allowing an alternative syntax for
type {
id : name
...
}
as:
type name {
...
}
repositories : [
cvs my_cvs_3 {
connection : "http://abc.org" ;
branches : [
branch aBranchCalledWanda {},
branch main {
timestamp : "20100516213854+0200";
update-policy : no-update;
include : [
"some/path/or.complex.name",
"some/path/or.complex.name",
aName
];
exclude : [
~/.*/ ,
~/.*/,
my_name.exactly,
"some/path/or.complex.name"
];
}
];
}
];
which is fairly similar to the initial example. There are some subtle differences to make the syntax consistent.
- thomas
On 05/19/2010 05:21 PM, Thomas Hallgren wrote:
> What I meant with more to typing was the difference between:
>
> repositories {
> xxx;
> yyy;
> zzz;
> }
>
> and:
>
> repository xxx;
> repository yyy;
> repository zzz;
>
> I liked the fact that they were grouped together into one list element,
> regardless of if the order has significance or not. I also think that
>
> search-branches : [ x, y, z ];
>
> is different from:
>
> search-branches { x; y; z; }
>
> in that the former clearly declares a named ordered list of things
> whereas the latter comes through more as type declaration that isn't
> attached to anything.
>
> I would feel much more at home if we used:
>
> type { a:v; b:v; c:v; }
>
> as a definition of a anonymous structure of 'type' with the members 'a',
> 'b', and 'c'. whereas:
>
> [ a, b, c, ]
>
> declares an anonymous list of things. Naming is then done with:
>
> name : [ a, b, c, ];
>
> or
>
> name : type { a : v; b : v; c : v; };
>
> (which is consistent with the structure members so it can be applied
> recursively).
>
>
> Apply this to your initial example:
>
> repositories : [
> cvs {
> id : my_cvs_3;
> connection : "http://abc.org" ;
> branches [
> aBranchCalledWanda,
> main {
> timestamp : "20100516213854+0200";
> update-policy : no-update;
> include : [
> "some/path/or.complex.name",
> "some/path/or.complex.name",
> aName
> ];
> exclude : [
> ~/.*/ ,
> ~/.*/,
> my_name.exactly,
> "some/path/or.complex.name"
> ];
> }
> ];
> }
> ];
>
> I would also assume that member names are unique within a structure (I'm
> not fond of implicitly creating list when members are repeated, would
> much rather see a 'member already defined' syntax error). So if we were
> to change the 'exclude', then this would not work:
>
> include {
> name "some/path/or.complex.name" ;
> name aName ;
> pattern "*.middle.*" ;
> }
> exclude {
> pattern ~/.*apa/ ;
> pattern ~/.*bepa/ ;
> name aBadName;
> }
>
> this however would:
>
>
> include : match {
> names [ "some/path/or.complex.name", aName ];
> patterns [ ~/.*middle.*/ ];
> };
>
> exclude : match {
> patterns [ ~/.*apa/, ~/.*bepa/ ];
> names [ aBadName ];
> };
>
> - thomas
|
|
|
| Re: repository syntax [message #608076 is a reply to message #534591] |
Wed, 19 May 2010 18:17 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
Your last suggestion is a clear improvement on what we came up with
during our meeting.
In addition, I would like to use the "names" and "patterns" as you
suggested.
I can try to implement that and see what it feels/looks like.
It still has the irritating "syntactical embelishments" that are not
required, and that only makes sense once you understand the difference,
I think people are confused over how to delimit things with even the
simplest syntax - so I wanted to avoid using anything but ; and {}
But, let's try it anyway... (I mean, I did like it when I came up with
the idea ;)
There is one ambiguity, but I think it only prevents short hand notation
- this is ambiguous:
something ':' Expression
something ':' '[' ExpressionList ']'
since an Expression in itself can be a list of some type. By not
allowing such constructs - i.e. something is a simple expression
(possibly a list of say integers), or a list with some special syntax.
- henrik
On 5/19/10 5:38 PM, Thomas Hallgren wrote:
> The example was a bit inconsistent. Here's another try:
>
> repositories : [
> cvs {
> id : my_cvs_3;
> connection : "http://abc.org" ;
> branches : [
> branch { id : aBranchCalledWanda },
> branch {
> id : main;
> timestamp : "20100516213854+0200";
> update-policy : no-update;
> include : [
> "some/path/or.complex.name",
> "some/path/or.complex.name",
> aName
> ];
> exclude : [
> ~/.*/ ,
> ~/.*/,
> my_name.exactly,
> "some/path/or.complex.name"
> ];
> }
> ];
> }
> ];
>
> syntax can the be improved further by allowing an alternative syntax for
>
> type {
> id : name
> ...
> }
>
> as:
>
> type name {
> ...
> }
>
> repositories : [
> cvs my_cvs_3 {
> connection : "http://abc.org" ;
> branches : [
> branch aBranchCalledWanda {},
> branch main {
> timestamp : "20100516213854+0200";
> update-policy : no-update;
> include : [
> "some/path/or.complex.name",
> "some/path/or.complex.name",
> aName
> ];
> exclude : [
> ~/.*/ ,
> ~/.*/,
> my_name.exactly,
> "some/path/or.complex.name"
> ];
> }
> ];
> }
> ];
>
> which is fairly similar to the initial example. There are some subtle
> differences to make the syntax consistent.
>
> - thomas
>
>
> On 05/19/2010 05:21 PM, Thomas Hallgren wrote:
>> What I meant with more to typing was the difference between:
>>
>> repositories {
>> xxx;
>> yyy;
>> zzz;
>> }
>>
>> and:
>>
>> repository xxx;
>> repository yyy;
>> repository zzz;
>>
>> I liked the fact that they were grouped together into one list element,
>> regardless of if the order has significance or not. I also think that
>>
>> search-branches : [ x, y, z ];
>>
>> is different from:
>>
>> search-branches { x; y; z; }
>>
>> in that the former clearly declares a named ordered list of things
>> whereas the latter comes through more as type declaration that isn't
>> attached to anything.
>>
>> I would feel much more at home if we used:
>>
>> type { a:v; b:v; c:v; }
>>
>> as a definition of a anonymous structure of 'type' with the members 'a',
>> 'b', and 'c'. whereas:
>>
>> [ a, b, c, ]
>>
>> declares an anonymous list of things. Naming is then done with:
>>
>> name : [ a, b, c, ];
>>
>> or
>>
>> name : type { a : v; b : v; c : v; };
>>
>> (which is consistent with the structure members so it can be applied
>> recursively).
>>
>>
>> Apply this to your initial example:
>>
>> repositories : [
>> cvs {
>> id : my_cvs_3;
>> connection : "http://abc.org" ;
>> branches [
>> aBranchCalledWanda,
>> main {
>> timestamp : "20100516213854+0200";
>> update-policy : no-update;
>> include : [
>> "some/path/or.complex.name",
>> "some/path/or.complex.name",
>> aName
>> ];
>> exclude : [
>> ~/.*/ ,
>> ~/.*/,
>> my_name.exactly,
>> "some/path/or.complex.name"
>> ];
>> }
>> ];
>> }
>> ];
>>
>> I would also assume that member names are unique within a structure (I'm
>> not fond of implicitly creating list when members are repeated, would
>> much rather see a 'member already defined' syntax error). So if we were
>> to change the 'exclude', then this would not work:
>>
>> include {
>> name "some/path/or.complex.name" ;
>> name aName ;
>> pattern "*.middle.*" ;
>> }
>> exclude {
>> pattern ~/.*apa/ ;
>> pattern ~/.*bepa/ ;
>> name aBadName;
>> }
>>
>> this however would:
>>
>>
>> include : match {
>> names [ "some/path/or.complex.name", aName ];
>> patterns [ ~/.*middle.*/ ];
>> };
>>
>> exclude : match {
>> patterns [ ~/.*apa/, ~/.*bepa/ ];
>> names [ aBadName ];
>> };
>>
>> - thomas
>
|
|
|
| Re: repository syntax [message #608078 is a reply to message #534655] |
Thu, 20 May 2010 19:45 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
Working on the syntax again using the latest ideas.
Here is how I just defined "repository"
Repository returns build::Repository : {build::Repository}
(documentation = DOCUMENTATION)?
"repository" handlerType = ID name = ID
((':' "connection" ':' address = STRING ';')
|('{'
("connection" ':' address = STRING ';')?
(options += RepoOption)*
("branches" ':' '[' (branches += Branch) (',' branches += Branch)* ']')?
'}')
)
;
This means that it is possible to use a short form for repositories
where all that is needed is the type, name and address. Like this:
repository p2 platformRepo : connection : "http://dev.myorg.com/repo1";
The rationale is that following a definition it is possible to specify
'one thing' after a ':', or multiple things enclosed in '{'. These are
equivalent:
repository p2 platformRepo : connection : "http://dev.myorg.com/repo1";
repository p2 platformRepo {
connection : "http://dev.myorg.com/repo1";
// ...
}
But the later allows specification of more things.
This is consistent with the rest of the syntax in b3 - compare with:
function square(a, b) : a * b;
function square(a, b) { a * b; }
function oneTwoThree() : [1, 2, 3];
function oneTwoThree : [1, 2, 3];
(Continuing with Branches now...)
Regards
- henrik
|
|
|
| Re: repository syntax [message #608079 is a reply to message #534962] |
Thu, 20 May 2010 19:58 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
I am changing the following:
address = STRING ';'
to
address = Expression ';'
so that it is possible to use properties etc.
I can still provide code completion and suggest a simple string address.
The only thing not possible to do at edit time is to validate the
repository options against the address if it is something else than a
literal string. One can imagine that a particular protocoll for a
particular repository type *may* want to do this, but it is however
possible to issue a warning (for those repository types that so
requires) that full validation is deferred until runtime (which by the
way is always the case wrt the address itself :))
- henrik
On 5/20/10 9:45 PM, Henrik Lindberg wrote:
> Working on the syntax again using the latest ideas.
> Here is how I just defined "repository"
>
> Repository returns build::Repository : {build::Repository}
> (documentation = DOCUMENTATION)?
> "repository" handlerType = ID name = ID
> ((':' "connection" ':' address = STRING ';')
> |('{'
> ("connection" ':' address = STRING ';')?
> (options += RepoOption)*
> ("branches" ':' '[' (branches += Branch) (',' branches += Branch)* ']')?
> '}')
> )
> ;
>
> This means that it is possible to use a short form for repositories
> where all that is needed is the type, name and address. Like this:
>
> repository p2 platformRepo : connection : "http://dev.myorg.com/repo1";
>
> The rationale is that following a definition it is possible to specify
> 'one thing' after a ':', or multiple things enclosed in '{'. These are
> equivalent:
>
> repository p2 platformRepo : connection : "http://dev.myorg.com/repo1";
> repository p2 platformRepo {
> connection : "http://dev.myorg.com/repo1";
> // ...
> }
>
> But the later allows specification of more things.
> This is consistent with the rest of the syntax in b3 - compare with:
>
> function square(a, b) : a * b;
> function square(a, b) { a * b; }
>
> function oneTwoThree() : [1, 2, 3];
> function oneTwoThree : [1, 2, 3];
>
> (Continuing with Branches now...)
> Regards
> - henrik
>
|
|
|
| Re: repository syntax [message #608081 is a reply to message #534967] |
Thu, 20 May 2010 20:30 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
And I missed a terminating ';' after branches : [ ]
- henrik
On 5/20/10 9:58 PM, Henrik Lindberg wrote:
> I am changing the following:
> address = STRING ';'
> to
> address = Expression ';'
>
> so that it is possible to use properties etc.
>
> I can still provide code completion and suggest a simple string address.
> The only thing not possible to do at edit time is to validate the
> repository options against the address if it is something else than a
> literal string. One can imagine that a particular protocoll for a
> particular repository type *may* want to do this, but it is however
> possible to issue a warning (for those repository types that so
> requires) that full validation is deferred until runtime (which by the
> way is always the case wrt the address itself :))
>
> - henrik
>
> On 5/20/10 9:45 PM, Henrik Lindberg wrote:
>> Working on the syntax again using the latest ideas.
>> Here is how I just defined "repository"
>>
>> Repository returns build::Repository : {build::Repository}
>> (documentation = DOCUMENTATION)?
>> "repository" handlerType = ID name = ID
>> ((':' "connection" ':' address = STRING ';')
>> |('{'
>> ("connection" ':' address = STRING ';')?
>> (options += RepoOption)*
>> ("branches" ':' '[' (branches += Branch) (',' branches += Branch)* ']')?
>> '}')
>> )
>> ;
>>
>> This means that it is possible to use a short form for repositories
>> where all that is needed is the type, name and address. Like this:
>>
>> repository p2 platformRepo : connection : "http://dev.myorg.com/repo1";
>>
>> The rationale is that following a definition it is possible to specify
>> 'one thing' after a ':', or multiple things enclosed in '{'. These are
>> equivalent:
>>
>> repository p2 platformRepo : connection : "http://dev.myorg.com/repo1";
>> repository p2 platformRepo {
>> connection : "http://dev.myorg.com/repo1";
>> // ...
>> }
>>
>> But the later allows specification of more things.
>> This is consistent with the rest of the syntax in b3 - compare with:
>>
>> function square(a, b) : a * b;
>> function square(a, b) { a * b; }
>>
>> function oneTwoThree() : [1, 2, 3];
>> function oneTwoThree : [1, 2, 3];
>>
>> (Continuing with Branches now...)
>> Regards
>> - henrik
>>
>
|
|
|
Goto Forum:
Current Time: Sat Dec 21 14:26:41 GMT 2024
Powered by FUDForum. Page generated in 0.05006 seconds |
] 
Search
Help
Register
Login
Home
