What about runtime analysis of a classes members. Instead of assuming and depending on a classes function members to be located in one place, have it do a search and find the location of the function at runtime? Or if you insist upon using messages, why not use object identifiers with function name calls. So I can call a function of a class through messages, if the function does not exist it returns an error, if the function has moved it will find it and call it properly. Hmmm, maybe messages are better after all, because I could shut off an object to not recieve messages, alter that object and then turn it back on to recieve messages, this by manipulating/reprogramming an object at runtime (maybe I am being a runtime freak :)).

Messages would be really interesting come to think of it. An object would need to have a socket where by a delegate could be placed in there, that delegate would know what message to send and whom to send it to. An object that sends messages would need these sockets for delegation. There really is no event handlers anymore, any function could be an event handler, its now on the other side, the delegates reside in the event generator and control what function is called in response to the generation of that event by sending a message to that function.

It may even be possible to mix messages and direct function calls, delegate objects/types could be used to mask what is really happening underneath.

What you are describing is more or less the Objective-C runtime.

In Obj-C, when you write:

    [object drawAtX: x Y: y]

what it does is create a message packet with a "selector" of drawAtX:y: and arguments (object, x, y), and then invoke a runtime routine (something like __objc_msgSend) to lookup runtime tables for the object that knows how to respond to that. It first checks the given target (object). But the given target may not respond to the message, in which case various forwarding mechanisms exist.


Christophe

interested wrote:

> What about runtime analysis of a classes members. Instead of assuming and depending on a classes function members to be located in one place, have it do a search and find the location of the function at runtime? Or if you insist upon using messages, why not use object identifiers with function name calls. So I can call a function of a class through messages, if the function does not exist it returns an error, if the function has moved it will find it and call it properly. Hmmm, maybe messages are better after all, because I could shut off an object to not recieve messages, alter that object and then turn it back on to recieve messages, this by manipulating/reprogramming an object at runtime (maybe I am being a runtime freak :)).
>
> Messages would be really interesting come to think of it. An object would need to have a socket where by a delegate could be placed in there, that delegate would know what message to send and whom to send it to. An object that sends messages would need these sockets for delegation. There really is no event handlers anymore, any function could be an event handler, its now on the other side, the delegates reside in the event generator and control what function is called in response to the generation of that event by sending a message to that function.
>
> It may even be possible to mix messages and direct function calls, delegate objects/types could be used to mask what is really happening underneath.

> A practical example: I have a window object, that can respond to several "messages" (display, resize, etc). On this window, I have several objects that know about some of the messages, but others they just don't care. One object which has the focus is the one that receives the messages from the operating system.

I agree, looking at all the application frameworks out there, MFC, MacApp and so forth, they all have a common theme, pass around messages or events from one point to another. As C and C++ does not have runtime binding easily available, what happens is that the framework designers write very convoluted macro or lookup systems for making sure a message is passed from one point to another. Objective-C makes this far easier with its message passing  construct. If D has this option, and it's of course another performance burden, but not as bad as one thinks, it would open up a lot of good designs concerning writing application frameworks. If one even thinks big and possibly uses a message passing system that could make use of open standards for calling other entities (SOAP, XML-RPC, and so forth), it could also provide a lot of good solutions. --Kent

"Christophe de Dinechin" <descubes@earthlink.net> wrote in message news:3B7C8D0B.DC4770AD@earthlink.net...
>
> 1/ Macros
>
> I do believe in the necessity of macros. Because it is simple technology
> doesn't mean it is obsolete (unlike "register ;-) It is obsolete only for
> modularization (#include). But there is still no better way for
> environment-dependent compilation (#ifdef), or for textual replacements
> (see my extensive use of '.tbl' files in the LX compiler).

I agree with this viewpoint. Macros are necessary.

The D spec document pointed the problem with macros, they go through all scopes!

That is a good insight. Let's keep it. We need then SCOPED macros!

A macro should be defined in a scope and should take typed arguments. A template is just a macro. The template discussion should solve this.

Templates ARE macros. I will post later what I mean exactly with that, and a template spec.

"Christophe de Dinechin" <descubes@earthlink.net> wrote in message news:3B7C905D.5CFA76BC@earthlink.net...
> 8/ Operator overloading
>
> Total disagreement here :-) Operator overloading is at the very core of
the
> LX syntax, but it takes a completely different approach than C++ (the 'written' keyword that you may have seen in previous posts already). Written allows for N-ary operator overloading, and also the definition of new infix named operators and implicit conversions:
>
>  function And(integer A, B) return integer written A and B
>  function MultiplyAndAdd(matrix A, B, C) return matrix written A*B+C
>  function real(integer N) return real written N
>

Is this implemented?
Is (A*B)+C also equal to MultiplyAndAdd?

And (Horror)
Is A*(B+C) ALSO equal to MultiplyAndAdd?

How about parentheses?

Christophe de Dinechin wrote in message <3B7C8D0B.DC4770AD@earthlink.net>...
> I hope you covered the various cases of
>machine idioms that I documented in http://home.earthlink.net/~descubes/C--


Thanks for the laugh! Great satire.

Christophe de Dinechin wrote:

> 
> 1/ Macros
> 

Many confuse conditional compilation with macro's, that are actually two completly different things, in C they are handled by the same instance, but a language can either implement only one of the two, or handle them both with different instances. In my eyes conditional compiliation is a must, Macros are not.

Jacob,


It is implemented, and it "works" (that is, I did not find the bugs yet).
Explicit parentheses are eliminated during parsing, the tree form is the same,
so (A*B)+C is also MultiplyAndAdd. The tree structure being considered is
different for A+(B*C), so there is no match.


[localhost:~/Development/mozart/lx] ddd% cat test.lx
type matrix

function mla(matrix A, B, C) written A*B+C

matrix P, Q, R
matrix M := P * Q + R
matrix N := (P*Q) + R
matrix O := P* (Q+R)


[localhost:~/Development/mozart/lx] ddd% ./lx -parse test.lx -run_semantics
-stdout
test.lx:9: No written form matches 'P * (Q + R) '.
-- Generated by LX using lx-text.stylesheet
import  LX_BUILTINS
using LX_BUILTINS

variable  type matrix
constant  procedure mla( in matrix A;  in matrix B;  in matrix C)
   written A_ * B_ + C_
variable  matrix P
variable  matrix Q
variable  matrix R
variable  matrix M := mla (P, Q, R)
variable  matrix N := mla (P, Q, R)
variable  matrix O := P * (Q + R)
-- Thank you for using LX.
[localhost:~/Development/mozart/lx] ddd%


Christophe


jacob navia wrote:

> "Christophe de Dinechin" <descubes@earthlink.net> wrote in message news:3B7C905D.5CFA76BC@earthlink.net...
> > 8/ Operator overloading
> >
> > Total disagreement here :-) Operator overloading is at the very core of
> the
> > LX syntax, but it takes a completely different approach than C++ (the 'written' keyword that you may have seen in previous posts already). Written allows for N-ary operator overloading, and also the definition of new infix named operators and implicit conversions:
> >
> >  function And(integer A, B) return integer written A and B
> >  function MultiplyAndAdd(matrix A, B, C) return matrix written A*B+C
> >  function real(integer N) return real written N
> >
>
> Is this implemented?
> Is (A*B)+C also equal to MultiplyAndAdd?
>
> And (Horror)
> Is A*(B+C) ALSO equal to MultiplyAndAdd?
>
> How about parentheses?

Christophe de Dinechin wrote in message <3B7C964C.81944DE9@earthlink.net>...
>LATER NOTE: I just discovered you have typealias. OK, let me suggest that typedef should behave the C way (as typealias does today), and that typenew implements the new behavior...?. Don't change the meaning of typedef gratuitously...


Yes, that is a problem with D right now. I've been thinking of changing the typealias keyword to simply alias.

>PS: does your syntax allow: "int typedef handle" as in C?


No. I saw no need to support such monstrosities. I suspect the reason it is in C at all is because of a bug in an early C compiler that people started depending on <g>.

Christophe de Dinechin wrote in message <3B7C932F.6E190162@earthlink.net>...

>Anyway, you talk somewhere about: How do I keep an enum and a char array in sync. Well, if I had a preprocessor, here is what I would do:


That's similar to a trick I use. For example, suppose I need an enum value and string:

    #define colors \
        X(red) \
        X(green) \
        X(blue)

    // Do the enum...

    #define X(c)    COLOR_##c,
    enum COLOR { colors };
    #undef X

    // Do the corresponding array of strings...

    #define X(c)    #color ,
    char color_strings[] = { colors };
    #undef X

It's ugly, but I don't get the out-of-sync bugs anymore with it. This trick works with the Digital Mars compiler which works with unlimited size macros. Many C compilers fall over on this because they limit macro expansion text size.

For more complex tables, I'll write a separate program that generates C source which is then #Include'd.