Is 'the result' a good idea?

[LCMark]

With LCB I'm quite keen to ensure that we don't introduce any features or 'core' syntax which could be confusing and/or of limited utility. Indeed, @trevordevore's bug http://quality.runrev.com/show_bug.cgi?id=14963 has got me wondering whether 'the result' is a good idea.

Now, the bug itself is just that the compiler is not verifying that 'the result' can be assigned to - that would be easy to fix, but looking at @trevordevore's code, what he is trying to do doesn't actually make sense, even though at first glance it seems so. The code is this:

Code: Select all

variable tScript as String
put "get URLEncode(\q" & pString & "\q);return it" into tScript
execute script tScript
		
replace "+" with "%20" in the result
replace "*" with "%2A" in the result
return the result

The problem comes with the 'replace' lines. The current formalism for 'the result' is that it is always the return value of the last executed command. If the command 'returns nothing' then it assigns 'undefined' to the result. Note that this is a very strict thing - a command can't choose whether it can 'set the result' or not, as this is a source of fragility in code in LiveCode Script (and we don't want to repeat the same mistake!). This rule implies that 'the result' must be read-only - there's no point in a command being allowed to mutate 'the result', since (by the stated rule), it would get set to the return-value of that command afterwards anyway so the mutation would have no effect.

Given that we have a general 'into' postfix syntax, I therefore wonder whether 'the result' is needed at all. Either you are interested in the result of a command, or you aren't - if you are interested in it then you can almost as easily use a postfix into syntax. Indeed, in the above, due to the action of 'replace' it is a 'mutation in place' command meaning that it never communicates anything by a return value.

One of the reasons for adding 'the result' was to ease the writing of short runs of code which transform a value - so it was more to do with code brevity than anything else. i.e. It avoids you having to declare a variable to do the same thing. However, I wonder if adding something like this for the purposes of code brevity is only going to cause annoying and subtle errors; as well as frustration when you realize you can't use 'the result' in a particular context because you need to use a command like 'replace'.

So - proposal - get rid of 'the result' and 'get' and instead allow you to *not* have to declare variables... It should be possible to imagine a set of rules where the compiler implicit declares variables for you when they are used as the target of a pure 'out' context. This would model what I was trying to achieve with 'the result' (an implicitly defined variable which is typed by use) without the drawback it has as outlined above.

In this model, @trevordevore's code could become:

Code: Select all

variable tScript as String
put "get URLEncode(\q" & pString & "\q);return it" into tScript
execute script tScript into tURL
replace "+" with "%20" in tURL
replace "*" with "%2A" in tURL
return tURL

What do people think?

[n.allan]

I'm a noob to LCS but for what it's worth....

I can see the merits of "the result" variable BUT my initial thoughts are with regards to the "type" of "the result" too.

It looks like "the result" is automatically assigned a type returned from the previous function in LCS.
Will that cause confusion when attempting to "return" the result from a handler? The handler must specify it's return type if I am not mistaken?

So in all cases you should probably be assigning the output of your function to a typed variable anyway.

Just an initial observation.

[trevordevore]

@LCMark It should be noted that I wasn't expecting the replaced command to work on 'the result'. I gave it a try as I've been testing out various things to see how LCB works.

That being said, I am very much in favor of getting rid of 'the result' and 'it' in LCB. I've never liked these two aspects of the language. The concept of 'it' was confusing to me when I first started using LC. I never like using 'it' in my own code as it doesn't tell me anything about the data in the variable. 'the result' is ambiguous as well in the sense that it doesn't tell you anything about the data being returned. I would much rather write write 'into tURL' after 'execute script tScript' as it is clear what the returned data is expected to be.

So I would vote for doing away with 'the result' and going with 'into tVar'

[LCMark]

@n.allan: Handlers, just like variables, don't have to specify their return type. If you don't specify a return type on a handler then it is considered to return an 'untyped' value. So you can either 'return' or 'return <Value>' from it.

I initially thought there were merits to 'the result' in LCB - it is much better defined than the corresponding concept in LCS, but @trevordevore's example shows quite well that it isn't at all useful for achieving what it was intended for. (Slightly more brief and succinct code). I think implicit variable definition would work better - and be much clearer.

@trevordevore: I think the writing is on the wall for 'the result' We'll put some warnings in DP2, and then remove in DP3 or DP4. There is a potentially (correct?) abstraction of the idea of 'it' that we could look into at some point... It occurs to me that 'it' is designed to give a sideline return value from a command. The problem is that it is generic - if it were specific syntax for a particular command syntax, or collection of syntaxes then there wouldn't be the fragility problem it currently suffers from. Indeed, there is already a good example of this in the 'engine' module - 'the message was handled', 'the message was not handled' - this is the (almost) 'correct' way to express what 'dispatch' trys to do with 'it' and 'the result'.

[trevordevore]

@LCMark: I like the idea of sideline return values. 'the message was handled' works for me. There is no ambiguity and you don't have to write long dispatch commands in order to get at the sideline value.

Since you bring up dispatch, I noticed that with LCB we now have 'send' and 'post' for dispatching messages. It looks like 'post' is the nice way of sending a message that you don't need a response to right away. The engine can queue it up and send the message at the right time.

Looking at the docs, 'send' seems to work like 'dispatch' in LCS. What would the new syntax be for getting the returned value when using 'send' once 'the result' is removed? 'send "some message" to tObject into tReturnValue'? Or perhaps 'the message result'?

[LCMark]

@trevordevore: Yes - you should use 'send' if you need the object to execute the code then and there (whether you need the result or not). It comes with the problem that it could cause re-entrancy into your widget code which is something you have to be aware of and deal with (until such a time we have enough use-cases to look at to see how to ease this potentially thorny problem). 'post' is generally what you want to do when sending script a message as you avoid the whole re-entrancy nightmare.

In regards to getting the return value of the 'send', then for now it would be by using 'into ...'. You actually raise a good point here - the current implementation of 'the message was handled' is perhaps not quite right as it is what happened to the very last 'send' rather than the last one in the current handler. I'd probably want to fix that issue in a general way (internal architecture speaking) before adding more things like 'the message result'.

I've filed the last item as http://quality.runrev.com/show_bug.cgi?id=14973.

[monte]

Interesting discussion.

@LCMark Implicit typing for temporary variables probably suits the platform. Was there a reason that your code still declared tScript?

[LCMark]

@monte: No particular reason other than I was focused on the URL part which needed to change if 'the result' went away.

The intention is that LCB should be able to be used in a continuum of strictness. At one end, you'll be able to annotate variables with types and in which case the compiler will be very strict about what you can do with them. On the other end you'll be able to declare variables implicitly, or with no type; in which case the compiler will be less strict (but still attempt to infer as much info as possible).

The idea is that if you fully type all your variables you will not be allowed to compile code which could cause a type-check error. If you don't, then you might have such an error arise at runtime. We want to make sure that LCB can be used in a way which prevents you from producing code which suffers from 'simple coding' errors (much like the goals for Rust and Swift); however, realising the need to rapid prototyping, forcing people to do this in the first instance makes (from my point of view) the language of less general utility.

The reason for going down this route is that the goal is that eventually LCB and LCS will converge - it will be a matter of coding style which determines the difference; rather than fundamentally different viewpoints. There's still a way to go before we achieve this though, however it is important to have it on the horizon so we don't take any incorrect paths

[dunbarx]

@LCMark:

I had asked Kevin at the "unConference" if there was a "trend" leading towards required typing of all variables, whether in LCB or LCS, lurking in the future. He categorically stated "no", that typeless scripts are essentially sacrosanct. Am I misunderstanding your meaning when you say LCB and LCS will converge one day, in that either LCB will not need typing, or that LCS will?

Craig Newman

[FourthWorld]

Hopefully it'll be like Toolbook, which has had very graceful support for OS API calls for many years in a way that's simple and fairly consistent with the core language, a good model for inspiration (and one I'm hoping the team has spent time reviewing here in preparation for Builder).

In Toolbook you just write xTalk as you normally would, but when you need to call an OS API those APIs will need variables and params of specific sizes, so in those cases you declare them. But there remains no requirement to declare anything else, only those things where such declaration is truly essential.

If it's of interest I can see if I have any of my old TB code in my archives, but in the meantime I can't recommend strongly enough finding the TB manuals on this and being inspired by them. Very clean, simple approach to exposing the OS within an xTalk, with at least two decades of field testing behind it.

[LCMark]

@dunbarx: LCB does not require explicit typing nor will it ever require it. Indeed, it has always been my long held belief that typing should be treated as 'metadata' - indeed, in general use I refer to type declarations on variables as 'type annotations'. One of the things we are trying to achieve (and, indeed, am absolutely sure that we can!) is a situation where you can write code and have the choice. If you choose to use them then the compiler can identify faults in your code at the point of compilation, if not then you might get errors at runtime just as you do now in LCS. (Also, as a happy side-effect, when we make the compiler/VM 'competent' enough such annotations will also help towards greater performance).

@FourthWorld: Yes, seen it, read the manual - right now, in its infancy, LCB already has a similar level of support for foreign handlers as Toolbook does.. However it is not yet 'good enough' by the metrics I personally have. To give a context to this, I spent two hours tracking down a bug in a foreign binding example I was writing for a blog post before I went away on holiday, and as a result did not have time to finish the blog post (it was because I was over-releasing a foreign datatype). Toolbook and LCB's current level of foreign integration is far too low-level, and we can do a great deal better.

By the way, typing of any sort has no relation to supporting 'foreign code'. Typing is about verifiably correct code - regardless of the language one chooses to write the code in.

I like having choice In how I write code - which is one of the reasons why LCS/LCB will always allow you to choose how you wish to express yourself from a coding point of view in this regard