More D newb questions.

[Me Here]

Walter Bright wrote:

> First of all, what if you wanted
> 	T ~ T => T[]
> for all types in generic code? You've got an obvious problem, because it
> behaves very inconsistently for different types. 

This is exactly why Haskell and other Category Theory based type-inferencing 
languages dispatch on type signatures that combine both the parameters
*and* the return type.

See http://en.wikibooks.org/wiki/Haskell/Category_theory

	A category is, in essence, a simple collection. 
	It has three components:
	- A collection of objects. ...
	- A collection of morphisms, each of which ties two objects 
            (a source object and a target object) together. ...
	- A notion of composition of these morphisms. ...

Trying to do type inferenceing without taking return type into account 
during method resolution is doomed to fail.

There's also the concept os substitutability. 
T and T[...1...] (meaning any one element of t[]), should be substitutable.
In D, they aren't

>Secondly, what about
> structs? Should structs behave like basic types, or like arrays here? (I
> discussed this conundrum further in another post in this thread.)

If the struct has a opCat method with match type signature, dispatch to it.
If not, raise an error.

Can I imagine a use for T ~ T in conjunction with a struct? 
Yes. A single linked list might well use:

	head ~ node;
or
	list ~= newNode
> 
> > What does that equate to, maybe 8 or 10 opcodes?
> 
> That's a lot when you're faced with a "D sucks because array ops are slow"
> benchmark. It can double the time in the loop.

Hmm. How do you balance that view with the impact of
immutable strings in Dv2?

> 
> > (*BTW. Why does char[] replaceSlice(char[] string, char[] slice, char[]
> > replacement) require both the target string and target slice of that
> > string?)
> 
> Because all three parameters are needed to give sufficient information.

I kinda guessed it was done for a reason, but was looking for a clue as to
what that reason was. I (probably wrongly, given how bad my assumptions
about what D is doing under thc covers so far have panned out) that a 
slice carried enough information to identify the array it is a slice of.

Eg. (something like) struct slice { T[]* parent; type_t pos; type_t length }

I guess I have to did around in teh source, assuming that is a part of the open
sources.

Cheers, b.
--