[Python-ideas] Jump to function as an an alternative to call function

[Jacob Solinsky]

The code does the following 2 things:
A Verb class assembles the necessary morphemes in order in accordance with
the verb's subject, object, mode, grmamatical order, tense and polarity.

If all of the morphemes' default forms were mashed together at this point a
valid Ojibwe verb form would not be produced

The code in the mutate methods of each morphene transforms a sequence like
gi-bizindaw-in-si-in-w-in-m-ban
into
gi-bizindoo--si-n-oo-n-inini-mwaa-ban
gibizindoosinoonininimwaaban

A third piece of code creates thousands of verb instances and populates a
web form to show every conjugated form of a given verb, though that is not
important here.

The mutation of each morpheme is dependent on the type and form of the
preceding and following morpheme, occasionally requiring even more
information from the parent verb.
 As most morphemes' mutation method are unique, the subclasses of Morpheme
for the most part override the Morphems superclass's mutate implementation.
However, it would reduce my code's current redundancy if I could place
something like a macro expansion at the beginning of each mutate method's
internal code, as there is a piece of code used to set up each mutate
method's local variable space that I copied and pasted many times.

The code I wrote already functions fine, it is just that while I was
writing I was thinking to myself how convenient it would be if I could
"jump to" functions, and now I understand that the best way to do that
would just be to macro expand an often repeated segment of code.

On Fri, 17 Aug 2018, 15:24 Abe Dillon, <abedillon at gmail.com> wrote:

> Jacob, can you please describe in greater detail *what* you're trying to
> accomplish with your morpheme code? Not *how* you wish to accomplish it,
> but *what* the code is supposed to do?
>
> I've looked into other projects that try to model morphemes and similar
> language constructs to get a better idea of the problem space (NLTK
> <https://www.nltk.org/>, TextBlob
> <https://textblob.readthedocs.io/en/dev/>, PyGlot
> <https://polyglot.readthedocs.io/en/latest/MorphologicalAnalysis.html>,
> etc.) and it looks like machine learning is often employed for
> morpheme-related tasks. It may be that the rules for identifying and
> manipulating morphemes are inherently so complex that they don't lend
> themselves to elegant codification. That's usually the case for fields in
> which people turn to machine learning.
>
> It may also be a case where functional decomposition would help. The
> examples you've given aren't really sufficient to understand the problem.
> It could be a legitimate deficiency in Python's feature set, or it may be
> that Python already has features that could serve you better, or it may be
> that the problem is inherently difficult to codify in an elegant way.
>
> Without a concrete use-case, it's nearly impossible to justify adding a
> new feature to Python. This discussion is unlikely to lead to any
> meaningful action otherwise.
>
> On Thu, Aug 16, 2018 at 4:37 PM, Jacob Solinsky <jacobsolinsky at gmail.com>
> wrote:
>
>> So when getx is executed inside a let form, if it tries to read/write the
>> value of X it interacts with the X entry in the let form's symbol table
>> before moving to find X in the global environment, right? That is similar
>> to what I was trying to accomplish in python, but with the local symbol
>> table of the calling function rather than a let form.
>>
>> I think the way a "jump to" function rather than a "call function" would
>> be implemented would be by removing the prologue and epilogue of the
>> function's compiled code. Something vaguely like this:
>>
>> def foo(a,b):
>>     c = bar(d =3)%
>>     return c+2
>>
>> def bar(d)
>>      a += 2
>>      e = 4
>>      return a + b + d +e
>>
>> foo(7, 2)
>>
>> Here would be the symbol table
>>
>> Scope Foo
>> __________
>> a: fp - 1
>> b: fp - 2
>> d: fp - 3
>> e: fp - 5
>> c: fp - 4
>>
>> The interpreter would have to recognize that bar was being jumped to
>> rather than called and thus inject bar's arguments and variable
>> declarations and return value (if assigned to) into foo's stack frame.
>>
>> The translation of the above code would be this (I apologize for the
>> strange pseudoassembly, I don't know any of those languages on a more than
>> cursory level. The below code is obviously very slow, each variable read
>> from the memory and written to memory at every step, with no storage of
>> local variables in registers.) The "return c+2" statement is changed from a
>> return into a c += 2 assignment in the calling function.
>>
>> PUSH fp, returnregister # preserve old value in return register
>> PUSH -1(fp), 7 # load a
>> PUSH -2(fp),  2 # load b
>> PUSH -3(fp), 3 # load d
>> PUSH -4(fp), 0 # initialize c
>> ADDI -1(fp), -1(fp), 2 # a += 2
>> PUSH -5(fp), 4 # load e
>> ADD -4(fp), -1(fp), -2(fp) # c = a + b + d + e
>> ADD -4(fp), -4(fp), -5(fp) # c = a + d + d + e continued
>> ADDI returnregister, -4(fp), 2 # return c + 2
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, 16 Aug 2018, 14:44 Jonathan Fine, <jfine2358 at gmail.com> wrote:
>>
>>> Hi Jacob
>>>
>>> I'm finding the python-ideas list a bit noisy, so I'm sending this
>>> off-list.
>>>
>>> I've found
>>>
>>>
>>> https://www.gnu.org/software/emacs/manual/html_node/elisp/Dynamic-Binding.html
>>>
>>> https://www.gnu.org/software/emacs/manual/html_node/elisp/Variable-Scoping.html
>>>
>>> Please confirm that this is at least close to what you want, to be
>>> able to program your problem efficiently.
>>>
>>> Meanwhile, I'm thinking about how your algorithm might be expressed in
>>> Python.
>>>
>>> --
>>> Jonathan
>>>
>>
>> _______________________________________________
>> 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/20180817/047d99e9/attachment-0001.html>