Currently the spec does not allow any operations on string. I think it would be useful to relax this a little bit and allow compile-time concatenation of strings.
It allows breaking longer strings into multiple lines in the source code (e.g. for log functions).
It makes it easier to combine strings with CPP macros.
I can see two options for syntax for this:
The concatenation operator ++ -- this seems quite natural to me -- ++ concatenates bit-vectors, so why not also strings? In both cases the operation is associative but not commutative, so also algebraically it seems to be a reasonable match (unlike + which is usually commutative too). But the type signatures are not completely consistent ((bit<N>, bit<M>) -> bit<(N+M)> vs. ((string, string) -> string) but I think that is still OK.
"foo" ++ " " ++ "bar" ~~~> "foo bar"
An implicit, C-style concatenation, i.e. two literals separated by whitespace are merged
"foo" " " "bar" ~~~> "foo bar"
I believe the first option is superior, even though the second could be a little more CPP-friendly, but personally I find it quite peculiar.
In compiler, this could be handled by constant folding. It would also impact type checking.
Currently the spec does not allow any operations on
string
. I think it would be useful to relax this a little bit and allow compile-time concatenation of strings.I can see two options for syntax for this:
The concatenation operator
++
-- this seems quite natural to me --++
concatenates bit-vectors, so why not also strings? In both cases the operation is associative but not commutative, so also algebraically it seems to be a reasonable match (unlike+
which is usually commutative too). But the type signatures are not completely consistent ((bit<N>, bit<M>) -> bit<(N+M)>
vs. ((string, string) -> string
) but I think that is still OK.An implicit, C-style concatenation, i.e. two literals separated by whitespace are merged
I believe the first option is superior, even though the second could be a little more CPP-friendly, but personally I find it quite peculiar.
In compiler, this could be handled by constant folding. It would also impact type checking.