Re: How to implement dynamic typing?

"bartc" <bartc@freeuk.com> wrote
> "BGB / cr88192" <cr88192@hotmail.com> wrote in message
>> "David Belier" <davidbleier@hotmail.com> wrote in message
>>> Recently I finished chapter 7 of the dragon book (2nd edition) but I
>>> still don't understand how to implement dynamic typing. I don't get
>>> how you are supposed to store the type information with each variable
>>> and check it every time using an acceptable amount of resources and
>>> time. Can someone please name papers or websites to read?
>>
>> as others have said, it is not stored with the variable.
>
> Yes, quite a few people have said that.


in most dynamic languages of which I am aware, this is also generally the
case.




> Yet, I *do* store a tag with the variable! So clearly I must be doing
> something wrong...


not necessarily, although this is not the standard way of doing things.




> In:
>
> A := (1, "two", 3.0)


> a tag is stored with the variable A (saying it is a list), but tags
> are also stored for each of the values (saying they are an integer,
> a string, and a float). (In this implementation, A is not a
> pointer, it is a descriptor containing, for this example, the list
> tag, the length of the list (3), and a pointer to the elements, each
> in turn being a descriptor.)


> So more accurately tags can be stored with both variables and values.




I once considered the possibility of doing something roughly along these
lines, but mostly since I was considering writing an interpreter for MSIL.


the reason here is that storing types with the variables does allow better
emulating the semantics of static-typing, which may matter some in many
cases.


however, the space overhead though is likely to be a bit higher than plain
dynamic typing (where types are usually kept in the references and/or heap
objects), since now variables generally also need type tags.


however this may also save space (as well as reducing heap-based
allocations), when dealing with C-style memory objects (since, for example,
having an additional heap object to identify the type as well as to hold a
pointer, is not exactly free either).




for example, in a recent effort of mine to adapt an interpreter for a
language of mine (BGBScript, largely inspired by JavaScript) to have a
relatively seamless interface with C, I have ended up using a lot of, in
all, fairly nasty hacks (including having heap objects which do little more
than hold a type signature and pointer to another object). in this case,
having explicitly typed variables would help.


as well, I had essentially implemented a lot of typesystem mechanics as
essentially semi-disjoint systems:
a lot of stuff for C -tyle type mechanics, a lot of stuff for a Java/C#-like
typesystem, and a lot of stuff for dynamic typing.


however, in the more recent effort in many places I am ending up having to
further cross these lines, and not always necessarily cleanly. admitted, in
many cases this is more a matter of APIs, as actually a fair amount of the
internal machinery tends to be common between the systems.




actually, it was ammusing that in a lot of this, I wasn't just sitting
around fiddling with C code, but actually using BGBScript to probe and mess
around with stuff in C land.


admittedly, there are many ambiguous cases, such as for example, when it is
better to see a given object as its C-side representation, or as its
dynamically-typed form (not always equivalent). however, as-is, as a general
rule it defaults to seeing the dynamically-typed object, and I may later add
API facilities to gain access to the underlying C structures.


for example, the API call could be supplied with the name of a C-level type
to "cast" to (the other likely option would likely require adding metadata
annotations to the C headers to map particular dynamic type names to
particular C-level types).




a related ambiguity was when to marshall an array as the array object, or as
a pointer to the first element. this also ended up involving a little
hackery, but the current strategy (dynamic references getting the array
object, pointers getting the first element) should be about right, and
meshes well with my existing practice.

Return to the comp.compilers page.
Search the comp.compilers archives again.