First separator for subassignments must be '.' (issue 341490043 by dak@gnu.org)

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

First separator for subassignments must be '.' (issue 341490043 by dak@gnu.org)

Thomas Morley-2
Even without your patch one can do:

part.1,1 = "foo"
part.1,2 = "bar"
part.1,3 = "buzz"
part.2,1 = "xx"
part.2,2 = "yy"
part.2,3 = "zz"
part.3   = "whatever"

#(format #t "\n\"part\" contains:\n~y\n" part)
#(format #t "Example call in guile: \"1\" of \"part\":\n~a" (assoc-get 1
part))
#(format #t "\nExample calls with ly-syntax:")

%% Working:
\void \displayScheme \part.2,3
\void \displayScheme \part.3

%% Causing errors:
% \void \displayScheme \part,1,1
% \void \displayScheme \part,1.1
% \void \displayScheme \part.1.1

I wasn't aware you can create nested lists with this syntax, already.

If I understand correctly your patch will disallow a first comma,
forcing a dot
Will it force the comma as second separator?

https://codereview.appspot.com/341490043/

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: First separator for subassignments must be '.' (issue 341490043 by dak@gnu.org)

David Kastrup
Reviewers: thomasmorley651,

Message:
On 2018/10/03 16:56:27, thomasmorley651 wrote:
> Even without your patch one can do:

> part.1,1 = "foo"
> part.1,2 = "bar"
> part.1,3 = "buzz"
> part.2,1 = "xx"
> part.2,2 = "yy"
> part.2,3 = "zz"
> part.3   = "whatever"

> #(format #t "\n\"part\" contains:\n~y\n" part)
> #(format #t "Example call in guile: \"1\" of \"part\":\n~a" (assoc-get
1 part))
> #(format #t "\nExample calls with ly-syntax:")

> %% Working:
> \void \displayScheme \part.2,3
> \void \displayScheme \part.3

> %% Causing errors:
> % \void \displayScheme \part,1,1
> % \void \displayScheme \part,1.1
> % \void \displayScheme \part.1.1

> I wasn't aware you can create nested lists with this syntax, already.

> If I understand correctly your patch will disallow a first comma,
forcing a dot
> Will it force the comma as second separator?

No.  The errors you get for 1.1 are because 1.1 is a real number.  If
you write those 1 . 1 (not sure whether you can omit one or the other
space) they will work fine as well.  Enforcing stuff beyond the first
dot/comma would make the grammar more complex and I don't see that we'd
accomplish anything by that.  It's possible if it irritates people but
would then also sacrifice \part.2,3 .  I don't know whether that would
ever be a problem, though.

Description:
First separator for subassignments must be '.'

This pares down syntax supported since issue 4790 to match the allowed
usage from issue 4797.  Permitting ',' here seemed particularly
strange.

Please review this at https://codereview.appspot.com/341490043/

Affected files (+0, -5 lines):
   M lily/parser.yy


Index: lily/parser.yy
diff --git a/lily/parser.yy b/lily/parser.yy
index  
fe3b0927d638362e31623f4e2a995d83057904ec..5ba51786fa42091c33df1014483cb030ea21fe47  
100644
--- a/lily/parser.yy
+++ b/lily/parser.yy
@@ -696,11 +696,6 @@ assignment:
  parser->lexer_->set_identifier (path, $5);
                  $$ = SCM_UNSPECIFIED;
  }
- | assignment_id ',' property_path '=' identifier_init {
- SCM path = scm_cons ($1, $3);
- parser->lexer_->set_identifier (path, $5);
-                $$ = SCM_UNSPECIFIED;
- }
  | markup_mode_word '=' identifier_init
  {
  if (scm_is_false (Lily::markup_function_p ($3)))



_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: First separator for subassignments must be '.' (issue 341490043 by dak@gnu.org)

David Kastrup
In reply to this post by Thomas Morley-2
On 2018/10/03 16:56:27, thomasmorley651 wrote:
> Even without your patch one can do:

Oh, I forgot: "even without your patch" points to a misunderstanding.
The sole purpose of this patch is to remove a previously accepted
construct for assignment because, well, I was troubled by a discussion
pointing out that it was accepted (though only in assignment, not in
reference).

It doesn't seem either practically nor conceptually useful, there was no
discussion when I implemented it as part of another patch, and it seems
like a mistake to me now that I did so.

https://codereview.appspot.com/341490043/

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel