Parameter passing - calling styles

Eggplant Functional
1

When calling a script with parameters, I’m seeing some inconsistent behaviour.

Consider this script fragment …



set path to my folder's folder & "Data/OzOrgNames.txt"
Set counter = 33
Set loops = 0

Repeat with OrgDetails = each line of file path
	
	if loops < 4 then
		Set OrgName = (Item 1 of OrgDetails) & counter
		Set OrgCode = (Item 2 of OrgDetails) & counter
				
		AddNewStateFromText OrgName, counter
		// AddNewStateFromText( OrgName, counter)
		
	end if
	
	set loops = loops + 1
end repeat

which calls this script … and I only need the first couple of lines from this to explain the problem …


params  OrgName, nCounter

put the params

log "nCounter in NewState : " & nCounter
log "OrgName in NewState : " & OrgName

The pertinent lines in the first script are the call to AddNewStateFromText, towards the end of that script. As you can see, I have two versions of that call, one being to call it as a command, the other as a function.

Here’s the relevant log entries when calling it as a command …


addnewstatefromtext "Ray White Real Estate33","33"
Thu, 12/06/08 10:09:49 AM	log		nCounter in NewState : 33
Thu, 12/06/08 10:09:49 AM	log		OrgName in NewState : Ray White Real Estate34

And here’s the equivalent log entries when calling it as a function …


addnewstatefromtext ("Ray White Real Estate33", "33")
Thu, 12/06/08 10:08:23 AM	log		nCounter in NewState : 
Thu, 12/06/08 10:08:23 AM	log		OrgName in NewState : (Ray White Real Estate33,33)

The problem arises with the values assigned to nCounter and OrgName in the called function: When called as a command, the data assignments are correct, and are able to be used by the function, but if the routine is called as a function, the value intended for nCounter is appended to the value assigned to OrgName, and nCounter is left as null.

This, of course, causes serious issues further downstream, as any subsequent dependencies are now rendered incorrectly.

As I need to use the functional version of the call, could somebody please tell me what is happening here?

2

Sure. What you’re running into here is the fact that a function call in SenseTalk only occurs in the context of an expression, never as the first word on a line.

Whenever a script name is given as the first word on a line, that script will be called as a command, not as a function. When you put parentheses around the parameters you’re not turning it into a function call (it’s still a command). Instead, you’re turning what used to be two parameters into a list that’s being passed as a single parameter.

SenseTalk is a very contextual language. In this case, what makes something a function call in SenseTalk isn’t the syntax used (the parentheses after the name), but the context in which the call is made. You can call your AddNewStateFromText script as a function like this:

put AddNewStateFromText(OrgName, counter)

Since it’s being used as the parameter of a put command, AddNewStateFromText() is now expected to provide a value, so it’s called as a function.

Extremely observant scripters (or those who have attended the SenseTalk training class!) may notice that the parentheses (and even the commas) are a different color when they are used to create a list than when they are used to enclose the parameters of a function call. :slight_smile:

3

So, doing

SomeCommand  ("Ray White Real Estate33",33)

will pass in as the first parameter to the handler (note I didn’t refer to it a function or a command, the notion of a generic enough handler to be called either way) the list

(Ray White Real Estate33,33)

You can get away with the as parameters to really make life interesting

SomeCommand  ("Ray White Real Estate33",33) as parameters

Here is some code with output commented at the top to show the difference in how things are called and what is assigned to the parameters that a handler has defined…

-->  Wed, 6/11/08 7:41:10 PM	START  Running TossOut.script
-->  Ray White Real Estate33
-->  (Ray White Real Estate33,33)
-->  Wed, 6/11/08 7:41:10 PM	SUCCESS  Execution Time 0:00:00 TossOut.script

SomeCommand  ("Ray White Real Estate33",33) as parameters
SomeCommand  ("Ray White Real Estate33",33)

to SomeCommand  a, b
	put a
end SomeCommand

Hope this helps. I have been snagged by the idea and implementation of handlers which can be called either as functions or commands. However, this turns into a HUGE win in allowing you the flexibility on calling something in a clear way for your needs.

Historically I believe this ‘feature’ was introduced to be forward and backward compatible with other needs of the language evolution as well as HyperTalk the language in which SenseTalk was originally modeled. (Doug, care to comment on this).

4

[quote=“SenseTalkDoug”]SenseTalk is a very contextual language. In this case, what makes something a function call in SenseTalk isn’t the syntax used (the parentheses after the name), but the context in which the call is made. You can call your AddNewStateFromText script as a function like this:

put AddNewStateFromText(OrgName, counter)

[/quote]

Or in a more realistic coding context …


set SomeiVar = AddNewStateFromText(OrgName, counter)

Which makes perfect sense. Even to me. :slight_smile:

Many thanx.