[Python-ideas] Jump to function as an an alternative to call function
Elazar
elazarg at gmail.com
Wed Aug 15 20:55:13 EDT 2018
I have no opinion on the proposal, but the equation with goto is dead
wrong. Yes, technically this is a goto. But so is a regular function call.
Jumping to a function makes thd code _easier_ to reason about, statically,
not harder. When you call an arbitrary function, you have no idea whether
it will return or not. When you jump to a function, you _know_ it will not
return. That's strictly more information, based solely on the syntax of the
statement.
Yes, if you have local functions mutating the state then jumpung to them
makes the code difficult to read. *but so is calling them*, with the
addition of the returning that you have to track.
Jumping to functions is procedural programming. There is no reasonfor it to
be "considered harmful" any more than calling funcions; indeed even less
so.
Elazar
On Wed, Aug 15, 2018, 17:42 Eric Fahlgren <ericfahlgren at gmail.com> wrote:
> How about just
> https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf
>
> On Wed, Aug 15, 2018 at 5:38 PM David Mertz <mertz at gnosis.cx> wrote:
>
>> Hmm.. link broke. Is this right?
>>
>>
>> https://www.google.com/url?sa=t&source=web&rct=j&url=https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf&ved=2ahUKEwi8lqHYqfDcAhXImOAKHeAzDmsQFjAEegQIBhAB&usg=AOvVaw1CZug_36-PbevItYXTb7SR
>>
>> On Wed, Aug 15, 2018, 8:35 PM David Mertz <mertz at gnosis.cx> wrote:
>>
>>> Goto considered harmful.
>>>
>>>
>>> https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf&ved=2ahUKEwi8lqHYqfDcAhXImOAKHeAzDmsQFjAEegQIBhAB&usg=AOvVaw1CZug_36-PbevItYXTb7SR
>>>
>>> On Wed, Aug 15, 2018, 3:52 PM Jacob Solinsky <jacobsolinsky at gmail.com>
>>> wrote:
>>>
>>>> -Jumping to a function as opposed to calling a function
>>>>
>>>> When a function is jumped to, it inherits the variables in the caller’s
>>>> local namespace and is free to modify them or add new local variables,
>>>> unlike a normal function call, wherein the caller’s namespace is
>>>> inaccesible. At present, the only way I know of to accomplish this is to
>>>> bundle all variables in the caller method’s namespace as properties of the
>>>> method’s instance and have the callee method modify those properties.
>>>> Though it is easier to read code written this way, it resulted in a great
>>>> deal of redundancy in the code I was writing. The task I was attempting to
>>>> accomplish was approximately this:
>>>>
>>>> class Verb:
>>>> def __init__(self, parameters):
>>>> self.parameters = parameters
>>>> def conjugate(self):
>>>> #Using the parameters, chose an appropriate list of
>>>> morphemes to prefix and suffix to the verb
>>>> self.morphemelist = morphemelist
>>>> for morpheme in self.morphemelist:
>>>> morpheme.mutate()
>>>> returnstring = ‘'
>>>> for morpheme in self.morphemelist:
>>>> returnstring = returnstring + morpheme.form
>>>> returnstring = returnstring
>>>>
>>>> class Morpheme:
>>>> def __init__(self, verb, form, precedingmorpheme,
>>>> succeedingmorpheme):
>>>> self.verb = verb
>>>> self.form = form
>>>> self.precedingmorpheme = precedingmorpheme
>>>> self.succeedingmorpheme = succeedingmorpheme
>>>> def mutate(self):
>>>> #Using the verb’s parameters and the type and form of
>>>> the preceding and succeeding morpheme, mutate this morpheme’s form so that
>>>> #a correct verb form is produced
>>>> self.form = newform
>>>>
>>>> class Ban(Morpheme):
>>>> def __init__(self, verb, form):
>>>> super().__init__(verb, ‘ban’)
>>>> def mutate(self):
>>>> #This morpheme has mutation logic unique to itself but
>>>> with many similarities to the default morpheme’s mutation logic
>>>> self.form = newform
>>>>
>>>> Each subclass of Morpheme has its own slightly different mutate method.
>>>> Some subclasses of Morpheme needed to access and manipulate a great deal of
>>>> information about the verb and their surroundings, while other subclasses’
>>>> mutate methods differed little from the default. Most of the variables
>>>> manipulated by the mutate method are not used by any other methods of class
>>>> Morpheme and thus should not be made properties of the attached instance.
>>>> What I wish I were able to do is write many little methods that modify the
>>>> same set of local variables and compose them together into a complete
>>>> mutate method. This would be effectively equivalent to having the “jump to
>>>> function” calls be replaced with the text in the function’s body, like a C
>>>> language macrosubstitution, but without using anything like preprocessor
>>>> directives.
>>>>
>>>> Let foo(a, b) be the syntax to call foo(a, b), and foo(a, b)% be the
>>>> syntax to jump to foo(a, b)
>>>>
>>>> def foo(a):
>>>> return a + c
>>>>
>>>> def bar(a, c):
>>>> return foo(a)
>>>>
>>>> def bazz(a, c):
>>>> return foo(a)%
>>>>
>>>> c = 5
>>>>
>>>> call = bar(1, 3)
>>>>
>>>> jump = bazz(1, 3)
>>>>
>>>>
>>>> After execution, call in the above code would be 6 and jump in the
>>>> above code would be 4.
>>>>
>>>>
>>>> _______________________________________________
>>>> Python-ideas mailing list
>>>> Python-ideas at python.org
>>>> https://mail.python.org/mailman/listinfo/python-ideas
>>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>>
>>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180815/ced9e915/attachment-0001.html>
More information about the Python-ideas
mailing list