Forums

MultiArg assignment

General discussion about Cobra. Releases and general news will also be posted here.
Feel free to ask questions or just say "Hello".

Re: MultiArg assignment

Postby hopscc » Mon Oct 13, 2008 6:18 am

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)...
hopscc
 
Posts: 632
Location: New Plymouth, Taranaki, New Zealand

Re: MultiArg assignment

Postby Charles » Tue Oct 14, 2008 3:49 am

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

Postby Charles » Tue Oct 14, 2008 3:52 am

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

Postby hopscc » Tue Oct 14, 2008 7:53 am

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 ...
hopscc
 
Posts: 632
Location: New Plymouth, Taranaki, New Zealand

Re: MultiArg assignment

Postby Charles » Wed Oct 15, 2008 3:22 am

Patch applied and feedback added on ticket:38.
Charles
 
Posts: 2515
Location: Los Angeles, CA

Re: MultiArg assignment

Postby hopscc » Wed Oct 15, 2008 6:58 am

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
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

Postby Charles » Wed Oct 15, 2008 1:35 pm

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.
Charles
 
Posts: 2515
Location: Los Angeles, CA

Re: MultiArg assignment

Postby hopscc » Wed Oct 22, 2008 9:07 pm

Theres a new patch on the ticket for support of multiple vars in a for statement, Implemented for both (generic) dicts and Lists
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

Postby Charles » Fri Oct 24, 2008 10:08 pm

Charles
 
Posts: 2515
Location: Los Angeles, CA

Re: MultiArg assignment

Postby hopscc » Tue Oct 28, 2008 11:01 pm

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.
hopscc
 
Posts: 632
Location: New Plymouth, Taranaki, New Zealand

Previous

Return to Discussion

Who is online

Users browsing this forum: No registered users and 117 guests

cron