Expression Gate Documentation

[Syranide]

Interesting. Maybe we need to touch base (or try) with Gary and see if it would be possible to add it back but have it only work with "signed devices". Anybody know what the best way to get Gary's attention?[/b]

I see very little use for this outside of actually just optimizing dynamic expression performance, you can't really apply it to other things.

[bprater]

Argh, it would just be really nice to have a real programming language inside the Gmod world.

With the right tools -- I think people will do some really, really cool stuff with it. I want something like this to teach kids about basic programming in a fun, dynamic world. ("Want to learn all about sin?! Let's make Mario jump pads!")

I really love what you've done with EC Syranide. I've been having a blast with it. I just need more functionality!

Maybe you should post a list of future ideas you have planned for it when you have time.

[Syranide]

Argh, it would just be really nice to have a real programming language inside the Gmod world.

With the right tools -- I think people will do some really, really cool stuff with it. I want something like this to teach kids about basic programming in a fun, dynamic world. ("Want to learn all about sin?! Let's make Mario jump pads!")

I really love what you've done with EC Syranide. I've been having a blast with it. I just need more functionality!

Maybe you should post a list of future ideas you have planned for it when you have time.[/b]

You can have a real programming language inside gmod, allowing direct access to Lua in gmod is not an acceptable way because anyone could own your server in 1 minute, and all errors would go to the console and so on. However, it is very possible to write your own, I could very well have made a CPU instead by extending my Expression Gate-language, but I wanted something easily understandable and useable, and you rarely need the complexity of the CPU.

Hehe that is why I like garrysmod with wiremod, fun, yet so creative and inspiring
If you could please specify what you have in mind in terms of functionality I would love to hear it.

My current plans is basically just a polish of it, internal timer, local functions, native support for "packets", initializer section, true constants, strictly specified local and "session variables" to avoid misspelling, perhaps slightly revised language to make it even more friendly and so on, nothing that really affects the functionality of the expression gate.

[Syranide]

By the way, for those of you who didn't notice, -orb- made a wonderful tutorial for the Expression Gate where he goes over all the basics (also linked from the first page of this documentation), click here to see the tutorial!

If you feel insecure on how to get started with the Expression Gate, have a look at it and it should clear most of the confusion. I can really recommend all his other tutorials as well!

[bprater]

Thanks for being open to suggestions!

I like the future ideas. Global (or session, stuff that stays alive each cycle) and instances variables (variables that die) would be awesome.

Functions would be great, especially if they could be called with parameters.

Have a debug call that either outputted to the console or better -- to the screen like the 'debugger' does would be really helpful.

I think that real if/elseif/else stuff would be really great.

Here's some sample code I cooked up thinking about what would be nice to have.

<div class='codetop'>CODE</div><div class='codemain' style='height:200px;white-spacere;overflow:auto'>globals %State, %Energy

if PersonRange < 10 then
%State = &#39;kill&#39;
debug &#39;Ima killer&#39;
elseif PersonRange > 10 then
%State = &#39;seek&#39;
debug &#39;Ima heading for you!&#39;
else
%State = &#39;recharge&#39;
call recharge(0.5)
endif

function recharge( amount )
motion = 0
%Battery += amount
if %Battery > 5000 then
%State = &#39;seek&#39;
debug &#39;ok im recharged, ready to kill!&#39;
endif
endfunction</div>

[Syranide]

Thanks for being open to suggestions!

I like the future ideas. Global (or session, stuff that stays alive each cycle) and instances variables (variables that die) would be awesome.

Functions would be great, especially if they could be called with parameters.

Have a debug call that either outputted to the console or better -- to the screen like the &#39;debugger&#39; does would be really helpful.

I think that real if/elseif/else stuff would be really great.

Here&#39;s some sample code I cooked up thinking about what would be nice to have.

<div class='codetop'>CODE

<div class='codemain' style='height:200px;white-spacere;overflow:auto'>globals %State, %Energy

if PersonRange < 10 then
%State = &#39;kill&#39;
debug &#39;Ima killer&#39;
elseif PersonRange > 10 then
%State = &#39;seek&#39;
debug &#39;Ima heading for you!&#39;
else
%State = &#39;recharge&#39;
call recharge(0.5)
endif

function recharge( amount )
motion = 0
%Battery += amount
if %Battery > 5000 then
%State = &#39;seek&#39;
debug &#39;ok im recharged, ready to kill!&#39;
endif
endfunction</div>[/b][/quote]

I&#39;m always open for suggestions!

Yeah that is pretty much what I had intentions of, possibly also extending functions and variables to being "compound" (A.x, A.y), or like lua, so that you can assign outputs of functions as "a,b,c,d=fun()" both for packet support and other things. But that&#39;s another story.

If-else is something I want, although I&#39;m unsure of the syntax as I rather stay away from programming constructs, but it might be better in this case.

The basic idea with functions would be that you could possibly define functions "globally", so that you would always have access to them in a way (in all scripts), but I see many problems with them aswell, as they have limited usefulness except for structuring the code, as most common functions are already provided, and I don&#39;t want to blur the CPU/Expression Gate distinction. So I doubt the actual usefulness of functions for the expression gate as they would have very limited meaning, since they could only act as purely mathematical functions, and not as in normal languages where they can act as states and contain more advanced logic. So if they were to mainly be for structuring code, perhaps it should designed in another way.

It&#39;s important to understand that I don&#39;t want to sacrifice the simplicity of the gate, it&#39;s not meant as a "can do everything"-gate.

Not sure if I misunderstood you, but you can already have variables that remain between executions, by simply assigning a variable that is not an input.

[Little Green Man]

Thanks for the expression gate Syranide, I now use it way more than normal chips and it makes it so much clearer what you are doing. THANK YOU

[Syranide]

Thanks for the expression gate Syranide, I now use it way more than normal chips and it makes it so much clearer what you are doing. THANK YOU [/b]

Glad that you like it!
I do too,

[bprater]

It&#39;s important to understand that I don&#39;t want to sacrifice the simplicity of the gate, it&#39;s not meant as a "can do everything"-gate.

Not sure if I misunderstood you, but you can already have variables that remain between executions, by simply assigning a variable that is not an input.[/b]

Oh, I just meant similar to LUA&#39;s "local" variables. Sometimes its bad to have variables act global. It keeps biting me, outputs stay open, etc.

I think it&#39;s safe to blur a bit -- every bit of functionality you add takes it a bit closer. I think its safe to say that adding an internal timer makes it a real CPU!

Honestly, I&#39;m not sure what you are nervous about. I think it&#39;s fun to push this little chip as far as it will go. If we break it, we can always roll back a version or two!

Oh, another idea -- simple arrays. I&#39;d like to make a spybot that uses GPS instead of waypoints.

WaypointsX = array( &#39;35&#39;,&#39;25&#39;,&#39;155&#39; );
WaypointsY = array( &#39;25&#39;,&#39;123&#39;,&#39;3&#39; );
WaypointsZ = array( &#39;31&#39;,&#39;111&#39;,&#39;52&#39; );

CurrentWayPointX = WaypointsX[0];
CurrentWayPointY = WaypointsY[0];
CurrentWayPointZ = WaypointsZ[0];

[Syranide]

Oh, I just meant similar to LUA&#39;s "local" variables. Sometimes its bad to have variables act global. It keeps biting me, outputs stay open, etc.

I think it&#39;s safe to blur a bit -- every bit of functionality you add takes it a bit closer. I think its safe to say that adding an internal timer makes it a real CPU!

Honestly, I&#39;m not sure what you are nervous about. I think it&#39;s fun to push this little chip as far as it will go. If we break it, we can always roll back a version or two!

Oh, another idea -- simple arrays. I&#39;d like to make a spybot that uses GPS instead of waypoints.

WaypointsX = array( &#39;35&#39;,&#39;25&#39;,&#39;155&#39; );
WaypointsY = array( &#39;25&#39;,&#39;123&#39;,&#39;3&#39; );
WaypointsZ = array( &#39;31&#39;,&#39;111&#39;,&#39;52&#39; );

CurrentWayPointX = WaypointsX[0];
CurrentWayPointY = WaypointsY[0];
CurrentWayPointZ = WaypointsZ[0];[/b]

Local variables, yeah that was my plan to force you to specify whether they are local or not, and perhaps even have it warn you if you use an uninitialized local variable and so on.

Outputs staying open? Here you have (kind of) one of the reasons I want this to stay simple, because if they stay open, it is mostly because you made a bad choice when writing the code, many write "B = 0, A -> B = 2" instead of actually "B = (A ? 2 : 0)" and so on. Further, it is not like I can extend the language in 5 minutes, it has rather big implications on the implementation and people that fail to understand it will just stop using it.

Also, it is important to note, the expression gate does not add new functionality to wiremod, and it never will, it is a replacement to minimize lag and complexity. It is also a mathematical tool, not for states and algorithms like the CPU, so it is not intended for writing "application", it is only intended as a way to write "calculations". So, everything should not be possible using the expression gate.

Note that the lack of a simple language for the CPU-chip does not imply the expression gate should become a CPU-chip, this is why I also called it a gate (although technically it is a chip as it has memory), because it adds no more functionality, it is simply a tool, whereas the CPU means new possibilities. and adding an internal timer does not make it a CPU, it simply removes the need for an external timer, you still can&#39;t keep advanced states like the CPU and so on.

You also have to see the big picture, the CPU-chip is nice, but it became way to complicated after a while and people who didn&#39;t hang here had no clue how to use it... And I thought the expression gate was simple, I can use it without any problem, you too probably, but yet you will see people failing to use it day after day and making bad use of constructs, and I want it to be a tool for everyone, powerful but not unnecessarily complex.

Regarding the arrays, you can already cheat a little and use send/recv (packet support) locally.

WPX = send(12,32,12)
CWPX = recv(WPX,1)

But yeah, I&#39;ve had plans on arrays, but at the same time, it is important to note here that once again, introducing arrays can have pretty bad consequences if done hastily, as you can&#39;t do arithmetic on arrays, and then you&#39;d be seeing a lot of funny errors. Although there is the possibility of adding a stricter validator, it would mean more errors that most people don&#39;t understand what they mean.

So although I could make it into a CPU instead and allow everything to be done using it, it is not useful for most circumstances, and it is not my intention with it. And it would require it to work differently, because the CPU executes instructions ever now and then, the expression gate just instantly evaluates what it gets, meaning that you can&#39;t write to complex things either or it will start lagging horribly, which also brings me to keeping it simple and focused on what&#39;s important. The more complex uses should be done using the CPU in my opinion.

My current thought of a Expression Gate 2 is basically improvements (specify local and global, initializers and so on) and minor additions (perhaps arrays, native packet support, with perhaps even outside integration so that you could receive compound values from the GPS etc, using one wire).