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

Fri Aug 17 18:36:07 EDT 2018

Is "Ban" a class of morphemes or just a single morpheme? I would think
subclasses of Morpheme would be "Bound" and "Unbound" then there might be
subclasses of Bound and so on.

[Jacob Solinsky]

> now I understand that the best way to do that would just be to macro
> expand an often repeated segment of code.

This is also referred to as "functional decomposition" (if I understand you
correctly).

You can usually write a method as a sequence of steps you need to take,
then implement those steps in re-usable helper functions with descriptive
names.

My guess is that you'd want the morpheme class to be fairly simple and
leave a bunch of the joining logic to the Verb. I would make a morpheme
object's "morph" method take in some context (perhaps previous and next
morpheme and stress or something) and output a morphed version of the
morpheme without changing any internal state. That way, the "ban" morpheme
is always the "ban" morpheme no matter what.

It might also be easier to use dictionaries to look up morphemes based on
tense and other context. There are a lot of ways that data-structures and
coding practices can clean up code.

On Fri, Aug 17, 2018 at 4:13 PM, Jacob Solinsky <jacobsolinsky at gmail.com>
wrote:

> 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/8fabc6f6/attachment-0001.html>