xTalk Interpretation Differences

All flavors welcome.
Forum rules
Be kind.
Post Reply
User avatar
OpenXTalkPaul
Posts: 1485
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

xTalk Interpretation Differences

Post by OpenXTalkPaul »

Everyone here probably already knows that the original xTalk, HyperCard HyperTalk interpreter was extremely forgiving as far as flagging bad syntax, which most developer people would likely say is a bad thing (one might argue that this is part of why it was an even better xTalk for beginners programming, but I digress).
I've recently discovered that the 'feature' of this looseness that I really miss from HyperTalk's interpretation of xTalk, one that the LCC/OXT engines doesn't (currently) allow, is that it...
Allowed you to replace/override/or otherwise handle built-in messages, commands and functions before they get to 'the engine'!

So for example one could easily handle, let's say the 'play' command, to use their custom 'on play' command script in their stack or library, instead of, or in addition to (va 'pass' keyword), the engine's internal 'play' command. This would allow you to make players for custom data types... maybe .mod file player, or .flac files or whatever type. you could have syntax like
on play pMediaType,pMediaRef
and use it like:
play flac pFLACFilePath or play mod pModFilePath
just as there is...
play audioClip pAudioClip or play vc pMyMoviePath

To me this is THE use case MetaCard's author should have accepted for allowing it.
It's the same use-case as it is in other object-oriented programing (at least in Objective C), you can take a 'class' and make a copy class from it, modifying it into a custom class then get your app to use that instead of the original class, perhaps overriding aspects of the original that was used as the template. The 'class' template in the 'play' example is simply a standard xtalk 'message' type handler. Basically I'm saying internal commands and functions, at least certain very broadly applicable ones like 'play', should betrayed like class objects.
User avatar
richmond62
Posts: 2617
Joined: Sun Sep 12, 2021 11:03 am
Location: Bulgaria
Contact:

Re: xTalk Interpretation Differences

Post by richmond62 »

an even better xTalk for beginners programming
Ah, but you can have too much of a good thing.

If xTalk is regarded as a learner language (and this is not a time for a fight about this) then
allowing sloppiness to a ridiculous extreme may be counter productive in the long run.
https://richmondmathewson.owlstown.net/
User avatar
OpenXTalkPaul
Posts: 1485
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: xTalk Interpretation Differences

Post by OpenXTalkPaul »

richmond62 wrote: Mon Feb 14, 2022 8:27 am
an even better xTalk for beginners programming
Ah, but you can have too much of a good thing.

If xTalk is regarded as a learner language (and this is not a time for a fight about this) then
allowing sloppiness to a ridiculous extreme may be counter productive in the long run.
I said one MIGHT argue that ;-) ... but I'm not going to! One just needs to look at the crazy "Winkler Test" HyperTalk compatibility check from OpenXION author Rebecca Bettencourt to know that this looseness with syntax could be extremely confusing.

https://github.com/kreativekorp/openxio ... nkler-Test

Certainly I think it is good to have SOME reserved words, like 'word' or 'char' should NOT be useable as a variable AND as a keyword the way HyperTalk allowed, but I do think certain keywords, functions or commands like 'play' should be allowed to be overridden by a script author.

I must say that OpenXION has some interesting differences from how MC/RR/LC xTalk's evolved.
I like how you can type variables, if you want/need to, AND at the same time assign them a default value:

Code: Select all

on graph y as string is "sqrt(x)", leftWindow as number is -10, rightWindow as number is 10, ¬
        topWindow as number is 5, bottomWindow as number is -5, ¬
        columnsAvailable as integer is 80, rowsAvailable as integer is 20
And I think it's fantastic that OpenXION has syntax for creating custom objects in memory using create and props get/set defining syntax:

Code: Select all

object type capacitor pl capacitors extends impedor
    to create
        shared frequency as number is 2*pi/60
        shared capacitance as number is zero
    end create
    to get capacitance
        shared capacitance as number
        return capacitance
    end get
    to set capacitance to x
        shared capacitance as number
        put x into capacitance
    end set
    to get impedence
        shared frequency as number
        shared capacitance as number
        return (0,-1/(frequency * capacitance)) as complex
    end get
end capacitor
FourthWorld
Posts: 280
Joined: Sat Sep 11, 2021 4:37 pm
Contact:

Re: xTalk Interpretation Differences

Post by FourthWorld »

OpenXTalkPaul wrote: Sun Feb 13, 2022 11:16 pm I've recently discovered that the 'feature' of this looseness that I really miss from HyperTalk's interpretation of xTalk, one that the LCC/OXT engines doesn't (currently) allow, is that it...
Allowed you to replace/override/or otherwise handle built-in messages, commands and functions before they get to 'the engine'!
Back around '99 I had a long and somewhat passionate advocacy for that very thing with MetaCard's inventor, Dr Scott Raney.

I'll spare you the back-and-forth, and get to the TL/DR:

He reminded me of interoperability, the implications for tools and libraries shared for use in stacks unknown. In such cases, the developer crafts them for engine behavior, and cannot anticipate what may happen when engine behavior is overridden.

Maybe sometimes that turns out useful. But it's not hard to imagine cases where it turns out disastrous.

Along the way it would lengthen the internal token lookup table, adding extra evaluation overhead throughout the message path, and for a feature seldom used.

In cases where custom behavior is useful, a custom name for that clarifies its distinction. Bonus that it keeps the token table lean.

That was his argument, and he left me with an invitation:

Provide him with a use-case where a standard name for custom behavior was necessary and he'd reconsider.

I've never come up with one.
User avatar
OpenXTalkPaul
Posts: 1485
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: xTalk Interpretation Differences

Post by OpenXTalkPaul »

FourthWorld wrote: Sat Feb 19, 2022 3:46 pm
OpenXTalkPaul wrote: Sun Feb 13, 2022 11:16 pm I've recently discovered that the 'feature' of this looseness that I really miss from HyperTalk's interpretation of xTalk, one that the LCC/OXT engines doesn't (currently) allow, is that it...
Allowed you to replace/override/or otherwise handle built-in messages, commands and functions before they get to 'the engine'!
Back around '99 I had a long and somewhat passionate advocacy for that very thing with MetaCard's inventor, Dr Scott Raney.

I'll spare you the back-and-forth, and get to the TL/DR:

He reminded me of interoperability, the implications for tools and libraries shared for use in stacks unknown. In such cases, the developer crafts them for engine behavior, and cannot anticipate what may happen when engine behavior is overridden.

Maybe sometimes that turns out useful. But it's not hard to imagine cases where it turns out disastrous.

Along the way it would lengthen the internal token lookup table, adding extra evaluation overhead throughout the message path, and for a feature seldom used.

In cases where custom behavior is useful, a custom name for that clarifies its distinction. Bonus that it keeps the token table lean.

That was his argument, and he left me with an invitation:

Provide him with a use-case where a standard name for custom behavior was necessary and he'd reconsider.

I've never come up with one.
I actually was reading up on that old debate via ancient Use MetaCard Mail List logs in some mail list archive.
To me this is THE use case MetaCard's author should have accepted for allowing it.
I might have bought the not wanted to 'add to the lexer lookup table' back when 32 Megabytes Ram and a 200 Mhz CPU was a good rig, but not in 2022. Although, I can't understand how it would be any different processing-wise than trapping (and then maybe passing along) any other message ('on OpenCard' for example) as far as the engine is concerned.
And IMO certain keywords should allow for its 'forms' to be overridden, akin to overriding an object's method in OOP'. IMO, the 'PLAY' command in particular, which has been changed in various ways by different xTalks over the years, is a prime example. Play 'some sort of media and/or musical performance data' is really what it should be. 'Play' is such a broadly usable for all sorts of media.
Mind you, I understand that this could be overused, misused, abused and turn very confusing for the stack dev doing that sort of thing, but I'd rather have the option, at least for certain keywords like 'Play'. 'PlayPMD Piano "Cb4q") just doesn't read as nicely as 'Play Piano, Cb4q' does.

I've done some experiments trying to override 'play' with a Extension Builder public 'play' handler. It compiled OK, but didn't intercept the message before the engine did, frontscripts and other library insertion is a no go as well. Oh well.

I've been looking at what various xTalks did with Play and its 'playSentence' form (if they support it at all), so I'd probably try to go with one of those for a 'custom' play command, something like 'playFile (from Oracle Media Objects) myFile' for some alternative media filetypes. For 'playSentence' I've kept UDI's command name: 'PlayPMD' (could stand for Play MIDI Data or playSentence Musical Data).

Additionally, I'd like to have the option for more arbitrary use of the word 'the', just so that I could make an IDE-wide (global) variable such as 'loadedSoundFonts' and then refer to it as 'the loadedSoundFonts', just for 'syntactical sugar' readabilities sake!

Interestingly the engine already ignores multiple 'the's, so you can have a script line like:

Code: Select all

put the the the the the the the the the the the the the the the the commandNames
and it won't throw an error.
User avatar
richmond62
Posts: 2617
Joined: Sun Sep 12, 2021 11:03 am
Location: Bulgaria
Contact:

Re: xTalk Interpretation Differences

Post by richmond62 »

Last time I looked (Um . . . 2002 . . . when developing some educational software in Scotland), RunRev (as then was)
had

Play videoClip and Play AudioClip,

which was very easy indeed.

After LiveCode dumped QuickTime everything went pear-shaped.
https://richmondmathewson.owlstown.net/
User avatar
OpenXTalkPaul
Posts: 1485
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: xTalk Interpretation Differences

Post by OpenXTalkPaul »

richmond62 wrote: Wed Feb 23, 2022 8:18 am Last time I looked (Um . . . 2002 . . . when developing some educational software in Scotland), RunRev (as then was)
had

Play videoClip and Play AudioClip,

which was very easy indeed.

After LiveCode dumped QuickTime everything went pear-shaped.
Yes, they are still in there, but I think the idea was that most scripts would just be using the Player Control for playback going forward (post QT), as opposed to blind playback (no transport controls).
Changes
The use of QuickTime was deprecated in version 8.1. As the play videoClip .. form of the play command was relying on QuickTime, it is no longer supported.
So 'play videoClip' is apparently deprecated as of v8.1, even though it sill works using whatever multimedia API is the standard for a particular platform...On macOS and iOS this is now the AVFoundation (successor to QuickTime), on Windows it's whatever DirectX/DirectShow, and on Linux I believe it's GStreamer(?), on Android it's probably some JAVA JRE APIs. None of these are created equaly and may or may not play the media you want your app to play, depending on things like CODEC availability. For example when using AVFoundation (Mac/iOS) 'play videoClip tFile' will NOT play a MIDI file (and neither will it when using QuickTime 10, as v7 was last version to support MIDI file playback), while the same exact script will play a MIDI file on most Android (99% of Android builds come with Sonivox MIDI playback enabled). On Android/iOS mobile there's "play file tFileOrURL" as well as 'play video' in the dictionary (as opposed to play [ac|audioClip|vc|videoClip] tMediaFile] as well as the mobilePlayerCreate stuff.

Search for 'play' in the dictionary and you'll get a bunch of results, including some deprecated syntax and some related syntax that are only available on certain platforms. For example: set the playDestination to {internal | external}, is only available on Linux. It would be nice expand this to include output device (for things like FireWire or USB sound cards) and jack (Headphone, Line Level, etc.) on all platforms.

Now what if I want to play something completely different from what is supported by the available media API supports, file format such as FLAC, OGG, MOD, XMF, etc.? I CAN NOT intercept the 'play' command to check if a file is in one of these formats and then reroute it to a different API that can handle that particular file format. I have to create a different command named 'playOGG' or something like that instead. Not a big deal I guess, but If I can figure out how/where 'reserved' words are flagged for messages in the C++ source, I may just remove 'play' from that list, and/or 'the' could be ignored globally allowing for its arbitrary use for readability.
Post Reply

Who is online

Users browsing this forum: No registered users and 4 guests