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 array: the issue is not with the kind of collection but with elements. In either case, I guess, elements should actually be void* pointers. But then, the type is lost; to properly get back stored values, it seems one would have 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 type. 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 (template), 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 member of an enum) used with a possibly very long switching sequence. Meaning instead of something like:
	value = *(cast(type*)element);		// type is called 'type'
I need to write:
	if (type == Types.integer)		// enum 'Types'
	    value = *(cast(int*)element);
	else if .......
Very annoying.

Denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com

spir napisał:

> 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 actually be void* pointers. But then, the type
> is lost; to properly get back stored values, it seems one would have to add tagged-union-like tagging --but for
> pointers.
> 
> How would you do that? Various proposals welcome :-)

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

-- 
Tomek

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

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?).
> 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.

Thank you. 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.

> 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 ☣

spir.wikidot.com

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