Talk:Object disoriented

When was this language created? --Aardwolf 16:07, 14 Nov 2005 (GMT)

Around week ago.

Admit it. You just wanted a language where "fap fap fap..." was legal. ;->

Heheh... I actually considered rewriting that function so that it goes fbp fbp fbp fbp instead, honest! ...But then I thought nobody would notice or care. :)

I also noticed that one, though I can't remember which comic it is from. But I do remember what sound it was meant to represent... --Rune 22:32, 15 Nov 2005 (GMT)

Implementation

I am working on an implementation of this language in C++. It uses continuation passing style with a trampoline to allow 'infinite' recursion (limited by heap memory, not stack space). I am having problems running the example programs though; I would like to clarify a point in the spec. Are the a and b objects references to the values that initialised them? If so what happens if they are initialised to null (since this would prevent any assignment to them)? The example hello world seems to assume they are references, but then assigns to a null reference. --Sphen lee 08:20, 11 February 2008 (UTC)

It would appear to me that objects have value semantics, and that the null object is an actual object rather than a null object reference. -- Smjg 02:17, 13 March 2008 (UTC)

Omissions

Is this language case-sensitive?

What are the rules on what's a valid class name?

What should fz* do - return z, return *, throw a runtime error or what? -- Smjg 02:17, 13 March 2008 (UTC)

My implementation assumes that code is case sensitive, that class names can contain any character except dot, and that fz* is a runtime error. If you are implementing this language too I would be very interested to see if you can get the hello world program to work. After changing to value semantics as you suggested I am getting the fz* error... --Sphen lee 07:40, 13 March 2008 (UTC)

Just thinking about it, if objects have value semantics, members a and b would have to be pointers to these values. So effectively, an object would be

struct Object {
  Object *a, *b;
}

and when a or b is passed in as a function argument, it is this pointer that is passed. Is this what your implementation assumes? I'm also inclined to assume that c is a shallow copy (i.e. just copies the object in the first argument into the destination referred to by the second, and doesn't duplicate the child objects), but I'm not sure.

Here's another difficulty: What if a reference to a read-only object is passed to a function, and the function tries to modify it?

It would help if the creator of the language could clarify these issues. But meanwhile, I could still have a go at implementing it according to my interpretations. -- Smjg 00:05, 3 April 2008 (UTC)

I am using an Object class similar to that struct. My c performs a shallow copy. I have set up my copy operation so that if you attempt to copy a value into a null reference (ie. initialised to z) it will create a reference, otherwise it assigns to the reference. In pseudo C it looks like this:

if(!copyTarget)
    copyTarget = &value;
else
    *copyTarget = value;

I am no longer getting the fz* error in the Hello World program, but I seem to be getting an infinite loop instead...

Are we certain that the Hello world program should work? It uses assignment to self, which the author states hasn't been clarified yet. --Sphen lee 13:15, 14 April 2008 (UTC)

The reference programs have never been tested and might not work. But I've just checked the Hello World program and it SHOULD work. The assignment to self is delayed - it happens once the currently running function ends its execution. For instance:

cas

*various code comes in here*

rz <- s will change value here, to the value a had when the assignment happened.

z, when run, should be a do nothing function that returns z - the interpretation of 0 and 1 depend on it, since z is used as a 0 value, and the test to distinguish a 0 value from a 1 value is to run it on an object that stores two values and alternatively returns each one (so running a function on it effectively inverts the two values).

Also, c** should actually be deep copy, not shallow copy.

--(this comment by 70.81.136.175 at 05:19, 29 January 2009 UTC; please sign your comments with ~~~~)

And do what with circular data structures? Go into an infinite loop that consumes infinite memory? Or detect the circularity and reproduce it in the copied object? Or can you prove it impossible to create such a thing? -- Smjg 18:34, 3 February 2009 (UTC)

Well, it's pretty easy to design an atomic mushroom construct that expands indefinitely, same as in other functional languages. Circular references are impossible, since there are not really any references (except maybe if you consider some function execution side effects perhaps, but I don't think you can store those), the data structure always remains as a tree, although the data structures can expand indefinitely if the program is written that way (this is a feature - corresponds to the turing machine's infinite tape). What must be implemented though is tail recursion, to make the "s" variable usable for making loops (this includes structures that select between z and s so loops can have finite length). I think you could also want to optimize some parent/child looping constructs - in other words passing "s" to a child function call. The common point of these is the use of "s". The other way to loop is through lambda calculus-like looping constructs (doesn't even require the "s" variable!), and these should be optimized the same way as unlambda is (I have no idea how lambda calculus works or is interpreted, so I can't help there). Aside from looping constructs, I think data should stay within finite size unless the program explicitly generates infinite data, of course. I guess you could make an interpreter that stores all the functions referenced in the code (ie probably all the d. definitions and appearances of n and some generic object types such as z or the return values of o) and then stores references to these in the object data tree instead of the explicit code, but this excludes circular references, since it's just a data storage optimization, it doesn't change the actual workings. (70.81.136.175)