ENTER and RETURN

[tperry2x]

...the difference is in readability of scripts because 'the' is the token that indicates a property. With a global I can't 'put THE selectedSoundFont', but I can 'put selectedSoundFont'.
Now that I think of it there might be a way I suppose to make a new 'global property' like with those .tsv tab separated value files, I think I did do some experimenting with a 'properties.txt' file.

How about we use a shorthand version for custom functions, something like 'eval'. As in:

eval.png (51.16 KiB) Viewed 1095 times

Although, granted - that's not really gaining much - but puts a differentiator into custom functions. Perhaps? - What I mean is that we could use an alternative phrase instead of 'the[token]', we could use 'eval' in place of 'the'. Or even something like 'thefunc' as in "get thefunc(osversion)" or "answer thefunc(osversion)" - not very xTalk-ish though.

[OpenXTalkPaul]

Unfortunately what you mentioned in the seventh paragraph of your posting did not get anywhere:

Because the proposed "Open Language" syntax will be, AFAIK, based on a system of well-defined prototypes, it may be able to take care of many of the current cases where parentheses are currently needed. But I'll have to see it before I get too excited about it beyond that and making externals and custom handlers more readable.

If you look at the Extension builder source for its language modules (like com.livecode.canvas), and how it defines syntax for XB language, I think that is an argument to be made that 'open-language' initiative sort of went somewhere ( but of course wasn't documented ), although that system can only define new syntax for Extension Builder language, not for the scripting-engine side of things.

[richmond62]

It seems there are 2 potential ways forward:

1. Crack open the engine and overhaul everything that has been sitting there since whenever and now doesn't function properly: and as that is a moving target . . .

2. Allow over-riding, both on an individual end-user basis and on a keepers of the sacred flame basis.

#2 should win hands down: cheaper, cheaper, and, err, cheaper.

#2 should allow everyone to have their own 'hairstyle' in a way that a hard-boiled, locked-up engine just won't.

--------

In about 1968 (when I was 6) a very rich, elderly cousin of my father sent me a sizeable box of LEGO for my birthday with the strict instructions that my parents (who were strapped for cash) were to lie and say it was from them. Unbelievably generous!

There were 2 problems:

1. As I was 6 I could read quite well.

2. A booklet that came with the LEGO mentioned a motor.

So my father went over to the science labs where he worked and sweet talked one of the technicians into putting together a very simple battery motor glued onto a LEGO block.

Years later I saw a real LEGO motor and worked out that my one was better, because, it being simpler, it was more flexible (used it a lot with some Meccano).

So I am well aware that the. simpler and more 'primitive' an engine, the more freedom is afforded the person who would use the engine.

[FourthWorld]

Again, the play command, the APIs that this command relied on have changed so much it's broken and virtually useless now on some platforms, and it never followed (what I call) 'standard' xTalk anyway.

The principle in play was custom behavior merits a custom name. If built-in functions can be altered by libraries, predictable engine behavior becomes an unpredictable runtime environment.

That conversation was part of what led to my xTalk mantra:

Know the engine.
Trust the engine.
Use the engine.

But of course that only works where the engine is well maintained.

If the play command worked (syntactic warts and all), there would be no need to overload.

Indeed, given the syntactic warts, truly overloading the existing syntax isn't the desire here.

But without an engine that can play multimedia, any new syntax is dressing a corpse in a tuxedo: looks great, can't dance.

Scripting languages in general offer this value proposition: we handle the OS APIs so you can focus on application-specific functionality.

Multimedia playback is fundamental. When it works in the engine, details about how to use it conveniently can be worked out with relative ease.

But if the engine doesn't do what it says on the tin, Dr Raney saw that as his responsibility.

doesn't read very English-like, which I always thought was the goal of xTalk.

"Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo" reminds us of the challenges of attempting "English-like" in any language designed to send unambiguous instructions to a machine.

There is also conciseness, which usually increases learning/reading time up front, for the payoff of years of reduced typing.

For example, I'm grateful I can use the common syntax for arrays:

Code: Select all

put "10000" into tBudgetA["expenses"]["vendors"]["newfees"] 

...rather than a more conversational:

Code: Select all

put "10000" into hashbucket "newfees" of hashbucket "vendors" of hashbucket "expenses" of variable tBudgetA 

CSS is an extreme of this sort of conciseness, at first mystifyingly sparse, but ultimately replacing hundreds or thousands of lines of code with a very few lean directives (think 2D and 3D transforms, so elegant in CSS, so slow to execute back when we attempted those in JavaScript).

Of course language design is a matter of taste, and there's no disputing taste.

But where any additional learning effort is more than offset by downstream usability, my own tastes tend to enjoy the learning. I no longer see it as "I HAVE to learn that", seeing it instead as "I GET to learn that".

Whether code written for unambiguously telling a machine what to do also happens to read like a conversation with a friend over tea isn't something I think about often. I just want the machine to do what I want it to do so I can go get tea.

[OpenXTalkPaul]

Code: Select all

put "10000" into hashbucket "newfees" of hashbucket "vendors" of hashbucket "expenses" of variable tBudgetA 

I'd actually prefer that in some situations, or at least prefer to have that as an option, and it shouldn't make any difference to an interpreter that's doing ahead of time compiling.

In fact that is basically what we already have as far as object referencing

Code: Select all

set the imageData of "My Image" of group "images" of card "image Previews" of stack "Images" of stack "Image Browser" to myImageData 

But I agree, to some degree. As I mentioned, it can get a bit confusing when scripts don't trap some message that's implementation is being overridden. I'm sure it wasn't easy to make a App-Engine DSL subset of English that still reads like English but is also a capable programming language.

You can also look at the "Winkler Test" to see how confusing it can get:
https://github.com/kreativekorp/openxio ... lerTest.xn

Obviously it would be better if these things weren't neglected on the engine level, and that when things get fixed they get fixed on the engine level, but of course that has a higher barrier for entree than if we 'trust the script authors' allowing them to quickly work around some flaw or impliment some missing feature on their own without having to recompile the engine(s) and all that goes with that.

Consider the opposite line of thinking in SmallTalk. The 'small' comes from the minuscule amount of reserved words there are, everything else in a SmallTalk environment is built up from that very tiny set of syntax.

Six "keywords" are reserved in Smalltalk: true , false , nil , self , super , and thisContext

[FourthWorld]

You can also look at the "Winkler Test" to see how confusing it can get:
https://github.com/kreativekorp/openxio ... lerTest.xn

Ouch. That makes me grateful for Dr Raney's impatience with ambiguity.

Obviously it would be better if these things weren't neglected on the engine level, and that when things get fixed they get fixed on the engine level, but of course that has a higher barrier for entree than if we 'trust the script authors' allowing them to quickly work around some flaw or impliment some missing feature on their own without having to recompile the engine(s) and all that goes with that.

The engine talks to the OS. We talk to the engine.

OSes don't provide APIs for multimedia playback in oxTalk, so it falls on the engine to open that up for scripters.

Maybe oxBuilder can help. That was the original design goal, anyway. I've never had occasion to use it, so I have no opinion about it's usefulness for this task.

I did, however, use Toolbook, and was impressed with how easily they added FFI right into the main scripting language. I tried suggesting that with the LC engine crew in the early days of Builder design, but they were insistent that it be done in an entire new language.

[OpenXTalkPaul]

I did, however, use Toolbook, and was impressed with how easily they added FFI right into the main scripting language. I tried suggesting that with the LC engine crew in the early days of Builder design, but they were insistent that it be done in an entire new language.

I've never used Toolbook because it was Windows only, but it does seem like it was a pretty solid solution on that platform.

Yes I thought that as well, that they should have tried to add LCB features directly into the the scripting language, it may have had more adoption from users that way, although there would still be the low-level concepts (variable typing, memory pointers, OOP concepts, etc.) that users would've still had to wrap their heads around to use certain foreign APIs.

It seemed like they might've finally been moving in the direction of merging LCB with LCS somewhat. I gather that's why they've added things like Array-constants, new keyword that's like LCB's 'nothing' (undefined/null pointer), and on the other side allowing widgets to be created using LCS (which I'm starting to think the potential for creating objects of an arbitrary 'kind' was always present).

I wonder what the reasoning was for not doing that? I imagine it was some technical reasons.
I know the idea at one point was to 'bootstrap' build everything, including the language interpreter, in itself (hence the name LiveCode Builder). Those language modules (undocumented as they are) allow use to add to the language, so guess that was the 'open-language' infrastructure.

Anyway I'm grateful they added LCB & FFI at all, previous method of extending the environment was 'externals' glue code, writing in some non-xTalk-like lower level language (C/C++, Pascal, etc.). In my opinion LCB is easier, and does not require Xcode, VSCode, etc. and it feels easier for iterative development.

[richmond62]

I used Toolbook in 1998 as where I worked had suddenly (on a whim of one of the hundreds of sons on the Sheikh) decided to dump Macintosh and go for Windows.

It struck me at the time as an awkward sort of HyperCard with better colour and media leverage.

Toolbook is now discontinued.

[OpenXTalkPaul]

I used Toolbook in 1998 as where I worked had suddenly (on a whim of one of the hundreds of sons on the Sheikh) decided to dump Macintosh and go for Windows.

It struck me at the time as an awkward sort of HyperCard with better colour and media leverage.

Toolbook is now discontinued.

All I really I know about it is that it didn't use stack-of-cards metaphor as It was more for interactive 'book' (eBook) making, so more like Page Layout App I assume.

[FourthWorld]

Just nomenclature changes for differentiation. Functionally it was an xTalk, with stacks called "books" and cards called "pages".

[richmond62]

It took me about 3-4 hours to get things working in Toolbook after 4 years of HyperCard: as Richard says, just different words for the same sort of things.

My only real problem was that I didn't like Windows NT.

I was moving back and forth between TB on Windows NT at work, and Windows 98 inside Virtual PC on MacOS 8.6.1 at home with a JAZ drive.

Spent a longish time with the JAZ drive as it used a parallel port on the PC and a SCSI port on my G3 at home.

Mind you, I was making very basic EFL programs: most of which, after all the work, got flushed by the censor as not sufficiently Islamic. So didn't really do anything clever with FFI (Erm: Fancy Fairy Insects?).

Later, some of my colleagues were working with HyperStudio just before it went "Hold My Hand" to such an extent it became not fit for educational program design.