mutable default parameter problem [Prothon]

[Mark Hahn]

Re: mutable default parameter problem [Prothon]

Pierre-Frédéric Caillaud wrote:
[color=blue]
> Does the language enforce the bool return type on the ? variant ?[/color]

That's a good idea. I'll throw that out for a vote on the Prothon
discussion group.

You should join our mailing list. We need ideas. The traffic is light so
it won't be much of a bother. We only have 25 to 30 messages a day and
there are no pesky users yet :-) We have some really bright people
contributing right now and it is getting quite exciting.

We are in the middle of figuring out how to add classes to Prothon (just as
a design-contract kind of thing) and are about to move on to language
features (like coroutines) of the stackless engine we are built on. We have
Mr. Stackless himself (Christian) helping out so it should go well.

[Mark Hahn]

Re: mutable default parameter problem [Prothon]

Dave Brueck wrote:
[color=blue]
> You cut out my example that elaborated on the questions I was asking:[/color]

Sorry.
[color=blue]
> 1) It's just part of the name. So from the language's perspective,
> whether you call it appendINPLACE or append! makes no difference?[/color]

It makes no difference to the interpreter, but to the other Prothon
programmers it makes a difference because it's a convention. Also append!()
is a standard library function so you don't get to change it :-)
[color=blue]
> 2) (continuing on #1) that being the case, it's really just a naming
> convention, correct? (because the language itself doesn't do anything
> with that information - additional checking to enforce that
> convention, different functionality, etc)
>[color=green]
>> From what I gather that's a "yes" to both questions.[/color][/color]

Yes, Yes.
[color=blue][color=green][color=darkred]
>>> Seems like a waste to reserve a
>>> symbol for something so rarely needed.[/color]
>>
>> I disagree. In-place modification is significant and happens often.
>> Ignoring this is dangerous.[/color]
>
> Well, now we're down to disagreeing how often it occurs. I just
> haven't seen very many cases in practice where (1) I want to both do
> something to an object AND have it return itself in a single step and
> (2) doing so can be done in a clear way, and (3) I want to do it for
> a good reason rather than just wanting to save a line of code. In the
> few cases I've seen so far, the rationale has apparently been to make
> the code shorter, not necessarily better.[/color]

There are many clean readable programming conventions that rely on return
values. This is certainly an acceptable construct, right?

while len(list.append !(x)) < 10:
blah blah blah

Compare that to the less readable and less maintainable Python version:

list.append(x)
while len(list) < 10:
blah blah
list.append(x) # duplicate code

I can come up with many more. I think when you have been without a language
feature for a while you tend to block it out of your mind.
[color=blue][color=green]
>> How can you argue that the exclamation mark indicating
>> in-place-modification does not make it more readable?[/color]
>
> (1) Because in practice I haven't seen the need for it much,[/color]

You don't look for it because in the back of your mind you know you can't
use it.
[color=blue]
> it encourages
> cramming more onto a line just because you can.[/color]

You are being pretty negative here. Not everyone is out to cram more into a
line. Give people a little more credit.
[color=blue]
> The "print list.append!(5) " is a fine example of this IMO - you've
> combined two *completely unrelated* operations for no good reason.
> Yes, it's just an example, I know, but it's probably an example of
> how it'll be commonly (mis)used. For every one "good" use of the !
> form you'll probably have a thousand uses where the only benefit was
> that it saved a line of code. <0.5 wink>[/color]

I don't think I commited any big sin. It seemed plenty readable to me.
Combining operations on one line is done all the time. I suppose you would
code this:

x = a + b
x = x * c
print x

instead of this:

print (a+b) * c
[color=blue]
> (2) It's just a naming convention, so you can't rely on it's presence
> or absence as being accurate (probably not a big deal in practice, but
> still...)[/color]

All programming involves trust. Any programmer can obfuscate his code a
million ways.
[color=blue]
> (3) Cases like w = x.y.z!() would confuse me, as would
>
> ref! = obj.method![/color]

You are confused pretty easily. Maybe because you aren't used to them.
They read easily to me.
[color=blue]
> x = ref!(5, 6, 7) # what the heck, x == obj?![/color]

ref! is invalid by convention and obj?! would throw a syntax exception.

[Christian Tismer]

Re: mutable default parameter problem [Prothon]

Mark Hahn wrote:

....
[color=blue]
> 2) Evaluate the default expression once at each call time when the default
> value is needed. The default expression would be evaluated in the context
> of the function definition (like a closure).[/color]
[color=blue]
> Comments? How much Python code would these different proposals break?[/color]

I think not so very much.
The default mutable parameters have been abused to keep
class-like state. Default parameters in general have also been
used to speed up object lookup on certain speed contests.

Both usages are obsolete, since the same effect can be
achieved with a local function sitting in a scope,
from where it can use mutables it it needs to.

So I don't see many remaining advantages, and I think it is
a good idea to make the defaults less sticky.

+1 for 2)

ciao - chris

--
Christian Tismer :^) <mailto:tismer@ stackless.com>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34 home +49 30 802 86 56 mobile +49 173 24 18 776
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/

[Mark Hahn]

Re: mutable default parameter problem [Prothon]

Christian Tismer wrote:
[color=blue][color=green]
>> 2) Evaluate the default expression once at each call time when the
>> default value is needed. The default expression would be evaluated
>> in the context of the function definition (like a closure).[/color]
>[color=green]
>> Comments? How much Python code would these different proposals
>> break?[/color]
>
> I think not so very much.
> The default mutable parameters have been abused to keep
> class-like state. Default parameters in general have also been
> used to speed up object lookup on certain speed contests.
>
> Both usages are obsolete, since the same effect can be
> achieved with a local function sitting in a scope,
> from where it can use mutables it it needs to.
>
> So I don't see many remaining advantages, and I think it is
> a good idea to make the defaults less sticky.
>
> +1 for 2)[/color]

I'm glad you voted that way because I implemented #2 a few days ago :-o

Not that I couldn't change it.

[Pierre-Frédéric Caillaud]

Re: mutable default parameter problem [Prothon]

On Fri, 25 Jun 2004 15:45:51 -0700, Mark Hahn <mark@prothon.o rg> wrote:
[color=blue]
> Pierre-Frédéric Caillaud wrote:
>[color=green]
>> Does the language enforce the bool return type on the ? variant ?[/color]
>
> That's a good idea.[/color]

In fact I'm not that sure anymore. I like the fact Python operators like
"or" and "and" return values themselves and not booleans ; that's
extremely useful. Thus imposing boolean return types to these "?" method
might break some usability. Then again, it might also be a good idea, but
it needs somoe thinking !
[color=blue]
> You should join our mailing list. We need ideas. The traffic is light[/color]

Done !
[color=blue]
> and are about to move on to language
> features (like coroutines) of the stackless engine we are built on.[/color]

Very good !