www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - list of anything

reply spir <denis.spir gmail.com> writes:
Hello,

In Lisp-like languages, a list can hold anything:
	(1 "a" (1 "a"))
I do not find it trivial to simulate this in D. Using a linked list or an a=
rray: the issue is not with the kind of collection but with elements. In ei=
ther case, I guess, elements should actually be void* pointers. But then, t=
he type is lost; to properly get back stored values, it seems one would hav=
e to add tagged-union-like tagging --but for pointers.

How would you do that? Various proposals welcome :-)

Side-issue: to cast back elements, I wanted to store the actual element typ=
e. But I could not find a way to do that, instead get weird error messages =
like eg 'int' is not a value (so, what else?). For a typed collection (temp=
late), it is well possible to store the element type, like eg:
	struct List(T) {
	    alias T Element;
	    ...
	}
But this indeed gives a typed collection. So, what's the issue indicated by=
 the error?
If I don't have the type, the tag can only be a pseudo-thingie (possibly me=
mber of an enum) used with a possibly very long switching sequence. Meaning=
 instead of something like:
	value =3D *(cast(type*)element);		// type is called 'type'
I need to write:
	if (type =3D=3D Types.integer)		// enum 'Types'
	    value =3D *(cast(int*)element);
	else if .......
Very annoying.

Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com
Dec 18 2010
next sibling parent Tomek =?ISO-8859-2?Q?Sowi=F1ski?= <just ask.me> writes:
spir napisa=B3:


 In Lisp-like languages, a list can hold anything:
 	(1 "a" (1 "a"))
 I do not find it trivial to simulate this in D. Using a linked list or an=


 array: the issue is not with the kind of

 collection but with elements. In either case, I guess, elements should ac=


tually be void* pointers. But then, the type

 is lost; to properly get back stored values, it seems one would have to a=


dd tagged-union-like tagging --but for

 pointers.
=20
 How would you do that? Various proposals welcome :-)


std.variant is the discriminated union type in Phobos. Conversion back to o=
riginal type is not implicit, though.

--=20
Tomek
Dec 18 2010
prev sibling parent reply David Nadlinger <see klickverbot.at> writes:
On 12/18/10 1:16 PM, spir wrote:

 But I could not find a way to do that, instead get weird error messages like
eg 'int' is not a value (so, what else?).


It is a type, and as such a compile-time entity rather than a runtime 
value. You might want to have a look at »typeid()« though, which returns 
runtime type information.

Is there a reason why something like std.variant doesn't fit the bill?

David
Dec 18 2010
parent reply spir <denis.spir gmail.com> writes:
On Sat, 18 Dec 2010 13:35:21 +0100
David Nadlinger <see klickverbot.at> wrote:


 But I could not find a way to do that, instead get weird error messages=




 like eg 'int' is not a value (so, what else?). =20

 It is a type, and as such a compile-time entity rather than a runtime=20
 value. You might want to have a look at =C2=BBtypeid()=C2=AB though, whic=


h returns=20

 runtime type information.


Thank you. i understand this, but many elements are compile-time things and=
 still available at runtime: all consts, static, enum... and all funcs! See=
ms only types vanish.


 Is there a reason why something like std.variant doesn't fit the bill?


Don't know the module (yet). Many it's what I need (if element types can be=
 custom types, then certainly variant would do the job).

Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com
Dec 18 2010
parent bearophile <bearophileHUGS lycos.com> writes:
spir:


 i understand this, but many elements are compile-time things and still
available at runtime: all consts, static, enum... and all funcs! Seems only
types vanish.


Right. They traditionally "vanish" because most times you don't need them, so
you save both some memory and computations at runtime. D style is to work more
on types at compile-time. More or full run time reflection might be added but
at the moment this is a bit against D design philosophy. D is a more powerful
C, it's not a more Algol-style Dylan.

Bye,
bearophile
Dec 18 2010