-->
Page 1 of 1

User_Function()

PostPosted: Wed Nov 16, 2016 11:09 am
by Electroguard
All Function calls have the common ability to pass and return data with each function call, if needed.

So a TRIM(var or string) function could for instance take the raw data and return the trimmed result.

TRIM() doesn't exist in Esp_Basic, and to create a functional equivalent would require copying the required string into a global 'transfer' variable, gosub to a [TRIM] subroutine which must be written to use the specified transfer variable, then after 'return'ing from the subroutine, copy the modified global transfer variable to wherever it is needed or originally belonged... and that might need doing dozens of times.

How much more elegent and convenient it might be if some sort of...

USERĀ­_FUNCTION( [branch], {string or var1}, {string or var2}, {string or var3})

was available. The specified subroutine branch could extract the appropriate data from any supplied strings or variables, perhaps using a passed var or string to modify behaviour if required, then return the modified 'result' string or variable.

It would allow users to pass data to and from their own user-defined functions to effectively create their own functions from subroutine procedures which otherwise could not exchange data with the running program.

I'm not a professional programmer, so perhaps I'm talking rubbish, but I think it should be feasible for a USER_FUNCTION to 'goto' the supplied subroutine [BRANCH], where the subroute can manipulate the specified vars data, putting the results into (eg:) a RESULTS var, then the subroutine RETURN command returns back to the calling USER_FUNCTION which returns whatever is in the RESULTS var, so even allowing the returned function results to be used in comparison tests if needed.

It would open up the possibility for users to easily create any FUNCTIONality whenever they need.

Re: User_Function()

PostPosted: Thu Jan 26, 2017 6:33 am
by flywire
+1

Re: User_Function()

PostPosted: Sun Jun 04, 2017 2:08 am
by euclas@gmail.com
+1!

It could create an auxiliary file that was loaded together to be interpreted and stored in it all those functions created by the users (not to pollute the original source of the program, similar to the name "defalt.bas" which is the execution default).
In this file there would be the definition of the function and the labels and their returns, transparently.
Obviously, users could send their functions to be added to this file, such as a library that would be installed together with the interpreter.
This proposal lacked the definition of the type of data to be returned, to be able to be indicated if there were any errors during the execution.

Euclides (Brazil).