Deleting a preloaded image from memory

T

Thomas 'PointedEars' Lahn

Bart said:
Richard said:
[...]
You appear to be confusing javascript with C or some other language.

I'm not talking about javascript code. I'm talking about how a browser
compiles javascript code.

A (Web) browser does not compile "javascript" code. ECMAScript conforming
code is either compiled or interpreted, or both, by the script engine of an
execution environment (which can be a Web browser, and is in most cases).

SpiderMonkey, which is the script engine of the JavaScript reference
implementation used in Firefox, is known to compile source code to
bytecode that is interpreted by a virtual machine. SpiderMonkey itself
is written in C.
No, 'null' is a well defined address

It is not. You are confusing languages and concepts, as Richard said.
(must be)

I does not need to at all.
and its reference is somewhere between 0x000 and 0x0000000000000

It does not have to be.
(BTW, null is not a value, it's the "not-value" that is defined that way
by 0x0...).

Nonsense. Read the ECMAScript Language Specification. `null' is a
primitive value, the sole value of the Null type, which is an object type.
It may be represented in compiled code by any value that is not used
otherwise. In that regard it is not different to the (IEEE-754) NaN and
infinities values, which are primitive values as well, of the Number type,
in ECMAScript implementations.
No, I am not

Yes, you are.
You're right - this discussion is irrelevant to javascript authoring
itself.

Oh dear. You have not even understood that there are different ECMAScript
language implementations (JavaScript, JScript, Opera-ECMAScript, KJS), and
(therefore) different script engines. Where the ECMAScript Language
Specification makes exactly no statement on how the `null' value SHOULD
or MUST be represented in implementation code. And that is good so.


PointedEars
 
T

Thomas 'PointedEars' Lahn

Bart said:
Richard said:
[...]
You are speculating,
No, I am not
Oh yes you are. You just don't have access to the information necessary
to make these generalisations.

Maybe this will convince you. Say the following javascript code:

var aVar;

That was the declaration. The computer reserves a name 'aVar' for
future use, but this name does not refer to a memory address yet at
this point.

That is questionable, since aVar is initialized to `undefined', the sole
value of the Undefined type, which is another of the built-in ECMAScript
object types, by that statement (see ECMAScript Language Specification,
Edition 3 Final, 12.2 Variable statement).

Once again, I strongly recommend to you to read the language specification
before you post further bold statements about how you /think/ things work.
For I presume nobody here needs another VK.
[...]
Since a few decades, the jobs of the flikkering lamps were taken over
by minimal chipsets in stead of bulbs, today they're even 0,001
millimeter chips or so in stead of 1 meter of bulbs. Thus the term
micro-computing and even the company MicroSoft (=software for computers
with micro-chips).

You don't say!


Score adjusted

PointedEars
 
B

Bart Van der Donck

Thomas said:
That is questionable, since aVar is initialized to `undefined', the sole
value of the Undefined type, which is another of the built-in ECMAScript
object types, by that statement (see ECMAScript Language Specification,
Edition 3 Final, 12.2 Variable statement).

That would be possible, yes. Traditionally, the declaration only
reserves the name without assigning any value to it.

Maybe javascript has another logic here (what would be the difference
between executing 'var aVar;' and 'var aVar = null;' then ?)
 
N

news

Bart said:
That would be possible, yes. Traditionally, the declaration only
reserves the name without assigning any value to it.
Traditionally? Oh, you mean, "In other languages I've
encountered"...
Maybe javascript has another logic here (what would be the difference
between executing 'var aVar;' and 'var aVar = null;' then ?)

No maybe about it, ECMAscript behaviour is to do exactly as
Thomas described:
var aVar; results in aVar having the value undefined, regardless of
where
in the particular scope block it appears
var aVar = null; results in aVar having the value undefined until
this line
is executed, whereupon it will have the value null.
 
R

Richard Cornford

Bart said:
Richard said:
[...]
You are speculating,

No, I am not

Oh yes you are. You just don't have access to the information
necessary to make these generalisations.

Maybe this will convince you. Say the following javascript code:

var aVar;

That was the declaration.

Which causes a property to be created on the Variable object for the
pertinent execution context and its value to be initialised to
Undefined (assuming the property had not previously been created as a
result of an inner function declaration, the function's formal
parameters or a preceding variable declaration using the same
identifier).
The computer reserves a name 'aVar' for
future use,

Even if the implementation language is Java and the
'Activation/Variable' object extends HashTable?
but this name does not refer to a memory address yet at
this point.

Surly that depend on how the Undefined primitive type is implemented,
among many other things.
aVar = 5;

That was the assignment. 5 is converted (to keep things
simple) to binary numerical data ...

There is no need to keep it that simple. Javascript's only numeric type
is a 64 bit IEEE double precision floating point number, so that is how
the number is represented, though almost certainly not directly as the
variable has to know both the type it holds and the value of that type.

... . Then 00000101 is allocated to an address, let's say we
name the address ABC. A programmer actually instructs the
ABC-address to remember the value 00000101 for him, in case
he would need it later. This memory allocation is a physical
(electronical/magnetic) thing inside the hardware of your PC.

The variable aVar then gets assigned to memory address ABC.

How could you be certain of that? Surly if a variable holds the address
of a location in memory where the 64 bit IEEE double precision floating
point number is stored the variable will have lost track of the type of
its value, and then how is it supposed to know that it should read 8
bytes from that location instead of, say, one bit to retrieve a boolean
value?
If we dereference aVar, we don't need name ABC anymore and we
could free that address (that is, if it was not used by something else
anymore), and thus gaining memory space to create new addresses.

In old computer languages like Assembler,

And you are describing this as it may be implemented in assembler or C,
while real javascript implementations are more likely to be written in
C++ and be using an object for their 'Variable' object that leverages
the fact that they need a hash-table like object to implement the
native ECMAScript object (so that arbitrary named properties can be
added to, and removed from, the object at run time). With a hash-table
like 'Variable' object it is entirely possible that no additional
memory is allocated at the point of adding a name/value pair to the
object.

I have said it before; you just don't have the information to be making
these types of generalisations about javascript implementations. They
are written in many languages and the specification only requires that
they achieve identical apparent behaviour, implying nothing about the
details of the implementation needed to achieve that behaviour. The
odds are extremely low that even two implementations are similar enough
to justify this type of generalisation.

... . Thus the term micro-computing and even the company
MicroSoft (=software for computers with micro-chips).

You realise that most programmes will perceive you as patronising if
you waffle on about the history of computers as if it was unknown.

Richard.
 
L

Lasse Reichstein Nielsen

Bart Van der Donck said:
Maybe this will convince you. Say the following javascript code:

var aVar;

That was the declaration. The computer reserves a name 'aVar' for
future use, but this name does not refer to a memory address yet at
this point.

That depends entirely on the implementation.

Most likely the variable is bound to a location containing the
primitive value "undefined", but maybe the declaration just
crates an entry in an internal map structure that has no fixed
location.

I.e., at this point we have:

Symbol table: Maps variable name to location
Store(e.g., memory, or a logical equivalent): Maps locations to values

and the symbol table maps the variable name "aVar" to a location,
let's call it "loc1", and the store maps that location to the
primitive value "undefined" (however that is represented).

The symbol table can contain more information on a variable than its
location. That could be the type of the value stored at the
location. If that is the case, then indeed you don't need to allocate
a location yet, since the initial value of a declared variable is the
undefined value, which is uniquely identified by its type.
aVar = 5;

That was the assignment. 5 is converted (to keep things simple) to
binary numerical data (the notation with 1's and 0's).

The string "5" is parsed by the parser and likely converted to the
corresponding value of the Number type (a 64 bit floating point
number).

The left-hand-side is evaluated to the location "loc1" (an
L-value). The value of the right-hand-side is evaluated to the
number value 5.0, and this value is stored in the location "loc1".

That means that executing this assignment statement changes the
*store* to map "loc1" to the value 5.0, and not, as previously, the
value undefined.
Suppose each memory block consists of 8 bits, then the value would
become 00000101 in this case.

It wouldn't, unless the Javascript interpreter optimizes integer
values to be stored as non-floating point representations.
More likely is the bit pattern:
0x4014000000000000
But lets let that slide for now.
Then 00000101 is allocated to an address, let's say we name the
address ABC.

As an intermediate result, this "address" is likely to be a processor
register, but it can be a stack address too.

Or maybe it is all converted into one machine code instruction that
loads a constant directly into a location, that of the variable,
without an intermediate "landing place".
A programmer actually instructs the ABC-address to remember the
value 00000101 for him, in case he would need it later. This memory
allocation is a physical (electronical/magnetic) thing inside the
hardware of your PC.

Anything a computer remembers is stored somewhere, whether in main RAM
or in register RAM on the processor.
The variable aVar then gets assigned to memory address ABC.

That's quite likely not how it happens. The binding from variable to
location in the symbol table is created when the variable is declared
and stays fixed for the lifetime of the variable (ok, maybe the
location changes due to garbage collection if it's not stored on the
stack, but it's not something the programmer controls).

Instead the value at address (or register) ABC is read and then stored
in the location of the variable, i.e., at "loc1" (i.e., the store is
updated to map "loc1" to 5.0 instead of undefined).
If we dereference aVar, we don't need name ABC anymore and we could
free that address (that is, if it was not used by something else
anymore), and thus gaining memory space to create new addresses.

You seem to be looking at the memory at a very low level here, so I
wonder what you mean by "create new addresses". I'm guessing allocation.

Since a few decades, the jobs of the flikkering lamps were taken over
by minimal chipsets in stead of bulbs, today they're even 0,001
millimeter chips or so in stead of 1 meter of bulbs. Thus the term
micro-computing and even the company MicroSoft (=software for computers
with micro-chips).

Quite a few years ago, higher level languages were created exactly to
free programmers from having to think at the physical level. A modern
language, like ECMAScript, is not defined in terms of physical actions
at all, merely in terms of its logical semantics. That means that
implementations are free to pick from a wide range of implementation
methods, as long as the final result is consistent with the semantics.
And they do.

Your low-level thinking might be correct for an implementation like
Seamonkey, which is written in a relatively low-level language, C,
but it doesn't match an implementation like "Rhino" that is written
entirely in a very non-physical language, Java.

/L
 
L

Lasse Reichstein Nielsen

Bart Van der Donck said:
Thomas 'PointedEars' Lahn wrote:

That would be possible, yes. Traditionally, the declaration only
reserves the name without assigning any value to it.

Which tradition is that? Tradition among Javascript implementations or
among programming languages in general. That latter would be
incorrect. A variable declaration would typically generate an entry
in the symbol table and allocate a location to contain the variable's
value (often by decrementing the stack pointer).
Maybe javascript has another logic here (what would be the difference
between executing 'var aVar;' and 'var aVar = null;' then ?)

The difference is that the former makes aVar contain the value
"undefined" whereas the second updates it to contain the value "null".
Both are primitive values, internally each of their own single-valued
type.

/L
 
L

Lasse Reichstein Nielsen

Thomas 'PointedEars' Lahn said:
`null' is a primitive value, the sole value of the Null type, which
is an object type.

It's an "object type" only in the sense that the "typeof" operator
is defined to return the string "object" on either an actual object
or the null value. Internally (as specified by the ECMAScript standard),
it's otherwise no different from the other single-valued type, undefined.

/L
 
B

Bart Van der Donck

Richard said:
[...]
Browsers are not the only software that executes javascript code, and
you don't know how it is done in 'a browser', or anywhere else, in
general. You can only examine how it is done in specific
implementations, and cannot validly generalise beyond that. When you
are thinking about this remember that there is at least one javascript
implementation written in javascript.

It doesn't matter where, when, how, at what time, by whatever
intermediary applications, by what compiler, by who, by what language,
on which computer, etc. the compilation was done. The result on _any_
computer is _always_ the storage of the data as a combination of 0's
and 1's into memory addresses. That _can_ be generalized.
Not necessarily. IceBrowser uses Rhino for its javascript engine, and
Rhino is written in Java, so has no pointers. If you insist on going
down through the layers you will end up at the machine code level,
where there are no 'pointers',

This is totally wrong. At its basic level, _any_ computer works with
pointers, binary numeric data and memory addresses.
only integers loaded into data and address registers, etc.

What's that, "integers loaded into data" ? Binary numericals are not
integers, if that's what you mean ? And "loaded into data", does that
mean "allocated to memory addresses" ?

Then your statement could be read as "Binary numerical values that are
allocated to memory addresses". This is indeed the correct description
of what happens then.
A memory address, it is only conceptually a block when some (byte)
length information is also associated with the value.

Wrong. A memory address is a physical storage method on a microchip.
Rhino does not compile javascript to something the machine understands,
it compiles it to something the JVM understands, and the JVM does the
next step.

And what is that next step then ? -> Something the machine understands!
:))
The intermediate steps (eg JVM) are not important, in the end
javascript will always be compiled to machine code. You can't execute
javascript without a computer, right ? In analogy, you can't use memory
if you have no physical place to store it.
The difficulty is because javascript uses automatic garbage collection,
which is not intended to be influenced by executing code.
Correct.


No, in javascript Null (the value that is assigned with - x = null -)
is a primitive value, and may or may not have any association with a
memory address.

That might be the javascript way of presenting 'null'. But, after
compilation, 'null' certainly refers to an existing memory address. How
else could a machine know what 'null' is ?
An address between zero and zero (not a very wide gap)?

It's just a numeric reference. It has no further importance here.
Not in javascript. In javascript Null is a primitive type with a single
value. The nature of that value is not specified or important. It may
be entirely arbitrary, or borrowed from the implementation language.

I see. It might be the javascript presentation of 'null'.
Memory allocation is not part of machine code. The lowest level at
which memory allocation would be expected is at the level of the OS.

Wrong. Memory allocation always happens, independent of any OS. An OS
instructs the memory allocation, yes. But it's the machine that keeps
the data available for future reference. No OS or application can keep
data for you.

C'mon Richard, you're a smart guy. We're just talking about different
levels here, that's all. I don't want to sound patronising to anyone -
I'm just talking about the very electronical, mechanical, magnetical
basics of a computer. Whatever the app or OS, you can't fool Mother
Nature. You can't switch a light on or off if you don't have a light.
I'ld say you are thinking "from the top level" (looking down from
javascript to memory) and I am thinking from the other direction.
 
V

VK

Bart said:
Indeed, not at the high javascript code level - but it does at the
browser's low compile level.

Not even there - at least not for IE under Windows. Where JScript is a
separate process run by browser from separate system DLL
(%windows%jscript.dll). This DLL in turns uses imported VBScript
modules for low level memory allocation which is turn uses umported
stubs from system.dll which in turn uses core C++ code to say fill RAM
bytes XXXXX123 - XXXXX128 with something useful (and returns it back
later). On this level you are right - but on such low level you could
say as well that JScript operates with binary data only.
These are just general basic computer
mechanisms. Every variable points (or 'references' if you like) to a
memory block address.

That is true for languages with direct memory access (with pointers)
like C or C++. You made a very good attempt to describe JavaScript from
the point of view of C++ but it's futile for that exact reason. Instead
you should look at JavaScript from the Java projection because in
memory management Java is its closest relative.

The only valuable description of JScript memory management I've found
so far (and I was rather insistent) is here:
<http://blogs.msdn.com/ericlippert/archive/2003/09/17/53038.aspx>

Further comments on it can be found here:
<http://lab.msdn.microsoft.com/produ...edbackid=fd744276-341d-4d34-87f6-3fb29c09fd8c>
(you may need Microsoft Password to get it, if you have Hotmail account
it will work too).

I cannot comment on any other UA's and other platforms rather than
Windows. No valuable info is found, which doesn't mean of course that
it doesn't exist). With Firefox you for sure can try to find the
relevant block in the distribution source.
 
B

Bart Van der Donck

VK said:
[...]. Where JScript is a
separate process run by browser from separate system DLL
(%windows%jscript.dll). This DLL in turns uses imported VBScript
modules for low level memory allocation which is turn uses umported
stubs from system.dll which in turn uses core C++ code to say fill RAM
bytes XXXXX123 - XXXXX128 with something useful (and returns it back
later). On this level you are right - but on such low level you could
say as well that JScript operates with binary data only.

Exactly. I am talking about the most basic level where the OS writes
and reads its stored data (below any application or computer language
or OS-specific functionalitites).
That is true for languages with direct memory access (with pointers)
like C or C++. You made a very good attempt to describe JavaScript from
the point of view of C++ but it's futile for that exact reason. Instead
you should look at JavaScript from the Java projection because in
memory management Java is its closest relative.

I am not talking about computer languages, but about physical memory
allocation.
I cannot comment on any other UA's and other platforms rather than
Windows. No valuable info is found, which doesn't mean of course that
it doesn't exist). With Firefox you for sure can try to find the
relevant block in the distribution source.

It doesn't matter if you're using Windows or some UNIX from 1970. It
works the same.
 
L

Lasse Reichstein Nielsen

Bart Van der Donck said:
It doesn't matter where, when, how, at what time, by whatever
intermediary applications, by what compiler, by who, by what language,
on which computer, etc. the compilation was done. The result on _any_
computer is _always_ the storage of the data as a combination of 0's
and 1's into memory addresses. That _can_ be generalized.

It's also so general that it tells us nothing.

To go back to what I remember as the beginning of this detour: The
representation of the "null" value in Javascript is not in any way
guaranteed to be any specific bit pattern.
That might be the javascript way of presenting 'null'. But, after
compilation, 'null' certainly refers to an existing memory address. How
else could a machine know what 'null' is ?

The null value will probably have a fixed binary representation,
potentially spread over a number of adresses.

There can be more than one null value stored at different locations
in memory.

The interpreter running the Javascript program (or the bytecode
created from the Javascript program) will recognize the bit pattern
wherever it's stored.

No addresses are relevant to this that are not also relevant to
numbers.

I see. It might be the javascript presentation of 'null'.

It's the Javascript definition of the null type, and null values.
C'mon Richard, you're a smart guy. We're just talking about different
levels here, that's all.

Absolutely. But you are making claims about Javascript at a level
where Javascript is not defined. Implementations can agree at the
higher abstraction level and disagree violently at lower levels,
which means that any claim made at a physical level is incorrect
for somec Javascript implementation.
I don't want to sound patronising to anyone -
I'm just talking about the very electronical, mechanical, magnetical
basics of a computer.

We all know about that. What we are failing to see is how it is
relevant.

/L
 
V

VK

Bart said:
I am talking about the most basic level where the OS writes
and reads its stored data (below any application or computer language
or OS-specific functionalitites).

On such level (which does exists of course) you cannot use then the
terms "variable", "null value", "undefined value" and even "have value
of" itself - these are human abstractions you left on the floor above
(language engine).
Different resolution level - different way to describe the mechanics.
Say electron has a mass (kind of), but you will not use mv^2 on it?
Or say "declare variable before the first use" is a good programming
practice for code reliability and readability. Yet if you dig good
enough in the lower level, you'll find that the parser does
automatically (pre-)declare all var'ed identifiers in your program.
Does it mean that "declare variable before the first use" requirement
is not applicable to JavaScript? Of course not - these are different
unrelated matters (human level and machine level).

Fiiiuuuh... a stone to someone's garden... Just you wait Mr. Higgins...
(never mind, a side comment not to you)
It doesn't matter if you're using Windows or some UNIX from 1970. It
works the same.

It doesn't work this way for Sinclair Spectrum from 1982 for sure :))
 
T

Thomas 'PointedEars' Lahn

Lasse said:
It's an "object type" only in the sense that the "typeof" operator
is defined to return the string "object" on either an actual object
or the null value. Internally (as specified by the ECMAScript standard),
it's otherwise no different from the other single-valued type, undefined.

`undefined' is the sole value of the _Undefined_ type.


PointedEars
 
B

Bart Van der Donck

VK said:
On such level (which does exists of course) you cannot use then the
terms "variable", "null value", "undefined value" and even "have value
of" itself - these are human abstractions you left on the floor above
(language engine).

On that level you can only talk about X bits that are 0 or 1 (lamp off
or on) inside each byte. Some might call this undefined/defined,
false/true, no/yes, null/not-null, 0/1, black/white etc. Use what you
like; it's just the boolean principle.
Different resolution level - different way to describe the mechanics.
Say electron has a mass (kind of), but you will not use mv^2 on it?
Or say "declare variable before the first use" is a good programming
practice for code reliability and readability. Yet if you dig good
enough in the lower level, you'll find that the parser does
automatically (pre-)declare all var'ed identifiers in your program.

Javascript declaration and initialization can be joined into one code
instruction (var abc=123 or a=123). No need to do this separately in
javascript.
Does it mean that "declare variable before the first use" requirement
is not applicable to JavaScript? Of course not - these are different
unrelated matters (human level and machine level).

These thoughts are coming from a few levels too high. I don't think
they have anything to do with memory allocation on machine level. The
javascript code will be compiled correctly anyhow.
It doesn't work this way for Sinclair Spectrum from 1982 for sure :))

It does.
 
T

Thomas 'PointedEars' Lahn

Bart said:
This is totally wrong.

You are quick with unfounded generalizations, and completely discard the
possibility that you do not know everything, or even that you may be wrong.
It's no fun discussing with you.
At its basic level, _any_ computer works with pointers, binary numeric
data and memory addresses.

(At a computer's basic level there are electrons or other smallest carriers
of information.) At the lowest machine code level (that is _not_ an
Assembler language!) there are no pointers; there are registers that can
hold _integer_ data (currently mostly stored as binary digits). But it
is still a matter of how you define "machine code level", because Java
bytecode is interpreted by the Java Virtual _Machine_. (/You/ started
this exercise in tetrapilotomy[1], you know.)


PointedEars
___________
[1] The art of splitting a single hair into four parts
(preferably of equal size).
 
R

Richard Cornford

Bart said:
Richard said:
[...]
Browsers are not the only software that executes javascript
code, and you don't know how it is done in 'a browser', or
anywhere else, in general. You can only examine how it is
done in specific implementations, and cannot validly
generalise beyond that. When you are thinking about this
remember that there is at least one javascript
implementation written in javascript.

It doesn't matter where, when, how, at what time, by whatever
intermediary applications, by what compiler, by who, by what
language, on which computer, etc. the compilation was done.
The result on _any_ computer is _always_ the storage of the
data as a combination of 0's and 1's into memory addresses.
That _can_ be generalized.

And the result is so general that it is utterly trivial. Hardly worth
saying at all.

Remember that you responded to the suggestion that:-

| Setting a pointer to null obviously won't delete the object
| pointed to from memory, but just change the address the
| pointer is referencing (from address of the object to
| null = 0x0000000).

- was pure speculation with the rather specific assertion that "That is
no speculation - it's just how this works", and went on to detail the
precise process of assigning a value to a variable in javascript. These
were not generalisations about how computers work. Rather they were
generalisations about what javascript implementations do, and you don't
have the information necessary to be saying that these things are true
or (or even relevant to) all javascript implementations.
This is totally wrong. At its basic level, _any_ computer works
with pointers, binary numeric data and memory addresses.

In machine code there are no pointers. 'Pointer' is a concept that may
apply to some values but that concept is in the mind of the programmer
not inherent in the machine code.
What's that, "integers loaded into data" ?

Data registers, as in data registers and address reregisters, etc.
(where etc. may be, for example, the program counter).
Binary numericals are not integers,

Above you described them as "a combination of 0's and 1's", when there
are no actual ones or zeros in the hardware. Any bit pattern can be
conceived as a representation of an integer value.
if that's what you mean ? And "loaded into data",
does that mean "allocated to memory addresses" ?

I mean that if you look down as far as the state of the electronic
circuits there is no inherent meaning in anything you see. No pointers,
no allocated memory, not variable and so on.
Then your statement could be read as "Binary numerical values
that are allocated to memory addresses". This is indeed the
correct description of what happens then.

That is writing more in than I meant to say, which was only that at that
lowest level you have nothing but bit patterns in electronic circuits.
that is what happens, but there is little point stating it.
Wrong. A memory address is a physical storage method on a
microchip.

No they are not, and that was not my point anyway. Conceptually a
'block' has a magnitude in addition to a location. The address is only a
location.
And what is that next step then ? -> Something the machine
understands! :))
The intermediate steps (eg JVM) are not important,

You said:-

| Referencing and memory allocation take place when
| the browser compiles the javascript to something
| the machine understands.

- in which "the *browser* compiles the javascript to something the
machine understands" (stress added by me) is a questionable assertion
when the browser is written in Java and the javascript complied into
bytecode. It is, as you say, the JVM that produces the actual executable
code, not the browser as you asserted.

And preceding that with "memory allocation take place when ..." is also
questionable as memory allocation may not happen at that point, or not
entirely happen at that point, some of it may be happening later, when
the JVM creates the executable code, or when that code is actually
executed. The language that the browser and javascript interpreter are
written in can make a great deal of difference to where and when memory
allocation may happen. You just don't have the information to generalise
about what a browser may do internally, or when it may do it.
in the end javascript will always be compiled to
machine code.

That is not necessarily true. The most that can be said is that
executing javascript involves executing machine code, but that is also
too trivial to be worth saying.
You can't execute
javascript without a computer, right ?

That is precisely why the above is trivial.
In analogy, you can't use
memory if you have no physical place to store it.
err?



That might be the javascript way of presenting 'null'.

If you are assigning null in javascript it is what null is in javascript
(and what it is not) that is significant.
But, after compilation, 'null' certainly refers to an
existing memory address.

Null does not have to be implemented as the sort of thing that refers at
all.
How else could a machine know what 'null' is ?

The machine doesn't have to care, only the implementation software needs
to have an attitude about how null is implemented.
It's just a numeric reference. It has no further
importance here.


I see. It might be the javascript presentation of 'null'.

Your mistake here is assuming that null must necessarily have s specific
concrete manifestation. Javascript only requires that null be an
implemented concept, and so it can have any manifestation that the
implementers likes.
Wrong. Memory allocation always happens, independent of
any OS.

Machine code is capable of addressing any location made available in the
hardware, at any time. The concept of reserving, allocating and freeing
areas in memory needs to be implemented by a programmer, it is not
inherent in machine code.
An OS instructs the memory allocation, yes. But it's the
machine that keeps the data available for future reference.

But the hardware does not prevent any machine code from writing to any
memory at any time. That level of control of memory access is something
that is programmed as a layer above the hardware, and usually that
program is a fundamental aspect of the OS.
No OS or application can keep
data for you.

The OS can, and usually does, impose the control over which software
uses which memory, when and how.
C'mon Richard, you're a smart guy. We're just talking
about different levels here, that's all.

We are supposed to e talking about javascript here, so your
generalisations about the behaviour of javascript interprets and web
browsers pitched at a level below the javascript implementation, are
inappropriate, irrelevant, and probably wrong due to the freedom
allotted to the implementers to achieve the required behaviour in any
way the want.

I'ld say you are thinking "from the top level" (looking
down from javascript to memory) and I am thinking from the
other direction.

Looking down it is possible to see that the possible permutations
multiply so rapidly at the implementation level that it cannot be
possible to declare a single outcome at the lowest level without that
outcome being so trivial that it has no relevance to the actual writing
of javascript code. That also makes it obvious that starting at the
lowest level with any specific scheme cannot lead back up to any
generalisations about javascript.

The bottom line is that it doesn't matter what null may actually be,
just that assigning null to a variable that previously was the only
reference to an object will result in there being no accessible
references to the object remaining in the system. So that object then
becomes available for automated garbage collection, which may happen at
any subsequent point but should result in resources consumed by the
object becoming available again (in some sense).

Richard.
 
L

Lasse Reichstein Nielsen

Thomas 'PointedEars' Lahn said:
Lasse Reichstein Nielsen wrote:

[about "null"]
`undefined' is the sole value of the _Undefined_ type.

.... just as "null" is the sole value of the _Null_ type.

One could argue that the Null type isn't really necessary.
/L
 
T

Thomas 'PointedEars' Lahn

Lasse said:
Thomas 'PointedEars' Lahn said:
Lasse Reichstein Nielsen wrote: [about "null"]
Internally (as specified by the ECMAScript standard),
it's otherwise no different from the other single-valued type,
undefined.

`undefined' is the sole value of the _Undefined_ type.

... just as "null" is the sole value of the _Null_ type.

ACK. There is in fact no notion in the specification that Null or
Undefined are Object types. And especially the definition of the
internal ToPrimitive operator suggests that they are not. I got
confused with all Object types starting with capital letters, and
assumed that therefore (and because of `typeof null') Null and
Undefined are Object types, too. My bad.
One could argue that the Null type isn't really necessary.

ACK. But from what I can see, the specification of operators
and algorithms would have been more complicated without it.


PointedEars
 
V

VK

ACK. But from what I can see, the specification of operators
and algorithms would have been more complicated without it.

"null" and "undefined" (and the 3rd "empty" in some languages but not
in JavaScript) are abstactions over the concept of "nothing is here".
It is like an empty room where I took every single item out, and
another empty room no one ever put any item in yet.
Factually it is the same empty room in either case. But in the first
case the emptiness is the result of an explicit action, in the second
case it is the default "natural" state. The first case is "null", the
second case is "undefined". This distinction is being useful in some
cases. JavaScript though has a specific of having "undefined" as a
value one can /assign/ as any other value. IMHO that is one of cases
then in attempt to simplify one matter they unnecessary complicate
other. IMHO.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top