On 1/5/2015 3:12 AM, Chris Angelico wrote:
On Mon, Jan 5, 2015 at 6:43 PM, Eric S. Johansson <e...@harvee.org> wrote:
The obvious answer is saving that meta-information in conjunction with the
code but when working in a team environment, that information is going to
drive you handies up the wall because it's going to visually overwhelm the
actual code. Serving the meta-information separately will mean it's even
harder to recover a speech friendly version of the code after it's been
touched.
This, I think, is going to be your hardest problem to solve. Once
someone edits your code using a conventional set of tools, any saved
meta-information will be out of date, and that's a critical failure;
ergo you can't save anything, and have to deduce it all from the code.
Exactly. That's one of the reasons why I was heading down the path of
embedded meta-metadata. It might be acceptable if I could devise rules
for hiding the metadata but even with that, the reversal is still a bit
of a challenge..
So your only option, as I see it, is to devise some kind of 100%
reversible transliteration format.
With the right metadata, you have that reversibility. I think what makes
it easier and harder is that when you write code using speech, you tend
to use idioms (a.k.a. templates). My gut sense tells me that I should be
able to recognize the structure of an idiom for going back from the code
form to the speakable form. the metadata should help this process.
In the example I gave of class, the actual template generating code has
a bunch of conditionals to add or delete subcomponents of the template.
the template tool I use is something I developed myself which is a
speakable template form, can do recursive expansion but has no
conditionals in it (doing so reduces speak ability).
I think a form of pattern matching or shape recognition would be core to
creating the code to speakable form translation but I'm feeling a bit
stumped because I don't know where to find how other people have solved
this kind of problem.
I should clarify that by shape recognition, I don't mean a geometric or
image-based shape. it's more of an abstraction I used in my own mental
models of how code is constructed. for what it's worth, what I just
described is one of the things that makes programming by speech so
difficult. We all have different mental models of how code works. I see
code in three dimensions varying in time. I know not everybody does. :-)
One of the side effects of this visualization of code is that it lets me
identify potential idioms. Some idioms are task transient, others are
more general. If there's some way to recognize the pattern of code that
is in an idiom and be able to preserve the variations within the idiom
then I think we are on the right path.
Interestingly, this is sometimes needed between human languages.
Romanization of (say) Korean text involves representing the sounds of
the syllables in some kind of Latin script. If those transliterations
are perfectly reversible, you can manipulate the Korean text using a
US-English keyboard [1], while still producing correct Korean output.
It ought, in theory at least, to be possible to craft a reversible
transliteration between Python code and a more efficient speakable
form. You might have to place some restrictions on the Python code
(for instance, strict formatting rules, to avoid having spurious edits
when you use speech mode), and maybe you'd need a "fall-back" spoken
form that spells out the exact code, in case someone's done something
weird. But this would be something where you'd be better able to judge
than I am.
it'll never be 100% speech driven. There will always be a time when you
have to use your hands. The goal is to minimize that time.
I should also point out that going from A -> B -> A' is not going to
result in A = A' at least not at a character for character level.
however, given a set of inputs, you will get identical results on
outputs when using A and A'. Yes, this will make differences in
revision control hard to track unless the check in process performs a A
-> B -> A' transformation and only checks in A'
So maybe now the question has changed to how does one specify an idiom
such that one can extract the arguments defining that idiom instance
from existing source code.
--- eric
--
https://mail.python.org/mailman/listinfo/python-list
