function pointers/references

[andenixa]

I understand that this should probably go to the future suggestions forum, but due to its new layout it is hard to use that for a live discussion.

I understand that adding the OOP to eScript would probably too much work. I wonder if its possible to add function pointers/references though. That would simplify things a lot and allow for a very flexible systems to be created. I mean its already almost there, there are method_scripts et cetera.

[guialtran]

myPkg_ <- This name helps to know where the function came
myFunction <- name of the function
byref <- parameter passed by reference
elem <- parameter

Code: Select all

function myPkg_myFunction( byref elem )
//if you modify the element here, the variable is also changed out of her without the use of return
...
endfunction


///example
use uo;
use basic;

include ":magery:myconfig";   // include ":name_pkg:name_File";  //obs -> your config should be made to the file."name_File.cfg"
//this is a command point ".myComand"
program myProgram( character )
    var myvar := 0;
    magery_plusplus( myvar );
    SendSysMessage( character, cstr(myvar) );
endprogram


//it is inside a package magery
//within the file "myconfig.cfg"
function magery_plusplus( byref myparam )
    myparam := myparam + 1; 
endfunction

sorry for my english.

[andenixa]

Thank you for the interest in the topic. Passing variable by reference is not exactly what I meant by having function pointers introduced.

Here what I meant, take a simple example:

function Area( length, width )
return legth * width;
endfunction

program test( )
var functionPointer := Area;

print( functionPointer( 1, 2 ) ); // should print: "2"
endprogram

[phao]

I think you're making the mistake a friend of mine is doing.

He often tells me how big, complicated, and generic the systems he's planning to do are.

I believe the name eScript tells us something. eScript is not an interpreted language, so the code written in eScript isn't, by definition, an actual script. But, the name "script" is very commonly given to code that is designed to do small and specific tasks, which is what I believe to be the purpose of eScript.

For example, you don't write a big code that could be used as a generic special ability, that could behave as 20 different special abilities. You write 20 small pieces of code, one for each. Same for spells. Sometimes, you can encapsulate a pattern, but from the experience I have, it's only worth doing this kind of stuff in eScript, if the pattern is really obvious. Which elimitates the use of OOP and pointers, for its most part, here.

I highly believe that eScript was designed to be a "gluing" programming language, like shell script for UNIX or batch scripting for windows/dos (imagine the modules functions as the user land command line programs). Adding OOP or pointers to eScript makes as much sense as adding pointers to shell script (I think they tried that in csh and tcsh). A eScript program rarely needs to enter a loop, if you wanna search, use 'in'; if you wanna sort, use .sort(); if you wanna generate a list, there are a bunch of functions for that in uo.em; the whole language is designed so that you just have to use it as a gluing mechanism. You will, sometimes, need a foreach (probably the most common looping mechanism I use), which easily replaces stuff like map, filter, fold, ... for most task's necessities.

The only actual system I have in my shard is a "watcher" program, which does, in order, what I tell it to do. It's used to escape the concurrence POL has (that could cause two poisons to be casted at the same time in the same player). Since the watcher is only one program, I decide the order of computation of things. And even though, it's not big, it's not "generic", it's not complicated, and using OOP would probably make it unecessarily complicated.

Maybe, if you tell us what you wanna do with OOP or function pointers, we can point an alternative.

NOTE: OOP is over-rated. Programmers tend to make things look more complicated than they are. OOP is not the solution to MANY problems it's used to solve (it can solve, but it's not a good tool to solve) -- and OOP is not a solution for "gluing programming".

NOTE2: If you still wanna use escript for big, serious, real world, or whatever name people use to refer to programming that is not small and specific, good luck with error detection, and handling.

[andenixa]

I think you're making the mistake a friend of mine is doing.

First, your friend is not making a mistake. he is just a more experienced coder. Having a general approach to a problem is one of the toughest and desirable traits for a CS person. My experience tells me that code duplication is the utter-evil, unfortunately employed by many novices.

Second, I wasn't speaking about OOP, nor pointers. I am speaking about functional programing and being able to point/reference a function. Dare you to read carefully. Ultima online has a strong object relations underneath, so being able to OOP would be a definite plus, but I wasn't proposing it, so don't mention it.

Third, the name "eScript" tells me nothing, but it would be safe to assume that eScript is an interpreted language. (What shall a name "Python" suggest then?! A bird eating abomination?)

And last, unless you are writing a "Hello, world" script, having loops is inevitable with only a small fraction could be averted with "value in list" statement.

A note to a note: I am not using eScript for a "real-world" programing (whatever that could mean), instead I use it to develop a real-world shard and it would benefit from having functional programming as it makes the development more robust.

PS: I guess thats my limitation, but I never heard of "gluing" programing languages.

[phao]

First, your friend is not making a mistake. he is just a more experienced coder. Having a general approach to a problem is one of the toughest and desirable traits for a CS person. My experience tells me that code duplication is the utter-evil, unfortunately employed by many novices.

Second, I wasn't speaking about OOP, nor pointers. I am speaking about functional programing and being able to point/reference a function. Dare you to read carefully. Ultima online has a strong object relations underneath, so being able to OOP would be a definite plus, but I wasn't proposing it, so don't mention it.

Third, the name "eScript" tells me nothing, but it would be safe to assume that eScript is an interpreted language. (What shall a name "Python" suggest then?! A bird eating abomination?)

And last, unless you are writing a "Hello, world" script, having loops is inevitable with only a small fraction could be averted with "value in list" statement.

A note to a note: I am not using eScript for a "real-world" programing (whatever that could mean), instead I use it to develop a real-world shard and it would benefit from having functional programming as it makes the development more robust.

PS: I guess thats my limitation, but I never heard of "gluing" programing languages.

You're wrong for so many reasons.

About my friend. He's making a mistake. He's not trying to capture common patterns into functions. He's trying to make something simple into something complicated by thinking he's capturing common patterns into functions. In many cases, he's "seeing" problems that are not there -- for some reason he can make everything complicated. Which is pretty much what you seem to be doing. This happens because you never programmed anything relevant in eScript or because you're just doing it plain wrong (he was doing it plain wrong -- he had stuff like nested nested nested loops).

Before I started my shard, I already knew how to do it. I had the code in my mind. It's just a matter of writing it, which is what I'm doing. I'm not using any packaged (I'm with POL 099 and basic setup). And, so far, never had any need for functional programming, pointers, etc. Some of the stuff, very few of it, I considered to be time consuming, but most of that is gone just by reading more of the reference (the more I know the modules, the smaller my codes get).

About code duplication, I have none. Most computational patterns are already captured into the module functions. You'll need to create some for your own, but no need for any special tool here.

You asked for pointers to function. eScript is obviously not functional, having pointers to functions won't change a thing. Maybe you have no clue what functional programming is. I know you didn't ask for OOP, but you mentioned it:

I understand that adding the OOP to eScript would probably too much work. I wonder if its possible to add function pointers/references though. That would simplify things a lot and allow for a very flexible systems to be created. I mean its already almost there, there are method_scripts et cetera.

This that you said made me think "He wants OOP, but thinks it's too much to ask and is asking something else instead.", which is not a long shot.

About eScript being interpreted. ECOMPILE compiles .src files containing eScript files into .ecl files, which are something POL can understand. eScript isn't interpreted directly. Python is the name of a snake, not a name that means a piece of code that is often used to be small programs, which is what "script" can mean in many contexts.

About loops. You'd be surprised how often you can avoid them. After reading some stuff CWO and Turley wrote on performance and runaway scripts, I started to pay more attention to loops, and started using more of the modules functions to loop for me, which boosts pefromance. I cut a bunch of loops from my code.

By the way, a programming language for gluing is a programming language designed to put pieces together, normally created by other tools: http://en.wikipedia.org/wiki/Glue_language -- shellscript is a very famous glue language. It's not a paradigm or anything... it's just one characteristic of the language.

If you really wanted functional programming, you'd ask for better support for recursivity (not pointers to functions), but you didn't, which means that you either is totally clueless on the topic, or that you really didn't do nothing relevant in eScript.

Functional programming is just programming with no side effects. Stuff like map, filter, fold, ..., mechanisms like continuations, or functions as first class objects, or macros are just stuff that help with functional programming -- not all functional programming languages have all this stuff.

Many books on science, in general (including ones on computer science, or even programming), say "Making things big and complex is easy, and anyone can do it, but making them small and simple is the hard thing." -- I bet you thought about adding new features to eScript faster than trying to solve your problems with simplicity, which is probably possible for most problems, with just eScript.

Please ignore the many spelling mistakes. I'm about to sleep.

Please, also, don't be upset. I'm annoying, but I'm not trying to get you angry. Maybe I am, but not doing it intentionally.

[andenixa]

Phao, I didn't say I can not progress without functional programming or OOP but merely saying these would help a lot. I am well aware of the implications of adding a new feature such as FP. All I wanted is to hear developer's comments about the feasibility of the proposition based on the fact they might already have some of the required functionality built-it.

Your first message sounded like you have a lot of code duplication, and I am sorry if I got you wrong. Having scripted for almost 11 years I abhor the excess complexity. I also apologizes if I sounded too offensive, but I really do want to hear the opinion on the topic, not reasons of why I might not want it.

Perhaps I do not require the whole functionality behind the FP, but having a function as a first class object is just a fancy way of putting the simple idea I expressed. Thus being able to both filter and map data are direct inferences from the ability to assign a function to a variable and pass it as an argument to another.

The main argument in favor of the more advanced programming paradigms is that they allow to save time by making a code reusable and in fact less complex. Needles to say that the same thing could be implemented using the archaic methods, but thats why we invented a lighter instead of being stuck with flint and tinder. I do not like the tendency of making arcane art out of the coding process, but rather prefer using all the tricks of trade available to achieve the goal the most robust way possible. I also would rather end up with a slightly more sophisticated system than the one that lacks features I need to prevent the repetitive coding of similar nature over and over again.

PS: Books also say you shouldn't try to make things simpler than they should be.

[guialtran]

I think you're making the mistake a friend of mine is doing.

He often tells me how big, complicated, and generic the systems he's planning to do are.

I believe the name eScript tells us something. eScript is not an interpreted language, so the code written in eScript isn't, by definition, an actual script. But, the name "script" is very commonly given to code that is designed to do small and specific tasks, which is what I believe to be the purpose of eScript.

For example, you don't write a big code that could be used as a generic special ability, that could behave as 20 different special abilities. You write 20 small pieces of code, one for each. Same for spells. Sometimes, you can encapsulate a pattern, but from the experience I have, it's only worth doing this kind of stuff in eScript, if the pattern is really obvious. Which elimitates the use of OOP and pointers, for its most part, here.

I highly believe that eScript was designed to be a "gluing" programming language, like shell script for UNIX or batch scripting for windows/dos (imagine the modules functions as the user land command line programs). Adding OOP or pointers to eScript makes as much sense as adding pointers to shell script (I think they tried that in csh and tcsh). A eScript program rarely needs to enter a loop, if you wanna search, use 'in'; if you wanna sort, use .sort(); if you wanna generate a list, there are a bunch of functions for that in uo.em; the whole language is designed so that you just have to use it as a gluing mechanism. You will, sometimes, need a foreach (probably the most common looping mechanism I use), which easily replaces stuff like map, filter, fold, ... for most task's necessities.

The only actual system I have in my shard is a "watcher" program, which does, in order, what I tell it to do. It's used to escape the concurrence POL has (that could cause two poisons to be casted at the same time in the same player). Since the watcher is only one program, I decide the order of computation of things. And even though, it's not big, it's not "generic", it's not complicated, and using OOP would probably make it unecessarily complicated.

Maybe, if you tell us what you wanna do with OOP or function pointers, we can point an alternative.

NOTE: OOP is over-rated. Programmers tend to make things look more complicated than they are. OOP is not the solution to MANY problems it's used to solve (it can solve, but it's not a good tool to solve) -- and OOP is not a solution for "gluing programming".

NOTE2: If you still wanna use escript for big, serious, real world, or whatever name people use to refer to programming that is not small and specific, good luck with error detection, and handling.

You remind me of an old friend, he always thought he was right even if he was wrong.
He was always offensive even saying “Ho, I don’t wanna be!”
He always thought everything was easy and never had problems to understand anything.
I ask myself how can anybody know so much and have such a mediocre life.

[phao]

You remind me of an old friend, he always thought he was right even if he was wrong.
He was always offensive even saying “Ho, I don’t wanna be!”
He always thought everything was easy and never had problems to understand anything.
I ask myself how can anybody know so much and have such a mediocre life.

Geez... he must be annoying. Tell him that.

PS: Books also say you shouldn't try to make things simpler than they should be.

Yeah. I just can't think of ways to make them complicated, in most of the cases while programming in eScript.

About opinions. You can clearly see that I think adding common features from OOP or FP languages into eScript is kinda silly. But, I think you should look at other languages.

Look at shellscript, which is probably the most used scripting language to put pieces together. Go to some place where people USE shellscript, and ask them why they wouldn't add those stuff you want. Some will say "I like this stuff and I'd like them in the language", but some others will tell you "If you want to build some system that would be complex in shellscript, you probably should be using other tool, like C, instead of shellscript; and not extend the language." -- I'm with the later. If you want anything more complex, go with C++, program the CORE. Maybe you can solve your problem by adding module functions.

[guialtran]

You remind me of an old friend, he always thought he was right even if he was wrong.
He was always offensive even saying “Ho, I don’t wanna be!”
He always thought everything was easy and never had problems to understand anything.
I ask myself how can anybody know so much and have such a mediocre life.

Geez... he must be annoying. Tell him that.

PS: Books also say you shouldn't try to make things simpler than they should be.

Yeah. I just can't think of ways to make them complicated, in most of the cases while programming in eScript.

About opinions. You can clearly see that I think adding common features from OOP or FP languages into eScript is kinda silly. But, I think you should look at other languages.

Look at shellscript, which is probably the most used scripting language to put pieces together. Go to some place where people USE shellscript, and ask them why they wouldn't add those stuff you want. Some will say "I like this stuff and I'd like them in the language", but some others will tell you "If you want to build some system that would be complex in shellscript, you probably should be using other tool, like C, instead of shellscript; and not extend the language." -- I'm with the later. If you want anything more complex, go with C++, program the CORE. Maybe you can solve your problem by adding module functions.

No

[andenixa]

Shell-scripts and escript should not be compared because they have a non-overlapping areas of application. I hardly see any relevance.

The suggestion to program the core doesn't make any sense:

• Whenever the new core is out my changes are lost.
• Comes with no containers or lists but low level data structures. Writing my own? NO.
• Automatic garbage collection in C++ is non-existent. Memory management sucks donkey balls, try it for 1500+ scripts and you'll get the idea; certainly you DON'T want it for something like a shard scripting.
• Neither C++ is a good choice for a text parsing; which I do a LOT.

[Turley]

• Whenever the new core is out my changes are lost.

why not simply code something generic that everyone could find usefull and submit a corepatch

[*] Comes with no containers or lists but low level data structures. Writing my own? NO.

ever coded in c++? i think not

[*] Automatic garbage collection in C++ is non-existent. Memory management sucks donkey balls, try it for 1500+ scripts and you'll get the idea; certainly you DON'T want it for something like a shard scripting.

a simple delete in deconstructor never hurt someone

[*] Neither C++ is a good choice for a text parsing; which I do a LOT.[/list]

Whats the problem with text parsing? There are hundreds of possibilities to parse a text.

[andenixa]

Thank you for your reply,
could you elaborate on the topic please? I am really interested on the developers opinion.

[phao]

Shell-scripts and escript should not be compared because they have a non-overlapping areas of application. I hardly see any relevance.

The suggestion to program the core doesn't make any sense:

• Whenever the new core is out my changes are lost.
• Comes with no containers or lists but low level data structures. Writing my own? NO.
• Automatic garbage collection in C++ is non-existent. Memory management sucks donkey balls, try it for 1500+ scripts and you'll get the idea; certainly you DON'T want it for something like a shard scripting.
• Neither C++ is a good choice for a text parsing; which I do a LOT.

The fact that shellscript and escript aren't used for the same goals isn't important for the comparison. The fact is that both were created to put together functionalities provided by some external source (shellscript put together, normally, text-mode programs written in C; and escript puts together modules functions provided by POL, written in C++).

In all programming languages you'll put things together. You do that even in assembly. The point is the extend to which you do this gluing. Most of my code in eScript doesn't involve functions or other programs I created that are "pure, or almost pure, escript programs". Most stuff is just, really, putting things together. My shard is in its initial state, so I understand that in the future, it'll get more complicated, but I don't think it'll get to a point that I'll need extremely complicated systems in eScript.

About programming the Core. Tell what you think to tomi, he's doing some interesting stuff for his own changing the core. I bet turley and other devs have been doing that for a long time ago.

Have you ever heard of libraries? Solves pretty much all your problems. And, STL's data structures aren't low level.

[Turley]

I understand you both, ok not the way you discuss
function pointer is an interresting idea, but nothing simple. So maybe someday someone codes it

[andenixa]

I understand you both, ok not the way you discuss
function pointer is an interresting idea, but nothing simple. So maybe someday someone codes it

Thank you. Thats what I wanted to know.