|
|
|
| Authored by: xtifr on Wednesday, May 23 2012 @ 12:50 AM EDT |
Besides, if it could be symbolic than 2=3 is a possibly
acceptable statement and that just looks bad :)
I think it's
actually possible to do something like that in some versions of Fortran, though
not so directly. I think you have to pass a number where the system is
expecting a variable, and then it can assign a new value to the number, which
then affects any other code that uses that number. I'm not sure of the details,
though, or whether that's still true in any modern versions of
Fortan.
In Forth, there are no restrictions on names whatsoever, and
it's standard to define 0 as a constant with the value of zero, because
constants use less memory than literal numeric values.* It only affects code
compiled after the constant is defined, though, not the whole system. But you
can define 0 to be anything--another number, a random number generator,
or a game of pong. (Not that I recommend it.) :)
* if used often
enough. There's a fixed amount of overhead for each declared constant, but then
each use of the constant requires less memory than a literal value would. The
number 0 tends to get used a whole lot.
---
Do not meddle in
the affairs of Wizards, for it makes them soggy and hard to light. [ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Wednesday, May 23 2012 @ 08:16 AM EDT |
The example might be more clear if the syntax of the language allowed us to
define a symbol_named_2, having the numeric value 2 by saying:
"2"=2, "3"=3, "123"=123,
and then somewhere else in the program we say:
x="2" + "3" + "123" with the result that the
symbol X now, indirectly, refers to a location containing 128.
Of course we could also say "5"="Hello world :)" and
Print "5" would print
Hello world :)
In our attempts to clarify and understand this 'symbolic' thing as it relates to
the case, for brevity, we've used names/symbols such as "a",
"y"....etc. which might not take much time to resolve dynamically.
But that wouldn't make much sense in the real world where we have lots of memory
and HDD/SSD space. (Way back when systems were small (really small), programmers
used single character names because otherwise they couldn't get a program to fit
existing memory/storage).
Most programs contain much longer, meaningful, names such as:
"the_intermediate_result_after_doing_a_specific_something"
because we humans have to have that to keep things straight in our (human)
minds.
That's a BIG symbolic reference to a value that will eventually be found
someplace in memory. It takes a lot longer to resolve it to a memory location.
So, for run time efficiency, the symbol should/must be resolved before we 'run'
the program (and then never need to be resolved again unless the source code is
changed, etc. and we need to revise the bytecode).
Dexopt was designed to do just that, it resolves it, just once, calculating a
numeric offset value (from the beginning of the program) and stores the offset
in the Dalvik bytecode.
The DVM does_not_dynamically_resolve_a_symbolic_reference because it can't, the
symbolic reference is not in the bytecode.
The DVM sees and uses only the numeric offset, which_is_not_a_symbol. (Of course
Oracle is trying to confuse things by saying that when we (humans) look at the
offset number, that the number_is_a_symbol too. But the computer doesn't see it
that way, it sees it as a_specific_final_value that can be used immediately.)[ Reply to This | Parent | # ]
|
|
|
|
|
