The compiler could just deal. I'm confused why any of this needs to be more complex in the language syntax? Just make objects able to be passed as parameters. The compiler can deal with generating and storing the mega pointers when needed.
Then in your example, you could just pass the serial object into binary() and it could just use it internally as an object.
At compile time we know what things are objects, we know everything about objects, and we can generate whatever is needed to make it work. What am I missing?
That's getting better, IMO. Is the "@" in @outptr("0" + (value & 1)) really necessary? It kind of carries the reverse semantics of other @'s. The parens should be enough context to denote a method call, with method_name() being okay for parameterless calls.
-Phil
Wait! What about methods that don't need parameters? There would be no parentheses.
I think as long as there is nothing like '+= 1' after it, there should be no problem. Boy, typos could get really hard to debug, as they would be interpreted as indirect method calls.
What about methods that don't need parameters? There would be no parentheses.
Naked parens, as in my example above, are adequate disambiguation. In Perl, BTW, both the sigil ("&" instead of "@") and empty parameter lists are allowable to denote procedure calls.
The compiler could just deal. I'm confused why any of this needs to be more complex in the language syntax? Just make objects able to be passed as parameters. The compiler can deal with generating and storing the mega pointers when needed.
Then in your example, you could just pass the serial object into binary() and it could just use it internally as an object.
At compile time we know what things are objects, we know everything about objects, and we can generate whatever is needed to make it work. What am I missing?
Roy
The trouble comes from having to pass three longs every time you want to pass a method pointer. It's inefficient. The pointer needs to be established, once, in the instance's context, which means it ought to live in VAR - though there may be no VAR section, otherwise. Making it, and then just passing an address pointer to that structure is a 1-long affair that plays nicely as a parameter and a variable.
That could be used to make a pointer to a child object's method! Or, used to get the address of some VAR or DAT resource. Wait... it could do ALL the above, as the compiler would know the context.
that was my thinking.
it also would work to call a method of an sub object with cognew
Methods should always have parentheses even if they are no params.
You may only be kidding, but it does make reading a program easier, in that you automatically know which symbols in an expression are mere variables and which could cause side effects.
Now I really do have to go to bed. Heater, I guess I'll have to surrender the night (morning) to you to exert your influence.
You may only be kidding, but it does make reading a program easier, in that you automatically know which symbols in an expression are mere variables and which could cause side effects.
Now I really do have to go to bed. Heater, I guess I'll have to surrender the night (morning) to you to exert your influence.
You wouldn't need to pass the mega pointer around, you would just pass the pointer to it around.
The compiler would turn the passed object into a pointer to it's mega pointer, then inside the compiler would generate the proper code to use that param as a pointer to a mega pointer (since it knows that param is an object).
The syntax still doesn't need anything special. The compiler just deals.
You wouldn't need to pass the mega pointer around, you would just pass the pointer to it around.
The compiler would turn the passed object into a pointer to it's mega pointer, then inside the compiler would generate the proper code to use that param as a pointer to a mega pointer (since it knows that param is an object).
The syntax still doesn't need anything special. The compiler just deals.
The problem, still, is where is this mega-pointer going to live? It needs to live in VAR space, as that is unique to the instance, but there needs to be a VAR allocation made at compile-time to accommodate the mega-pointer. The programmer needs to get involved to make this happen.
When an object is instantiated in the language, a tuple would be created once, then you pass the pointer to that tuple around. That's what I take away from Roy's comment.
I still want the ability to instantiate an object on the stack as a local variable in a function. This way we needn't litter the global scope, but we do pay a price with a little more overhead, though not a lot. The intent is to be able to use lightweight objects on the stack, like string manipulation, numbers, etc.
I think the tuple approach cleans things up a lot and allows the code to be re-used among multiple instances, including anonymous local instances.
Actually, I do think that method calls should always have parentheses. Like you I like to see that the thing is actually doing work not just referencing data.
Err,,, actually, I also think that blocks should have braces or at least some observable delimiter. But I guess Chip won't want to hear that here.
This is all very interesting.
There is only one thing worse than a language designed by one man (say Pascal) and that is a language designed by committe (say Ada).
I wonder what a language designed by public web fourum might look like....
Actually, I do think that method calls should always have parentheses. Like you I like to see that the thing is actually doing work not just referencing data.
Err,,, actually, I also think that blocks should have braces or at least some observable delimiter. But I guess Chip won't want to hear the here.
This is all very interesting.
There is only one thing worse than a language designed by one man (say Pascal) and that is a language designed by committe (say Ada).
I wonder what a language designed by public web fourum might look like....
I see the value in always using parentheses for methods, actually. Braces, though, do eat up lots of vertical space.
This language is going to get distilled down to something very tidy before it's done.
This language is going to get distilled down to something very tidy before it's done.
I hope so.
I really like spin and pasm.
I know that all that C efford is needed, but me, myself and I LOVE spin and pasm.
they are made for each other. I stumble over >= as often in spin as I stumble over # in pasm, BUT else?
It is easy to read. with those intension-markers in the prop-tool you do not need braces. Even if I think that a smarter editor could take care of that and put them in or out at will using intention as marker...
Now getting inline-pasm, function pointer and more memory ...
Actually, I do think that method calls should always have parentheses. Like you I like to see that the thing is actually doing work not just referencing data.
Err,,, actually, I also think that blocks should have braces or at least some observable delimiter. But I guess Chip won't want to hear the here.
This is all very interesting.
There is only one thing worse than a language designed by one man (say Pascal) and that is a language designed by committe (say Ada).
I wonder what a language designed by public web fourum might look like....
Wow, a language designed by public web forum would have absolutely every concievable option, would take 20 years to be specified, and a further 20 to be implemented providing there was no creep. And you thought Windoze is bloated! But at least by the time its ready for prime time, the computers would be so fast they would be thinking for themselves.
Could someone explain to me in what possible way function references would be useful?
This would make Spin a bit of an odd ball language. Spin only has objects and methods, there are no free standing functions. So a pointer to a method without any knowledge of it's instance is, well, odd ball. You cannot do that in C++ or Java for example.
That method that you are about to call through a pointer had better not be using any non-local variables or something is going to explode.
Actually, you *can* do that in C++. It's called a static member function.
Yes. This is precisely what we need. And this is quite simple and easy to understand.
If spin gets too complex, then we may as well abandon it, and push into C.
I still think function pointers will be harder to understand than object references. The main problem as I see it is that they aren't easy to implement. If the Spin compiler could just keep track of the class of an object then it would know which methods go with that object and could compile them correctly. If you implement object references then you haven't really changed the Spin language much at all. All you've done is made it possible to pass an object as a parameter to a method in another object. This is called making object refernces first class data types which is part of any good language design. As it is, objects are second-class citizens because you can't assign them to variables or pass them as parameters.
For me as fast I read (Call Functions) give me thinking on ---- Prop2 OS
With other words if You can Call functions from any parameter area that have
ON Call structures
and
ON Return structures
that some can be hold in same variables
Like CPM else on 68k it was called by Trap instruction that Called F,Y + some needed Variables for that F-function
and You have complete structure to made simple OS in SPIN
But to that we need talk on and made that DATA structures
For me as fast I read (Call Functions) give me thinking on ---- Prop2 OS
With other words if You can Call functions from any parameter area that have
ON Call structures
and
ON Return structures
that some can be hold in same variables
Like CPM else on 68k it was called by Trap instruction that Called F,Y + some needed Variables for that F-function
and You have complete structure to made simple OS in SPIN
But to that we need talk on and made that DATA structures
I think all we need to do here is treat DAT labels appearing as methods, as in-line assembly, which gets loaded into the cog at $000 with the parameters at some known locations (ie $1B0..$1BF). That would be very simple to do.
Actually, you *can* do that in C++. It's called a static member function.
Yes. But a static member function is pretty much a free standing function with no access to the properties of objects of the class it is in. It's just that a static member function is in the classes name space and can access the classes static properties. So it's not much like a Spin method at all.
However. It turns out that you can in fact have pointers to normal object methods in C++.
[COLOR=blue]
typedef[/COLOR] [COLOR=blue]void[/COLOR] ( myclass::*FUNC ) ( [COLOR=blue]int[/COLOR] ); [COLOR=green]// Define a type which is a pointer to a member
// of myclass taking an integer parameter
// and returning nothing. Note the position of the "*"[/COLOR]
[COLOR=blue]void[/COLOR] TestMemberFunc () {
myclass obj; [COLOR=green]// instantiate myclass[/COLOR]
FUNC f = &myclass::myfunc; [COLOR=green] // Create member function pointer and
// assign address of member function to it. [/COLOR]
(obj.*f) (123); [COLOR=green]// Call it the member function through the pointer[/COLOR]
}
Where that typdef thing is like Chip's mega-pointer.
Which reinforces my oft repeated statement that I don't believe there is a single human being who inderstands the repercussions of all of C++s features:)
What is needed that we declare area $E80 - $EFF as Functions communication area.
Then have maybe 4 longs to one function that describe
1 if that function exist
2. if that function have be already started
3. if not started - start it in first place
How longs are used that are most important so all functions have same structure to call them
1 long can be identifier and flags if function runing
2 long pointer to parameter area
3 long some parameters
2 - 4 on return variables
I think all we need to do here is treat DAT labels appearing as methods, as in-line assembly, which gets loaded into the cog at $000 with the parameters at some known locations (ie $1B0..$1BF). That would be very simple to do.
There is only one thing worse than a language designed by one man (say Pascal) and that is a language designed by committee (say Ada).
I wonder what a language designed by public web forum might look like....
I hope (and trust) that what will happen here is that Chip will carefully consider all of the excellent input and weight it against the 'cost' and come up with a slick product.
Sometimes things just come together as though they were meant to be that way. With other projects, it feels like you are in an endless uphill battle against nature. Chip shows a great ability to find the natural way.
What is efficient in execution is often at odds with what is slick in expression. In such instances I almost always favor execution. That is why I much prefer C to C++.
In the case of the P2, I'm in Sapieha's camp: PASM is slick enough that I may end up using it, mostly. Meanwhile, I hope SPIN doesn't get too OOP'd, and least not beyond what is economical and simple.
Yes. But a static member function is pretty much a free standing function with no access to the properties of objects of the class it is in. It's just that a static member function is in the classes name space and can access the classes static properties. So it's not much like a Spin method at all.
It is just like one of Chip's original proposals that function pointers could only access function parameters and globals. Of course, the "super pointer" concept is more like a pointer to a member function in C++.
I hope (and trust) that what will happen here is that Chip will carefully consider all of the excellent input and weight it against the 'cost' and come up with a slick product.
Sometimes things just come together as though they were meant to be that way. With other projects, it feels like you are in an endless uphill battle against nature. Chip shows a great ability to find the natural way.
What is efficient in execution is often at odds with what is slick in expression. In such instances I almost always favor execution. That is why I much prefer C to C++.
In the case of the P2, I'm in Sapieha's camp: PASM is slick enough that I may end up using it, mostly. Meanwhile, I hope SPIN doesn't get too OOP'd, and least not beyond what is economical and simple.
I don't think adding single inheritance should greatly complicate Spin and has some big advantages. It could be though that it doesn't fit well with the existing Spin bytecode engine. I'm not sure why three longs would be necessary to represent a pointer to a method. Must be some artifact of the implementation. Two seems like it should suffice, one for the method itself and the other for the object's instance variables. That ends up being like a closure in Lisp.
I know little of lisp but in Scheme and JavaScript you can return a function from a function. Perhaps I should say return a reference to an inner function from a function.
When do that the returned function has access to all variables that were in scope when it was created as an inner function including all the local variables that one might expect "vaporized" when the outer function returned.
Not only that but every time you get a reference to that inner function each one has it's own set of different variables. It gets new "referencing environment" as they say.
If that all sounds tough to follow I agree, as a programmer in languages of the style of C for ages this whole closure thing was a bit stomach churning when I met it for the first time last year. It actually makes JavaScript a more expressive language that Java or C++ both of which are hoping to intoduce closure soon I beleive.
Comments
Then in your example, you could just pass the serial object into binary() and it could just use it internally as an object.
At compile time we know what things are objects, we know everything about objects, and we can generate whatever is needed to make it work. What am I missing?
Roy
Wait! What about methods that don't need parameters? There would be no parentheses.
I think as long as there is nothing like '+= 1' after it, there should be no problem. Boy, typos could get really hard to debug, as they would be interpreted as indirect method calls.
@ has already got to many different meanings in Spin already and this would introduce another.
-Phil
Methods should always have parentheses even if they are no params. In the same way the blocks should always have braces.
Only kidding, could not resist:)
The trouble comes from having to pass three longs every time you want to pass a method pointer. It's inefficient. The pointer needs to be established, once, in the instance's context, which means it ought to live in VAR - though there may be no VAR section, otherwise. Making it, and then just passing an address pointer to that structure is a 1-long affair that plays nicely as a parameter and a variable.
Boy, I was getting a sinking feeling there.
that was my thinking.
it also would work to call a method of an sub object with cognew
cognew(obj@method(string("HI")),@stack)
Enjoy!
Mike
Now I really do have to go to bed. Heater, I guess I'll have to surrender the night (morning) to you to exert your influence.
-Phil
Thanks for all your help, Phil and Everyone.
The compiler would turn the passed object into a pointer to it's mega pointer, then inside the compiler would generate the proper code to use that param as a pointer to a mega pointer (since it knows that param is an object).
The syntax still doesn't need anything special. The compiler just deals.
The problem, still, is where is this mega-pointer going to live? It needs to live in VAR space, as that is unique to the instance, but there needs to be a VAR allocation made at compile-time to accommodate the mega-pointer. The programmer needs to get involved to make this happen.
I still want the ability to instantiate an object on the stack as a local variable in a function. This way we needn't litter the global scope, but we do pay a price with a little more overhead, though not a lot. The intent is to be able to use lightweight objects on the stack, like string manipulation, numbers, etc.
I think the tuple approach cleans things up a lot and allows the code to be re-used among multiple instances, including anonymous local instances.
since you are deep into this -
on syntax level the nicest would be to either pass a object reference down to a sub-object or a reference to a function of that object.
is it possible to make objects global ?
thus you could reference all objects from all objects ?
just spinning here...
Enjoy!
Mike
Err,,, actually, I also think that blocks should have braces or at least some observable delimiter. But I guess Chip won't want to hear that here.
This is all very interesting.
There is only one thing worse than a language designed by one man (say Pascal) and that is a language designed by committe (say Ada).
I wonder what a language designed by public web fourum might look like....
I see the value in always using parentheses for methods, actually. Braces, though, do eat up lots of vertical space.
This language is going to get distilled down to something very tidy before it's done.
I hope so.
I really like spin and pasm.
I know that all that C efford is needed, but me, myself and I LOVE spin and pasm.
they are made for each other. I stumble over >= as often in spin as I stumble over # in pasm, BUT else?
It is easy to read. with those intension-markers in the prop-tool you do not need braces. Even if I think that a smarter editor could take care of that and put them in or out at will using intention as marker...
Now getting inline-pasm, function pointer and more memory ...
yeah.
Enjoy!
Mike
I have be thinking on it now litle.
It is nice work --- BUT.
That need second part of work ----> Structures to CALL PASM drivers to be very usable
Can you give an example of what you'd like to see?
For me as fast I read (Call Functions) give me thinking on ---- Prop2 OS
With other words if You can Call functions from any parameter area that have
ON Call structures
and
ON Return structures
that some can be hold in same variables
Like CPM else on 68k it was called by Trap instruction that Called F,Y + some needed Variables for that F-function
and You have complete structure to made simple OS in SPIN
But to that we need talk on and made that DATA structures
I think all we need to do here is treat DAT labels appearing as methods, as in-line assembly, which gets loaded into the cog at $000 with the parameters at some known locations (ie $1B0..$1BF). That would be very simple to do.
Yes. But a static member function is pretty much a free standing function with no access to the properties of objects of the class it is in. It's just that a static member function is in the classes name space and can access the classes static properties. So it's not much like a Spin method at all.
However. It turns out that you can in fact have pointers to normal object methods in C++.
[COLOR=blue] typedef[/COLOR] [COLOR=blue]void[/COLOR] ( myclass::*FUNC ) ( [COLOR=blue]int[/COLOR] ); [COLOR=green]// Define a type which is a pointer to a member // of myclass taking an integer parameter // and returning nothing. Note the position of the "*"[/COLOR] [COLOR=blue]void[/COLOR] TestMemberFunc () { myclass obj; [COLOR=green]// instantiate myclass[/COLOR] FUNC f = &myclass::myfunc; [COLOR=green] // Create member function pointer and // assign address of member function to it. [/COLOR] (obj.*f) (123); [COLOR=green]// Call it the member function through the pointer[/COLOR] }Where that typdef thing is like Chip's mega-pointer.
It's nicely explained here: http://tipsandtricks.runicsoft.com/Cpp/MemberFunctionPointers.html
Which reinforces my oft repeated statement that I don't believe there is a single human being who inderstands the repercussions of all of C++s features:)
Let's not see Spin go that way...
Yes and NO.
What is needed that we declare area $E80 - $EFF as Functions communication area.
Then have maybe 4 longs to one function that describe
1 if that function exist
2. if that function have be already started
3. if not started - start it in first place
How longs are used that are most important so all functions have same structure to call them
1 long can be identifier and flags if function runing
2 long pointer to parameter area
3 long some parameters
2 - 4 on return variables
I hope (and trust) that what will happen here is that Chip will carefully consider all of the excellent input and weight it against the 'cost' and come up with a slick product.
Sometimes things just come together as though they were meant to be that way. With other projects, it feels like you are in an endless uphill battle against nature. Chip shows a great ability to find the natural way.
What is efficient in execution is often at odds with what is slick in expression. In such instances I almost always favor execution. That is why I much prefer C to C++.
In the case of the P2, I'm in Sapieha's camp: PASM is slick enough that I may end up using it, mostly. Meanwhile, I hope SPIN doesn't get too OOP'd, and least not beyond what is economical and simple.
I know little of lisp but in Scheme and JavaScript you can return a function from a function. Perhaps I should say return a reference to an inner function from a function.
When do that the returned function has access to all variables that were in scope when it was created as an inner function including all the local variables that one might expect "vaporized" when the outer function returned.
Not only that but every time you get a reference to that inner function each one has it's own set of different variables. It gets new "referencing environment" as they say.
If that all sounds tough to follow I agree, as a programmer in languages of the style of C for ages this whole closure thing was a bit stomach churning when I met it for the first time last year. It actually makes JavaScript a more expressive language that Java or C++ both of which are hoping to intoduce closure soon I beleive.