Handlers/Functions with or without ( )

[palanolho]

Greetings everyone.

I would like to make a fracture request regarding the user of ( ) when calling an handler/function

I recently had a problem because I was using the revDeleteXMLNode handlers like this:

Code: Select all

revDeleteXMLNode(treeID, treeNode)

This was giving me an "invalid number of arguments" error and I wasn't understanding why.

So, after pulling out much of my hair, I surprisingly found out that the problem was with the ( ).

if I called the handler without the ( ) it worked just fine.

For me this doesn't make sense, because the ( ) are a matter of organization and code readability.

You can use "If ... then" or you can use "If (...) then"
but with handlers/functions this is not true and its confusing..

For example:
"revXMLText tTreeID, tRoot ,true" doesn't work but "revXMLText(tTreeID, tRoot ,true)" will work
"revDeleteXMLNode(treeID, treeNode)" doesn't work but "revDeleteXMLNode treeID, treeNode" will work


So, my suggestion is:

- When calling or creating an handler/function, make the use of ( ) an optional thing and allow to call/create handlers/functions with and without the ( )

ex:
WHEN CREATING/DEFINING

Code: Select all

function myFunction (var1, var2)
end myFunction 

function myFunction var1, var2
end myFunction 

on myHandler (var1, var2)
end myHandler 

on myHandler var1, var2
end myHandler

All these options should be equivalent

WHEN USING

Code: Select all

myFunction (x, y)
myFunction x, y
myHandler(x,y)
myHandler x,y

All there options should be equivalent

Many thanks
- Miguel

[Klaus]

Hola Miguel,

please don't take it personally, but I highly doubt that RunRev will change the way
Livecode works only because some users have these problems!

Learn as much by heart as you can, for the rest check the dictionary,
that's what I did in the last 14 years with MetaCard/Revolution/Livecode

Best

Klaus

[palanolho]

In my opinion, is no a matter of me liking it or not, its more a logic thing that makes sense BUT ....

It's only a suggestion top developers to create better readably code.

I'm only trying to help to improve this great tool, and believe me, despite knowing how to program for some years (common programming languages), and despite Livecode being complete different from everything I know, I'm really enjoying to learn and use Livecode

Cheers
- Miguel

[Klaus]

Hola Miguel,

yes, sure, what I meant is that Livecode has been working this way for the last 21 (sic!) years
(as MetaCard/Revolution/Livecode) and it is unlikely that this will change in the future.


Best

Klaus

[[-hh]]

..........

[FourthWorld]

So, my suggestion is:
- When calling or creating an handler/function, make the use of ( ) an optional thing and allow to call/create handlers/functions with and without the ( )

There are two basic types of handlers in LiveCode, commands and functions. This has been a defining characteristic of all xTalks dialects going back to HyperCard 1.0 (somewhat inspired by Pascal, which distinguishes between procedures and functions), carried through with SuperCard, Oracle Media Objects, Lingo, ToolBook, Eggplant, Gain Momentum, Plus, and others, and is unlikely to change.

Whether one sees this as a bug or a feature depends on how you look at it. Given that it's been this way for decades and is unlikely to change, it seems more useful to focus on understanding why there are two so each can be used effectively:

In general, commands perform an action and functions return a value.

I like to think of the parentheses used with function calls as a mnemonic device, since they visually form something like a box, reminding us that it's really just a placeholder for a value that will wind up in that place in the statement.

For example, in:

Code: Select all

DoSomethingWith SomeValue()

"DoSomethingWith" is the command, which acts on the value returned by "SomeValue()". If the "SomeValue()" function returns "foo", the engine evaluates that first to arrive at:

Code: Select all

DoSomethingWith "foo"

What we see in that simple example is carried out rather consistently throughout all of LiveCode: every statement in LiveCode begins with a command, and may include functions among the tokens it uses to derive values the command will work on.

Let's take this a step further with this example:

Code: Select all

DoSomethingWith SomeValue(1,1), "bar"

If we have these definitions:

Code: Select all

command DoSomethingWith pValue, pFieldName
   put pValue into fld pFieldName
end DoSomethingWith

function SomeValue pNum1, pNum2
   return pNum1 + pNum2
end SomeValue

...then what happens is pretty clear.

But attempting to use command syntax for the function call would make it difficult for both the engine to parse and for us to read:

Code: Select all

DoSomethingWith SomeValue 1,1,"bar"

Is "bar" an argument to SomeValue or to DoSomething?

To resolve that ambiguity we'd need to add some characters to act as delimiters in that statement to make it clear which arguments are for which handler.

In LiveCode, those delimiters are parentheses.

So when using libraries, whether RunRev's or from third parties, just take note of whether the token is a command or a function, remembering that statements must begin with a command while a function will return a value for a command to act on, and the rest falls into place.

[palanolho]

Thank you very much for the explanations everyone

cheers
- Miguel

[[-hh]]

..........

[FourthWorld]

I don't say that such a calling method is better or should be made.

Exactly. I think we're on the same page.

Moving parentheses around doesn't get rid of them, and even when RunRev implements their definable syntax initiative the basic xTalk rule of commands being actions that can act on values returned from functions will likely still come into play.

And in the meantime LC works how it works: when using functions from a library, we need to use parens in the prescribed form.

[[-hh]]

..........

[FourthWorld]

But why not (meanwhile) introduce a 'cFunction' or a 'fCommand' with 'command syntax' that does both, directly returning an expression like a function and setting the result (may contain warnings) like a handler?
For example

Code: Select all

fCommand getItem str, j
  # code to add a warning 'j is out of bounds' to
  #  'the result' if j > the num of items of str
  return item j of str
end cFunction

You can kind of do that now, in the sense that commands can indeed retun values (often for error handling, as you suggest), but unlike funtions their values aren't returned in-place, instead obtainable with a subsequent call to get the local variable "it".

If you need an in-place value returned from a handler, functions do this now very easily at the low cost of typing two parentheses - with the extra benefit that adding those parens helps distinguish the function's args and make the whole statement that much clearer.

Better still, this is how the engine works. No need to wait for new features if we just use commands for commands and functions for functions.

[[-hh]]

..........

[FourthWorld]

You pointed out that functions are just special commands with a return statement, easier to use, avoiding the subsequent call (should read 'the result' instead of 'it' in your description).

Good catch - thanks. "It" is often used by engine commands to return values, but you're right, many commands also use "the result", esp. for error info.

You also say, that we don't need things we can have 'a kind of' otherwise

I don't think those are my words, and I apologize if what I did write seemed to say that. Certainly not my intention; I'm not even sure I understand what's meant there.

All I intended to do here was provide some background on why all xTalks have worked the way they do so the OP could do what he needs to do and move on. He hasn't posted since he said "Thanks" so I guess he got what he was looking for.

Yes, LC is a language of 'workarounds'

One man's "workaround" is another man's "feature". I try to avoid labels like that when I can, and just get people the code they need to get their job done and move on.

Never met a language yet someone didn't complain about, and never met one someone didn't love. Thankfully we have thousands to choose from, so we can all have exactly what we most want.

And with LiveCode being open source, there's no end to the possibilities, since everyone can fork it and make it work however they prefer. Like Linux - via la difference.

So, after all, what are the real critera for a thing to become a 'new feature'?

Submitting a request to RunRev's DB would be the first step:
http://quality.runrev.com/

[[-hh]]

..........

[FourthWorld]

Thank you for the kind words. Sorry if it seemed I was insulted, or insulting; didn't feel either way here to me, but that's one of the problems with forums and email: they carry no tone or any of the other factors that make live conversation so much smoother. If you find yourself passing through Los Angles drop me a note and we'll have a beer. It'll be good conversation for sure.

In the meantime, this is the Feature Requests forum, so if you feel strongly about your proposal feel free to refine it here and/or submit it as a request at the URL I posted.