Poking around in the engine

[tperry2x]

While poking around in the engine, I wondered if anyone knew about this.
(I might just be late to the party again here)

poking-around.png (184.49 KiB) Viewed 1753 times

The answer command can take the name of a function at the end, so that whenever a button is clicked - that can be handled whenever. The rest of the script does not stop because it's waiting on user input.

As in:

Code: Select all

on mouseUp
   answer "Do you want to save changes?" with "Save" or "Don't Save" or "Cancel" tChosenOpt it
end mouseUp

on tChosenOpt theButton
   put "you chose: " & theButton into fld "output"
end tChosenOpt

I just thought this was handy, and other people probably already know about it. It's not covered in the dictionary as an option though.

[richmond62]

You may have just 'ruined' my Sunday as this is really fascinating . . .

[FourthWorld]

I believe that may be a bug, where the example given:

Code: Select all

on mouseUp
   answer "Do you want to save changes?" with "Save" or "Don't Save" or "Cancel" tChosenOpt it
end mouseUp

...is equivalent to having two statements separated by a semicolon:

Code: Select all

on mouseUp
   answer "Do you want to save changes?" with "Save" or "Don't Save" or "Cancel";  tChosenOpt it
end mouseUp

From time to time over the years I've seen cases where the parser stops working on a statement once it reaches the expected end of the statement, where anything beyond that is ignored.

This seems similar, except that the portion beyond the defined statement is treated as a new statement.

[richmond62]

Just cracked open LC 963 and popped this into a button:

Code: Select all

on mouseUp
   answer "Well?" with "Yes" or "No" myCrud it
end mouseUp

on myCrud
   put "You Got It!"
end myCrud

And, when I selected a button in the answer dialogue got "You Got It!" in the messageBox.

[tperry2x]

I believe that may be a bug...

Yes, unfortunately. Seems like it's a parameter left in but never implemented, which is a pity.

[richmond62]

Why should that be regarded as a bug, and not a useful feature?

[FourthWorld]

Why should that be regarded as a bug, and not a useful feature?

I suppose we can invent any convention we want, allowing all possibilities.

But historically, an xTalk command is the first word of a statement clause, and statements outside of inline conditional expressions are separated by carriage returns; inside of conditional expressions they follow the condition definition.

MetaCard expanded on this convention to allow multiple statements on a single line when the statements are separated by a semicolon.

So in the OX/LC multiverse, the basic rule of commands applies fairly consistently, where the separator between them can be either a return or a semicolon, or a conditional expression.

OXTalkers are free to do what they like, but I would invite reflection on the value of "sometimes" rules, breaks from otherwise-consistent conventions that work in some contexts but not others.

In this case the question boils down to:

Is the additional cognitive and documentation encumbrance of yet another "sometimes" rule offset by not having to type one statement-delimiter character?

I would imagine the answer will vary by reader.

Personally I avoid teaching and using "sometimes" options wherever practical, but that's just me.

[richmond62]

But historically

Um, 'historically' is no argument at all: in Scotland, historically, we used to torture socially marginalised women so they had mental breakdowns and would say they were witches: we then burnt them alive . . . the fact that that happened historically is no reason to keep doing it.

And 2 lines of code from my Devawriter Pro look 'kinda clunky' if we want to judge things by historic precedent:

Code: Select all

   set the coloroverlay["color"] of me to white
   set the coloroverlay["opacity"] of me to "100"

Personally I think:

Code: Select all

answer "Do you sweat on cool days?" with "yes" or "no" doSomethingElse it

is pretty bizarre code, but I would assume whoever introduced that (K.M.?) had some reason for doing that and it was not just a 'blip'.

[FourthWorld]

Personally I think:

Code: Select all

answer "Do you sweat on cool days?" with "yes" or "no" doSomethingElse it

is pretty bizarre code

So far, in our sample of two, we have unanimous agreement.

but I would assume whoever introduced that (K.M.?) had some reason for doing that and it was not just a 'blip'.

I wouldn't be so confident that it was an intended feature. Parsing is complex stuff, and the Ask and Answer commands are unusual cases in LC, so we can imagine any review of parsing clean-up that might have found other anomalies can easily miss this one.

Evidence that it isn't intentional:
- It's unlike the rest of the syntax;
- undocumented;
- I've not seen scripts depending on it written by either Dr Raney or anyone on the LC team;
- if you follow their bug DB closely you'll find from time to time similar oddities easily explained by incomplete exception handling during parsing that their CTO has flagged as a bug and fixed.

What evidence can we find that it's intentional?

[richmond62]

What evidence can we find that it's intentional?

Almost as much as evidence there is to prove it is unintentional.

AND I can see no very good reason to remove it.

[FourthWorld]

What evidence can we find that it's intentional?

Almost as much as evidence there is to prove it is unintentional.

I listed four elements evidencing the likelihood that this anomaly is unintentional.

So far the list of evidence that it's intentional is empty.

Did you mean to include something that was deleted when posting?

AND I can see no very good reason to remove it.

Agreed there. I would leave it in place and undocumented.

The only priority at the moment is an m-series compile for macOS. Without that, everything done on this code base risks significant diminished value as soon as Apple stops supporting Intel compiles.

[richmond62]

The only priority at the moment is an m-series compile for macOS.

Is that a fact?

Or is it just another of those things you decided unilaterally?

Either way: what are you doing about it?

[FourthWorld]

The only priority at the moment is an m-series compile for macOS.

Is that a fact?

Or is it just another of those things you decided unilaterally?

It's obviously an opinion, like your own words.

But the importance of an m-series build has been expressed by others in various forms, and is based on well-known elements:
- Most xTalk fans are Mac users.
- Apple will not support dual architectures forever.
- All platforms benefit from ecosystem growth.
- Conversely, platforms suffer from ecosystem decline.

Ether way: what are you doing about it?

I haven't used a GPL-governed xTalk engine in many years, and while I'm considering this one for a project just over the horizon, the project is at least many months away from having to choose a dev platform to build it with.

So what little I've done to headhunt a resource for this is infinitely disproportionate to my usage.

You?

[OpenXTalkPaul]

pretty bizarre code, but I would assume whoever introduced that (K.M.?) had some reason for doing that and it was not just a 'blip'.

I was thinking there could have been some reason for this at one time, perhaps with 'Answer Record' or some other form of that's no longer supported. Maybe some good reason to break tradition just a bit, similar to filter command having a form that allows for a function in place of a sorting property?

Certainly not being documented is not a great indicator that it was unintentional. The documentation has always been lacking.

Whether it's a bug or just undocumented feature, I always find discoveries like this interesting and a bit like finding an "Easter Egg".

I just noticed a feature (definitely not a bug) that the Tools palette had handlers that allow drag-and-drop installation of Widget modules (those .lcm files). It's not documented anywhere as far as I know.