Nothingness

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Nothingness

Håkan Stenholm-2
If the table is truely spares you could allways  enter each field as a
single database element and use the original 'table key + fieldname' as
the key for this 'single field' database.
This would avoid the need to use any kind of 'nil' value alltogether.



Reply | Threaded
Open this post in threaded view
|

Nothingness

Erik Pearson-2
That is a good idea. However, in this case I'm anticipating the need to do
pattern matching on multiple fields, and being able to retrieve records in
a single chunk is quite nice. Also, each field would require extra storage
for the "fieldname", no?

Interestingly, records do support the concept of "undefined" ...

Erik.

--On Saturday, October 27, 2001 12:09 AM +0200 H?kan Stenholm
<hokan.stenholm> wrote:

> If the table is truely spares you could allways  enter each field as a
> single database element and use the original 'table key + fieldname' as
> the key for this 'single field' database. This would avoid the need to
> use any kind of 'nil' value alltogether.
>



Erik Pearson
@ Adaptations
email     : erik
voice/fax : +1 510 527 5437
text page : page.erik



Reply | Threaded
Open this post in threaded view
|

Nothingness

Vance Shipley-2
>
> Interestingly, records do support the concept of "undefined" ...
>
> Erik.

-module(undef).
-export([test/0]).

-record(r1, {name, phone, address}).

test() ->
        #r1{name = "Joe", phone="5551234"}.


Erlang (BEAM) emulator version 5.1 [threads:0]

Eshell V5.1  (abort with ^G)
1> c(undef).
{ok,undef}
2> undef:test().
{r1,"Joe","5551234",undefined}




   -Vance


Reply | Threaded
Open this post in threaded view
|

Nothingness

Erik Pearson-2
Or this:

-module(undef).
-record(undef,{x}}.
-export(undef/0).
undef() -> (#undef{})#undef.x.

Then if you do:

c("undef").
is_atom(undef:undef()).
true

And if you further explore, e.g.

size(atom_to_binary(undef:undef())).
13

you'll find that all that is really returned is the atom 'undefined'. Not
very exciting :(

However, 'undefined' is used throughout the otp (over 2K occurrences in the
erl source for lib) -- if you grep through the sources it is used
everywhere. There is one entry in the spec for 'undefined', and it is
uneventful. Alas, 'undefined' is just a regular atom, and a long one at
that, so unsuitable for storage in a mnesia table.

Erik.

--On Friday, October 26, 2001 8:52 PM -0400 Vance Shipley
<vances> wrote:

>>
>> Interestingly, records do support the concept of "undefined" ...
>>
>> Erik.
>
> -module(undef).
> -export([test/0]).
>
> -record(r1, {name, phone, address}).
>
> test() ->
> #r1{name = "Joe", phone="5551234"}.
>
>
> Erlang (BEAM) emulator version 5.1 [threads:0]
>
> Eshell V5.1  (abort with ^G)
> 1> c(undef).
> {ok,undef}
> 2> undef:test().
> {r1,"Joe","5551234",undefined}
>
>
>
>
>    -Vance



Erik Pearson
@ Adaptations
email     : erik
voice/fax : +1 510 527 5437
text page : page.erik



Reply | Threaded
Open this post in threaded view
|

Nothingness

Robert Virding-4
Why all this?

As you state at the end 'undefined' is just an atom.  This means that
its storage IS efficient in a mnesia table, at least for tables in
memory, and the length of the atom is irrelevant.  All that is stored
is an atom identifier.

I suppose we could have called the atom '$undefined$' or some such to
make it a little more clear that this value was different.

Robert

Erik Pearson <erik> writes:

>Or this:
>
>-module(undef).
>-record(undef,{x}}.
>-export(undef/0).
>undef() -> (#undef{})#undef.x.
>
>Then if you do:
>
>c("undef").
>is_atom(undef:undef()).
>true
>
>And if you further explore, e.g.
>
>size(atom_to_binary(undef:undef())).
>13
>
>you'll find that all that is really returned is the atom 'undefined'. Not
>very exciting :(
>
>However, 'undefined' is used throughout the otp (over 2K occurrences in the
>erl source for lib) -- if you grep through the sources it is used
>everywhere. There is one entry in the spec for 'undefined', and it is
>uneventful. Alas, 'undefined' is just a regular atom, and a long one at
>that, so unsuitable for storage in a mnesia table.
>
>Erik.


Reply | Threaded
Open this post in threaded view
|

Nothingness

Robert Virding-4
In reply to this post by Vance Shipley-2
I am pretty sure that in the manual it explicity states that the value
of a record field which is not given a value when the record is
created and does not have an explicit default value will have the value
of the atom 'undefined'.

Or least it should because this is what happens.

Robert

"Vance Shipley" <vances> writes:

>>
>> Interestingly, records do support the concept of "undefined" ...
>>
>> Erik.
>
>-module(undef).
>-export([test/0]).
>
>-record(r1, {name, phone, address}).
>
>test() ->
> #r1{name = "Joe", phone="5551234"}.
>
>
>Erlang (BEAM) emulator version 5.1 [threads:0]
>
>Eshell V5.1  (abort with ^G)
>1> c(undef).
>{ok,undef}
>2> undef:test().
>{r1,"Joe","5551234",undefined}


Reply | Threaded
Open this post in threaded view
|

Nothingness

Erik Pearson-2
In reply to this post by Robert Virding-4
Aye, the rub: this is a mnesia table on disk, where atoms are stored as
binaries.

--On Saturday, October 27, 2001 4:56 PM +0200 Robert Virding
<rv> wrote:

> Why all this?
>
> As you state at the end 'undefined' is just an atom.  This means that
> its storage IS efficient in a mnesia table, at least for tables in
> memory, and the length of the atom is irrelevant.  All that is stored
> is an atom identifier.
>
> I suppose we could have called the atom '$undefined$' or some such to
> make it a little more clear that this value was different.

That might have been helpful --

Is there a technical reason why there could not be a special type of term
-- not an atom, a list, or anything else -- which means 'undefined'?

It could be detectable with the function "is_undefined/1" or
"is_defined/1", and set with "undefined/0"... perhaps would need its own
printable representation... could have its own binary transformation...


Erik.

>
> Robert
>
> Erik Pearson <erik> writes:
>> Or this:
>>
>> -module(undef).
>> -record(undef,{x}}.
>> -export(undef/0).
>> undef() -> (#undef{})#undef.x.
>>
>> Then if you do:
>>
>> c("undef").
>> is_atom(undef:undef()).
>> true
>>
>> And if you further explore, e.g.
>>
>> size(atom_to_binary(undef:undef())).
>> 13
>>
>> you'll find that all that is really returned is the atom 'undefined'.
>> Not  very exciting :(
>>
>> However, 'undefined' is used throughout the otp (over 2K occurrences in
>> the  erl source for lib) -- if you grep through the sources it is used
>> everywhere. There is one entry in the spec for 'undefined', and it is
>> uneventful. Alas, 'undefined' is just a regular atom, and a long one at
>> that, so unsuitable for storage in a mnesia table.
>>
>> Erik.



Erik Pearson
@ Adaptations
email     : erik
voice/fax : +1 510 527 5437
text page : page.erik



Reply | Threaded
Open this post in threaded view
|

Nothingness

Erik Pearson-2
In reply to this post by Robert Virding-4
The only indexed reference I found to "undefined" is on page 47 of the
spec, which is in reference to "LIA-1 functions", and not at all in the
book (concurrent programming...). It is however fully documented for the
case of records in the text of the "extensions since 4.4" document.

Erik.

--On Saturday, October 27, 2001 4:59 PM +0200 Robert Virding
<rv> wrote:

> I am pretty sure that in the manual it explicity states that the value
> of a record field which is not given a value when the record is
> created and does not have an explicit default value will have the value
> of the atom 'undefined'.
>
> Or least it should because this is what happens.
>
> Robert
>
> "Vance Shipley" <vances> writes:
>>>
>>> Interestingly, records do support the concept of "undefined" ...
>>>
>>> Erik.
>>
>> -module(undef).
>> -export([test/0]).
>>
>> -record(r1, {name, phone, address}).
>>
>> test() ->
>> # r1{name = "Joe", phone="5551234"}.
>>
>>
>> Erlang (BEAM) emulator version 5.1 [threads:0]
>>
>> Eshell V5.1  (abort with ^G)
>> 1> c(undef).
>> {ok,undef}
>> 2> undef:test().
>> {r1,"Joe","5551234",undefined}



Erik Pearson
@ Adaptations
email     : erik
voice/fax : +1 510 527 5437
text page : page.erik