NewsForumsCodeLogsGallerySpecsSearch

When is monkey separated from mojo?

Monkey Forums/Monkey Programming/When is monkey separated from mojo?

Rixarn(Posted 2011) [#1]
Something i would love to do is to create frameworks in monkey (mojo independent) and just generate target libs in the native languaje. But for that we need monkey to be truly independent... So.. when is that happening? :)


therevills(Posted 2011) [#2]
Monkey is already independent of Mojo, Mojo is "just" a graphics module which Monkey imports...


Rixarn(Posted 2011) [#3]
Hum, since the app class was part of mojo i thought so... but you´re right... the app class makes no sense outside of mojo. The thing is.. i can't "compile" (translate") if there is no main function. So.. how can i make.. lets say.. a maze generation algorithm class or library without making the class or library an application itself?


therevills(Posted 2011) [#4]
You still need a Main function, that is the entry point for Monkey:

Strict

Function Main:Int()
	Local foo:Foo = New Foo
	foo.Output
	Return 0
End

Class Foo
	Field bar:Int
	
	Method New()
		bar = 100
	End
	
	Method Output:Void()
		Print bar
	End
End



Rixarn(Posted 2011) [#5]
Yes I know that. Perhaphs i'm not explaining myself he he... I understood now this has nothing to do with mojo. What i will love monkey to do is to be able to translate code withouth the need for a main function.

I would love to be able to write this

Strict

Class MyClass

End

And have this:

class MyClass{

};

In other words... for monkey to give us the option to just translate code from monkey to the target platform language.. (C++ in the case of GLFW, javascript for flash) etc..


ziggy(Posted 2011) [#6]
The Main function is needed "by design". The Monkey compiler is built in a way that it compiles only used parts of source code. If you import mojo, but you don't use a specific function of mojo, the unused part won't be compiled into the generated translation.
So, the compiler does not translate code "top to botom". The Compiler does start from the Main function and compile anything referenced "in cascade". That's a way to get the smaller translations possible, and a way to allow cross-referencing of modules.

So, a Monkey "library" should be written in the form of a module.


therevills(Posted 2011) [#7]
What Ziggy said...

(C++ in the case of GLFW, javascript for flash)


BTW Actionscript is used for Flash and Javascript is used for HTML5.


Rixarn(Posted 2011) [#8]
I see... thanks for the clear explanation ziggy

@therevills, thanks for the clarification

Oh well, then i'll just code in monkey what i know i'll only use with monkey.. thanks :)


Tibit(Posted 2011) [#9]
Well I don't think it's impossible to use monkey to translate code, I asked Mark for this before and he asked me the use I had in mind for that functionality.

Like you said, build an algorithm in monkey, use in javacript/C#/C++ and so on and so forth, that is quite awesome :)

Maybe this is something to be asked for again, I don't think it would be that hard to do since the translation-algorithm itself is already written.

I'd like that feature myself anyway! And if more wants it, then I can see it happening one day :P


Rixarn(Posted 2011) [#10]
I think the same Tibit :) It would be awesome to do that... it's a feature that adds value to monkey.


skid(Posted 2011) [#11]
Like you said, build an algorithm in monkey, use in javacript/C#/C++ and so on and so forth, that is quite awesome :)


With JS and C# the languages are managed so you can perhaps already do this. With C++ you will have to provide your own common garbage collector so NO monkey can't be used to generate autonomous objects that can magically plug in to you app unless you leave C++ target off your list.