[DGD] typeof bug?

[Robert Forshaw]

>In DGD, typeof is a plain function (although a kfun) that gives you the
>dynamic type of a value, and not, as Pär Winzell pointed out, a language
>device that gives you the static type of a variable. Note the
>distinction between variable and value.
>
>When you invoke typeof with a typed variable containing the nil value,
>nil is copied from your typed variable into the untyped (mixed)
>parameter of typeof. This effectively discards the type information of
>the variable. So all typeof can do is inspect the value you pass it. And
>the nil value has no type.

I had already understood that, though you have (implicitly) pointed out that 
I was using the term "variable" imprecisely, to refer to both its value and 
itself. So thanks for that. :)

> > Here's the macro in question that gave rise to my discovery that typeof
> > doesn't do what I thought it did:
> >
> > #define EMPTY(X) { if(typeof(X) == T_STRING) X = ""; else if(typeof(X) 
>==
> > T_ARRAY) X = ({ }); else X = nil; }
> >
> >
> > In literature, one tries to express as much as possible with as few 
>words as
> > possible. By the same reasoning, I want to achieve as much function as
> > possible with as little code as possible (with as much lucidity as
> > possible), and this is my means of doing that. That is why I would find 
>such
> > a feature useful. Here's just a few of the other definitions and macros 
>I
> > like to use:
>

>Concerning literature, I strongly disagree with your view. Being brief
>and to the point is a merit. But this should not be taken too far,
>because then the text will be terse and difficult to absorb. The same
>holds true for programming languages. But perhaps you and I mean the
>same thing?

When I say I want to express as much with as little, I'm speaking primarily 
in the cognitive sense, not in terms of how much function is achieved by the 
code (that is a secondary goal). I want to be able to glance at a page of 
code and immediately see what it does. I want to be able to read rather than 
interpret. I want to elucidate rather than obfuscate.

e.g. take the following lines of code:

s = "";
s = EMPTY_STRING;
EMPTY(s);

These all do the same thing, but if I have to look at one line a millisecond 
longer, I'll go for the one that conveys its' meaning to me more quickly. It 
all adds up.

I don't know whether you think the "terse and hard to absorb" argument was 
refering to literature or programming, or both, Since you give no example of 
something being "terse and hard to absorb" I can't comment. From where I 
stand now I certainly don't agree. (Incidently, by literature I really meant 
fiction).

>
> > #define EMPTY_ARRAY ({ })
> >
> > #define EMPTY_STRING ""
> >
> > #define SWAP(X, Y) { mixed val; val = (X); X = (Y); Y = val; }
> >
> > #define ARR_INCREASE_SIZE(X, INC) { X += allocate(INC); }
> >
> > #define GET_BIT(C, B) (((C) << (31 - (B))) >> 31)
> >
> > #define ARR_REDUCE_BY(X, A) if(A < sizeof((X))) X = X[..sizeof(X) -\
> > (A + 1)]; else X = EMPTY_ARRAY;
> >
> > #define UNTIL(X) while(!(X))
> >
> > #define ARR_SET_MAX(X, MAX) { if(MAX < sizeof(X)) {\
> > if(MAX > 0) { X = X[..MAX - 1]; } else { X = EMPTY_ARRAY; } }\
> > else { X += allocate(MAX - sizeof(X)); } }
> >
> > #define REMOVE_ELEMENT(A, E) A = A[..E - 1] + A[E + 1..];
> >
> > #define MAX(V, M) ((V) > (M) ? (M) : (V))
> > #define MIN(V, M) ((V) < (M) ? (M) : (V))
> >
> > #define APPEND(A, X) A += ({ X });
> >
> > #define LOOPVARS() int i, sz;
> >
> > #define ITOC(I) (((string)(I))[0])
> >
> > #define IS_EMPTY(V) (!(V) || (V) == EMPTY_STRING)
> >
> > ...and so on.
> >
> > As an aside, I'm coding a pseudo-language which is parsed into LPC.
> > Preprocessor definitions come in very handy when trying to keep my code
> > short and to the point.
>
>Macros are kludgy and should generally be avoided. I won't argue why, as
>there are many good explanations on the Web and elsewhere.

I don't know what you mean by "kludgy", nor have I experienced anything but 
an immediate advantage to using these macros. I'll try looking up these 
explanations you allude to and then see if I want to continue using macros.

>Most of the macros above are better implemented as functions.

Since I don't know what your "kludgy" argument refered to, I have no context 
by which I can determine why you think they would be better implented as 
functions. Quite a few of them would take a longer execution time as 
functions, declaring more superfluous variables. Take ARR_REDUCE_BY(X, A) 
for instance. As a function, it would have to return a value and I would 
have to assign that value back onto a variable. So ARR_REDUCE_BY(x, a) would 
become a = arr_reduce_by(x, a);. And in some cases I can not achieve the 
code I want at all save with a macro (or typing it out by hand). e.g. 
SWAP(X, Y). Neither the function, nor the typing it out manually, 
accomplishes what I'm aiming for by the use of macros.

>As another aside, if your language is parsed into LPC, compiled, and
>executed, it is by definition not a pseudo-language but a real one.

Thanks for the clarification. Does the concept "psuedo-language" refer to 
anything specific?

_________________________________________________________________
Want to block unwanted pop-ups? Download the free MSN Toolbar now!  
http://toolbar.msn.co.uk/