Points in order
1) c,d implementation: yes theres no shortage of implementation possibilities - as noted list rhs is whats working '= c,d' isnt and hasnt even been looked at yet.
I take it from the repetition of this particular item you would like to have this syntax (sometime)
2) Surely - most often you are doing a direct arg assignment to lvalues and you have an exact count match. My issue is that if you have an arbitrary list and
only want some of the start of it it doesnt do the simple thing - assign what it does have from the front (python) - less common case that it may be
3) slicing - yes you've said that. Its an extra step however (and unnecessary).
The existence of an easy additional step doesnt make it convenient to have to do it however.
Theres the (possibly minor in the scheme of things) cost of the (extra, unnecessary) slicing operation
( I forget what the overhead for that was now 5-25x vs an index)
4) discontiguous items - hehe - This shortcut isnt meant to be a help for for that, nothing much helps for that for serious discontinuities..... otoh if thers only the odd item not required
an easy way for doing that is to assign them to a matching list to the last discontinuity and ignore the variables for the items you're not interested in
5) slice vs bracketing c,d: I dont follow what youre referring to here - you have to slice in python and dont (have to) bracket lists.
In cobra+patch currently the option is between using brackets on rhs or doing each assignment individually .. its been very hard to get those two confused and convenience wise theres no contest between them. (fwiw the bracketing so far hasnt been particularly onerous since thats all there is and a literal list is exactly analogous to a list variable for this anyway)...
Forums
MultiArg assignment
20 posts
• Page 2 of 2 • 1, 2
Re: MultiArg assignment
There doesn't have to be any slicing overhead at runtime -- the compiler can detect that case and generate more efficient code.
- Charles
- Posts: 2515
- Location: Los Angeles, CA
Re: MultiArg assignment
Do you want me to apply the existing patch now, or wait for a subsequent patch?
- Charles
- Posts: 2515
- Location: Los Angeles, CA
Re: MultiArg assignment
Ummm probably apply it. - if nothing else that will give that bit some air time
I'm part way through the
for k,v in Dict
handling
and looks like theres some duplication and
some refactoring of the first patch code will be needed
but I've not finished getting it working ( few more days yet ... got some other distractions)
I can resync my sandbox against a patched tree without any probs ...
I'm part way through the
for k,v in Dict
handling
and looks like theres some duplication and
some refactoring of the first patch code will be needed
but I've not finished getting it working ( few more days yet ... got some other distractions)
I can resync my sandbox against a patched tree without any probs ...
- hopscc
- Posts: 632
- Location: New Plymouth, Taranaki, New Zealand
Re: MultiArg assignment
Patch applied and feedback added on ticket:38.
- Charles
- Posts: 2515
- Location: Los Angeles, CA
Re: MultiArg assignment
Good-O
re the feedback items
a) a,b = Inumerable-stuff
yep - thats doable manually (now) using a for-expression so it'd be just another recognise-and rewrite
Theres an example in one of the tests I think
b) Use AST node and _bindImp
My fault, ignorance and laziness. When I stated on this I had little idea of the wokings of bindImp or what you had to do in it.
First shot was to avoid all that area entirely if possible and rewrite the AST stream from level of the parser and let subsequent processing look after whatever happened next....
(that worked well - I didnt have to work anything out then about how/where the inferred typing got done)
I've been able to revise that some since investigating multiArg in for loops and seeing the example helper method for extended initialization .
So yeah - sometime down the line it'll get revised 'better'
c) idExpression{,2}
extracted that cos I wanted a subset expression handler that could recognise only Ids ( NameExpr and Dot thingies - essentially lvalues) - forgot about lvalue indexers,
Also needed to break on ASSIGN token ( for where multiarg list not have terminating ','
the third expression in the first line is read by expression() as an assignExpr which isnt desirable - probably should have thought about using precedence values ...
carving out a subset idexpression recogniser from expression was a dirty hack that worked after the first few attempts croaked
Treating as comma sep exprs and testing after is gonna be cleaner /less code though even if have to fiddle with the precedence values some more
Can you point to anywhere else in the code where you do 'testing for assignability' (is search for isAssignable sufficient??) ?
d) a,b = 1,2 ( no rhs list literals)
It looks like I'll have a good start on the bits' to support that once the multiarg-in-'for' coding is done
re the feedback items
a) a,b = Inumerable-stuff
yep - thats doable manually (now) using a for-expression so it'd be just another recognise-and rewrite
- Code: Select all
a,b = for t in INumerable-stuff get t
Theres an example in one of the tests I think
b) Use AST node and _bindImp
My fault, ignorance and laziness. When I stated on this I had little idea of the wokings of bindImp or what you had to do in it.
First shot was to avoid all that area entirely if possible and rewrite the AST stream from level of the parser and let subsequent processing look after whatever happened next....
(that worked well - I didnt have to work anything out then about how/where the inferred typing got done)
I've been able to revise that some since investigating multiArg in for loops and seeing the example helper method for extended initialization .
So yeah - sometime down the line it'll get revised 'better'
c) idExpression{,2}
extracted that cos I wanted a subset expression handler that could recognise only Ids ( NameExpr and Dot thingies - essentially lvalues) - forgot about lvalue indexers,
Also needed to break on ASSIGN token ( for where multiarg list not have terminating ','
- Code: Select all
a,b,c = [1,2,3]
# versus
a,b,c, = [1,2,3]
the third expression in the first line is read by expression() as an assignExpr which isnt desirable - probably should have thought about using precedence values ...
carving out a subset idexpression recogniser from expression was a dirty hack that worked after the first few attempts croaked
Treating as comma sep exprs and testing after is gonna be cleaner /less code though even if have to fiddle with the precedence values some more
Can you point to anywhere else in the code where you do 'testing for assignability' (is search for isAssignable sufficient??) ?
d) a,b = 1,2 ( no rhs list literals)
It looks like I'll have a good start on the bits' to support that once the multiarg-in-'for' coding is done
- hopscc
- Posts: 632
- Location: New Plymouth, Taranaki, New Zealand
Re: MultiArg assignment
Regarding the assignment expression that would get recognize in "a, b, c = [1, 2, 3]", you can "unpack it" by getting it's .left which you know will be the last target of the assignment and its .right which will be the rhs.
Regarding checking for assignable to, I see checks for type compatibility, but not whether the expression can be an lvalue. So this is still dropping through to C# and missing from AssignExpr. We'll need to add it, so you can skip that check for ticket:38 and focus on the other things.
Regarding checking for assignable to, I see checks for type compatibility, but not whether the expression can be an lvalue. So this is still dropping through to C# and missing from AssignExpr. We'll need to add it, so you can skip that check for ticket:38 and focus on the other things.
- Charles
- Posts: 2515
- Location: Los Angeles, CA
Re: MultiArg assignment
Theres a new patch on the ticket for support of multiple vars in a for statement, Implemented for both (generic) dicts and Lists
Hashtables still need to be unpacked manually pending a bugfix elsewhere (eventually)
I also removed the internal trap for an exception when the lhs arglist is longer than the rhs list in multiple arg assignment.
e.g.
- Code: Select all
for k,v in aGenericDict
print 'key=[k], value=[v]'
# this form from a dict can only have two (key,value) variables
tupleList=[1,2],[3,4],[5,6]]
for a,b in tupleList
print 'tuple=[a],[b]'
Hashtables still need to be unpacked manually pending a bugfix elsewhere (eventually)
I also removed the internal trap for an exception when the lhs arglist is longer than the rhs list in multiple arg assignment.
e.g.
- Code: Select all
a,b,c = [1,2] # will now emit an exception
- hopscc
- Posts: 632
- Location: New Plymouth, Taranaki, New Zealand
Re: MultiArg assignment
New patch on ticket for cleanup of multiArg assignment :
new AST node, simplify, shorten, rationalise parsing code
ditch .idexpression* and lookslikeMultiArgIsNext
Additional error checking
support assignment to indexors
more tests.
new AST node, simplify, shorten, rationalise parsing code
ditch .idexpression* and lookslikeMultiArgIsNext
Additional error checking
support assignment to indexors
more tests.
- hopscc
- Posts: 632
- Location: New Plymouth, Taranaki, New Zealand
20 posts
• Page 2 of 2 • 1, 2
Who is online
Users browsing this forum: No registered users and 117 guests