On Fri, Sep 20, 2013 at 11:07 AM, Loyall, David
<[email protected]>wrote:
In
> [C], a string "Hello" stored at memory location 1100 ends at memory
> location 1105 and looks like this on the wire: "Hello". (Bits actually, you
> know.)
>
> In a dynamically typed environment (Python?), a string "Hello" stored at
> memory location 1100 ends at memory location 1134 and looks like this on
> the wire: "STRING;CHARSET=UTF-8;CONTENT=Hello".
Thanks for your comments. They were thought provoking...
Having written C compilers and studied the Python C interpreter in detail,
I am generally familiar with what you are saying...I've never run across
the term "on the wire", though.
I believe that the great compile-time (static) typing vs. run-time
> (dynamic) typing debate goes like this:
> [snip]
>
Yes, I know that static and dynamic languages are different, and I'm
generally familiar with the mechanisms that make them different. Somehow
I'm trying to ask different questions.
As I was thinking about your comments, the thought arose that what I am
trying to do is discover *exactly* where my intuitions about types in
Python break down. We know they must break down--otherwise it would, in
fact, be easy to generate C from Python. That's not possible, although
PyPy is giving it a go! BTW, reductio ad absurdum is the second intuition
pump!
My first answers to where intuitions break down:
1. Aggregate types, such as lists and dicts. Analyzing the type of x in::
x = d.get(key)
can be arbitrarily tricky.
2. Aggregate types, such as classes and subclasses. Whether o.x makes
sense depends on the members defined in object o and all its subclasses.
3. Aggregate types, such as classes defined without Python source code.
Even "simple" looking types, like integer-like objects, might really be
objects of classes having __add__ members.
My present strategy is to investigate Leo's own source code, looking for
places where naming conventions are not sufficient to indicate the *actual*
types of objects.
This strategy is flexible. Leo already has some unit tests that pertain to
this topic. unit tests or other scripts could be informed that w means one
thing in Leo's core, and another thing in qtGui.py.
In short, it looks like aggregate types of various kinds pose the real test
for static type checking. It's easy to overlook how many assumptions lie
behind something like x = d.get(key).
Edward
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/groups/opt_out.
